Re: [PATCH v6 00/36] Andes(nds32) Linux Kernel Port

[Arnd Bergmann <arnd@arndb.de>]

On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu <green.hu@gmail.com> wrote:
> This is the 6th version patchset to add the Linux kernel port for Andes(nds32)
> processors. Almost all of the feedbacks from v5 patchseries has been addressed.
> Thanks to everyone who provided feedback on the previous version.
>
>
> This patchset adds core architecture support to Linux for Andestech's
> N13, N15, D15, N10, D10 processor cores.
>
> Based on the 16/32-bit AndeStar RISC-like architecture, we designed the
> configurable AndesCore series of embedded processor families. AndesCores
> range from highly performance-efficient small-footprint cores for
> microcontrollers and deeply-embedded applications to 1GHz+ cores running
> Linux, covering general-purpose N-series cores for a wide range of computing
> need, DSP-capable D-series cores for digital signal control,
> instruction-extensible E-series cores for application-specific acceleration,
> and secure S-series cores for best protection of the most valuable.
>
> The patches are based on v4.14-rc8, and can also be found in the
> following git tree:
>   https://github.com/andestech/linux.git nds32-4.14-rc8-v6
>
> The build script and toolchain repositories are able to be found here:
>   https://github.com/andestech/build_script.git
>
> Freely available instruction set and architecture overview documents can
> be found on the following page:
>   http://www.andestech.com/product.php?cls=9
>
>
> Vincent Ren-Wei Chen and I will maintain this port. Thanks to everyone who
> helped us and contributed to it. :) Any feedback is welcome.

Hi Greentime,

I think it's time to move this to the next step towards inclusion, as you appear
to have addressed all major issues, and only smaller details remain.

This is what I'd suggest for moving forward:

- split the patches into two branches in git: one 'next' branch for
everything that
  is ready to get merged in one pull request that you send to Linus, including
  drivers that you have received an Ack for from the respective subsystem
  maintainers, and one 'testing' branch for anything that is either
not quite ready
  or that you expect to get merged through someone else's tree (e.g.
  most device drivers). The 'testing' branch can merge in the 'next' branch
  or get rebased on it frequently.

- Ask reviewers to send 'Acked-by' or 'Reviewed-by' tags for the patches they
  are happy with, or to complain if they still see any major issues that
  should prevent the series from going in. I'll go through the submission once
  more myself and Ack any patches that I have actually reviewed.

- Decide what base to use for the 'next' branch, rebase it on that release one
  more time and then plan to never rebase it again. This will be the branch
  to send to linux-next and to Linus Torvalds. Given the current timing of the
  merge window, I would suggest to base it on top of v4.16-rc1 once that
  gets released, and then send it for inclusion in 4.17. Any changes you do
  in the meantime would be added on top of the original set.

- Ask Stephen Rothwell to include your 'next' branch in linux-next.
  (if you base on 4.16-rc1, wait until that is out).

- Submit any remaining driver patches that you do not have an 'Ack' for to
  the respective subsystem maintainers for inclusion in their trees.

- Upload a gpg key (4096 bits) for your greentime@andestech.com address
  to the keyservers, and arrange to have that signed by other kernel
  developers. You will need to sign git tags for pull requests with your
  key, and the key itself should be signed for this to work best.

- Once you have at least three signatures on your gpg key, apply for
  an account on kernel.org and move your git tree there,
  see https://www.kernel.org/category/faq.html. Alternatively,
  host the git tree on a web-facing git server from andestech.com
  (github works initially, but has a couple of shortcomings).

         Arnd