Platform device model drawback

Platform device model drawback

[Vitaly Bordug]

Hi, Greg!

While doing "platformization" for one of the Freescale SoC's, I have 
discovered a serious drawback of the model - it prevents registering 
driver with the same name.

For instance, cpm2 on either ppc82xx or ppc85xx is very flexible, and 
its device fsl-cpm-scc could (and actually are) utilized in the 
different drivers.

Those devices will have different bus_id, but pdev->name fields are the 
same for all the fsl-cpm-scc, only id is different there. Hence the 
fsl-cpm-scc could be driver_register'ed only once, while it is required 
several times.

Could you please suggest possible solutions for this situation? This is 
relatively common case among freescale chips, so I guess inventing a 
workaround is odd, and writing an additional shim to handle CPM device 
multiplexing  is odd either.

TIA!
--
Sincerely,
Vitaly

Re: Platform device model drawback

[Greg KH]

On Tue, Nov 15, 2005 at 07:51:20PM +0300, Vitaly Bordug wrote:
> Hi, Greg!
> 
> While doing "platformization" for one of the Freescale SoC's, I have 
> discovered a serious drawback of the model - it prevents registering 
> driver with the same name.

That's not a "drawback" :)

> For instance, cpm2 on either ppc82xx or ppc85xx is very flexible, and 
> its device fsl-cpm-scc could (and actually are) utilized in the 
> different drivers.
> 
> Those devices will have different bus_id, but pdev->name fields are the 
> same for all the fsl-cpm-scc, only id is different there. Hence the 
> fsl-cpm-scc could be driver_register'ed only once, while it is required 
> several times.

A driver is registered only once, but can be bound to multiple devices
just fine, right?

> Could you please suggest possible solutions for this situation? This is 
> relatively common case among freescale chips, so I guess inventing a 
> workaround is odd, and writing an additional shim to handle CPM device 
> multiplexing  is odd either.

I don't see the problem here.  Are you looking at the new stuff in
2.6.15-rc1?

thanks,

greg k-h

Re: Platform device model drawback

[Vitaly Bordug]

Greg KH wrote:
> On Tue, Nov 15, 2005 at 07:51:20PM +0300, Vitaly Bordug wrote:
>> Hi, Greg!
>>
>> While doing "platformization" for one of the Freescale SoC's, I have 
>> discovered a serious drawback of the model - it prevents registering 
>> driver with the same name.
> 
> That's not a "drawback" :)
> 
>> For instance, cpm2 on either ppc82xx or ppc85xx is very flexible, and 
>> its device fsl-cpm-scc could (and actually are) utilized in the 
>> different drivers.
>>
>> Those devices will have different bus_id, but pdev->name fields are the 
>> same for all the fsl-cpm-scc, only id is different there. Hence the 
>> fsl-cpm-scc could be driver_register'ed only once, while it is required 
>> several times.
> 
> A driver is registered only once, but can be bound to multiple devices
> just fine, right?
Please let me know, how?

I have for instance struct device_driver with name="fsl-cpm-scc" in both fs_enet and 
cpm_uart(one using SCC1, the other - SCC4, the same device with different id's).

Once it has been registered in fs_enet, I could not register it in cpm_uart, due to 
kobject_register fo require unique names in kobject->name. Am I missing something?

Not registering it in CPM_UART, how the pdev could be obtained?

Maybe this is clear, but platform stuff is cumbersome some times...
> 
>> Could you please suggest possible solutions for this situation? This is 
>> relatively common case among freescale chips, so I guess inventing a 
>> workaround is odd, and writing an additional shim to handle CPM device 
>> multiplexing  is odd either.
> 
> I don't see the problem here.  Are you looking at the new stuff in
> 2.6.15-rc1?
> 
Yes, sort of. I am going to add 8xx IRDA and make cpm_uart platform device model compatible.
> thanks,
> 
> greg k-h
> 
> 


-- 
Sincerely,
Vitaly

Re: Platform device model drawback

[Greg KH]

On Tue, Nov 15, 2005 at 08:59:06PM +0300, Vitaly Bordug wrote:
> Greg KH wrote:
> >On Tue, Nov 15, 2005 at 07:51:20PM +0300, Vitaly Bordug wrote:
> >>Hi, Greg!
> >>
> >>While doing "platformization" for one of the Freescale SoC's, I have 
> >>discovered a serious drawback of the model - it prevents registering 
> >>driver with the same name.
> >
> >That's not a "drawback" :)
> >
> >>For instance, cpm2 on either ppc82xx or ppc85xx is very flexible, and 
> >>its device fsl-cpm-scc could (and actually are) utilized in the 
> >>different drivers.
> >>
> >>Those devices will have different bus_id, but pdev->name fields are the 
> >>same for all the fsl-cpm-scc, only id is different there. Hence the 
> >>fsl-cpm-scc could be driver_register'ed only once, while it is required 
> >>several times.
> >
> >A driver is registered only once, but can be bound to multiple devices
> >just fine, right?
> Please let me know, how?

All PCI and USB and I2C drivers are able to bind to multiple devices :)

> I have for instance struct device_driver with name="fsl-cpm-scc" in both 
> fs_enet and cpm_uart(one using SCC1, the other - SCC4, the same device with 
> different id's).
> 
> Once it has been registered in fs_enet, I could not register it in 
> cpm_uart, due to kobject_register fo require unique names in kobject->name. 
> Am I missing something?

You only register the driver once.  The individual devices can be bound
to the same driver, right?

> Not registering it in CPM_UART, how the pdev could be obtained?
> 
> Maybe this is clear, but platform stuff is cumbersome some times...

Then make it cleaner :)

If you have specific code that explains this better, that might help
out.

thanks,

greg k-h

Re: Platform device model drawback

[Kumar Gala]

> You only register the driver once.  The individual devices can be bound
> to the same driver, right?
> 
> > Not registering it in CPM_UART, how the pdev could be obtained?
> > 
> > Maybe this is clear, but platform stuff is cumbersome some times...
> 
> Then make it cleaner :)

This is where the confusion is.  We have two instances of device A.  We 
want instance 1 of device A bound to driver "enet" and instance 2 of 
device A bound to "serial".

Today both instances are called "deviceA".  However we can't register two 
different drivers as "deviceA".

Not sure if that clarifies the issue any.

- kumar

Re: Platform device model drawback

[Andrey Volkov]

Vitaly Bordug wrote:
> Greg KH wrote:
> 
>> On Tue, Nov 15, 2005 at 07:51:20PM +0300, Vitaly Bordug wrote:
>>
>>> Hi, Greg!
>>>
>>> While doing "platformization" for one of the Freescale SoC's, I have
>>> discovered a serious drawback of the model - it prevents registering
>>> driver with the same name.
>>
>>
>> That's not a "drawback" :)
>>
>>> For instance, cpm2 on either ppc82xx or ppc85xx is very flexible, and
>>> its device fsl-cpm-scc could (and actually are) utilized in the
>>> different drivers.
>>>
>>> Those devices will have different bus_id, but pdev->name fields are
>>> the same for all the fsl-cpm-scc, only id is different there. Hence
>>> the fsl-cpm-scc could be driver_register'ed only once, while it is
>>> required several times.
>>
>>
>> A driver is registered only once, but can be bound to multiple devices
>> just fine, right?
> 
> Please let me know, how?
> 
> I have for instance struct device_driver with name="fsl-cpm-scc" in both
> fs_enet and cpm_uart(one using SCC1, the other - SCC4, the same device
> with different id's).
> 
> Once it has been registered in fs_enet, I could not register it in
> cpm_uart, due to kobject_register fo require unique names in
> kobject->name. Am I missing something?

May be better to convert fsl-cpm-scc to BUS driver which will be
derived from platform_driver? In this case you'll get flexible
SCCx enumerator as bonus.

--
Regards
Andrey Volkov

Re: Platform device model drawback

[Andy Fleming]

On Nov 15, 2005, at 11:59, Greg KH wrote:


> > I have for instance struct device_driver with name="fsl-cpm-scc"  
> in both
> > fs_enet and cpm_uart(one using SCC1, the other - SCC4, the same  
> device with
> > different id's).
> >
> > Once it has been registered in fs_enet, I could not register it in
> > cpm_uart, due to kobject_register fo require unique names in  
> kobject->name.
> > Am I missing something?
>
> You only register the driver once.  The individual devices can be  
> bound
> to the same driver, right?
>
> > Not registering it in CPM_UART, how the pdev could be obtained?
> >
> > Maybe this is clear, but platform stuff is cumbersome some times...
>
> Then make it cleaner :)
>
> If you have specific code that explains this better, that might help
> out.
>

So the problem Vitaly is referring to is that the CPM is somewhat  
programmable.  The SCC (Serial Communications Controller) is capable  
of being used as a uart, or as an ethernet device, depending on  
software configuration.  Currently, most systems I'm aware of  
configure this at boot time, depending on how the kernel has been  
configured.  So the same SOC may have SCC1 as a uart on one board,  
but as an ethernet controller on another board.

I believe there is work being done to clean this up, and make it more  
flexible.  As a temporary solution, we might want to declare 8  
different devices.  Something like "cpm-scc-uart", and "cpm-scc- 
enet".  And then create SCC1-4 twice, and let the board code delete  
the devices that aren't going to be used.

Andy

Re: Platform device model drawback

[Greg KH]

On Tue, Nov 15, 2005 at 01:34:47PM -0600, Kumar Gala wrote:
> > You only register the driver once.  The individual devices can be bound
> > to the same driver, right?
> > 
> > > Not registering it in CPM_UART, how the pdev could be obtained?
> > > 
> > > Maybe this is clear, but platform stuff is cumbersome some times...
> > 
> > Then make it cleaner :)
> 
> This is where the confusion is.  We have two instances of device A.  We 
> want instance 1 of device A bound to driver "enet" and instance 2 of 
> device A bound to "serial".

That's different from what was described earlier :)

In this case, you need two different struct devices.

> Today both instances are called "deviceA".  However we can't register two 
> different drivers as "deviceA".

Nor would you want to.

> Not sure if that clarifies the issue any.

A bit.  I think it still sounds messy...

thanks,

greg k-h

Re: Platform device model drawback

[Greg KH]

On Thu, Nov 17, 2005 at 09:51:56AM -0800, Peter Hanson wrote:
> On 11/16/05, Greg KH <greg@kroah.com> wrote:
> > On Wed, Nov 16, 2005 at 06:39:49PM -0800, Peter Hanson wrote:
> > > IIRC, Arabella claims to deal nicely with dynamic allocation of
> > > PowerPC resources to Linux devices =>
> > > http://www.arabellasw.com/home.php
> >
> > I don't understand how that pertains to this thread...
> 
> Potential conflict: multiple logical devices competing for the same
> SoC resource.  Converse: similar logical devices supported by
> different resources.  Both cases have been mentioned in this thread,
> with confusion about how to deal with them.
> 
> Does Arabella solve it as claimed?  I don't know.  But dynamic
> allocation doesn't sound crazy.  Maybe some of the code or design can
> even be copied.

Do you have a pointer to their code anywhere?

thanks,

greg k-h

Re: Platform device model drawback

[Peter Hanson]

On 11/16/05, Greg KH <greg@kroah.com> wrote:
> On Wed, Nov 16, 2005 at 06:39:49PM -0800, Peter Hanson wrote:
> > IIRC, Arabella claims to deal nicely with dynamic allocation of
> > PowerPC resources to Linux devices =3D>
> > http://www.arabellasw.com/home.php
>
> I don't understand how that pertains to this thread...

Potential conflict: multiple logical devices competing for the same
SoC resource.  Converse: similar logical devices supported by
different resources.  Both cases have been mentioned in this thread,
with confusion about how to deal with them.

Does Arabella solve it as claimed?  I don't know.  But dynamic
allocation doesn't sound crazy.  Maybe some of the code or design can
even be copied.

> And why did you post it only to me?

Oops.  Correcting now.

> thanks,
>
> greg k-h

Re: Platform device model drawback

[Peter Hanson]

On 11/17/05, Greg KH <greg@kroah.com> wrote:
> On Thu, Nov 17, 2005 at 09:51:56AM -0800, Peter Hanson wrote:
> > On 11/16/05, Greg KH <greg@kroah.com> wrote:
> > > On Wed, Nov 16, 2005 at 06:39:49PM -0800, Peter Hanson wrote:
> > > > IIRC, Arabella claims to deal nicely with dynamic allocation of
> > > > PowerPC resources to Linux devices =3D>
> > > > http://www.arabellasw.com/home.php
> > >
> > > I don't understand how that pertains to this thread...
> >
> > Potential conflict: multiple logical devices competing for the same
> > SoC resource.  Converse: similar logical devices supported by
> > different resources.  Both cases have been mentioned in this thread,
> > with confusion about how to deal with them.
> >
> > Does Arabella solve it as claimed?  I don't know.  But dynamic
> > allocation doesn't sound crazy.  Maybe some of the code or design can
> > even be copied.
>
> Do you have a pointer to their code anywhere?

I checked [http://www.arabellasw.com/products-free.php], and the
downloadable source is now gone.  :-(

> thanks,
>
> greg k-h

Re: Platform device model drawback

[Grant Likely]

On 11/15/05, Greg KH <greg@kroah.com> wrote:
> On Tue, Nov 15, 2005 at 01:34:47PM -0600, Kumar Gala wrote:
> > This is where the confusion is.  We have two instances of device A.  We
> > want instance 1 of device A bound to driver "enet" and instance 2 of
> > device A bound to "serial".
>
> That's different from what was described earlier :)
>
> In this case, you need two different struct devices.
Which is what we have.

>
> > Today both instances are called "deviceA".  However we can't register t=
wo
> > different drivers as "deviceA".
>
> Nor would you want to.
>
> > Not sure if that clarifies the issue any.
>
> A bit.  I think it still sounds messy...
Does this help?  (We also discussed this a bit at the PPC BoF at OLS this y=
ear)

 For example on the mpc52xx (see arch/ppc/syslib/mpc52xx_devices.c);
   - 6 PSC devices on chip;
   - (struct platform_device) for each device has: .name=3D'mpc52xx-psc';
   - However, SCC1 may be driven by the Ethernet driver but PSC2 and
PSC6 may be serial
   - problem then is: How do you get only PSC1 bound to the
psc-ethernet driver and only PSC2 & PSC6 bound to the serial driver?

Possible solution;  Modify the naming scheme slightly from what is
currently used.
1. Make the Ethernet driver register the name "mpc52xx-psc:eth"
2. Make the serial driver register the name "mpc52xx-psc:uart"
3. In the board-specific platform code, modify the .name field in
struct platform_device *before* the device is registered with the
platform device. (possibly by extending ppc_sys_device_fixup callback)
   - The board specific code would set PSC1 to "mpc52xx-psc:eth",
PSC2&6 to "mpc52xx-psc:uart".  PSC3-5 would stick with "mpc52xx-psc"
and so would not get bound to anything.

Q: Can the .name field be modified *after* platform_device is
registered w/ the platform bus?

g.

Re: Platform device model drawback

[Greg KH]

On Thu, Nov 17, 2005 at 04:46:17PM -0700, Grant Likely wrote:
> On 11/15/05, Greg KH <greg@kroah.com> wrote:
> > On Tue, Nov 15, 2005 at 01:34:47PM -0600, Kumar Gala wrote:
> > > This is where the confusion is.  We have two instances of device A.  We
> > > want instance 1 of device A bound to driver "enet" and instance 2 of
> > > device A bound to "serial".
> >
> > That's different from what was described earlier :)
> >
> > In this case, you need two different struct devices.
> Which is what we have.
> 
> >
> > > Today both instances are called "deviceA".  However we can't register two
> > > different drivers as "deviceA".
> >
> > Nor would you want to.
> >
> > > Not sure if that clarifies the issue any.
> >
> > A bit.  I think it still sounds messy...
> Does this help?  (We also discussed this a bit at the PPC BoF at OLS this year)
> 
>  For example on the mpc52xx (see arch/ppc/syslib/mpc52xx_devices.c);
>    - 6 PSC devices on chip;
>    - (struct platform_device) for each device has: .name='mpc52xx-psc';
>    - However, SCC1 may be driven by the Ethernet driver but PSC2 and
> PSC6 may be serial
>    - problem then is: How do you get only PSC1 bound to the
> psc-ethernet driver and only PSC2 & PSC6 bound to the serial driver?

I really do not know, sorry.

> 
> Possible solution;  Modify the naming scheme slightly from what is
> currently used.
> 1. Make the Ethernet driver register the name "mpc52xx-psc:eth"
> 2. Make the serial driver register the name "mpc52xx-psc:uart"
> 3. In the board-specific platform code, modify the .name field in
> struct platform_device *before* the device is registered with the
> platform device. (possibly by extending ppc_sys_device_fixup callback)
>    - The board specific code would set PSC1 to "mpc52xx-psc:eth",
> PSC2&6 to "mpc52xx-psc:uart".  PSC3-5 would stick with "mpc52xx-psc"
> and so would not get bound to anything.
> 
> Q: Can the .name field be modified *after* platform_device is
> registered w/ the platform bus?

No, it can not, sorry.

Good luck,

greg k-h

Re: Platform device model drawback

[Grant Likely]

On 11/18/05, Greg KH <greg@kroah.com> wrote:
> On Thu, Nov 17, 2005 at 04:46:17PM -0700, Grant Likely wrote:
> > Does this help?  (We also discussed this a bit at the PPC BoF at OLS th=
is year)
> >
> >  For example on the mpc52xx (see arch/ppc/syslib/mpc52xx_devices.c);
> >    - 6 PSC devices on chip;
> >    - (struct platform_device) for each device has: .name=3D'mpc52xx-psc=
';
> >    - However, SCC1 may be driven by the Ethernet driver but PSC2 and
> > PSC6 may be serial
> >    - problem then is: How do you get only PSC1 bound to the
> > psc-ethernet driver and only PSC2 & PSC6 bound to the serial driver?
>
> I really do not know, sorry.
>
> >
> > Possible solution;  Modify the naming scheme slightly from what is
> > currently used.
> > 1. Make the Ethernet driver register the name "mpc52xx-psc:eth"
> > 2. Make the serial driver register the name "mpc52xx-psc:uart"
> > 3. In the board-specific platform code, modify the .name field in
> > struct platform_device *before* the device is registered with the
> > platform device. (possibly by extending ppc_sys_device_fixup callback)
> >    - The board specific code would set PSC1 to "mpc52xx-psc:eth",
> > PSC2&6 to "mpc52xx-psc:uart".  PSC3-5 would stick with "mpc52xx-psc"
> > and so would not get bound to anything.

Ignoring the question below, do you see any problem with the above solution=
?

> >
> > Q: Can the .name field be modified *after* platform_device is
> > registered w/ the platform bus?
>
> No, it can not, sorry.
Not a big deal, that question was a bit of an aside.  If the name
could be changed, then the device function could change at runtime by
unbinding one function driver, changing the name and rebind
another....  But now that I think about it for more that 2ms, a
solution to this would be to just unregister, change .name, and
reregister the struct platform_device.

g.