On Wed, 13 Sep 2017 09:15:39 PDT (-0700), Arnd Bergmann wrote: > On Tue, Sep 12, 2017 at 11:56 PM, Palmer Dabbelt <palmer@xxxxxxxxxxx> wrote: >> I know it may not be the ideal time to submit a patch set right now, as it's >> the middle of the merge window, but things have calmed down quite a bit in the >> last month so I thought it would be good to get everyone on the same page. >> There's been a handful of changes since the last patch set, but most of them >> are fairly minor: >> >> * We changed PAGE_OFFSET to allowing mapping more physical memory on 64-bit >> systems. This is user configurable, as it triggers a different code model >> that generates slightly less efficient code. >> * The device tree binding documentation is back, I'd managed to lose it at some >> point. >> * We now pass the atomic64 test suite. >> * The SBI timer driver has been refactored. >> >> To the best of by knowledge, all the feedback we've gotten so far has been >> taken into account for this patch set. If I've missed anyone's feedback I'm >> sorry, just point it out and I'll try to dig it up. >> >> Just to be clear on timelines: we're not pushing to get into 4.14, but we are >> hoping we can make it in for 4.15. If I understand the process correctly, we >> should aim to get into linux-next some time in the next month so we can be >> merged during the next merge window. > > I looked at all patches again and found a few minor things that we > should clarify, but overall I think this looks good. Thanks! > What I think you should do as the next step is to separate the > architecture specific changes from the device drivers and put > them into one branch that you ask Stephen Rothwell to add to > linux-next. OK. Would it be possible to get the MAINTAINERS patch merged as part of this merge window? If I'm ready to actually start getting things merged I'd like to have a proper tree and I've been told this is a prerequisite. > For the driver patches, I would submit them separately now > with a reduced Cc-list that just contains the respective > subsystem maintainers as well as the relevant mailing lists. Makes sense. I'll wait a bit for some more feedback and if there's nothing major then I'll split things up for the v9. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html