Resent [to list only] because Thunderbird insists on converting UTF8
into top bit set ASCII.
On 08/07/17 18:40, Marcel Holtmann wrote:
> Hi Ian,
>
>> +#define BDADDR_BCM43430A0 (&(bdaddr_t) {{0xf8, 0x1a, 0x08, 0xca,
>> 0x25, 0x00}})
>
> isn't this a valid address? I do not see the point here. At least to
> me this is not one of the Broadcom default addresses that you get
> when no EEPROM address is configured.
Yeah, this one was sent out by mistake - thats why there are only 3
patches in the later series you've applied - I managed to test it on
another device and it turns out that the original code I had was
changing the bdaddr for no reason - these addresses are valid, as you
say.
I have no idea why this used to be set up this way, for some reason
the init scripts for the device would set the BDADDR up to == the MAC
of the Ethernet port. I assumed the devices were coming with invalid
MACs but I was wrong.
Is it intended behaviour that you cannot change the address via
btmgmt if the device started with a valid bdaddr? obviously this
patch is incorrect, but without it, btmgmt public-addr <foo> fails.
OTOH, bdaddr does not fail - which seems inconsistent to me. Surely
either both should work, or both fail?
This brings up a secondary issue - currently, some drivers *need*
help from userspace to get some things done, but it seems like it
would be a good idea if we filtered the command stream such that the
internal state of the device cannot be messed with from userspace,
except via approved APIs?
eg. - there is *no* legitimate reason for userspace to send a
firmware load command to the chip via my driver, since its already
handled by the kernels firmware mechanism - attempting to do so
should fail, IMO
-Ian
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
