Re: Class device namespaces

[Kay Sievers]

On Mon, Mar 30, 2009 at 10:49, Jean Delvare <khali@xxxxxxxxxxxx> wrote:
> On Sun, 29 Mar 2009 18:36:46 +0200, Kay Sievers wrote:
>> On Sun, Mar 29, 2009 at 17:48, Jean Delvare <khali@xxxxxxxxxxxx> wrote:

>> You have multiple instances, which request a firmware file for the
>> same parent device at the same time? Can't they request the firmware
>> for the actual child instead of using the same parent?
>
> No, there's a single firmware request which collides with an i2c-dev
> class device name. The firmware request happens to use the parent
> device's name as its class device name, and it happens that both the
> i2c-adapter class and the i2c-dev class name their class devices the
> same way (which makes sense as they refer to the same thing,
> i2c-adapter for the kernel-space access and i2c-dev for the user-space
> access), and the latter is a child of the former. So when an
> i2c-adapter class device is used as the parent for a firmware request,
> and the i2c-dev driver is loaded, you get a collision.

Ah, I see. If you have a single firmware request, how about using the
bus parent device of your i2c device to request the file, instead of
the class parent device? Then you should get the glue directory, and
all should work.

If that does not work for some reason, we can make the firmware class
to add the "firmware-%s" prefix, like your patch did, only if the
parent is a class device, not a bus device. That should prevent the
breakage of tools making these wrong assumptions.

> Now that we have a use case which would justify that a class device
> child of another class device gets its own namespace, is there a chance
> to see it happen?

Maybe we could do that, and do it only in the case of a class device
uses a class device of a different class as a parent. We need to make
sure, that we don't insert "block" between the disk and the partition,
and the like. It would be kind of inconsistent though, because we
don't do the same thing for any bus devices.

It's very uncommon that class devices want to parent with a class
device of a different class. In most cases, the parent device class
should be converted to a bus, and also use proper device binding
logic. If device binding is not needed, then one of the classes may be
just not needed. Having inter-dependencies between different classes
of the same subsystem, and use each other as a parent sounds rather
strange to me, and I would need to be convinced, that the driver core
would need to work around such issues, and not the subsystem itself.
:)

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