[PATCH] UWB support for HAL

[Perez-Gonzalez, Inaky]

>From: Marcel Holtmann [mailto:marcel at holtmann.org] 
>
>> Why? there is no need for that. Interfaces/instances that are
>> children of a single device already have the parent definitions.
>> UMC should be as hidden as possible.
>
>for good HAL integration we need an easy way to identify these
>capabilities. So it would make sense to have them as own objects in the
>HAL tree.

But here is my point; user space shall not care if the device is
connected via a UMC 'bridge' or it's a HWA device (where UMC is 
done by the USB interfaces mechanism). That should be totally 
transparent. The only thing userspace has to be concerned with is
which UWB RC controller is associated to which device, which a 
symlink will do.

>If we always have the winet0 interface then it would be simple, but my
>understanding is that in theory we can have multiple 
>interfaces assigned
>to different beacon groups. Somehow these need to be created and
>involving user space and HAL might be a good idea.

Nope, that's not correct. You can only be in a single beacon group
at the time. The UWB RC will know about others, but won't be able
to act on them, other than to avoid interference. 

A winet device can be (not yet implemented) in many Winet networks 
at the same time (which will require many winet interfaces, one for 
each network), but then, these will have to be linked to their 
'master' device and HAL will have to know those details.

>> BTW, in the future we might have to do away without 
>/sys/class/uwb_host
>> [as the class support is removed]. Bear in mind!
>
>Shouldn't be a big problem. You simply declare it as subsystem or use
>links to actual sysfs devices.

Great :)