diff mbox series

[v2,1/6] riscv: dts: sifive unmatched: Name gpio lines

Message ID bb7e8e36425a2c243cfbf03a23af525499268822.1637107062.git.plr.vincent@gmail.com (mailing list archive)
State New, archived
Headers show
Series [v2,1/6] riscv: dts: sifive unmatched: Name gpio lines | expand

Commit Message

Vincent Pelletier Nov. 16, 2021, 11:57 p.m. UTC
Follow the pin descriptions given in the version 3 of the board schematics.

Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com>

--
Changes since v1:
- Remove trailing "." on subject line.
---
 arch/riscv/boot/dts/sifive/hifive-unmatched-a00.dts | 4 ++++
 1 file changed, 4 insertions(+)

Comments

Krzysztof Kozlowski Nov. 17, 2021, 9:28 a.m. UTC | #1
On 17/11/2021 00:57, Vincent Pelletier wrote:
> Follow the pin descriptions given in the version 3 of the board schematics.
> 
> Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com>
> 
> --
> Changes since v1:
> - Remove trailing "." on subject line.
> ---

This is not a correct changelog placement - you have to use '---' just
like git uses it. Just test it yourself and you will see the problem.

Best regards,
Krzysztof
Vincent Pelletier Nov. 18, 2021, 12:34 a.m. UTC | #2
On Wed, 17 Nov 2021 10:28:59 +0100, Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> wrote:
> On 17/11/2021 00:57, Vincent Pelletier wrote:
> > Follow the pin descriptions given in the version 3 of the board schematics.
> > 
> > Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com>
> > 
> > --
> > Changes since v1:
> > - Remove trailing "." on subject line.
> > ---  
> 
> This is not a correct changelog placement - you have to use '---' just
> like git uses it. Just test it yourself and you will see the problem.

Indeed, thanks for catching this.

Is there a recommended way for managing these not-for-commit-message
chunks automatically ?
I obviously compose them by hand so far, and put them in my local git
working copy commit messages, but I would be happier if I did not have
to make (bad) decisions on such mechanical detail.

On a related topic, is there a way to automate "git send-email"
recipient list using get_maintainer.pl (plus some more magic lines,
for example to exclude bouncing addresses) ?

While process/submitting-patches.rst describes what the result should
look like, it feels to me that it (or another related file) could be
more directive on what commands/workflows help to get such result, for
casual contributors like myself. Have I missed such documentation ?

Regards,
Krzysztof Kozlowski Nov. 18, 2021, 1:44 p.m. UTC | #3
On 18/11/2021 01:34, Vincent Pelletier wrote:
> On Wed, 17 Nov 2021 10:28:59 +0100, Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> wrote:
>> On 17/11/2021 00:57, Vincent Pelletier wrote:
>>> Follow the pin descriptions given in the version 3 of the board schematics.
>>>
>>> Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com>
>>>
>>> --
>>> Changes since v1:
>>> - Remove trailing "." on subject line.
>>> ---  
>>
>> This is not a correct changelog placement - you have to use '---' just
>> like git uses it. Just test it yourself and you will see the problem.
> 
> Indeed, thanks for catching this.
> 
> Is there a recommended way for managing these not-for-commit-message
> chunks automatically ?
> I obviously compose them by hand so far, and put them in my local git
> working copy commit messages, but I would be happier if I did not have
> to make (bad) decisions on such mechanical detail.

There is an idea of git notes (wasn't really efficient) or git branch
description for cover letter (--cover-from-description, didn't try yet).

> 
> On a related topic, is there a way to automate "git send-email"
> recipient list using get_maintainer.pl (plus some more magic lines,
> for example to exclude bouncing addresses) ?

There are few different options, so depends what do you want, e.g.:
git send-email --cc-cmd "scripts/get_maintainer.pl --no-git --no-roles
--no-rolestats" --to linux-kernel@vger.kernel.org 0*

However above does not take care about cover-letter.

> 
> While process/submitting-patches.rst describes what the result should
> look like, it feels to me that it (or another related file) could be
> more directive on what commands/workflows help to get such result, for
> casual contributors like myself. Have I missed such documentation ?

Not sure. Anyway just look at the lists at lore.kernel.org how other
people are doing it.


Best regards,
Krzysztof
diff mbox series

Patch

diff --git a/arch/riscv/boot/dts/sifive/hifive-unmatched-a00.dts b/arch/riscv/boot/dts/sifive/hifive-unmatched-a00.dts
index 4f66919215f6..305a086e5207 100644
--- a/arch/riscv/boot/dts/sifive/hifive-unmatched-a00.dts
+++ b/arch/riscv/boot/dts/sifive/hifive-unmatched-a00.dts
@@ -245,4 +245,8 @@  &pwm1 {
 
 &gpio {
 	status = "okay";
+	gpio-line-names = "J29.1", "PMICNTB", "PMICSHDN", "J8.1", "J8.3",
+		"PCIe_PWREN", "THERM", "UBRDG_RSTN", "PCIe_PERSTN",
+		"ULPI_RSTN", "J8.2", "UHUB_RSTN", "GEMGXL_RST", "J8.4",
+		"EN_VDD_SD", "SD_CD";
 };