On Sat, Feb 1, 2014 at 11:06 AM, Frank Praznik <frank.praznik@xxxxxxxxx> wrote: > On 1/31/2014 15:45, Benjamin Tissoires wrote: >> >> On Fri, Jan 31, 2014 at 3:04 PM, Frank Praznik <frank.praznik@xxxxxxxxx> >> wrote: >>> >>> On 1/31/2014 14:10, Benjamin Tissoires wrote: >>>> >>>> Hi Frank, >>>> >>>> just a quick review: >>>> >>>> On Fri, Jan 31, 2014 at 12:32 PM, Frank Praznik >>>> <frank.praznik@xxxxxxxxx> >>>> wrote: >>>>> >>>>> Currently there is no reliable way for a device module or hidraw >>>>> application to >>>>> retrieve the client MAC address of the associated wireless device. >>>>> This >>>>> series >>>>> of patches adds a stable way of retrieving this information. >>>> >>>> Well, if I look at the uevent of a Bluetooth mouse I have: >>>> >>>> $ cat >>>> >>>> /sys/devices/pci0000\:00/0000\:00\:14.0/usb3/3-2/3-2\:1.0/bluetooth/hci0/hci0\:43/0005\:046D\:B00D.001F/uevent >>>> DRIVER=hid-generic >>>> HID_ID=0005:0000046D:0000B00D >>>> HID_NAME=Ultrathin Touch Mouse >>>> HID_PHYS=00:10:60:ea:df:ae >>>> HID_UNIQ=00:1f:20:96:33:47 >>>> MODALIAS=hid:b0005g0001v0000046Dp0000B00D >>>> >>>> I would say that HID_UNIQ is the client MAC address set by hidp, no? >>>> So you don't need to duplicate the info by adding a new field in >>>> hid_device. >>>> >>> In a patch I recently submitted I was using the UNIQ field for retrieving >>> a >>> Bluetooth device MAC address and was warned against it because "UNIQ is a >>> way to provide unique identifiers for devices, but it's not guaranteed to >>> stay the same". HIDP happens to store the MAC in the UNIQ data, but >>> there >>> is no guarantee that it will always be there. With these patches you can >>> be >>> completely sure that the data in client_addr is the client device MAC >>> address. >> >> ok. But still, adding a transport-specific information to hid_device >> is IMO a bad idea. We fought to make HID agnostic of the transport >> layer enough. >> >> David, could you elaborate why you think that UNIQ may change in the >> future regarding BT? >> If the BT MAC address is the same principle of an ethernet MAC >> address, UNIQ seems to fit perfectly well. >> >> Otherwise, you may be able to retrieve the MAC address by using the >> parent of the current device. >> >> Cheers, >> Benjamin > > Are you referring to using the hid_device::dev.parent pointer? I know that Yes > hidp sets it to point to the hci_conn struct from which src address for the > Bluetooth connection can be obtained, but making assumptions about an opaque > pointer like that seems dangerous. Is the parent pointer guaranteed to > point to the hci_conn struct as long as the bus type is Bluetooth? And nope. If you use uhid, then the parent will not be a hci_conn. With enough guards, you should be able to use it, but it's not ideal I agree. I really want to have David's opinion regarding the UNIQ field. IMO, this seems to be the most transport-agnostic way of doing it. Cheers, Benjamin -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
