SET_NETDEV_DEV -> 83xx HDLC Driver??

SET_NETDEV_DEV -> 83xx HDLC Driver??

[Russell McGuire]

All,

I am partly done porting a combination of the 83xx ATM driver and dscc4 HDLC
driver into a 83xx HDLC driver.

However, encounter a call I don't truly understand.

SET_NETDEV_DEV(dev, pointer_to_some_handle);

I can see plenty of examples of this registering some kind of PCI device
handle, however in this case I am not using a PCI device. So what should the
pointer be? Or can this call be ignored, and if so what are the
consequences?

I see the some of the Freescale Ethernet devices don't use this call.

Anyway, can somebody shed some light on if I am going to need this, or a way
to get it to work, without creating a PCI device?

-Russ

Re: SET_NETDEV_DEV -> 83xx HDLC Driver??

[Andy Fleming]

On Jan 25, 2008, at 20:43, Russell McGuire wrote:

> All,
>
> I am partly done porting a combination of the 83xx ATM driver and  
> dscc4 HDLC
> driver into a 83xx HDLC driver.
>
> However, encounter a call I don't truly understand.
>
> SET_NETDEV_DEV(dev, pointer_to_some_handle);
>
> I can see plenty of examples of this registering some kind of PCI  
> device
> handle, however in this case I am not using a PCI device. So what  
> should the
> pointer be? Or can this call be ignored, and if so what are the
> consequences?
>
> I see the some of the Freescale Ethernet devices don't use this call.
>
> Anyway, can somebody shed some light on if I am going to need this,  
> or a way
> to get it to work, without creating a PCI device?


Look at gianfar.c (which uses a platform_device) or ucc_geth (which  
uses an of_device).  Which freescale devices don't use that call?   
We'll fix them.

Andy

RE: SET_NETDEV_DEV -> 83xx HDLC Driver??

[Russell McGuire]

Andy,

/drivers/net/fec_8xx

Doesn't use the call, though I imagine it is legacy or only for older
boards.

Thanks for pointing me at the newer stuff, guess I had a brain cramp and
didn't think to look there. Also makes much more sense now that the 
pdev->dev is not a PCI device but a Platform device.

One question, since you've probably got more experience with this than I do.

The gianfar, and ucc_geth drivers are not modules. Is there a problem with
using these driver _probe_ functions in a module style driver? OR should I
just change my driver over to be a platform style?

As far as I can tell the HDLC driver I am trying to create for the 83xx is
going to be somewhat similar to the Ethernet driver. Only I don't want it
loaded as part of the kernel.

-Russ

> -----Original Message-----
> From: Andy Fleming [mailto:afleming@freescale.com]
> Sent: Tuesday, January 29, 2008 2:33 PM
> To: rmcguire@videopresence.com
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: SET_NETDEV_DEV -> 83xx HDLC Driver??
> 
> 
> On Jan 25, 2008, at 20:43, Russell McGuire wrote:
> 
> > All,
> >
> > I am partly done porting a combination of the 83xx ATM driver and
> > dscc4 HDLC
> > driver into a 83xx HDLC driver.
> >
> > However, encounter a call I don't truly understand.
> >
> > SET_NETDEV_DEV(dev, pointer_to_some_handle);
> >
> > I can see plenty of examples of this registering some kind of PCI
> > device
> > handle, however in this case I am not using a PCI device. So what
> > should the
> > pointer be? Or can this call be ignored, and if so what are the
> > consequences?
> >
> > I see the some of the Freescale Ethernet devices don't use this call.
> >
> > Anyway, can somebody shed some light on if I am going to need this,
> > or a way
> > to get it to work, without creating a PCI device?
> 
> 
> Look at gianfar.c (which uses a platform_device) or ucc_geth (which
> uses an of_device).  Which freescale devices don't use that call?
> We'll fix them.
> 
> Andy

Re: SET_NETDEV_DEV -> 83xx HDLC Driver??

[Scott Wood]

Russell McGuire wrote:
> Andy,
> 
> /drivers/net/fec_8xx
> 
> Doesn't use the call, though I imagine it is legacy or only for older
> boards.

I don't think it's used on anything, actually.  drivers/net/fs_enet is 
the driver for 8xx fec.

-Scott

83xx HDLC Driver Dev - Multiple PHYs?

[Russell McGuire]

All,

I have gotten my HDLC driver up to the point where it can register itself
with the Linux kernel. However now I am faced with a dilemma and style
question, that is probably best answered by you driver developers that have
more experience.

I am putting support for multiple PHY's into the HDLC driver, but after
converting it to use the of_device tree, and inserting a UCC@5000 for a
single UCC HDLC driver, it occurred to me that if I insert more devices
(UCC@6000, UCC@7000, UCC@8000) that the driver will attempt to load multiple
times.

So here is the question.

Solution 1:
Should I develop the system to have a single ucc@xxxx entry in the
platform.dts file and have a field(s) like phy-count=<4>, to support
multiple devices? And have each instance of the module contain private data
for one UCC, interrupt handling, etc...  

OR

Solution 2:
Is there a way to have a module know if it has already been loaded, so it
doesn't insert multiple times and then play the rest like Solution 3?

OR

Solution 3:
Have phy-count=4; defined in the driver header, or a module parameter, and
have a single module instance of the driver itself responsible for creating
a single private data structure and setting up multiple UCC's and PHY's?

This also feeds into a question on SET_NETDEV_DEV. How does it react to
multiple net devices attached to a single base driver?

-Russ

> -----Original Message-----
> From: Andy Fleming [mailto:afleming@freescale.com]
> Sent: Tuesday, January 29, 2008 2:33 PM
> To: rmcguire@videopresence.com
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: SET_NETDEV_DEV -> 83xx HDLC Driver??
> 
> 
> On Jan 25, 2008, at 20:43, Russell McGuire wrote:
> 
> > All,
> >
> > I am partly done porting a combination of the 83xx ATM driver and
> > dscc4 HDLC
> > driver into a 83xx HDLC driver.
> >
> > However, encounter a call I don't truly understand.
> >
> > SET_NETDEV_DEV(dev, pointer_to_some_handle);
> >
> > I can see plenty of examples of this registering some kind of PCI
> > device
> > handle, however in this case I am not using a PCI device. So what
> > should the
> > pointer be? Or can this call be ignored, and if so what are the
> > consequences?
> >
> > I see the some of the Freescale Ethernet devices don't use this call.
> >
> > Anyway, can somebody shed some light on if I am going to need this,
> > or a way
> > to get it to work, without creating a PCI device?
> 
> 
> Look at gianfar.c (which uses a platform_device) or ucc_geth (which
> uses an of_device).  Which freescale devices don't use that call?
> We'll fix them.
> 
> Andy

Re: 83xx HDLC Driver Dev - Multiple PHYs?

[Jochen Friedrich]

Hi Russell,

> I am putting support for multiple PHY's into the HDLC driver, but after
> converting it to use the of_device tree, and inserting a UCC@5000 for a
> single UCC HDLC driver, it occurred to me that if I insert more devices
> (UCC@6000, UCC@7000, UCC@8000) that the driver will attempt to load multiple
> times.

The module should only be loaded once. If the driver attempts to load multiple
times, this looks like a userscpace bug.

Thanks,
Jochen

Re: 83xx HDLC Driver Dev - Multiple PHYs?

[Andy Fleming]

On Jan 29, 2008, at 23:10, Russell McGuire wrote:

>
> All,
>
> I have gotten my HDLC driver up to the point where it can register  
> itself
> with the Linux kernel. However now I am faced with a dilemma and style
> question, that is probably best answered by you driver developers  
> that have
> more experience.
>
> I am putting support for multiple PHY's into the HDLC driver, but  
> after
> converting it to use the of_device tree, and inserting a UCC@5000  
> for a
> single UCC HDLC driver, it occurred to me that if I insert more  
> devices
> (UCC@6000, UCC@7000, UCC@8000) that the driver will attempt to load  
> multiple
> times.

There is already a mechanism to ensure modules aren't loaded again  
when a new device is found.  Look at the gianfar support again.  The  
mpc8548 CDS has 4 eTSEC devices and one driver which handles them all  
(gianfar).  The driver is initialized once.  The probe function will  
be called for each instance of the device.  You need to make sure  
your driver's probe function can be called once per device.

>
> Solution 3:
> Have phy-count=4; defined in the driver header, or a module  
> parameter, and
> have a single module instance of the driver itself responsible for  
> creating
> a single private data structure and setting up multiple UCC's and  
> PHY's?

No, please.  If the PHYs aren't discoverable, you might need  
something like that.  But I suspect you just have one PHY per  
device.  If you have more, how is that configured?  Is the hardware  
aware of the number of PHYs?  Or are you just selecting between  
different PHY addresses?

>
> This also feeds into a question on SET_NETDEV_DEV. How does it  
> react to
> multiple net devices attached to a single base driver?

SET_NETDEV_DEV declares the base *device* of the net device.  The  
driver is a separate issue.  And it shouldn't be a problem, because  
each device instance has its own private structure.

Andy