Re: RISC-V Linux Port v8
- Date: Wed, 13 Sep 2017 13:18:17 -0700 (PDT)
- From: Palmer Dabbelt <palmer@xxxxxxxxxxx>
- Subject: Re: RISC-V Linux Port v8
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
>> * 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.
> 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
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.