Hi, so I am working with RFKILL subsystem right now. One major problem that I have is that in the cases of platform RFKILL switches, I have no idea which device it actually belongs to. Lets take my X61 as an example: # udevadm info --query=all --path=/class/rfkill/rfkill0 P: /devices/platform/thinkpad_acpi/rfkill/rfkill0 E: UDEV_LOG=3 E: DEVPATH=/devices/platform/thinkpad_acpi/rfkill/rfkill0 E: RFKILL_NAME=tpacpi_bluetooth_sw E: RFKILL_TYPE=bluetooth E: RFKILL_STATE=1 # udevadm info --query=all --path=/class/rfkill/rfkill1 P: /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/rfkill/rfkill1 E: UDEV_LOG=3 E: DEVPATH=/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/rfkill/rfkill1 E: RFKILL_NAME=4965AGN E: RFKILL_TYPE=wlan E: RFKILL_STATE=1 As you can see for the 4965 WiFi, we clearly have a proper parent and know which device is affected by the RFKILL switch. For the Bluetooth one we have the problem that it just points to a platform device and not the Bluetooth device. Do we have any plans on how to handle this? I would like to identify the affected device. It is kinda tricky with hotplug devices like Bluetooth were it just disconnects from the bus when using the RFKILL switch, but at least when enabled we would see which device is attached to it. So any ideas or is this just wishful thinking on my part? Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Davide Libenzi | [patch 7/8] fdmap v2 - implement sys_socket2 |
| Greg Kroah-Hartman | [PATCH 018/196] coda: convert struct class_device to struct device |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
| David Newall | Re: Slow DOWN, please!!! |
git: | |
| Christoph Lameter | Network latency regressions from 2.6.22 to 2.6.29 |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Arjan van de Ven | Re: [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
