[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ç