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 3/5] net: Introduce field for the MII time stamper.
Date: Wed, 21 Mar 2018 14:51:51 -0700 [thread overview]
Message-ID: <20180321215151.7x5skyfrpixezmau@localhost> (raw)
In-Reply-To: <cbab700a-8a4f-8c4a-b959-e356de006f6e@gmail.com>
On Wed, Mar 21, 2018 at 12:12:00PM -0700, Florian Fainelli wrote:
> > +static int mdiobus_netdev_notification(struct notifier_block *nb,
> > + unsigned long msg, void *ptr)
> > +{
> > + struct net_device *netdev = netdev_notifier_info_to_dev(ptr);
> > + struct phy_device *phydev = netdev->phydev;
> > + struct mdio_device *mdev;
> > + struct mii_bus *bus;
> > + int i;
> > +
> > + if (netdev->mdiots || msg != NETDEV_UP || !phydev)
> > + return NOTIFY_DONE;
>
> You are still assuming that we have a phy_device somehow, whereas you
> parch series wants to solve that for generic MDIO devices, that is a bit
> confusing.
The phydev is the only thing that associates a netdev with an MII bus.
> > +
> > + /*
> > + * Examine the MII bus associated with the PHY that is
> > + * attached to the MAC. If there is a time stamping device
> > + * on the bus, then connect it to the network device.
> > + */
> > + bus = phydev->mdio.bus;
> > +
> > + for (i = 0; i < PHY_MAX_ADDR; i++) {
> > + mdev = bus->mdio_map[i];
> > + if (!mdev)
> > + continue;
> > + if (mdiodev_supports_timestamping(mdev)) {
> > + netdev->mdiots = mdev;
> > + return NOTIFY_OK;
>
> What guarantees that netdev->mdiots gets cleared?
Why would it need to be cleared?
> Also, why is this done
> with a notifier instead of through phy_{connect,attach,disconnect}?
We have no guarantee the mdio device has been probed yet.
> It
> looks like we still have this requirement of the mdio TS device being a
> phy_device somehow, I am confused here...
We only need the phydev to get from the netdev to the mii bus.
> > + }
> > + }
> > +
> > + return NOTIFY_DONE;
> > +}
> > +
> > #ifdef CONFIG_PM
> > static int mdio_bus_suspend(struct device *dev)
> > {
>
> > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > index 5fbb9f1da7fd..223d691aa0b0 100644
> > --- a/include/linux/netdevice.h
> > +++ b/include/linux/netdevice.h
> > @@ -1943,6 +1943,7 @@ struct net_device {
> > struct netprio_map __rcu *priomap;
> > #endif
> > struct phy_device *phydev;
> > + struct mdio_device *mdiots;
>
> phy_device embedds a mdio_device, can you find a way to rework the PHY
> PTP code to utilize the phy_device's mdio instance so do not introduce
> yet another pointer in that big structure that net_device already is?
It would be strange and wrong to "steal" the phy's mdio struct, IMHO.
After all, we just got support for non-PHY mdio devices. The natural
solution is to use it.
Thanks,
Richard
next prev parent reply other threads:[~2018-03-21 21:51 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 [this message]
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=20180321215151.7x5skyfrpixezmau@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 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).