From: Richard Cochran <richardcochran@gmail.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: netdev@vger.kernel.org, devicetree@vger.kernel.org,
Andrew Lunn <andrew@lunn.ch>, David Miller <davem@davemloft.net>,
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 2/5] net: phy: Move time stamping interface into the generic mdio layer.
Date: Sat, 24 Mar 2018 09:59:11 -0700 [thread overview]
Message-ID: <20180324165911.m34hxpyaszmxvi4p@localhost> (raw)
In-Reply-To: <20180321214513.5kkw4qpbhp3juxur@localhost>
On Wed, Mar 21, 2018 at 02:45:13PM -0700, Richard Cochran wrote:
> On Wed, Mar 21, 2018 at 12:10:07PM -0700, Florian Fainelli wrote:
> > > + phydev->mdio.ts_info = dp83640_ts_info;
> > > + phydev->mdio.hwtstamp = dp83640_hwtstamp;
> > > + phydev->mdio.rxtstamp = dp83640_rxtstamp;
> > > + phydev->mdio.txtstamp = dp83640_txtstamp;
> >
> > Why is this implemented a the mdio_device level and not at the
> > mdio_driver level? This looks like the wrong level at which this is done.
>
> The question could be asked of:
>
> struct mdio_device {
> int (*bus_match)(struct device *dev, struct device_driver *drv);
> void (*device_free)(struct mdio_device *mdiodev);
> void (*device_remove)(struct mdio_device *mdiodev);
> }
>
> I saw how this is done for the phy, etc, but I don't see any benefit
> of doing it that way. It would add an extra layer (or two) of
> indirection and save the space four pointer functions. Is that
> trade-off worth it?
Actually, there was another reason not to put these methods into the
driver structure. In contrast to phy_device, mdio_device doesn't have
a pointer to the driver structure. It looks like there is no way to
start from a mdio_device and get to a mdio_driver. Please correct me
if I'm wrong.
I propose keeping those methods in the mdio_device, wrapping them in
#ifdef CONFIG_NETWORK_PHY_TIMESTAMPING. That way, they do not add any
burden to the vast majority of users.
Thoughts?
Thanks,
Richard
next prev parent reply other threads:[~2018-03-24 16:59 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 [this message]
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
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=20180324165911.m34hxpyaszmxvi4p@localhost \
--to=richardcochran@gmail.com \
--cc=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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.