[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.0710161355150.9662-100000@iolanthe.rowland.org>
Date: Tue, 16 Oct 2007 14:04:43 -0400 (EDT)
From: Alan Stern <stern@...land.harvard.edu>
To: Matthew Dharm <mdharm-kernel@...-eyed-alien.net>
cc: Greg KH <greg@...ah.com>, Dave Young <hidave.darkstar@...il.com>,
<bbpetkov@...oo.de>,
Kernel development list <linux-kernel@...r.kernel.org>,
USB development list <linux-usb-devel@...ts.sourceforge.net>
Subject: Re: [linux-usb-devel] usb+sysfs: duplicate filename 'bInterfaceNumber'
On Tue, 16 Oct 2007, Matthew Dharm wrote:
> I haven't looked at this code at all, but neither approach feels right to
> me.
>
> How does this work at all? Even if you load a driver later, wouldn't it
> call usb_set_interface(), which would call usb_create_sysfs_intf_files()
> and hit the same issue?
usb_set_interface() is smart enough to remove the old interface files
before creating new ones, since it expects them to exist already.
Hence there's no problem in that scenario.
But usb_set_configuration doesn't expect there to be any pre-existing
interface files, because there isn't even an interface until the
registration is performed.
> Heck, why do both call usb_create_sysfs_intf_file()? I would guess if
> you're *changing* the active configuration you would need to do that, but
> why in usb_set_interface() at all?
For a couple of reasons. The "interface" attribute file contains the
iInterface string descriptor, and that file is present only if such a
descriptor exists. Since different altsettings might not agree on
whether or not iInterface exists, the attribute has to be created anew
for each altsetting. (Yes, we could let the file always be present and
just be blank if there is no descriptor.)
The most important reason has to do with the endpoint pseudo-devices.
Different altsettings can have different endpoints, so those have to be
removed and re-created whenever the altsetting changes.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists