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

[Arınç ÜNAL]

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ç