Re: 802.15.4-2020 PHR field changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Fri, Sep 13, 2024 at 3:53 PM Stefan Schmidt
<stefan@xxxxxxxxxxxxxxxxxx> wrote:
>
> Hello,
>
> On 9/13/24 12:59 AM, Alexander Aring wrote:
> > Hi,
> >
> > On Mon, Sep 9, 2024 at 8:19 PM James Hanley <jhanley@xxxxxxxxxxxx> wrote:
> >>
> >> Has there been any effort to understand the changes needed to include/net/ieee802154.h and associated files within drivers/net/ieee802154 to support the ratification of 15.4-2020?  One prime example is the "Extended PHR" bit which was previously reserved to now allow extend the PHR of 2 more octets giving bits 8-11 to be used for "Frame Length MSB" and bits 12-15 marked as "Reserved" - this in combination of the legacy PHR bits 0-6 labeled as "Frame Length LSB" now allows for a frame MTU of 2048 octets.
> >>
> >> The 802.15.4-2020 is available individually free of charge through the IEEE website through the IEEE Get Program. https://ieeexplore.ieee.org/document/9144691
> >>
> >> Is there a way to prototype these new changes to the spec with the mac802154_hwsim driver?
> >>
> >
> > mac802154_hwsim driver uses mac802154 the SoftMAC implementation.
> > There are quite more changes necessary as the whole mac802154 stack
> > deals with static 127 bytes MTU defines, etc. Unfortunately, it isn't
> > just a driver change.
>
> I understand it the way that James actually wanted to try prototyping
> stack changes and verify with hwsim. James, could you clarify?
>

Why shouldn't this be possible? Of course it should and I would
definitely want to see it when adding any support for that for the
rest that's being involved. The "rest" is probably most of the work.

> To answer your question, we currently have no support for any of the
> newer 802154 specs. :/ Bigger MTU was brought up before (IIRC in the
> subGHz context) but nobody started to actually work on it.
>
> We are happy to take changes in, but currently we have no plans on our
> side to get this going.
>

yea, just send patches. I am open to starting with hwsim to support
kind of such a "bigger mtu" phy "type" as long it doesn't break the
kernel and finding the spots that need to be somehow changed.

- Alex






[Index of Archives]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux