Linux-WPAN Archive on lore.kernel.org
 help / color / Atom feed
* wpanusb?
@ 2020-05-25 12:39 Christopher Friedt
  2020-05-26 19:38 ` wpanusb? Stefan Schmidt
  0 siblings, 1 reply; 14+ messages in thread
From: Christopher Friedt @ 2020-05-25 12:39 UTC (permalink / raw)
  To: linux-wpan

Hi all,

Bouncing around a bit, but in Zephyr, there is reference to a
"wpanusb" Linux kernel driver here:

https://docs.zephyrproject.org/latest/samples/net/wpanusb/README.html

This *might* be the driver in question:

https://github.com/finikorg/wpanusb

Just wondering if anyone has made any attempts to submit that, or
would that go directly upstream these days?

Hope you are well.

Incidentally, we're hoping to do a microconference at Linux Plumbers
again this year again, virtually of course.

C

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: wpanusb?
  2020-05-25 12:39 wpanusb? Christopher Friedt
@ 2020-05-26 19:38 ` Stefan Schmidt
  2020-05-29 19:33   ` wpanusb? Christopher Friedt
  0 siblings, 1 reply; 14+ messages in thread
From: Stefan Schmidt @ 2020-05-26 19:38 UTC (permalink / raw)
  To: Christopher Friedt, linux-wpan

Hello.

On 25.05.20 14:39, Christopher Friedt wrote:
> Hi all,
> 
> Bouncing around a bit, but in Zephyr, there is reference to a
> "wpanusb" Linux kernel driver here:
> 
> https://docs.zephyrproject.org/latest/samples/net/wpanusb/README.html
> 
> This *might* be the driver in question:
> 
> https://github.com/finikorg/wpanusb

It is.

> 
> Just wondering if anyone has made any attempts to submit that, or
> would that go directly upstream these days?

I had a chance to talk to the author a while back. Not much activity 
from his side.

For me this needs to be designed in a way where we could have bare 
metal, Zephyr, RIOT or Contiki based firmware implementing the interface 
and the driver would just work. The code available is a good start but 
needs more work.

I was, and somehow still am, planning on working on this. But with the 
world turned upside down there was always something else to look at 
before. Its on my list, just not very high. If anyone wants to have a 
stab at this feel free and let me know.

> Hope you are well.
> 
> Incidentally, we're hoping to do a microconference at Linux Plumbers
> again this year again, virtually of course.

Feel free to keep me in the loop. Would be happy to participate again if 
time allows.

regards
Stefan Schmidt

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: wpanusb?
  2020-05-26 19:38 ` wpanusb? Stefan Schmidt
@ 2020-05-29 19:33   ` Christopher Friedt
  2020-05-30 11:33     ` wpanusb? Stefan Schmidt
  0 siblings, 1 reply; 14+ messages in thread
From: Christopher Friedt @ 2020-05-29 19:33 UTC (permalink / raw)
  To: Stefan Schmidt; +Cc: linux-wpan

Hi Stefan!

On Tue, May 26, 2020 at 3:38 PM Stefan Schmidt
<stefan@datenfreihafen.org> wrote:
> On 25.05.20 14:39, Christopher Friedt wrote:
> > Hi all,
> >
> > Bouncing around a bit, but in Zephyr, there is reference to a
> > "wpanusb" Linux kernel driver here:
> >
> > https://docs.zephyrproject.org/latest/samples/net/wpanusb/README.html
> >
> > This *might* be the driver in question:
> >
> > https://github.com/finikorg/wpanusb
> >
> > Just wondering if anyone has made any attempts to submit that, or
> > would that go directly upstream these days?
>
> I had a chance to talk to the author a while back. Not much activity
> from his side.

I was chatting with him as well on Zephyr Slack and let him know that
there was significant interest in it going upstream. I worry though
that it might not be a high priority for his employer.

Is there a linux-wpan IRC? Would be nice to chat in real-time at some point.

> For me this needs to be designed in a way where we could have bare
> metal, Zephyr, RIOT or Contiki based firmware implementing the interface
> and the driver would just work. The code available is a good start but
> needs more work.

I agree mostly. Of course each RTOS has their own headers, way of
declaring things, etc, but for the most part it could be platform
independent.

> I was, and somehow still am, planning on working on this. But with the
> world turned upside down there was always something else to look at
> before. Its on my list, just not very high. If anyone wants to have a
> stab at this feel free and let me know.

I'll bring it up in the Zephyr Slack. They want to incorporate it into
their "tools" repository, but it really should go into Linux at some
point.

We'll probably end up working on this for BB.O - even just having a
single driver that works for all boards in Zephyr is a pretty large
step.

Lastly, I feel like this is a recurring question, but a number of us
will likely need a bunch of 802.15.4 USB dongle to speak to our 15.4
nodes. I have a couple of ATUSB on my desk, but are there others in
our group that don't have any idea where to get parts, and likely
building one from scratch would be more time than they want to take.

Do you know of an off-the-shelf product that works with existing
drivers upstream?

M.f.G.

Chris

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: wpanusb?
  2020-05-29 19:33   ` wpanusb? Christopher Friedt
@ 2020-05-30 11:33     ` Stefan Schmidt
  2020-05-30 15:08       ` wpanusb? Christopher Friedt
  0 siblings, 1 reply; 14+ messages in thread
From: Stefan Schmidt @ 2020-05-30 11:33 UTC (permalink / raw)
  To: Christopher Friedt; +Cc: linux-wpan

Hello.

On 29.05.20 21:33, Christopher Friedt wrote:
> Hi Stefan!
> 
> On Tue, May 26, 2020 at 3:38 PM Stefan Schmidt
> <stefan@datenfreihafen.org> wrote:
>> On 25.05.20 14:39, Christopher Friedt wrote:
>>> Hi all,
>>>
>>> Bouncing around a bit, but in Zephyr, there is reference to a
>>> "wpanusb" Linux kernel driver here:
>>>
>>> https://docs.zephyrproject.org/latest/samples/net/wpanusb/README.html
>>>
>>> This *might* be the driver in question:
>>>
>>> https://github.com/finikorg/wpanusb
>>>
>>> Just wondering if anyone has made any attempts to submit that, or
>>> would that go directly upstream these days?
>>
>> I had a chance to talk to the author a while back. Not much activity
>> from his side.
> 
> I was chatting with him as well on Zephyr Slack and let him know that
> there was significant interest in it going upstream. I worry though
> that it might not be a high priority for his employer.
> 
> Is there a linux-wpan IRC? Would be nice to chat in real-time at some point.

#linux-wpan at Freenode :-)

>> For me this needs to be designed in a way where we could have bare
>> metal, Zephyr, RIOT or Contiki based firmware implementing the interface
>> and the driver would just work. The code available is a good start but
>> needs more work.
> 
> I agree mostly. Of course each RTOS has their own headers, way of
> declaring things, etc, but for the most part it could be platform
> independent.

I would still expect that each RTOS has their own firmware to adapt 
their ieee802154 abstraction and supported hw to the generic wpanusb 
driver. The USB interface they expose would be the same, and behave the 
same though.

>> I was, and somehow still am, planning on working on this. But with the
>> world turned upside down there was always something else to look at
>> before. Its on my list, just not very high. If anyone wants to have a
>> stab at this feel free and let me know.
> 
> I'll bring it up in the Zephyr Slack. They want to incorporate it into
> their "tools" repository, but it really should go into Linux at some
> point.

I agree.

> We'll probably end up working on this for BB.O - even just having a
> single driver that works for all boards in Zephyr is a pretty large
> step.

If work is going on for this and you are getting an idea on the level of 
abstraction I would be happy to discuss how this should result in a 
generic wpanusb driver.

> Lastly, I feel like this is a recurring question, but a number of us
> will likely need a bunch of 802.15.4 USB dongle to speak to our 15.4
> nodes. I have a couple of ATUSB on my desk, but are there others in
> our group that don't have any idea where to get parts, and likely
> building one from scratch would be more time than they want to take.
> 
> Do you know of an off-the-shelf product that works with existing
> drivers upstream?

ATUSB are still being produced and sold:
http://shop.sysmocom.de/products/atusb

Sysmocom is doing small batches (100-200 pieces) whenever their stock 
goes low. The price is not really making money for them and is mostly 
covering their expenses. Its one of their many contributions to help 
Open Source projects with hardware. (As you most likely can read from 
this I am _very_ happy they are handling all the hardware manufacturing 
and logistics for this).

I am flashing every single one of these atusb's by hand as well (for 
free, just to keep the supply alive). :-)

The available CC2531 dongles would be available for ~10 USD from China, 
but there is no driver support (it would be a perfect candidate for the 
wpanusb driver with a bare-metal firmware).

If the need it not USB but SPI there are plenty to choose from.

regards
Stefan Schmidt

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: wpanusb?
  2020-05-30 11:33     ` wpanusb? Stefan Schmidt
@ 2020-05-30 15:08       ` Christopher Friedt
  2020-05-30 18:10         ` wpanusb? Koen Zandberg
  0 siblings, 1 reply; 14+ messages in thread
From: Christopher Friedt @ 2020-05-30 15:08 UTC (permalink / raw)
  To: Stefan Schmidt; +Cc: linux-wpan

On Sat, May 30, 2020 at 7:33 AM Stefan Schmidt
<stefan@datenfreihafen.org> wrote:
> On 29.05.20 21:33, Christopher Friedt wrote:
> > On Tue, May 26, 2020 at 3:38 PM Stefan Schmidt
> > <stefan@datenfreihafen.org> wrote:
> >> On 25.05.20 14:39, Christopher Friedt wrote:
> >>> Hi all,
> >>>
> >>> Bouncing around a bit, but in Zephyr, there is reference to a
> >>> "wpanusb" Linux kernel driver here:
> >>>
> >>> https://docs.zephyrproject.org/latest/samples/net/wpanusb/README.html
> >>>
> >>> This *might* be the driver in question:
> >>>
> >>> https://github.com/finikorg/wpanusb
> >>>
> >>> Just wondering if anyone has made any attempts to submit that, or
> >>> would that go directly upstream these days?
> >>
> >> I had a chance to talk to the author a while back. Not much activity
> >> from his side.
> >
> > I was chatting with him as well on Zephyr Slack and let him know that
> > there was significant interest in it going upstream. I worry though
> > that it might not be a high priority for his employer.
> >
> > Is there a linux-wpan IRC? Would be nice to chat in real-time at some point.
>
> #linux-wpan at Freenode :-)

I see some familiar nicks there ;-)

> >> For me this needs to be designed in a way where we could have bare
> >> metal, Zephyr, RIOT or Contiki based firmware implementing the interface
> >> and the driver would just work. The code available is a good start but
> >> needs more work.
> >
> > I'll bring it up in the Zephyr Slack. They want to incorporate it into
> > their "tools" repository, but it really should go into Linux at some
> > point.
>
> > We'll probably end up working on this for BB.O - even just having a
> > single driver that works for all boards in Zephyr is a pretty large
> > step.
>
> If work is going on for this and you are getting an idea on the level of
> abstraction I would be happy to discuss how this should result in a
> generic wpanusb driver.

Sounds good. If you want to email me directly I can see if I can fit
it into the current project, or even see if I can work with the
original wpanusb author.

> > Lastly, I feel like this is a recurring question, but a number of us
> > will likely need a bunch of 802.15.4 USB dongle to speak to our 15.4
> > nodes. I have a couple of ATUSB on my desk, but are there others in
> > our group that don't have any idea where to get parts, and likely
> > building one from scratch would be more time than they want to take.
> >
> > Do you know of an off-the-shelf product that works with existing
> > drivers upstream?
>
> ATUSB are still being produced and sold:
> http://shop.sysmocom.de/products/atusb
>
> Sysmocom is doing small batches (100-200 pieces) whenever their stock
> goes low. The price is not really making money for them and is mostly
> covering their expenses. Its one of their many contributions to help
> Open Source projects with hardware. (As you most likely can read from
> this I am _very_ happy they are handling all the hardware manufacturing
> and logistics for this).
>
> I am flashing every single one of these atusb's by hand as well (for
> free, just to keep the supply alive). :-)

That is dedication ;-) Hopefully this winter I should have some
dedicated manufacturing space, so I'm looking forward to spinning out
a few OSHW boards too.

> The available CC2531 dongles would be available for ~10 USD from China,
> but there is no driver support (it would be a perfect candidate for the
> wpanusb driver with a bare-metal firmware).

Excellent!

I also found this which seems like it should be supported (with
something out of linux-firmware maybe?)

http://www.ti.com/tool/CC2531EMK

C

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: wpanusb?
  2020-05-30 15:08       ` wpanusb? Christopher Friedt
@ 2020-05-30 18:10         ` Koen Zandberg
  2020-05-31 16:13           ` wpanusb? Christopher Friedt
  0 siblings, 1 reply; 14+ messages in thread
From: Koen Zandberg @ 2020-05-30 18:10 UTC (permalink / raw)
  To: Christopher Friedt, Stefan Schmidt; +Cc: linux-wpan

[-- Attachment #1.1: Type: text/plain, Size: 2075 bytes --]

Hello all,

Long term RIOT maintainer here.

On 30-05-2020 17:08, Christopher Friedt wrote:
> On Sat, May 30, 2020 at 7:33 AM Stefan Schmidt
> <stefan@datenfreihafen.org> wrote:
>> On 29.05.20 21:33, Christopher Friedt wrote:
>>> On Tue, May 26, 2020 at 3:38 PM Stefan Schmidt
>>> <stefan@datenfreihafen.org> wrote:
>>>> On 25.05.20 14:39, Christopher Friedt wrote:
>>>>> Hi all,
>>>>>
>>>>> Bouncing around a bit, but in Zephyr, there is reference to a
>>>>> "wpanusb" Linux kernel driver here:
>>>>>
>>>>> https://docs.zephyrproject.org/latest/samples/net/wpanusb/README.html
>>>>>
>>>>> This *might* be the driver in question:
>>>>>
>>>>> https://github.com/finikorg/wpanusb
>>>>>
>>>>> Just wondering if anyone has made any attempts to submit that, or
>>>>> would that go directly upstream these days?
>>>> I had a chance to talk to the author a while back. Not much activity
>>>> from his side.
>>> I was chatting with him as well on Zephyr Slack and let him know that
>>> there was significant interest in it going upstream. I worry though
>>> that it might not be a high priority for his employer.
Most of our developers have of-the-shelve development boards such as the
nrf52840dk and the samr21-xplained pro. For us a generic firmware +
Linux kernel driver would be a very welcome addition to the tool set.
>>>> For me this needs to be designed in a way where we could have bare
>>>> metal, Zephyr, RIOT or Contiki based firmware implementing the interface
>>>> and the driver would just work. The code available is a good start but
>>>> needs more work.
>>> I'll bring it up in the Zephyr Slack. They want to incorporate it into
>>> their "tools" repository, but it really should go into Linux at some
>>> point.

I'm willing to work on this for a RIOT implementation, assuming there is
some documentation available on the USB protocol side :)
I think I should be able to get a relative generic firmware application
able to run on any of our hardware boards as long as they have a radio
and a USB interface.

Koen



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: wpanusb?
  2020-05-30 18:10         ` wpanusb? Koen Zandberg
@ 2020-05-31 16:13           ` Christopher Friedt
  2020-06-03 18:18             ` wpanusb? Stefan Schmidt
  0 siblings, 1 reply; 14+ messages in thread
From: Christopher Friedt @ 2020-05-31 16:13 UTC (permalink / raw)
  To: Koen Zandberg; +Cc: Stefan Schmidt, linux-wpan

Hi Koen,

On Sat, May 30, 2020 at 2:10 PM Koen Zandberg <koen@bergzand.net> wrote:
>
> Hello all,
>
> Long term RIOT maintainer here.
>
> I'm willing to work on this for a RIOT implementation, assuming there is
> some documentation available on the USB protocol side :)
> I think I should be able to get a relative generic firmware application
> able to run on any of our hardware boards as long as they have a radio
> and a USB interface.

That's great news!

Also, I heard from the original wpanusb author and he said he'll put
submitting a patch any day now.

Cheers,

C

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: wpanusb?
  2020-05-31 16:13           ` wpanusb? Christopher Friedt
@ 2020-06-03 18:18             ` Stefan Schmidt
  2020-06-05 11:07               ` wpanusb? Koen Zandberg
  0 siblings, 1 reply; 14+ messages in thread
From: Stefan Schmidt @ 2020-06-03 18:18 UTC (permalink / raw)
  To: Christopher Friedt, Koen Zandberg; +Cc: linux-wpan, Andrei Emeltchenko

Hello.

[Putting Adrei in CC as well, not sure if he is subscribed to linux-wpan]

On 31.05.20 18:13, Christopher Friedt wrote:
> Hi Koen,
> 
> On Sat, May 30, 2020 at 2:10 PM Koen Zandberg <koen@bergzand.net> wrote:
>>
>> Hello all,
>>
>> Long term RIOT maintainer here.
>>
>> I'm willing to work on this for a RIOT implementation, assuming there is
>> some documentation available on the USB protocol side :)
>> I think I should be able to get a relative generic firmware application
>> able to run on any of our hardware boards as long as they have a radio
>> and a USB interface.
> 
> That's great news!
> 
> Also, I heard from the original wpanusb author and he said he'll put
> submitting a patch any day now.

Happy to see that we finally have the critical mass to get this moved 
forward. :-)

Here is my take on what I think needs to be done.

On a first review I found nothing wrong with the design. It needs 
further extending and flexibility in my opinion, though.

o Add a GET_EXTENDED_ADDR command to receive the extended address 
provided by the transceiver itself, or firmware in some way.

o Adding a GET_CAPABILITIES command to query device capabilities
  during init to enable and set needed ieee802154_ops based on the 
device. Given that we aim to support as many transceivers as possible we 
can't rely on static device knowledge to configure wpanusb correctly.

o Add opcode for set_lbt in USB spec

o Add opcode for set_frame_retries USB spec. (If a transceiver does not 
support AutoACK in hardware do Zephyr and RIOT support a software 
fallback to handle AutoACK?)

o How are we going to handle transceiver which allow MTUs > 127? Not a 
high priority as the kernel part does not support this either right now.

o Do Zephyr or RIOT expose additional functionality we should support here?

o Koen, you offered to look into implementing the firmware support for 
the USB spec in RIOT. Does the spec fit what RIOT has as abstraction for 
ieee802154?

o Adrei, Chris, I understand it you would work on the wpanusb as well as 
the Zephyr firmware side, correct?

o I see additional use cases for a bare metal firmwares (a different fw 
to support wpanusb on the atusb device or CC2531 comes to mind). But 
none of those are critical in the beginning.

regards
Stefan Schmidt

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: wpanusb?
  2020-06-03 18:18             ` wpanusb? Stefan Schmidt
@ 2020-06-05 11:07               ` Koen Zandberg
  2020-06-07 12:17                 ` wpanusb? Stefan Schmidt
  2020-07-24 13:41                 ` wpanusb? Stefan Schmidt
  0 siblings, 2 replies; 14+ messages in thread
From: Koen Zandberg @ 2020-06-05 11:07 UTC (permalink / raw)
  To: Stefan Schmidt, Christopher Friedt; +Cc: linux-wpan, Andrei Emeltchenko

[-- Attachment #1.1: Type: text/plain, Size: 3441 bytes --]

Hello

On 03-06-2020 20:18, Stefan Schmidt wrote:
> Hello.
>
> Happy to see that we finally have the critical mass to get this moved
> forward. :-)
>
> Here is my take on what I think needs to be done.
>
> On a first review I found nothing wrong with the design. It needs
> further extending and flexibility in my opinion, though.
I would suggest using USB bulk endpoints for both the tx and rx paths.
An interrupt IN endpoint might be useful for events from the radio back
to the host such as ack information from a transmit. This way we can
keep the control messages to configuration only. This is similar to how
USB ethernet devices are using different USB endpoints. I also see
issues with transferring large 802.15.4g frames over control endpoints.
Something similar like CDC-ECM would be my preference here: Split the
frame in multiple bulk transfers and detect the end of the frame by a
transfer size not equal to the endpoint size.
>
> o Add a GET_EXTENDED_ADDR command to receive the extended address
> provided by the transceiver itself, or firmware in some way.
+1
>
> o Adding a GET_CAPABILITIES command to query device capabilities
>  during init to enable and set needed ieee802154_ops based on the
> device. Given that we aim to support as many transceivers as possible
> we can't rely on static device knowledge to configure wpanusb correctly.
Does it make sense to include also a "protocol" version here, to allow
extending the feature set of the driver later without causing
compatibility issues between the firmware and the kernel?
>
> o Add opcode for set_lbt in USB spec
This requires some clarification for me how the radio should be
configured. Is this just a CSMA/CCA switch?
>
> o Add opcode for set_frame_retries USB spec. (If a transceiver does
> not support AutoACK in hardware do Zephyr and RIOT support a software
> fallback to handle AutoACK?)
This can be implemented in RIOT. I don't think there is something in
place at the moment, most of our radios support this in hardware, but I
see no technical reason why not to support this.
>
> o How are we going to handle transceiver which allow MTUs > 127? Not a
> high priority as the kernel part does not support this either right now.
There is some preliminary support for 802.15.4g radios in RIOT. I know
some developers that would prefer not to have to have the MTU limited to
127 bytes :)
>
> o Do Zephyr or RIOT expose additional functionality we should support
> here?
>
> o Koen, you offered to look into implementing the firmware support for
> the USB spec in RIOT. Does the spec fit what RIOT has as abstraction
> for ieee802154?

Yes, implementing configuration settings as USB control messages makes
glueing them to the radio abstraction layer very easy. For now RIOT has
configuration for:

 - reading and writing channel/page settings
 - read/write to addresses, both long and short
 - PAN ID
 - TX power settings
 - reading the max PSDU size
 - Ack config settings
 - CCA and CSMA configuration, enabling/disabling, retries and backoff
exponent (max/min)
 - CCA threshold and mode

Furthermore, it is possible to get frame metadata such as the received
signal strength and the number of retries required for the frame
transmit. All these settings depend a bit on the radio hardware features
of course, but thats what we have the GET_CAPABILITIES for.

Koen



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: wpanusb?
  2020-06-05 11:07               ` wpanusb? Koen Zandberg
@ 2020-06-07 12:17                 ` Stefan Schmidt
  2020-07-06 14:42                   ` wpanusb? Stefan Schmidt
  2020-07-24 13:41                 ` wpanusb? Stefan Schmidt
  1 sibling, 1 reply; 14+ messages in thread
From: Stefan Schmidt @ 2020-06-07 12:17 UTC (permalink / raw)
  To: Koen Zandberg, Christopher Friedt; +Cc: linux-wpan, Andrei Emeltchenko

Hallo.

On 05.06.20 13:07, Koen Zandberg wrote:
> Hello
> 
> On 03-06-2020 20:18, Stefan Schmidt wrote:
>> Hello.
>>
>> Happy to see that we finally have the critical mass to get this moved
>> forward. :-)
>>
>> Here is my take on what I think needs to be done.
>>
>> On a first review I found nothing wrong with the design. It needs
>> further extending and flexibility in my opinion, though.
> I would suggest using USB bulk endpoints for both the tx and rx paths.
> An interrupt IN endpoint might be useful for events from the radio back
> to the host such as ack information from a transmit. This way we can
> keep the control messages to configuration only. This is similar to how
> USB ethernet devices are using different USB endpoints. I also see
> issues with transferring large 802.15.4g frames over control endpoints.
> Something similar like CDC-ECM would be my preference here: Split the
> frame in multiple bulk transfers and detect the end of the frame by a
> transfer size not equal to the endpoint size.

That sounds fine to me. Adrei, what do you think about this change?

>>
>> o Add a GET_EXTENDED_ADDR command to receive the extended address
>> provided by the transceiver itself, or firmware in some way.
> +1
>>
>> o Adding a GET_CAPABILITIES command to query device capabilities
>>   during init to enable and set needed ieee802154_ops based on the
>> device. Given that we aim to support as many transceivers as possible
>> we can't rely on static device knowledge to configure wpanusb correctly.
> Does it make sense to include also a "protocol" version here, to allow
> extending the feature set of the driver later without causing
> compatibility issues between the firmware and the kernel?

I was hoping that we could cover what we need with the current spec and 
we could just add more capability flags for new things. We could got the 
full way to have a protocol version during the init as well.

>>
>> o Add opcode for set_lbt in USB spec
> This requires some clarification for me how the radio should be
> configured. Is this just a CSMA/CCA switch?

 From what I have seen this listen before talk is often (always?) a 
hardware feature of sub GHz (where its needed) transceivers. I would 
assume this just makes sure we pass the config from linux stack through 
the driver to the firmware.

>>
>> o Add opcode for set_frame_retries USB spec. (If a transceiver does
>> not support AutoACK in hardware do Zephyr and RIOT support a software
>> fallback to handle AutoACK?)
> This can be implemented in RIOT. I don't think there is something in
> place at the moment, most of our radios support this in hardware, but I
> see no technical reason why not to support this.

Good

>>
>> o How are we going to handle transceiver which allow MTUs > 127? Not a
>> high priority as the kernel part does not support this either right now.
> There is some preliminary support for 802.15.4g radios in RIOT. I know
> some developers that would prefer not to have to have the MTU limited to
> 127 bytes :)

While we do not support this in the Linux stack yet, we should still 
make sure the spec here is capable of supporting this.

>>
>> o Do Zephyr or RIOT expose additional functionality we should support
>> here?
>>
>> o Koen, you offered to look into implementing the firmware support for
>> the USB spec in RIOT. Does the spec fit what RIOT has as abstraction
>> for ieee802154?
> 
> Yes, implementing configuration settings as USB control messages makes
> glueing them to the radio abstraction layer very easy. For now RIOT has
> configuration for:
> 
>   - reading and writing channel/page settings
>   - read/write to addresses, both long and short
>   - PAN ID
>   - TX power settings
>   - reading the max PSDU size

Hmm, we do not have that. But getting the info from the firmware would 
be useful.


>   - Ack config settings
>   - CCA and CSMA configuration, enabling/disabling, retries and backoff
> exponent (max/min)
>   - CCA threshold and mode

Is there a way to the device in promiscuous mode?

> 
> Furthermore, it is possible to get frame metadata such as the received
> signal strength and the number of retries required for the frame

Currently the spec only covers LQI, but getting extra stats on the 
reliability could bring in some extra benefit for routing decisions.

> transmit. All these settings depend a bit on the radio hardware features
> of course, but thats what we have the GET_CAPABILITIES for.

Yes, exactly, with the capabilities we get during init from the firmware 
it can be signalled what it supports and we would enable the needed 
device ops for the Linux stack ased on this.

regards
Stefan Schmidt

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: wpanusb?
  2020-06-07 12:17                 ` wpanusb? Stefan Schmidt
@ 2020-07-06 14:42                   ` Stefan Schmidt
       [not found]                     ` <CAF4BF-TdLpg6hCc8iiR40tGmV9C5EPDF6c6Qr5m5CfDWOVJUMA@mail.gmail.com>
  0 siblings, 1 reply; 14+ messages in thread
From: Stefan Schmidt @ 2020-07-06 14:42 UTC (permalink / raw)
  To: Koen Zandberg, Christopher Friedt; +Cc: linux-wpan, Andrei Emeltchenko

Hello.

Bumping this thread again.

On 07.06.20 14:17, Stefan Schmidt wrote:
> Hallo.
> 
> On 05.06.20 13:07, Koen Zandberg wrote:
>> Hello
>>
>> On 03-06-2020 20:18, Stefan Schmidt wrote:
>>> Hello.
>>>
>>> Happy to see that we finally have the critical mass to get this moved
>>> forward. :-)
>>>
>>> Here is my take on what I think needs to be done.
>>>
>>> On a first review I found nothing wrong with the design. It needs
>>> further extending and flexibility in my opinion, though.
>> I would suggest using USB bulk endpoints for both the tx and rx paths.
>> An interrupt IN endpoint might be useful for events from the radio back
>> to the host such as ack information from a transmit. This way we can
>> keep the control messages to configuration only. This is similar to how
>> USB ethernet devices are using different USB endpoints. I also see
>> issues with transferring large 802.15.4g frames over control endpoints.
>> Something similar like CDC-ECM would be my preference here: Split the
>> frame in multiple bulk transfers and detect the end of the frame by a
>> transfer size not equal to the endpoint size.
> 
> That sounds fine to me. Adrei, what do you think about this change?

I heard back from him directly that he agrees with the idea of using 
bulk endpoints. He is working on other parts right now and does not have 
a working 15.4 setup at all. Unclear when he can come back to this.

If we want this moving forward we need to push it ourselves. 
Christopher, as you brought this up I am wondering if you have any plan 
to work on the wpanusb driver side? Koen offered to work on the RIOT 
side, but this does need the linux kernel driver as well.

If nobody plans any work on wpanusb I would need to see if I can free up 
time for it and do it myself. Not sure if and when this will be possible 
though.

With the other changes we discussed as changes before we should have a 
first target of what we wanted to get implemented. (and see what we 
forgot when the pieces are coming together)

regards
Stefan Schmidt

>>>
>>> o Add a GET_EXTENDED_ADDR command to receive the extended address
>>> provided by the transceiver itself, or firmware in some way.
>> +1
>>>
>>> o Adding a GET_CAPABILITIES command to query device capabilities
>>>   during init to enable and set needed ieee802154_ops based on the
>>> device. Given that we aim to support as many transceivers as possible
>>> we can't rely on static device knowledge to configure wpanusb correctly.
>> Does it make sense to include also a "protocol" version here, to allow
>> extending the feature set of the driver later without causing
>> compatibility issues between the firmware and the kernel?
> 
> I was hoping that we could cover what we need with the current spec and 
> we could just add more capability flags for new things. We could got the 
> full way to have a protocol version during the init as well.
> 
>>>
>>> o Add opcode for set_lbt in USB spec
>> This requires some clarification for me how the radio should be
>> configured. Is this just a CSMA/CCA switch?
> 
>  From what I have seen this listen before talk is often (always?) a 
> hardware feature of sub GHz (where its needed) transceivers. I would 
> assume this just makes sure we pass the config from linux stack through 
> the driver to the firmware.
> 
>>>
>>> o Add opcode for set_frame_retries USB spec. (If a transceiver does
>>> not support AutoACK in hardware do Zephyr and RIOT support a software
>>> fallback to handle AutoACK?)
>> This can be implemented in RIOT. I don't think there is something in
>> place at the moment, most of our radios support this in hardware, but I
>> see no technical reason why not to support this.
> 
> Good
> 
>>>
>>> o How are we going to handle transceiver which allow MTUs > 127? Not a
>>> high priority as the kernel part does not support this either right now.
>> There is some preliminary support for 802.15.4g radios in RIOT. I know
>> some developers that would prefer not to have to have the MTU limited to
>> 127 bytes :)
> 
> While we do not support this in the Linux stack yet, we should still 
> make sure the spec here is capable of supporting this.
> 
>>>
>>> o Do Zephyr or RIOT expose additional functionality we should support
>>> here?
>>>
>>> o Koen, you offered to look into implementing the firmware support for
>>> the USB spec in RIOT. Does the spec fit what RIOT has as abstraction
>>> for ieee802154?
>>
>> Yes, implementing configuration settings as USB control messages makes
>> glueing them to the radio abstraction layer very easy. For now RIOT has
>> configuration for:
>>
>>   - reading and writing channel/page settings
>>   - read/write to addresses, both long and short
>>   - PAN ID
>>   - TX power settings
>>   - reading the max PSDU size
> 
> Hmm, we do not have that. But getting the info from the firmware would 
> be useful.
> 
> 
>>   - Ack config settings
>>   - CCA and CSMA configuration, enabling/disabling, retries and backoff
>> exponent (max/min)
>>   - CCA threshold and mode
> 
> Is there a way to the device in promiscuous mode?
> 
>>
>> Furthermore, it is possible to get frame metadata such as the received
>> signal strength and the number of retries required for the frame
> 
> Currently the spec only covers LQI, but getting extra stats on the 
> reliability could bring in some extra benefit for routing decisions.
> 
>> transmit. All these settings depend a bit on the radio hardware features
>> of course, but thats what we have the GET_CAPABILITIES for.
> 
> Yes, exactly, with the capabilities we get during init from the firmware 
> it can be signalled what it supports and we would enable the needed 
> device ops for the Linux stack ased on this.
> 
> regards
> Stefan Schmidt

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: wpanusb?
       [not found]                     ` <CAF4BF-TdLpg6hCc8iiR40tGmV9C5EPDF6c6Qr5m5CfDWOVJUMA@mail.gmail.com>
@ 2020-07-23  8:15                       ` Stefan Schmidt
  2020-07-24 13:26                       ` wpanusb? Stefan Schmidt
  1 sibling, 0 replies; 14+ messages in thread
From: Stefan Schmidt @ 2020-07-23  8:15 UTC (permalink / raw)
  To: Christopher Friedt; +Cc: Koen Zandberg, linux-wpan, Andrei Emeltchenko, erik

Hello.

On 21.07.20 19:11, Christopher Friedt wrote:
> +Erik
> 
> Sorry for my late response.
> 
> On Mon, Jul 6, 2020 at 10:42 AM Stefan Schmidt 
> <stefan@datenfreihafen.org <mailto:stefan@datenfreihafen.org>> wrote:
> 
>     If we want this moving forward we need to push it ourselves.
>     Christopher, as you brought this up I am wondering if you have any plan
>     to work on the wpanusb driver side? Koen offered to work on the RIOT
>     side, but this does need the linux kernel driver as well.
> 
> 
> Erik is also actively looking at wpan-usb for the BeagleConnect currently.
> 
> I'm sure I could get it up to snuff. In particular, it should be 
> straight-forward to do with the nice list of TODO items that Stefan 
> outlined earlier in the thread :-) 
> [1]<https://marc.info/?t=159041047800001&r=1&w=2>

Koen will also have some time in August and expressed interest in 
working on it. I will be away on vacation first half of August. It would 
be great if you three can coordinate this a bit.

> 
>     With the other changes we discussed as changes before we should have a
>     first target of what we wanted to get implemented. (and see what we
>     forgot when the pieces are coming together)
> 
> 
> Exactly.
> 
> I had one question, specifically because it impacts the BeagleConnect 
> project, but also because it's been a while since I've done any 15.4 
> hacking in Linux.
> 
> Does Linux already support the 900 MHz phy and IEEE bits?
> 
> If possible, we're hoping to be able to use it for the 2.4 GHz band and 
> the 900 MHz band.

We have drivers for the sub-GHz band (at86rf212 and the HUL USB support 
in atusb which also uses the 212). We also have support for a 
listen-before-talk (LBT) driver operation to make that part work with 
the drivers.

To be honest I have not done sub-GHz testing myself here, but given the 
work people put into the at86rf212 support I would think it should work 
for some first tries. Reports welcome!

regards
Stefan Schmidt

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: wpanusb?
       [not found]                     ` <CAF4BF-TdLpg6hCc8iiR40tGmV9C5EPDF6c6Qr5m5CfDWOVJUMA@mail.gmail.com>
  2020-07-23  8:15                       ` wpanusb? Stefan Schmidt
@ 2020-07-24 13:26                       ` Stefan Schmidt
  1 sibling, 0 replies; 14+ messages in thread
From: Stefan Schmidt @ 2020-07-24 13:26 UTC (permalink / raw)
  To: Christopher Friedt; +Cc: Koen Zandberg, linux-wpan, Andrei Emeltchenko, erik

Hello

On 21.07.20 19:11, Christopher Friedt wrote:
> 
> Does Linux already support the 900 MHz phy and IEEE bits?
> 
> If possible, we're hoping to be able to use it for the 2.4 GHz band and 
> the 900 MHz band.

As follow up from what I wrote on the 900 MHz stuff before here is a 
link where we are adding sub GHz support to the atusb driver

https://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan-next.git/commit/?id=d5dd29e4dafef4baad7bf529ad73cafeb13e1aa8

regards
Stefan Schmidt

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: wpanusb?
  2020-06-05 11:07               ` wpanusb? Koen Zandberg
  2020-06-07 12:17                 ` wpanusb? Stefan Schmidt
@ 2020-07-24 13:41                 ` Stefan Schmidt
  1 sibling, 0 replies; 14+ messages in thread
From: Stefan Schmidt @ 2020-07-24 13:41 UTC (permalink / raw)
  To: Koen Zandberg, Christopher Friedt; +Cc: linux-wpan, Andrei Emeltchenko, erik

Hello.

[Added Erik here to be part of the discussion]

This mostly goes to Koen and Erik. Please coordinate how you are wanting 
to work on this. And be pro-active. Waiting for the other one to start 
will just lead to starving :-)


I started to hack together some parts as I would do them. Really not 
working at all right now and only compile tested. I will give more 
details below. I am not sure if I will find time to work more on this 
next week before I go on vacation, so here is what I have:

https://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan-next.git/log/?h=wpanusb-original

Feel free to use any of it or ignore it if you have something better.
Really just my take in a really rushed break.

On 05.06.20 13:07, Koen Zandberg wrote:
> Hello
> 
> On 03-06-2020 20:18, Stefan Schmidt wrote:
>> Hello.
>>
>> Happy to see that we finally have the critical mass to get this moved
>> forward. :-)
>>
>> Here is my take on what I think needs to be done.
>>
>> On a first review I found nothing wrong with the design. It needs
>> further extending and flexibility in my opinion, though.
> I would suggest using USB bulk endpoints for both the tx and rx paths.
> An interrupt IN endpoint might be useful for events from the radio back
> to the host such as ack information from a transmit. This way we can
> keep the control messages to configuration only. This is similar to how
> USB ethernet devices are using different USB endpoints. I also see
> issues with transferring large 802.15.4g frames over control endpoints.
> Something similar like CDC-ECM would be my preference here: Split the
> frame in multiple bulk transfers and detect the end of the frame by a
> transfer size not equal to the endpoint size.

For the above I completely ignore the move to bulk. This still needs doing.

>> o Add a GET_EXTENDED_ADDR command to receive the extended address
>> provided by the transceiver itself, or firmware in some way.
> +1

My take on this is in the above branch.

>> o Adding a GET_CAPABILITIES command to query device capabilities
>>   during init to enable and set needed ieee802154_ops based on the
>> device. Given that we aim to support as many transceivers as possible
>> we can't rely on static device knowledge to configure wpanusb correctly.

I started to work on this. The real questions is are we passing all the 
frequency bands and others settings through the USB spec or are we going 
with tables for these inside the firmware and driver and only reference 
them? The later is more efficient the first one is more flexible and 
likely more extensible for future changes.


> Does it make sense to include also a "protocol" version here, to allow
> extending the feature set of the driver later without causing
> compatibility issues between the firmware and the kernel?

How about we are using the USB version part of the descriptor for this? 
We would identify a newer version device not only the spec. The device 
handling could work on both.

>>
>> o Add opcode for set_lbt in USB spec

Added a first take on this.

> This requires some clarification for me how the radio should be
> configured. Is this just a CSMA/CCA switch?
>>
>> o Add opcode for set_frame_retries USB spec. (If a transceiver does
>> not support AutoACK in hardware do Zephyr and RIOT support a software
>> fallback to handle AutoACK?)

Added a first take on this. Needs USB helper functions to handle the 
config data being passed to the device.

> This can be implemented in RIOT. I don't think there is something in
> place at the moment, most of our radios support this in hardware, but I
> see no technical reason why not to support this.
>>
>> o How are we going to handle transceiver which allow MTUs > 127? Not a
>> high priority as the kernel part does not support this either right now.
> There is some preliminary support for 802.15.4g radios in RIOT. I know
> some developers that would prefer not to have to have the MTU limited to
> 127 bytes :)

This is completely ignored for now.

>> o Do Zephyr or RIOT expose additional functionality we should support
>> here?
>>
>> o Koen, you offered to look into implementing the firmware support for
>> the USB spec in RIOT. Does the spec fit what RIOT has as abstraction
>> for ieee802154?
> 
> Yes, implementing configuration settings as USB control messages makes
> glueing them to the radio abstraction layer very easy. For now RIOT has
> configuration for:
> 
>   - reading and writing channel/page settings
>   - read/write to addresses, both long and short
>   - PAN ID
>   - TX power settings
>   - reading the max PSDU size
>   - Ack config settings
>   - CCA and CSMA configuration, enabling/disabling, retries and backoff
> exponent (max/min)
>   - CCA threshold and mode
> 
> Furthermore, it is possible to get frame metadata such as the received
> signal strength and the number of retries required for the frame
> transmit. All these settings depend a bit on the radio hardware features
> of course, but thats what we have the GET_CAPABILITIES for.

If I have time to do more work on this I will update you folks. As I 
wrote above. Read over it and feel free to use any of the above or 
implement it yourself.

Looking forward to the progress on this when back from my vacation. :-)

regards
Stefan Schmidt

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, back to index

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-25 12:39 wpanusb? Christopher Friedt
2020-05-26 19:38 ` wpanusb? Stefan Schmidt
2020-05-29 19:33   ` wpanusb? Christopher Friedt
2020-05-30 11:33     ` wpanusb? Stefan Schmidt
2020-05-30 15:08       ` wpanusb? Christopher Friedt
2020-05-30 18:10         ` wpanusb? Koen Zandberg
2020-05-31 16:13           ` wpanusb? Christopher Friedt
2020-06-03 18:18             ` wpanusb? Stefan Schmidt
2020-06-05 11:07               ` wpanusb? Koen Zandberg
2020-06-07 12:17                 ` wpanusb? Stefan Schmidt
2020-07-06 14:42                   ` wpanusb? Stefan Schmidt
     [not found]                     ` <CAF4BF-TdLpg6hCc8iiR40tGmV9C5EPDF6c6Qr5m5CfDWOVJUMA@mail.gmail.com>
2020-07-23  8:15                       ` wpanusb? Stefan Schmidt
2020-07-24 13:26                       ` wpanusb? Stefan Schmidt
2020-07-24 13:41                 ` wpanusb? Stefan Schmidt

Linux-WPAN Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-wpan/0 linux-wpan/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-wpan linux-wpan/ https://lore.kernel.org/linux-wpan \
		linux-wpan@vger.kernel.org
	public-inbox-index linux-wpan

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-wpan


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git