On Tue, Sep 1, 2020 at 12:41 AM Nobuhiro Iwamatsu
<nobuhiro1.iwamatsu@xxxxxxxxxxxxx> wrote:
> On Mon, Aug 31, 2020 at 11:19:02AM +0200, Arnd Bergmann wrote:
> > On Mon, Aug 31, 2020 at 10:10 AM Nobuhiro Iwamatsu
> > <nobuhiro1.iwamatsu@xxxxxxxxxxxxx> wrote:
> > >
> > > Visconti is a series of Toshiba's SoCs targeting image processing
> > > applications[0]. These set of patches adds support for Visconti5 a Arm
> > > v8 based SoC.
> > >
> > > The series add minimal support for the Visconti5 SoC and the TMPV7708 RM
> > > main board. Peripherals such as UART, SPI, I2c and timer use Arm's
> > > IP and work with the existing kernel drivers in the tree. The series
> > > includes a pinctrl driver to select appropriate functions on the pins.
> >
> > The arch/arm64 series looks all reasonable to me, nice work!
> >
> > Once the review from the DT and pinctrl maintainers is completed
> > and you have received their Acked-by or Reviewed-by tags, please
> > send the series with those tags to soc@xxxxxxxxxx for inclusion, keeping
> > everyone else on Cc.
> >
> > I'd leave it up to Linus Walleij whether he wants to merge the pinctrl driver
> > through his subsystem tree, or whether we should pick it up through
> > the soc tree, either way works for the initial merge. For any updates to
> > the pinctrl driver and additional subsystem support (clk, media, ...)
> > in later releases there is no need to Cc the SoC maintainers as those
> > should just get merged through the subsystem while we take care
> > of the DT files.
>
> Thank you for the explanation. I will do that.
> BTW, I searched the process for this but I couldn't find any detailed
> documentation. Could you tell me if you know?
We never documented this well, sorry about that.
Generally speaking, if you only have small updates (a few patches
at a time), feel free to send those patches to soc@xxxxxxxxxx once
you consider them ready for inclusion.
On 32-bit architectures as well as the more widely used 64-bit
platforms with many .dts files, please send pull requests that group
the patches into logical topics. Once you are listed in the
MAINTAINERS file and you want to host a git tree on git.kernel.org
for that purpose, you can apply for a kernel.org account and
send pull request from there as well as have the tree integrated
into linux-next for earlier testing. On the more specialized platforms
without third-party machine support in the kernel, that is usually not
necessary.
In either case, patches and pull requests should be based on
an early -rc tag from mainline Linux (normally -rc1) and get sent
between -rc1 and roughly -rc5 for new features. Bug fixes can
be sent at any time regardless of the current -rc, with a balance
between sending them quickly and collecting multiple of them
into a pull request to reduce the number of merges. Please let
us know whether bug fixes should be applied only at the next
merge window, on current kernels, or backported to previous
releases, using the "Fixes:" and "Cc: stable@xxxxxxxxxxxxxxx"
tags as appropriate. The default is to backport bug fixes as far
back as they apply, unless there is a reason not to.
Arnd
