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 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?
--
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
