pull-request: ieee802154 2018-05-08

pull-request: ieee802154 2018-05-08

[Stefan Schmidt]

Hello Dave.

An update from ieee802154 for your *net* tree.

Two fixes for the mcr20a driver, which was being added in the 4.17 merge window,
by Gustavo and myself.
The atusb driver got a change to GFP_KERNEL where no GFP_ATOMIC is needed by
Jia-Ju.

The last and most important fix is from Alex to get IPv6 reassembly working
again for the ieee802154 6lowpan adaptation. This got broken in 4.16 so please
queue this one also up for the 4.16 stable tree.

regards
Stefan Schmidt

The following changes since commit aa8f8778493c85fff480cdf8b349b1e1dcb5f243:

  ipv6: add RTA_TABLE and RTA_PREFSRC to rtm_ipv6_policy (2018-04-23 12:01:21 -0400)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan.git ieee802154-for-davem-2018-05-08

for you to fetch changes up to f18fa5de5ba7f1d6650951502bb96a6e4715a948:

  net: ieee802154: 6lowpan: fix frag reassembly (2018-04-23 20:56:24 +0200)

----------------------------------------------------------------
Alexander Aring (1):
      net: ieee802154: 6lowpan: fix frag reassembly

Gustavo A. R. Silva (1):
      ieee802154: mcr20a: Fix memory leak in mcr20a_probe

Jia-Ju Bai (1):
      net: ieee802154: atusb: Replace GFP_ATOMIC with GFP_KERNEL in atusb_probe

Stefan Schmidt (1):
      net: ieee802154: mcr20a: do not leak resources on error path

 drivers/net/ieee802154/atusb.c      |  2 +-
 drivers/net/ieee802154/mcr20a.c     | 15 ++++++++++-----
 net/ieee802154/6lowpan/6lowpan_i.h  |  4 ++--
 net/ieee802154/6lowpan/reassembly.c | 14 +++++++-------
 4 files changed, 20 insertions(+), 15 deletions(-)

Re: pull-request: ieee802154 2018-05-08

[David Miller]

From: Stefan Schmidt <s.schmidt@samsung.com>
Date: Tue,  8 May 2018 10:29:27 +0200

> An update from ieee802154 for your *net* tree.
> 
> Two fixes for the mcr20a driver, which was being added in the 4.17 merge window,
> by Gustavo and myself.
> The atusb driver got a change to GFP_KERNEL where no GFP_ATOMIC is needed by
> Jia-Ju.
> 
> The last and most important fix is from Alex to get IPv6 reassembly working
> again for the ieee802154 6lowpan adaptation. This got broken in 4.16 so please
> queue this one also up for the 4.16 stable tree.

Pulled, thanks.

Please submit the -stable fix directly, you can feel free to CC: me.

Thank yuo.

Re: pull-request: ieee802154 2018-05-08

[Stefan Schmidt]

Hello.


On 05/08/2018 04:18 PM, David Miller wrote:
> From: Stefan Schmidt <s.schmidt@samsung.com>
> Date: Tue,  8 May 2018 10:29:27 +0200
>
>> An update from ieee802154 for your *net* tree.
>>
>> Two fixes for the mcr20a driver, which was being added in the 4.17 merge window,
>> by Gustavo and myself.
>> The atusb driver got a change to GFP_KERNEL where no GFP_ATOMIC is needed by
>> Jia-Ju.
>>
>> The last and most important fix is from Alex to get IPv6 reassembly working
>> again for the ieee802154 6lowpan adaptation. This got broken in 4.16 so please
>> queue this one also up for the 4.16 stable tree.
> Pulled, thanks.

Thanks.
>
> Please submit the -stable fix directly, you can feel free to CC: me.

Will do when the patch hits Linus git tree.

I have a quick question on the process here. From the netdev-faq document
I was under the impression all stable patches under net/ and drivers/net
should be brought up to you and would be handled by you.

Does this apply to the core part of net (I fully understand that ieee802154
is rather a niche) or is there some other reason for this exception?

Both processes (the normal stable one as well as the slightly different one
for net/) would be fine to go with for me. Just need to know which one I
should use for future stable patches. :-)

regards
Stefan Schmidt

Re: pull-request: ieee802154 2018-05-08

[David Miller]

From: Stefan Schmidt <stefan@osg.samsung.com>
Date: Tue, 8 May 2018 21:55:37 +0200

> On 05/08/2018 04:18 PM, David Miller wrote:
>> Please submit the -stable fix directly, you can feel free to CC: me.
> 
> Will do when the patch hits Linus git tree.
> 
> I have a quick question on the process here. From the netdev-faq document
> I was under the impression all stable patches under net/ and drivers/net
> should be brought up to you and would be handled by you.
> 
> Does this apply to the core part of net (I fully understand that ieee802154
> is rather a niche) or is there some other reason for this exception?
> 
> Both processes (the normal stable one as well as the slightly different one
> for net/) would be fine to go with for me. Just need to know which one I
> should use for future stable patches. :-)
> 
> regards
> Stefan Schmidt

Generally wireless and ipsec have been submitting them directly,
sometimes the Intel ethernet guys do too.

Sometimes this makes things easier for me, and I'll ask you to submit
things directly when that is the case like right now.

Thank you.

Re: pull-request: ieee802154 2018-05-08

[Stefan Schmidt]

Hello.


On 05/09/2018 02:06 AM, David Miller wrote:
> From: Stefan Schmidt <stefan@osg.samsung.com>
> Date: Tue, 8 May 2018 21:55:37 +0200
>
>> On 05/08/2018 04:18 PM, David Miller wrote:
>>> Please submit the -stable fix directly, you can feel free to CC: me.
>> Will do when the patch hits Linus git tree.
>>
>> I have a quick question on the process here. From the netdev-faq document
>> I was under the impression all stable patches under net/ and drivers/net
>> should be brought up to you and would be handled by you.
>>
>> Does this apply to the core part of net (I fully understand that ieee802154
>> is rather a niche) or is there some other reason for this exception?
>>
>> Both processes (the normal stable one as well as the slightly different one
>> for net/) would be fine to go with for me. Just need to know which one I
>> should use for future stable patches. :-)
>>
>> regards
>> Stefan Schmidt
> Generally wireless and ipsec have been submitting them directly,
> sometimes the Intel ethernet guys do too.
>
> Sometimes this makes things easier for me, and I'll ask you to submit
> things directly when that is the case like right now.

Thanks for taking the time to explain it. I will go ahead and handle
the stable patches for ieee802154 directly from now on. If you want
to have this changed again just let me know.

regards
Stefan Schmidt