From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Wed, 15 Jul 2009 23:27:55 +0000 Subject: Re: [PATCH] Explicitly disable BT radio using rfkill interface on Message-Id: List-Id: References: <4A4A8B6D.3060509@dell.com> In-Reply-To: <4A4A8B6D.3060509@dell.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: linux-hotplug@vger.kernel.org On Thu, Jul 16, 2009 at 00:24, Mario Limonciello wrote: >> Right, and even when it's loaded, there is no guarantee, that this >> device is already created by udev. >> > So this code for switch_logitech was originally authored by Marcel.  I > can try to help clean this part up, but I'd like to treat that as an > independent problem to follow up to after I get the logic for getting > this Dell HW working after S3. Sure, it still needs to be fixed or ripped out before the next udev release. We can not keep stuff like this in the udev tree. People use this as a starting point for their new tools, and therefore we can not ship such broken things. >>> These values will not change across a suspend/resume. >>> I don't know whether libusb has an API to open the particular device >>> given by those numbers, but it ought to. >> >> I didn't see anything like that. If that can't be done, I'll just add >> the few needed things to switch the device to code inside of udev and >> drop that libusb thing entirely. >> > I'll look into switching to this pair instead.  I didn't see any obvious > method to select devices by these properties, but I've just skimmed > libusb source looking for them.  If I don't find them, i'll resubmit the > patch with Marcel's recommendations of using more pointers for readability. Fine, just put all that in a function that accepts bus and dev num as a parameter to find the device. If libusb can not be fixed, I'll put the needed bits in the udev tree and drop libusb completely. As said, we are not going to search over all devices to find what we already have. Thanks, Kay