Message ID | 1508200182-104605-1-git-send-email-keescook@chromium.org |
---|---|
Headers | show |
Series | networking: Convert timers to use timer_setup() | expand |
+ linux-wireless Hi Kees, Kees Cook <keescook@chromium.org> writes: > This is the current set of outstanding networking patches to perform > conversions to the new timer interface (rebased to -next). This is not > all expected conversions, but it contains everything needed in networking > to eliminate init_timer(), and all the non-standard setup_*_timer() uses. So this also includes patches which I had queued for wireless-drivers-next: https://patchwork.kernel.org/patch/9986253/ https://patchwork.kernel.org/patch/9986245/ And looking at patchwork[1] I have even more timer_setup() related patches from you. It would be really helpful if you could clearly document to which tree you want the patches to be applied. I don't care if it's net-next or wireless-drivers-next as long as it's not the both (meaning that both Dave and me apply the same patch, which would be bad). The thing is that I really do not have time to figure out for every patch via which tree it's supposed to go. For now I'll just drop all your timer_setup() related patches from my queue and I'll assume Dave will take those. Ok? [1] https://patchwork.kernel.org/project/linux-wireless/list/
On Tue, Oct 17, 2017 at 7:18 AM, Kalle Valo <kvalo@codeaurora.org> wrote: > + linux-wireless > > Hi Kees, > > Kees Cook <keescook@chromium.org> writes: > >> This is the current set of outstanding networking patches to perform >> conversions to the new timer interface (rebased to -next). This is not >> all expected conversions, but it contains everything needed in networking >> to eliminate init_timer(), and all the non-standard setup_*_timer() uses. > > So this also includes patches which I had queued for > wireless-drivers-next: > > https://patchwork.kernel.org/patch/9986253/ > https://patchwork.kernel.org/patch/9986245/ > > And looking at patchwork[1] I have even more timer_setup() related > patches from you. It would be really helpful if you could clearly > document to which tree you want the patches to be applied. I don't care Hi! Sorry about that. It's been a bit tricky to juggle everything. > if it's net-next or wireless-drivers-next as long as it's not the both > (meaning that both Dave and me apply the same patch, which would be > bad). The thing is that I really do not have time to figure out for > every patch via which tree it's supposed to go. Which split is preferred? I had been trying to separate wireless from the rest of net (but missed some cases). > For now I'll just drop all your timer_setup() related patches from my > queue and I'll assume Dave will take those. Ok? > > [1] https://patchwork.kernel.org/project/linux-wireless/list/ I guess I'll wait to see what Dave says. Thanks! -Kees
Kees Cook <keescook@chromium.org> writes: > On Tue, Oct 17, 2017 at 7:18 AM, Kalle Valo <kvalo@codeaurora.org> wrote: >> + linux-wireless >> >> Hi Kees, >> >> Kees Cook <keescook@chromium.org> writes: >> >>> This is the current set of outstanding networking patches to perform >>> conversions to the new timer interface (rebased to -next). This is not >>> all expected conversions, but it contains everything needed in networking >>> to eliminate init_timer(), and all the non-standard setup_*_timer() uses. >> >> So this also includes patches which I had queued for >> wireless-drivers-next: >> >> https://patchwork.kernel.org/patch/9986253/ >> https://patchwork.kernel.org/patch/9986245/ >> >> And looking at patchwork[1] I have even more timer_setup() related >> patches from you. It would be really helpful if you could clearly >> document to which tree you want the patches to be applied. I don't care > > Hi! Sorry about that. It's been a bit tricky to juggle everything. Yeah, I understand. >> if it's net-next or wireless-drivers-next as long as it's not the both >> (meaning that both Dave and me apply the same patch, which would be >> bad). The thing is that I really do not have time to figure out for >> every patch via which tree it's supposed to go. > > Which split is preferred? I had been trying to separate wireless from > the rest of net (but missed some cases). So what we try to follow is that I apply all patches for drivers/net/wireless to my wireless-drivers trees, with exception of Johannes taking mac80211_hwsim.c patches to his mac80211 trees. And Johannes of course takes all patches for net/wireless and net/mac80211. So in general I prefer that I take all drivers/net/wireless patches and make it obvious for Dave that he can ignore those patches (not mix wireless-drivers and net patches into same set etc). But like I said, it's ok to push API changes like these via Dave's net trees as well if you want (and if Dave is ok with that). The chances of conflicts is low, and if there are be any those would be easy to fix either by me or Dave. >> For now I'll just drop all your timer_setup() related patches from my >> queue and I'll assume Dave will take those. Ok? >> >> [1] https://patchwork.kernel.org/project/linux-wireless/list/ > > I guess I'll wait to see what Dave says. Ok, I don't drop the patches from my queue quite yet then.
From: Kees Cook <keescook@chromium.org> Date: Mon, 16 Oct 2017 17:28:44 -0700 > This is the current set of outstanding networking patches to perform > conversions to the new timer interface (rebased to -next). This is not > all expected conversions, but it contains everything needed in networking > to eliminate init_timer(), and all the non-standard setup_*_timer() uses. I've applied this except: 1) the IRDA stuff, it's staging and needs to go via Greg KH 2) the MPC ATM didn't apply at all to net-next Such a huge patch series like this is a huge burdon upon a subsystem maintainer. Split this kind of stuff up into manageable chunks next time, maybe a dozen patches at a time. Do not submit multiple series at once to get around this size limit. Submit one at a time, wait for it to get applied, and then after that you can submit the next one. Thanks.
On Wed, Oct 18, 2017 at 4:42 AM, David Miller <davem@davemloft.net> wrote: > From: Kees Cook <keescook@chromium.org> > Date: Mon, 16 Oct 2017 17:28:44 -0700 > >> This is the current set of outstanding networking patches to perform >> conversions to the new timer interface (rebased to -next). This is not >> all expected conversions, but it contains everything needed in networking >> to eliminate init_timer(), and all the non-standard setup_*_timer() uses. > > I've applied this except: > > 1) the IRDA stuff, it's staging and needs to go via Greg KH Ah yes, thanks. I didn't update the Subject when I followed the path change into staging. I'll redirect this to Greg. > 2) the MPC ATM didn't apply at all to net-next Okay, I will respin it again and collect more conversions before sending the next batch. > Such a huge patch series like this is a huge burdon upon > a subsystem maintainer. Agreed, and I'm very thankful you've made time to dig through this pile. I've tried to minimize the number of separate patches, since many cases can be mechanically updated with Coccinelle (which we'll do at the tail end of this conversion). > Split this kind of stuff up into manageable chunks next time, > maybe a dozen patches at a time. Do not submit multiple > series at once to get around this size limit. Submit one > at a time, wait for it to get applied, and then after that > you can submit the next one. Okay, I'll limit postings to a dozen. I think I'll need to maintain separate trees for each subsystem's batches. I've been splitting them up manually out of one single giant tree, which has been ... insane. Thanks again! -Kees
On Tue, Oct 17, 2017 at 10:44 PM, Kalle Valo <kvalo@codeaurora.org> wrote: > Kees Cook <keescook@chromium.org> writes: >> Which split is preferred? I had been trying to separate wireless from >> the rest of net (but missed some cases). > > So what we try to follow is that I apply all patches for > drivers/net/wireless to my wireless-drivers trees, with exception of > Johannes taking mac80211_hwsim.c patches to his mac80211 trees. And > Johannes of course takes all patches for net/wireless and net/mac80211. > > So in general I prefer that I take all drivers/net/wireless patches and > make it obvious for Dave that he can ignore those patches (not mix > wireless-drivers and net patches into same set etc). But like I said, > it's ok to push API changes like these via Dave's net trees as well if > you want (and if Dave is ok with that). The chances of conflicts is low, > and if there are be any those would be easy to fix either by me or Dave. Okay, great. That'll help. I'll wait for the dust to settle and rebase against -next, and then I'll see what's outstanding and double-check where they need to be sent (and I'll queue new conversions up accordingly too). >>> For now I'll just drop all your timer_setup() related patches from my >>> queue and I'll assume Dave will take those. Ok? >>> >>> [1] https://patchwork.kernel.org/project/linux-wireless/list/ >> >> I guess I'll wait to see what Dave says. > > Ok, I don't drop the patches from my queue quite yet then. Alright, thanks very much! -Kees