| Message ID | 20180508082927.7928-1-s.schmidt@samsung.com |
|---|---|
| State | Accepted, archived |
| Delegated to: | David Miller |
| Headers | show |
| Series | pull-request: ieee802154 2018-05-08 | expand |
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.
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
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.
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
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(-)