From: Andrew Lunn <andrew@lunn.ch>
To: Richard Cochran <richardcochran@gmail.com>
Cc: netdev@vger.kernel.org, devicetree@vger.kernel.org,
David Miller <davem@davemloft.net>,
Florian Fainelli <f.fainelli@gmail.com>,
Mark Rutland <mark.rutland@arm.com>,
Miroslav Lichvar <mlichvar@redhat.com>,
Rob Herring <robh+dt@kernel.org>,
Willem de Bruijn <willemb@google.com>
Subject: Re: [PATCH net-next RFC V1 5/5] net: mdio: Add a driver for InES time stamping IP core.
Date: Thu, 22 Mar 2018 00:50:07 +0100 [thread overview]
Message-ID: <20180321235007.GA28402@lunn.ch> (raw)
In-Reply-To: <20180321224702.cbcq3wckmojsrgjf@localhost>
On Wed, Mar 21, 2018 at 03:47:02PM -0700, Richard Cochran wrote:
> On Wed, Mar 21, 2018 at 11:16:52PM +0100, Andrew Lunn wrote:
> > The MAC drivers are clients of this device. They then use a phandle
> > and specifier:
> >
> > eth0: ethernet-controller@72000 {
> > compatible = "marvell,kirkwood-eth";
> > #address-cells = <1>;
> > #size-cells = <0>;
> > reg = <0x72000 0x4000>;
> >
> > timerstamper = <×tamper 2>
> > }
> >
> > The 2 indicates this MAC is using port 2.
> >
> > The MAC driver can then do the standard device tree things to follow
> > the phandle to get access to the device and use the API it exports.
>
> But that would require hacking every last MAC driver.
>
> I happy to improve the modeling, but the solution should be generic
> and work for every MAC driver.
Well, the solution is generic, in that the phandle can point to a
device anywhere. It could be MMIO, it could be on an MDIO bus,
etc. You just need to make sure you API makes no assumption about how
the device driver talks to the hardware.
How clever is this device? Can it tell the difference between
1000Base-X and SGMII? Can it figure out that the MAC is repeating
every bit 100 times and so has dropped to 10Mbits? Does it understand
EEE? Does it need to know if RGMII or RGMII-ID is being used?
Can such a device really operation without the MAC being involved? My
feeling is it needs to understand how the MII bus is being used. It
might also be that the device is less capable than the MAC, so you
need to turn off some of the MAC features. I think you are going to
need the MAC actively involved in this.
Andrew
next prev parent reply other threads:[~2018-03-21 23:50 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-21 18:58 [PATCH net-next RFC V1 0/5] Peer to Peer One-Step time stamping Richard Cochran
2018-03-21 18:58 ` [PATCH net-next RFC V1 1/5] net: Introduce peer to peer one step PTP " Richard Cochran
2018-03-21 20:05 ` Keller, Jacob E
2018-03-21 21:26 ` Richard Cochran
2018-03-21 23:51 ` Keller, Jacob E
2018-03-21 18:58 ` [PATCH net-next RFC V1 2/5] net: phy: Move time stamping interface into the generic mdio layer Richard Cochran
2018-03-21 19:10 ` Florian Fainelli
2018-03-21 21:45 ` Richard Cochran
2018-03-24 16:59 ` Richard Cochran
2018-03-21 18:58 ` [PATCH net-next RFC V1 3/5] net: Introduce field for the MII time stamper Richard Cochran
2018-03-21 19:12 ` Florian Fainelli
2018-03-21 21:51 ` Richard Cochran
2018-03-24 17:01 ` Richard Cochran
2018-03-21 18:58 ` [PATCH net-next RFC V1 4/5] net: Use the generic MII time stamper when available Richard Cochran
2018-03-21 18:58 ` [PATCH net-next RFC V1 5/5] net: mdio: Add a driver for InES time stamping IP core Richard Cochran
2018-03-21 19:33 ` Andrew Lunn
2018-03-21 21:36 ` Richard Cochran
2018-03-21 21:44 ` Andrew Lunn
2018-03-21 21:57 ` Richard Cochran
2018-03-21 22:16 ` Andrew Lunn
2018-03-21 22:47 ` Richard Cochran
2018-03-21 23:50 ` Andrew Lunn [this message]
2018-03-24 17:12 ` Richard Cochran
2018-03-24 18:48 ` Andrew Lunn
2018-03-25 4:51 ` Richard Cochran
2018-03-25 15:59 ` Andrew Lunn
2018-03-25 22:10 ` Richard Cochran
2018-03-25 23:01 ` Florian Fainelli
2018-04-03 3:55 ` Richard Cochran
2018-04-03 13:13 ` Andrew Lunn
2018-04-03 15:02 ` Richard Cochran
2018-03-25 23:01 ` Andrew Lunn
2018-04-03 4:27 ` Richard Cochran
2018-03-25 23:06 ` Andrew Lunn
2018-03-25 22:14 ` Richard Cochran
2018-03-22 0:43 ` Andrew Lunn
2018-03-22 1:57 ` Richard Cochran
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180321235007.GA28402@lunn.ch \
--to=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=f.fainelli@gmail.com \
--cc=mark.rutland@arm.com \
--cc=mlichvar@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=richardcochran@gmail.com \
--cc=robh+dt@kernel.org \
--cc=willemb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).