Re: RISC-V Linux Port v6

[Will Deacon <will.deacon@arm.com>]

On Wed, Jul 12, 2017 at 09:58:01AM +0200, Arnd Bergmann wrote:
> On Wed, Jul 12, 2017 at 3:31 AM, Palmer Dabbelt <palmer@dabbelt.com> wrote:
> > While it's only been a day since the last patch set (which might be a bit
> > fast), I've generally been spinning new patch sets whenever I get through my
> > inbox.  For my other patch sets I've managed to get buried in a week's worth of
> > email in a few hours, but for this one it appears there's been significantly
> > less feedback so I've managed to get through everything.  I'm hoping that's a
> > good sign: either I've started to figure out what I'm doing or the code has
> > gotten better -- hopefully it doesn't mean everyone else has given up :).
> 
> I don't seem have received the last few versions, but I did get this one,
> good to see the progress!
> 
> A few general notes for the next version:
> 
> - please always include the patch version in the subject for each
>   patch, as 'git format-patch -v 7' will do.
> 
> - In the introductory mail, list the entire history since v1 if you can
>   reconstruct it. I'm pretty lost now keeping track of earlier versions
>   and what has changed compared to this one, so I'd have to start
>   reviewing from scratch.
> 
> > As it's been only a day, the changes are pretty minimal:
> >
> >  * The patch set is now based on linux-next/master, which I believe is a better
> >    base now that we're getting closer to upstream.
> 
> It's not entirely clear though. Until the end of the merge window, this is fine,
> as stuff in linux-next today is likely to end up in 4.13-rc1 on Sunday.
> However, once -rc1 is out, you should base your patches on that to
> get a bisectable patch series once it is merged. If there are conflicts
> or dependencies on other trees that get scheduled for 4.14, we have
> to see how to resolve them one at a time.
> 
> > At this point I'm not really sure how to proceed: reviews have calmed down
> > quite a bit over the last two weeks, but I'm not familiar with the Linux
> > development process enough to know how to get closer to upstream.  Is this
> > ready for inclusion into another tree?  If so, is linux-next the right tree to
> > work off of?
> 
> Without having looked at the current state of the patch series, I would
> guess that next week is a good time to ask for inclusion *in* linux-next,
> while continuing the review.

My only concern about getting this into -next is that is sets expectations
that this is going to land in the next merge window, but we're unable to
review much of the atomics, barriers and locking code because the
architecture document is being rewritten and is not yet available:

https://marc.info/?i=8709419e3d964b86b025bb35a6b55440%40HQMAIL105.nvidia.com

Will