Re: [PATCH 00/14] mips: dts: ralink: mt7621: improve DTS style

From: Arınç ÜNAL
Date: Sat Mar 16 2024 - 11:16:38 EST


On 16.03.2024 17:03, Justin Swartz wrote:
On 2024-03-16 11:24, Arınç ÜNAL wrote:
On 16.03.2024 07:54, Justin Swartz wrote:
This set of patches was created with the intention of cleaning up
arch/mips/boot/dts/ralink/mt7621.dtsi so that it is aligned with
the Devicetree Sources (DTS) Coding Style [1] [2] guide.

[1] Documentation/devicetree/bindings/dts-coding-style.rst

[2] https://docs.kernel.org/devicetree/bindings/dts-coding-style.html

Justin Swartz (14):
   mips: dts: ralink: mt7621: reorder cpu node attributes
   mips: dts: ralink: mt7621: reorder cpuintc node attributes
   mips: dts: ralink: mt7621: reorder mmc regulator attributes
   mips: dts: ralink: mt7621: reorder sysc node attributes
   mips: dts: ralink: mt7621: reorder gpio node attributes
   mips: dts: ralink: mt7621: reorder i2c node attributes
   mips: dts: ralink: mt7621: reorder spi0 node attributes
   mips: dts: ralink: mt7621: move pinctrl and sort its children
   mips: dts: ralink: mt7621: reorder mmc node attributes
   mips: dts: ralink: mt7621: reorder gic node attributes
   mips: dts: ralink: mt7621: reorder ethernet node attributes and kids
   mips: dts: ralink: mt7621: reorder pcie node attributes and children
   mips: dts: ralink: mt7621: reorder pci?_phy attributes
   mips: dts: ralink: mt7621: reorder the attributes of the root node

  arch/mips/boot/dts/ralink/mt7621.dtsi | 430 ++++++++++++++------------
  1 file changed, 239 insertions(+), 191 deletions(-)

A well done patch series. Thank you very much for doing this!

Arınç

++ for reviewing them all.

As you have at least one board that features an MT7621 SoC,
please may you (and anyone else willing) take a look at a
patch [1] that I've submitted for spi-mt7621.c which allows
GPIO chip select lines to be used as well as the native chip
selects.

There's already been some back and forth with Mark Brown about
the initial version of the patch (the linked patch is v2) and,
of course I messed up how I send v2, as you'll read in the thread.

It seems you weren't included because I rely on [2] to determine
which people to address as maintainers when sending patches.

I'd prefer not to be involved. It's not my area of expertise.


Is there a better approach for populating git send's --to argument?

This is how I used to submit patches before I started using b4 [1].

git format-patch HEAD~X --subject-prefix "PATCH (RFC) (tree) (vX)" --cover-letter

/scripts/get_maintainer.pl --norolestats --nol --nor 00* > to.txt
/scripts/get_maintainer.pl --norolestats --nom 00* > cc.txt

git send-email --no-chain-reply-to \
--to-cmd="cat to.txt && cat > /dev/null" \
--cc-cmd="cat cc.txt && cat > /dev/null" \
00*

[1] https://b4.docs.kernel.org/en/latest/index.html

Arınç