Hello Greg.
Federico Vaga and me are working on the ZIO framework
(ohwr.org/projects/zio) and he's currently adding the bus abstraction,
so we can support several cards of the same type. Under ZIO,
different devices may have different attributes: an SPI ADC chip may
allow to choose from two voltage references while a PCI digital-output
device may have a device-wide clocking rate.
But the list of attributes associated to a device is only known when
the driver is matched. In other workds, the "device" part is only
claiming "here I am and I'm called <sth>", then the probe method of the
<sth> driver will instantiate the device with its attributes.
However, the device appears in sysfs whether or not there is a driver
for it (which we agree is correct), but the list of attributes is only
known when the driver is matched -- because the list is known to the
driver, not to the device.
Here are some paths we evaluated:
1- /sys/bus/zio/devices may include place-holders, while a successful
match and probe will create real stuff is in /sys/zio/devices/<sth>-0/
But this would mean kobjects and you mandated us to only use devices
instead.
2- Like above, but falling in /sys/devices/virtual/zio/ ?
3- Attributes may be added after match succeeds, before calling probe.
This cam be done with a "raw" call to sysfs_create_group(); then
groups cna be added to dev->groups so they will be removed on
device_unregister().
4- Attributes may be added to the device before drv->probe is called
(or after it succeeds), using FIXMEFEDE. But .... FIXMEFEDE
5- The real attributes may live in another device, which is a child of
the one used within the bus abstraction. Here the drawback is using
an additional device and directory level for no reason.
6- We may use a fake (almost empty) device for the match function, and
then register the real one, with full attributes, when the match
succeeds (so match is called again and must be worked around). This
would work but is clearly a horrible hack.
We looked at other bus abstractions, and all of them host homogeneous
devices (they may have sub-devices, but none of them has different
attributes). Even the platform bus has no per-device attribute list
instantiated by the driver. In the cases where the attribute list is
different for each device, the list is known to the device, before the
match function is called.
Any suggestion is welcome. Meanwhile, Federico started implementing 3
above, but it still looks a dirty approach, and possibly not future-proof.
thanks
/alessandro (and federico)
On Fri, Feb 24, 2012 at 04:20:51PM +0100, Alessandro Rubini wrote:
> Hello Greg.
>
> Federico Vaga and me are working on the ZIO framework
> (ohwr.org/projects/zio) and he's currently adding the bus abstraction,
> so we can support several cards of the same type. Under ZIO,
> different devices may have different attributes: an SPI ADC chip may
> allow to choose from two voltage references while a PCI digital-output
> device may have a device-wide clocking rate.
>
> But the list of attributes associated to a device is only known when
> the driver is matched. In other workds, the "device" part is only
> claiming "here I am and I'm called <sth>", then the probe method of the
> <sth> driver will instantiate the device with its attributes.
That's fine, it is what happens with lots of drivers, you can do this
with the default attribute group assigned to that driver, right?
> However, the device appears in sysfs whether or not there is a driver
> for it (which we agree is correct), but the list of attributes is only
> known when the driver is matched -- because the list is known to the
> driver, not to the device.
>
> Here are some paths we evaluated:
>
> 1- /sys/bus/zio/devices may include place-holders, while a successful
> match and probe will create real stuff is in /sys/zio/devices/<sth>-0/
> But this would mean kobjects and you mandated us to only use devices
> instead.
>
> 2- Like above, but falling in /sys/devices/virtual/zio/ ?
>
> 3- Attributes may be added after match succeeds, before calling probe.
> This cam be done with a "raw" call to sysfs_create_group(); then
> groups cna be added to dev->groups so they will be removed on
> device_unregister().
>
> 4- Attributes may be added to the device before drv->probe is called
> (or after it succeeds), using FIXMEFEDE. But .... FIXMEFEDE
>
> 5- The real attributes may live in another device, which is a child of
> the one used within the bus abstraction. Here the drawback is using
> an additional device and directory level for no reason.
>
> 6- We may use a fake (almost empty) device for the match function, and
> then register the real one, with full attributes, when the match
> succeeds (so match is called again and must be worked around). This
> would work but is clearly a horrible hack.
Ick, don't do that...
> We looked at other bus abstractions, and all of them host homogeneous
> devices (they may have sub-devices, but none of them has different
> attributes). Even the platform bus has no per-device attribute list
> instantiated by the driver. In the cases where the attribute list is
> different for each device, the list is known to the device, before the
> match function is called.
I think you need to look at how the system bus is handled. It just went
into 3.3-rc and allows for "different" types of devices to all be on the
same bus, with different drivers and attributes. Let me know if how
that works does not work out for you.
thanks,
greg k-h
> I think you need to look at how the system bus is handled. It just went
> into 3.3-rc and allows for "different" types of devices to all be on the
> same bus, with different drivers and attributes. Let me know if how
> that works does not work out for you.
Can I have a reference to the patch(s) which introduces this?
I taked a look (3.3-rc5) but I didn't find it
Thank you
--
Federico Vaga
On Wed, Feb 29, 2012 at 02:57:01PM +0100, Federico Vaga wrote:
> > I think you need to look at how the system bus is handled. It just went
> > into 3.3-rc and allows for "different" types of devices to all be on the
> > same bus, with different drivers and attributes. Let me know if how
> > that works does not work out for you.
>
> Can I have a reference to the patch(s) which introduces this?
> I taked a look (3.3-rc5) but I didn't find it
Look at ca22e56debc57b47c422b749c93217ba62644be2 and the patches after
it.
Hope this helps,
greg k-h