SMSC 8720a/MDIO/PHY help.

SMSC 8720a/MDIO/PHY help.

[ANDY KENNEDY]

I have written my MDIO driver, registered it via mdiobus_register(), and
have verified that the SCMS LAN8710 driver picks it up (via sysfs).
What am I missing?  The state machine never starts.  I get no runs,
hits, or errors (and nobody left -- it is baseball season after all).

If you have an idea of something for me to try, I'd love to entertain
it.

Thanks,
Andy

Re: SMSC 8720a/MDIO/PHY help.

[Michael Riesch]

> If you have an idea of something for me to try, I'd love to entertain
> it.

I am rather new to PHYLIB, but these are my ideas:

 1) make sure phy_connect is executed (AFIAK called by MDIO bus driver)

 2) maybe you need to call phy_start / phy_stop (AFAIK from the PHY
driver's open / close function)

HTH,
Michael

RE: SMSC 8720a/MDIO/PHY help.

[ANDY KENNEDY]

> -----Original Message-----
> From: Michael Riesch [mailto:michael@riesch.at]
> Sent: Wednesday, April 13, 2011 4:19 PM
> To: netdev@vger.kernel.org
> Cc: ANDY KENNEDY
> Subject: Re: SMSC 8720a/MDIO/PHY help.
> 
> 
> > If you have an idea of something for me to try, I'd love to
> entertain
> > it.
> 
> I am rather new to PHYLIB, but these are my ideas:
> 
>  1) make sure phy_connect is executed (AFIAK called by MDIO bus
> driver)

Going through the phy.txt doc under Documentation/networking:
PHY Abstraction Layer
(Updated 2008-04-08)
though it may be a bit out-of-date, I did see what you are talking about.  What I'm hung up on at the moment is the behavior of adjust_link().  It appears that I only need to start the queues, though I don’t know.

> 
>  2) maybe you need to call phy_start / phy_stop (AFAIK from the PHY
> driver's open / close function)

Currently, when I do this I only get the call to adjust_link() over and over again.

> 
> HTH,
> Michael

Thanks for the help!

Andy

RE: SMSC 8720a/MDIO/PHY help.

[ANDY KENNEDY]

> > -----Original Message-----
> > From: Michael Riesch [mailto:michael@riesch.at]
> > Sent: Wednesday, April 13, 2011 4:19 PM
> > To: netdev@vger.kernel.org
> > Cc: ANDY KENNEDY
> > Subject: Re: SMSC 8720a/MDIO/PHY help.
> >
> >
> > > If you have an idea of something for me to try, I'd love to
> > entertain
> > > it.
> >
> > I am rather new to PHYLIB, but these are my ideas:
> >
> >  1) make sure phy_connect is executed (AFIAK called by MDIO bus
> > driver)

Along this line of though:  phy_connect requires struct net_device, which has a struct net_device_ops within it.  When I do a phy_connect am I supposed to provide the minimal functions for netdev_ops (correct this list if I am mistaken):
ndo_open
ndo_stop
ndo_start_xmit
ndo_get_stats
ndo_set_multicast_list
As well as populate the dev->dev_addr within the struct net_device.

The part that confuses me is that the smsc.c ??driver?? under drivers/net/phy/smsc.c doesn’t do any of this.  This is a phy supported by this file, so should I have to do all this to get the device up?

Spinning,
Andy

RE: SMSC 8720a/MDIO/PHY help.

[Michael Riesch]

> 
> Along this line of though:  phy_connect requires struct net_device, which has a struct net_device_ops within it.  When I do a phy_connect am I supposed to provide the minimal functions for netdev_ops (correct this list if I am mistaken):
> ndo_open
> ndo_stop
> ndo_start_xmit
> ndo_get_stats
> ndo_set_multicast_list
> As well as populate the dev->dev_addr within the struct net_device.
> 
> The part that confuses me is that the smsc.c ??driver?? under drivers/net/phy/smsc.c doesn’t do any of this.  This is a phy supported by this file, so should I have to do all this to get the device up?

The smsc.c is a PHY driver, so it is probed when the specified PHY
appears on the MDIO bus. It is responsible for the proper PHY settings
like auto-negotiation etc.

If I understood you correctly, you are writing a MDIO bus driver, the
opposite part. It provides access to the MDIO bus, the net_device
structure with its ops (and, of course, implements them as well).

With a call of PHY_connect you can stick the both of them together. And
the nice trick: Maybe your PHY is supported by the generic PHY driver
and you just need your MDIO bus driver, which provides the net_device
ops, registers the MDIO bus and calls phy_connect. (and maybe
phy_start(), I am not sure about that one).

HTH

Re: SMSC 8720a/MDIO/PHY help.

[Andy Fleming]

On Wed, Apr 13, 2011 at 11:08 PM, ANDY KENNEDY <ANDY.KENNEDY@adtran.com> wrote:
>> > -----Original Message-----
>> > From: Michael Riesch [mailto:michael@riesch.at]
>> > Sent: Wednesday, April 13, 2011 4:19 PM
>> > To: netdev@vger.kernel.org
>> > Cc: ANDY KENNEDY
>> > Subject: Re: SMSC 8720a/MDIO/PHY help.
>> >
>> >
>> > > If you have an idea of something for me to try, I'd love to
>> > entertain
>> > > it.
>> >
>> > I am rather new to PHYLIB, but these are my ideas:
>> >
>> >  1) make sure phy_connect is executed (AFIAK called by MDIO bus
>> > driver)
>
> Along this line of though:  phy_connect requires struct net_device, which has a struct net_device_ops within it.  When I do a phy_connect am I supposed to provide the minimal functions for netdev_ops (correct this list if I am mistaken):
> ndo_open
> ndo_stop
> ndo_start_xmit
> ndo_get_stats
> ndo_set_multicast_list
> As well as populate the dev->dev_addr within the struct net_device.
>
> The part that confuses me is that the smsc.c ??driver?? under drivers/net/phy/smsc.c doesn’t do any of this.  This is a phy supported by this file, so should I have to do all this to get the device up?


Hmm....where are you calling phy_connect from?  phy_connect() is
called from a net_device driver, to connect the net device to the PHY.
The net_device should be filled in by the net driver. The PHY Lib
doesn't use the struct net_device * itself.  It merely passes that
structure to the registered adjust_link() callback, as context.

We could theoretically make the net_device a void *, and let the
caller of phy_connect() determine its own context, but that didn't
seem necessary at the time.  It also might make sense for
adjust_link() to pass the struct phy_device.

But those are all just possible enhancements for the future.

Andy

Re: SMSC 8720a/MDIO/PHY help.

[Andy Fleming]

On Wed, Apr 13, 2011 at 4:38 PM, ANDY KENNEDY <ANDY.KENNEDY@adtran.com> wrote:
>> -----Original Message-----
>> From: Michael Riesch [mailto:michael@riesch.at]
>> Sent: Wednesday, April 13, 2011 4:19 PM
>> To: netdev@vger.kernel.org
>> Cc: ANDY KENNEDY
>> Subject: Re: SMSC 8720a/MDIO/PHY help.
>>
>>
>> > If you have an idea of something for me to try, I'd love to
>> entertain
>> > it.
>>
>> I am rather new to PHYLIB, but these are my ideas:
>>
>>  1) make sure phy_connect is executed (AFIAK called by MDIO bus
>> driver)
>
> Going through the phy.txt doc under Documentation/networking:
> PHY Abstraction Layer
> (Updated 2008-04-08)
> though it may be a bit out-of-date, I did see what you are talking about.  What I'm hung up on at the moment is the behavior of adjust_link().  It appears that I only need to start the queues, though I don’t know.
>
>>
>>  2) maybe you need to call phy_start / phy_stop (AFAIK from the PHY
>> driver's open / close function)
>
> Currently, when I do this I only get the call to adjust_link() over and over again.


...this means that the state machine is running.  The PHY is polling
every couple seconds to report the current state. It calls
adjust_link() to keep the net_device up-to-date on that state. What
other behavior are you expecting to see?


Andy

RE: SMSC 8720a/MDIO/PHY help.

[ANDY KENNEDY]

> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Andy Fleming
> Sent: Friday, April 15, 2011 3:30 PM
> To: ANDY KENNEDY
> Cc: michael@riesch.at; netdev@vger.kernel.org
> Subject: Re: SMSC 8720a/MDIO/PHY help.
> 
> On Wed, Apr 13, 2011 at 4:38 PM, ANDY KENNEDY
> <ANDY.KENNEDY@adtran.com> wrote:
> >> -----Original Message-----
> >> From: Michael Riesch [mailto:michael@riesch.at]
> >> Sent: Wednesday, April 13, 2011 4:19 PM
> >> To: netdev@vger.kernel.org
> >> Cc: ANDY KENNEDY
> >> Subject: Re: SMSC 8720a/MDIO/PHY help.
> >>
> >>
> >> > If you have an idea of something for me to try, I'd love to
> >> entertain
> >> > it.
> >>
> >> I am rather new to PHYLIB, but these are my ideas:
> >>
> >>  1) make sure phy_connect is executed (AFIAK called by MDIO bus
> >> driver)
> >
> > Going through the phy.txt doc under Documentation/networking:
> > PHY Abstraction Layer
> > (Updated 2008-04-08)
> > though it may be a bit out-of-date, I did see what you are
> talking about.  What I'm hung up on at the moment is the behavior
> of adjust_link().  It appears that I only need to start the queues,
> though I don't know.
> >
> >>
> >>  2) maybe you need to call phy_start / phy_stop (AFAIK from the
> PHY
> >> driver's open / close function)
> >
> > Currently, when I do this I only get the call to adjust_link()
> over and over again.
> 
> 
> ...this means that the state machine is running.  The PHY is
> polling
> every couple seconds to report the current state. It calls
> adjust_link() to keep the net_device up-to-date on that state. What
> other behavior are you expecting to see?

Well, you see I was expecting it to be up and running at that point (to be able to assign an IP, pass traffic, etc) -- but that is due to ignorance of (1) network device drivers, (2) PHY device drivers, (3) MDIO bus drivers, (4) General level 2 networking, (5) ;) get the point?

See, I'm totally new to networking (at this level).  Device drivers, yes, but not networking.

Though, after Michael's e-mails, I have discovered that I have to
1) Make the MDIO bus work
2) Establish communications with the MDIO driver (in this case smsc.c under net/phy)
3) Make all my NDO required functions for controlling the "real" network device -- I was unaware that the PHY _WASN'T_ the network device.
4) Call phy_connect_direct (so I don't trash the already existent smsc.c as before stated)
5) Finally, after the NDO functions are written, register the NDO with the networking layer of the Kernel.

One thing I have done wrong (realized AFTER depending upon the work I've done) is that I should have split out the MDIO and the network device.  

Now, where is the document that explains all this.  The PHY document is very informative, however, if you don't know that a PHY is NOT a network device, you're kinda outta luck.  Even Wiki reports a PHY as the Physical Link layer of the OSI model.  Which, again, doesn't tell the ignorant much.

I have a bit more knowledge now, however, and I think I've about got my network device up (that would be I'm only 80% ignorant now ;).

Andy

Re: SMSC 8720a/MDIO/PHY help.

[Andy Fleming]

On Fri, Apr 15, 2011 at 3:53 PM, ANDY KENNEDY <ANDY.KENNEDY@adtran.com> wrote:
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org [mailto:netdev-
>> owner@vger.kernel.org] On Behalf Of Andy Fleming
>> Sent: Friday, April 15, 2011 3:30 PM
>> To: ANDY KENNEDY
>> Cc: michael@riesch.at; netdev@vger.kernel.org
>> Subject: Re: SMSC 8720a/MDIO/PHY help.
>>
>> On Wed, Apr 13, 2011 at 4:38 PM, ANDY KENNEDY
>> <ANDY.KENNEDY@adtran.com> wrote:
>> >> -----Original Message-----
>> >> From: Michael Riesch [mailto:michael@riesch.at]
>> >> Sent: Wednesday, April 13, 2011 4:19 PM
>> >> To: netdev@vger.kernel.org
>> >> Cc: ANDY KENNEDY
>> >> Subject: Re: SMSC 8720a/MDIO/PHY help.
>> >>
>> >>
>> >> > If you have an idea of something for me to try, I'd love to
>> >> entertain
>> >> > it.
>> >>
>> >> I am rather new to PHYLIB, but these are my ideas:
>> >>
>> >>  1) make sure phy_connect is executed (AFIAK called by MDIO bus
>> >> driver)
>> >
>> > Going through the phy.txt doc under Documentation/networking:
>> > PHY Abstraction Layer
>> > (Updated 2008-04-08)
>> > though it may be a bit out-of-date, I did see what you are
>> talking about.  What I'm hung up on at the moment is the behavior
>> of adjust_link().  It appears that I only need to start the queues,
>> though I don't know.
>> >
>> >>
>> >>  2) maybe you need to call phy_start / phy_stop (AFAIK from the
>> PHY
>> >> driver's open / close function)
>> >
>> > Currently, when I do this I only get the call to adjust_link()
>> over and over again.
>>
>>
>> ...this means that the state machine is running.  The PHY is
>> polling
>> every couple seconds to report the current state. It calls
>> adjust_link() to keep the net_device up-to-date on that state. What
>> other behavior are you expecting to see?
>
> Well, you see I was expecting it to be up and running at that point (to be able to assign an IP, pass traffic, etc) -- but that is due to ignorance of (1) network device drivers, (2) PHY device drivers, (3) MDIO bus drivers, (4) General level 2 networking, (5) ;) get the point?
>
> See, I'm totally new to networking (at this level).  Device drivers, yes, but not networking.
>
> Though, after Michael's e-mails, I have discovered that I have to
> 1) Make the MDIO bus work
> 2) Establish communications with the MDIO driver (in this case smsc.c under net/phy)
> 3) Make all my NDO required functions for controlling the "real" network device -- I was unaware that the PHY _WASN'T_ the network device.
> 4) Call phy_connect_direct (so I don't trash the already existent smsc.c as before stated)
> 5) Finally, after the NDO functions are written, register the NDO with the networking layer of the Kernel.
>
> One thing I have done wrong (realized AFTER depending upon the work I've done) is that I should have split out the MDIO and the network device.
>
> Now, where is the document that explains all this.  The PHY document is very informative, however, if you don't know that a PHY is NOT a network device, you're kinda outta luck.  Even Wiki reports a PHY as the Physical Link layer of the OSI model.  Which, again, doesn't tell the ignorant much.


Take a look at Documentation/networking/netdevices.txt

Also grep around in drivers/net to see networking drivers that have
been ported to use phylib (look for phy_connect or phy_attach).

RE: SMSC 8720a/MDIO/PHY help.

[ANDY KENNEDY]

> -----Original Message-----
> From: Andy Fleming [mailto:afleming@gmail.com]
> Sent: Friday, April 15, 2011 4:02 PM
> To: ANDY KENNEDY
> Cc: michael@riesch.at; netdev@vger.kernel.org
> Subject: Re: SMSC 8720a/MDIO/PHY help.
> > Now, where is the document that explains all this.  The PHY
> document is very informative, however, if you don't know that a PHY
> is NOT a network device, you're kinda outta luck.  Even Wiki
> reports a PHY as the Physical Link layer of the OSI model.  Which,
> again, doesn't tell the ignorant much.
> 
> 
> Take a look at Documentation/networking/netdevices.txt
> 
> Also grep around in drivers/net to see networking drivers that have
> been ported to use phylib (look for phy_connect or phy_attach).

That's pretty much what I did.  After that, I was able (using my function stubs) to do an ifconfig eth0 and see that at least the kernel assigned my IP address to the device (though nothing else worked, but that was further than I was getting).

Like I said, I'm not completely ignorant anymore.  I look forward to the day (perhaps Monday) when I'm only half ignorant ;).

Thanks for your help!

Andy