Patch submission process about at91 DTS

Patch submission process about at91 DTS

[Kévin Raymond]

Hi there,

We have several at91-kizbox* DTSs and I have few patches to suggest.
The idea is to split one dts over dtsi + several dts.

My current patches are based an tested over the linux repo[0] against the
master branch (4e19652 Update the RISC-V MAINTAINERS file).

Should I rebase them against the linux-at91[1] repository? Which branch,
at91-next? I would love them to reach the 4.14 branch but am not sure of
the right path to submit those changes.

Thanks for your help,

[0]_git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[1]_git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git

--
K?vin Raymond
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180131/07360d40/attachment.sig>

Patch submission process about at91 DTS

[Alexander Dahl]

Hello K?vin,

Am Mittwoch, 31. Januar 2018, 18:04:53 CET schrieb K?vin Raymond:
> My current patches are based an tested over the linux repo[0] against the
> master branch (4e19652 Update the RISC-V MAINTAINERS file).
> 
> Should I rebase them against the linux-at91[1] repository? Which branch,
> at91-next? I would love them to reach the 4.14 branch but am not sure of
> the right path to submit those changes.

As far as I understood the process, it is common to base those patches on the 
last tag of Linus' tree at the time sending. At the moment this would be 
v4.15, in two weeks it will be v4.16-rc1. If you rebase it on top another 
tree, add this information to your introductory mail.

Greets
Alex

Patch submission process about at91 DTS

[Florian Vaussard]

Hi K?vin,

Le 31. 01. 18 ? 18:04, K?vin Raymond a ?crit?:
> Hi there,
> 
> We have several at91-kizbox* DTSs and I have few patches to suggest.
> The idea is to split one dts over dtsi + several dts.
> 
> My current patches are based an tested over the linux repo[0] against the
> master branch (4e19652 Update the RISC-V MAINTAINERS file).
> 
> Should I rebase them against the linux-at91[1] repository? Which branch,
> at91-next? I would love them to reach the 4.14 branch but am not sure of
> the right path to submit those changes.
> 

Linux 4.14 is already out, so only patches for a stable release can be
backported. See in Documentation/process/stable-kernel-rules.rst for the
rules. I guess that your patches do not apply for stable. So your patches
will be applied to a latter release (4.16 if you are lucky as the merge window
is now opened but most probably 4.17+).

For the submission process itself, please read Documentation/process/* and
especially "5.Posting.rst" and "submitting-patches.rst". There is also a
documentation specific to DT patches in Documentation/devicetree/bindings/
submitting-patches.txt.

TL;DR look into the MAINTAINERS file or use ./scripts/get_maintainer.pl.
For your AT91 patches, you should CC the maintainers:

- Nicolas Ferre <nicolas.ferre@microchip.com>
- Alexandre Belloni <alexandre.belloni@free-electrons.com>

You should also CC the DT mainling list.

Finally the AT91 Git tree is here [1]. Use that unless told differently by the
maintainers.

Best,
Florian

[1] git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git

Patch submission process about at91 DTS

[Nicolas Ferre]

On 01/02/2018 at 10:03, Florian Vaussard wrote:
> Hi K?vin,

Thanks to you Florian and Alexander for having answered to K?vin!

> Le 31. 01. 18 ? 18:04, K?vin Raymond a ?crit?:
>> Hi there,
>>
>> We have several at91-kizbox* DTSs and I have few patches to suggest.
>> The idea is to split one dts over dtsi + several dts.

When you talk about "several"... what is the rough amount?

We are using this arrangement on our own "vendor tree" branches and
tried to not send too much .dts variants to Mainline... We now plan to
move to something more maintainable and elegant like the DT overlays.
They will be loaded by the bootloader and certainly stored in our own
overlays git repository.

What about just having a superset in Mainline and providing variants on
your own repository? Beware of thinking about maintenance while sending
a big amount of .dts variants to Mainline...

>> My current patches are based an tested over the linux repo[0] against the
>> master branch (4e19652 Update the RISC-V MAINTAINERS file).
>>
>> Should I rebase them against the linux-at91[1] repository? Which branch,
>> at91-next? I would love them to reach the 4.14 branch but am not sure of
>> the right path to submit those changes.
>>
> 
> Linux 4.14 is already out, so only patches for a stable release can be
> backported. See in Documentation/process/stable-kernel-rules.rst for the
> rules. I guess that your patches do not apply for stable. So your patches
> will be applied to a latter release (4.16 if you are lucky as the merge window
> is now opened but most probably 4.17+).
> 
> For the submission process itself, please read Documentation/process/* and
> especially "5.Posting.rst" and "submitting-patches.rst". There is also a
> documentation specific to DT patches in Documentation/devicetree/bindings/
> submitting-patches.txt.
> 
> TL;DR look into the MAINTAINERS file or use ./scripts/get_maintainer.pl.
> For your AT91 patches, you should CC the maintainers:
> 
> - Nicolas Ferre <nicolas.ferre@microchip.com>
> - Alexandre Belloni <alexandre.belloni@free-electrons.com>
> 
> You should also CC the DT mainling list.
> 
> Finally the AT91 Git tree is here [1]. Use that unless told differently by the
> maintainers.
> 
> Best,
> Florian
> 
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/nferre/linux-at91.git

Yes, this tree is mostly useful for its up-to-date at91-next branch.

Alexandre's git tree is here:
https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git/
And it's usually where Alexandre build the topic branches that will be
sent to upstream (arm-soc actually).

So, both at91-next branch on my tree or at91-dt on Alexandre's one
usually do the trick.

Anyway, we'll communicate with you if anything needs to be enhanced on
your patches.

Best regards,
-- 
Nicolas Ferre