Hi, Thanks for your comment. On Tue, Sep 01, 2020 at 09:50:56AM +0200, Arnd Bergmann wrote: > 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. > No problem. > 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. > Thank you for the detailed explanation. The above explanation was very useful. > Arnd > Best regards, Nobuhiro
