[lkml]   [2009]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Class device namespaces
    On Mon, Mar 30, 2009 at 10:49, Jean Delvare <> wrote:
    > On Sun, 29 Mar 2009 18:36:46 +0200, Kay Sievers wrote:
    >> On Sun, Mar 29, 2009 at 17:48, Jean Delvare <> 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.


     \ /
      Last update: 2009-03-30 13:27    [W:0.024 / U:2.216 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site