Re: [PATCH v3 0/8] Add Toshiba Visconti ARM64 Platform support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux