From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Tue, 14 Jul 2009 16:52:59 +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 Tue, Jul 14, 2009 at 18:40, Mario Limonciello wrote: >> Last I heard, you had created a udev rule which was supposed to match >> the removal event for the BT device, but which udev wasn't executing. >> Is that still the case?  If it is, you should post the rule together >> with the udev log for a resume.  Maybe somebody will be able to figure >> out why the rule isn't being executed. >> > Yeah, Kay already identified why the rule wasn't being executed.  It was > reliant on properties of the device that aren't cached in the udev database. Right, sysfs is gone when the remove event is handled. And stuffing all sysfs properties in the udev database would just be totally insane. :) >> Also, I noticed that your C program for reviving the BT device seemed >> more complex than necessary.  You should know beforehand that if the BT >> device's path is 4-1.3 then the corresponding mouse device's path will >> be 4-1.2 (just decrement the last byte of the pathname).  You can then >> match this device up with libusb by reading the busnum and devnum >> attributes from the sysfs directory. >> > I wasn't sure I wanted to jump to this conclusion as I can't predict if > this will change for future hardware that supports these features. What the action you want to take at removal? You can set ENV{REMOVE_CMD}= and it will be passed to RUN+= for that exact device when it goes away. You can also just store any other custom property in the udev database, and it will be there on remove. Kay