lkml.org 
[lkml]   [2012]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: How to make a bus with heterogeneous devices?
On Sat, Mar 3, 2012 at 16:44, Federico Vaga <federico.vaga@gmail.com> wrote:
>> Maybe I miss something but it sounds not that different from USB.
>>
>> You have a bus that enumerates devices and a "bus driver" creates a
>> generic device on that bus for everything it finds. These devices stay
>> generic, do not have type-specific attributes, but export matches
>> again to bind other device-specific drivers, which create _new_ child
>> devices below the generic ones with the proper attributes matching
>> their individual type of devices. So every "logical" device is always
>> represented by one generic device and one type-specific child device.

>> 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.
>
> - I register the generic (empty) device on the bus

You can always add some generic, no-type specific attributes there, if
that fits in your model.

> - when the device match with a driver
>  - I register a new device child of the matched one but without connect
>    it directly on the bus.

You can assign all these devices to the same bus (see details below).

> The result will be something like (zio is our bus):
>
> /sys/bus/zio/devices/<generic-dev1>/<real-device1>/<attributes>
> /sys/bus/zio/devices/<generic-dev2>/<real-device2>/<attributes>
> /sys/bus/zio/devices/<generic-devN>/<real-deviceN>/<attributes>
>
> When there is not a driver:
>
> /sys/bus/zio/devices/<generic-dev1>/<device-stuff>
> /sys/bus/zio/devices/<generic-devN>/<device-stuff>
>
> Where the generic-dev is an empty device used to make the bus work. Is
> it correct?

All buses have have a 'subsystem directory' at:
/sys/bus/
This location exposes the 'device tree classification', like the
'collection of devices by subsystem'

The bus "zio" has its directory at:
/sys/bus/zio/

All devices known to the bus "zio" are referenced at:
/sys/bus/zio/devices/*

Which is a bunch of symlinks pointing into the:
/sys/devices/
directory, which is the tree of all devices from all subsystems. This
tree exposes the 'device tree hierarchy'.

So your registered devices would all show up in:
/sys/bus/zio/devices/generic0 --> ../../../devices/.../generic0
/sys/bus/zio/devices/generic1 --> ../../../devices/.../generic1
/sys/bus/zio/devices/generic2 --> ../../../devices/.../generic2
/sys/bus/zio/devices/type-a0 --> ../../../devices/.../generic0/type-a0
/sys/bus/zio/devices/type-a1 --> ../../../devices/.../generic1/type-a1
/sys/bus/zio/devices/type-b0 --> ../../../devices/.../generic2/type-b0

They all show up on the same bus, but the type-specific devices are
child devices of the generic ones.

>> All these devices, the generic ones and the type-specific ones can be
>> on the same bus (struct bus_type) when they get a "struct device_type"
>> assigned which carries the device-type specific set of attributes.
>
> But if all devices can live on the bus (set device->bus for all
> devices), when I register the "real-device" (type-specific)  the bus try
> to match it with a driver (again); but we already matched the device
> with its driver. it is better if the type-specific devices are not
> directly on the bus but only a child of a device on the bus.

You can sort them out by 'struct device_type' in your probe functions,
that should not be a problem.

We generally do not like devices which do not belong to a bus or
class, they are kind of 'invisible' to userspace, and udev can not use
them directly, it sees them only as a parent device of a device with a
bus or class.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2012-03-04 20:01    [W:0.643 / U:0.948 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site