All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Johan Jonker <jbx6244@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	Heiko Stuebner <heiko@sntech.de>,
	devicetree@vger.kernel.org, linux-rockchip@lists.infradead.org
Subject: Re: [PATCH 3/9] arm64: dts: rockchip: Prepare Rockchip RK1808
Date: Mon, 17 May 2021 13:03:03 +0200	[thread overview]
Message-ID: <3f5767aa-77c4-6007-adfa-a85bf0a7e9ad@suse.de> (raw)
In-Reply-To: <f46625ed-4c83-9fd2-52cd-e07a4d93a254@gmail.com>

Hi Johan,

On 17.05.21 03:29, Johan Jonker wrote:
> Send the complete serie to all maintainers and mail lists.

That's unhelpful - all patches went to linux-rockchip, LAKML and LKML,
and get_maintainers.pl was used. The cover letter was explicitly copied
to DTML as get_maintainers.pl doesn't catch it. You'll find them here:

https://lore.kernel.org/linux-rockchip/20210516230551.12469-1-afaerber@suse.de/

Which mailing list or maintainer do you think all should've gone to in
addition? You're not listed anywhere in linux-next MAINTAINERS. If you
want to be CC'ed, you can nicely ask me to for a v2 (and explaining why
would help for the next series), or you can send patches against
MAINTAINERS yourself.

Copying all maintainers and lists would likely not be appreciated by the
colleagues and may get mails flagged as spam.

> ===
> Heiko's sort rules:
> 
> compatible
> reg
> interrupts
> [alphabetical]
> status [if needed]
> 
> ===
> My incomplete list:
> 
> For nodes:
> If exists on top: model, compatible and chosen.
> Sort things without reg alphabetical first,
> then sort the rest by reg address.
> 
> Inside nodes:
> If exists on top: compatible, reg and interrupts.
> In alphabetical order the required properties.
> Then in alphabetical order the other properties.
> And as last things that start with '#' in alphabetical order.
> Add status below all other properties for soc internal components with
> any board-specifics.
> Keep an empty line between properties and nodes.
> 
> Exceptions:
> Sort pinctrl-0 above pinctrl-names, so it stays in line with clock-names
> and dma-names.
> Sort simple-audio-card,name above other simple-audio-card properties.
> Sort regulator-name above other regulator properties.
> Sort regulator-min-microvolt above regulator-max-microvolt.
> 
> ===


Here's a rule for you: No top-posting on kernel lists.


> 
> Fix complete dtsi for property sort order!
> Add more drivers. (cru, pinctrl)

-ETONE! I don't work for Rockchip, so don't command me to add drivers
for them that I have no source code for (cover letter) nor complete TRM.
You're welcome that I did this service to the kernel community in my
spare time... If you look up the date of Hackweek 20, you'll find that
it took me two months to get this patchset binding-documented and
cleaned up to this point, so by extrapolation it's unrealistic to expect
much more of me here anytime soon. Rudeness certainly does not motivate.

Heiko knows me - if he has any comments, he should be well capable of
voicing them himself inline. I will not follow nonsensical rules that
diverge from other mainline arm-soc vendors - unless I've missed some
new directive from Rob or arm-soc maintainers that would apply to all.

Thanks for nothing,

Andreas

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)

WARNING: multiple messages have this Message-ID (diff)
From: "Andreas Färber" <afaerber@suse.de>
To: Johan Jonker <jbx6244@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	Heiko Stuebner <heiko@sntech.de>,
	devicetree@vger.kernel.org, linux-rockchip@lists.infradead.org
Subject: Re: [PATCH 3/9] arm64: dts: rockchip: Prepare Rockchip RK1808
Date: Mon, 17 May 2021 13:03:03 +0200	[thread overview]
Message-ID: <3f5767aa-77c4-6007-adfa-a85bf0a7e9ad@suse.de> (raw)
In-Reply-To: <f46625ed-4c83-9fd2-52cd-e07a4d93a254@gmail.com>

Hi Johan,

On 17.05.21 03:29, Johan Jonker wrote:
> Send the complete serie to all maintainers and mail lists.

That's unhelpful - all patches went to linux-rockchip, LAKML and LKML,
and get_maintainers.pl was used. The cover letter was explicitly copied
to DTML as get_maintainers.pl doesn't catch it. You'll find them here:

https://lore.kernel.org/linux-rockchip/20210516230551.12469-1-afaerber@suse.de/

Which mailing list or maintainer do you think all should've gone to in
addition? You're not listed anywhere in linux-next MAINTAINERS. If you
want to be CC'ed, you can nicely ask me to for a v2 (and explaining why
would help for the next series), or you can send patches against
MAINTAINERS yourself.

Copying all maintainers and lists would likely not be appreciated by the
colleagues and may get mails flagged as spam.

> ===
> Heiko's sort rules:
> 
> compatible
> reg
> interrupts
> [alphabetical]
> status [if needed]
> 
> ===
> My incomplete list:
> 
> For nodes:
> If exists on top: model, compatible and chosen.
> Sort things without reg alphabetical first,
> then sort the rest by reg address.
> 
> Inside nodes:
> If exists on top: compatible, reg and interrupts.
> In alphabetical order the required properties.
> Then in alphabetical order the other properties.
> And as last things that start with '#' in alphabetical order.
> Add status below all other properties for soc internal components with
> any board-specifics.
> Keep an empty line between properties and nodes.
> 
> Exceptions:
> Sort pinctrl-0 above pinctrl-names, so it stays in line with clock-names
> and dma-names.
> Sort simple-audio-card,name above other simple-audio-card properties.
> Sort regulator-name above other regulator properties.
> Sort regulator-min-microvolt above regulator-max-microvolt.
> 
> ===


Here's a rule for you: No top-posting on kernel lists.


> 
> Fix complete dtsi for property sort order!
> Add more drivers. (cru, pinctrl)

-ETONE! I don't work for Rockchip, so don't command me to add drivers
for them that I have no source code for (cover letter) nor complete TRM.
You're welcome that I did this service to the kernel community in my
spare time... If you look up the date of Hackweek 20, you'll find that
it took me two months to get this patchset binding-documented and
cleaned up to this point, so by extrapolation it's unrealistic to expect
much more of me here anytime soon. Rudeness certainly does not motivate.

Heiko knows me - if he has any comments, he should be well capable of
voicing them himself inline. I will not follow nonsensical rules that
diverge from other mainline arm-soc vendors - unless I've missed some
new directive from Rob or arm-soc maintainers that would apply to all.

Thanks for nothing,

Andreas

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: "Andreas Färber" <afaerber@suse.de>
To: Johan Jonker <jbx6244@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
	Heiko Stuebner <heiko@sntech.de>,
	devicetree@vger.kernel.org, linux-rockchip@lists.infradead.org
Subject: Re: [PATCH 3/9] arm64: dts: rockchip: Prepare Rockchip RK1808
Date: Mon, 17 May 2021 13:03:03 +0200	[thread overview]
Message-ID: <3f5767aa-77c4-6007-adfa-a85bf0a7e9ad@suse.de> (raw)
In-Reply-To: <f46625ed-4c83-9fd2-52cd-e07a4d93a254@gmail.com>

Hi Johan,

On 17.05.21 03:29, Johan Jonker wrote:
> Send the complete serie to all maintainers and mail lists.

That's unhelpful - all patches went to linux-rockchip, LAKML and LKML,
and get_maintainers.pl was used. The cover letter was explicitly copied
to DTML as get_maintainers.pl doesn't catch it. You'll find them here:

https://lore.kernel.org/linux-rockchip/20210516230551.12469-1-afaerber@suse.de/

Which mailing list or maintainer do you think all should've gone to in
addition? You're not listed anywhere in linux-next MAINTAINERS. If you
want to be CC'ed, you can nicely ask me to for a v2 (and explaining why
would help for the next series), or you can send patches against
MAINTAINERS yourself.

Copying all maintainers and lists would likely not be appreciated by the
colleagues and may get mails flagged as spam.

> ===
> Heiko's sort rules:
> 
> compatible
> reg
> interrupts
> [alphabetical]
> status [if needed]
> 
> ===
> My incomplete list:
> 
> For nodes:
> If exists on top: model, compatible and chosen.
> Sort things without reg alphabetical first,
> then sort the rest by reg address.
> 
> Inside nodes:
> If exists on top: compatible, reg and interrupts.
> In alphabetical order the required properties.
> Then in alphabetical order the other properties.
> And as last things that start with '#' in alphabetical order.
> Add status below all other properties for soc internal components with
> any board-specifics.
> Keep an empty line between properties and nodes.
> 
> Exceptions:
> Sort pinctrl-0 above pinctrl-names, so it stays in line with clock-names
> and dma-names.
> Sort simple-audio-card,name above other simple-audio-card properties.
> Sort regulator-name above other regulator properties.
> Sort regulator-min-microvolt above regulator-max-microvolt.
> 
> ===


Here's a rule for you: No top-posting on kernel lists.


> 
> Fix complete dtsi for property sort order!
> Add more drivers. (cru, pinctrl)

-ETONE! I don't work for Rockchip, so don't command me to add drivers
for them that I have no source code for (cover letter) nor complete TRM.
You're welcome that I did this service to the kernel community in my
spare time... If you look up the date of Hackweek 20, you'll find that
it took me two months to get this patchset binding-documented and
cleaned up to this point, so by extrapolation it's unrealistic to expect
much more of me here anytime soon. Rudeness certainly does not motivate.

Heiko knows me - if he has any comments, he should be well capable of
voicing them himself inline. I will not follow nonsensical rules that
diverge from other mainline arm-soc vendors - unless I've missed some
new directive from Rob or arm-soc maintainers that would apply to all.

Thanks for nothing,

Andreas

-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-05-17 11:03 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-16 23:05 [PATCH 0/9] arm64: dts: rockchip: Initial Toybrick TB-RK1808M0 support Andreas Färber
2021-05-16 23:05 ` Andreas Färber
2021-05-16 23:05 ` Andreas Färber
2021-05-16 23:05 ` [PATCH 1/9] dt-bindings: arm: rockchip: Add Rockchip RK1808 and TB-RK1808M0 Andreas Färber
2021-05-16 23:05   ` Andreas Färber
2021-05-16 23:05   ` Andreas Färber
2021-05-18 14:15   ` Rob Herring
2021-05-18 14:15     ` Rob Herring
2021-05-18 14:15     ` Rob Herring
2021-05-16 23:05 ` [PATCH 2/9] dt-bindings: serial: snps-dw-apb-uart: Add Rockchip RK1808 Andreas Färber
2021-05-16 23:05   ` Andreas Färber
2021-05-16 23:05   ` Andreas Färber
2021-05-18 14:16   ` Rob Herring
2021-05-18 14:16     ` Rob Herring
2021-05-18 14:16     ` Rob Herring
2021-05-16 23:05 ` [PATCH 3/9] arm64: dts: rockchip: Prepare " Andreas Färber
2021-05-16 23:05   ` Andreas Färber
2021-05-16 23:05   ` Andreas Färber
2021-05-17  1:29   ` Johan Jonker
2021-05-17  1:29     ` Johan Jonker
2021-05-17  1:29     ` Johan Jonker
2021-05-17 11:03     ` Andreas Färber [this message]
2021-05-17 11:03       ` Andreas Färber
2021-05-17 11:03       ` Andreas Färber
2021-05-17  9:21   ` Marc Zyngier
2021-05-17  9:21     ` Marc Zyngier
2021-05-17  9:21     ` Marc Zyngier
2021-05-24 13:32     ` Andreas Färber
2021-05-24 13:32       ` Andreas Färber
2021-05-24 13:32       ` Andreas Färber
2021-05-24 15:21       ` Marc Zyngier
2021-05-24 15:21         ` Marc Zyngier
2021-05-24 15:21         ` Marc Zyngier
2021-05-24 21:13         ` Heiko Stübner
2021-05-24 21:13           ` Heiko Stübner
2021-05-24 21:13           ` Heiko Stübner
2021-05-16 23:05 ` [PATCH 4/9] arm64: dts: rockchip: Add Rockchip TB-RK1808M0 Andreas Färber
2021-05-16 23:05   ` Andreas Färber
2021-05-16 23:05   ` Andreas Färber
2021-05-16 23:05 ` [PATCH RFC 5/9] arm64: dts: rockchip: rk1808k-toybrick-m0: Suppress vGIC interrupt Andreas Färber
2021-05-16 23:05   ` Andreas Färber
2021-05-16 23:05   ` Andreas Färber
2021-05-17  9:29   ` Marc Zyngier
2021-05-17  9:29     ` Marc Zyngier
2021-05-17  9:29     ` Marc Zyngier
2021-05-24 14:40     ` Andreas Färber
2021-05-24 14:40       ` Andreas Färber
2021-05-24 14:40       ` Andreas Färber
2021-05-24 15:46       ` Marc Zyngier
2021-05-24 15:46         ` Marc Zyngier
2021-05-24 15:46         ` Marc Zyngier
2021-05-16 23:05 ` [PATCH 6/9] dt-bindings: mmc: rockchip-dw-mshc: Add Rockchip RK1808 Andreas Färber
2021-05-16 23:05   ` Andreas Färber
2021-05-16 23:05   ` Andreas Färber
2021-05-18 14:16   ` Rob Herring
2021-05-18 14:16     ` Rob Herring
2021-05-18 14:16     ` Rob Herring
2021-05-24 14:10   ` Ulf Hansson
2021-05-24 14:10     ` Ulf Hansson
2021-05-24 14:10     ` Ulf Hansson
2021-05-16 23:05 ` [PATCH 7/9] arm64: dts: rockchip: rk1808: Prepare eMMC node Andreas Färber
2021-05-16 23:05   ` Andreas Färber
2021-05-16 23:05   ` Andreas Färber
2021-05-16 23:05 ` [PATCH 8/9] arm64: dts: rockchip: rk1808k-toybrick-m0: Enable eMMC Andreas Färber
2021-05-16 23:05   ` Andreas Färber
2021-05-16 23:05   ` Andreas Färber
2021-05-16 23:05 ` [PATCH 9/9] arm64: dts: rockchip: rk1808: Add CPU operating points Andreas Färber
2021-05-16 23:05   ` Andreas Färber
2021-05-16 23:05   ` Andreas Färber
2021-05-17  9:02 ` [PATCH 0/9] arm64: dts: rockchip: Initial Toybrick TB-RK1808M0 support Marc Zyngier
2021-05-17  9:02   ` Marc Zyngier
2021-05-17  9:02   ` Marc Zyngier
2021-05-17 12:22   ` Andreas Färber
2021-05-17 12:22     ` Andreas Färber
2021-05-17 12:22     ` Andreas Färber
2021-05-17 13:42     ` Marc Zyngier
2021-05-17 13:42       ` Marc Zyngier
2021-05-17 13:42       ` Marc Zyngier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3f5767aa-77c4-6007-adfa-a85bf0a7e9ad@suse.de \
    --to=afaerber@suse.de \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=jbx6244@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.