Web lists-archives.com

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
>>   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.


> 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.