[PATCH 0/7] board: rockchip: add FriendlyElec NanoPi R3S

[Quentin Schulz]

Hi Tianling,

On 1/14/25 3:49 PM, Tianling Shen wrote:
> Hi Quentin,
> 
> On 2025/1/14 22:39, Quentin Schulz wrote:
>> Hi Tianling,
>>
>> On 12/26/24 10:20 AM, Tianling Shen wrote:
>>> The NanoPi R3S(as "R3S") is an open source platform with dual-Gbps
>>> Ethernet ports designed and developed by FriendlyElec for IoT
>>> applications.
>>>
>>> Tianling Shen (7):
>>>    arm64: dts: rockchip: Add FriendlyARM NanoPi R3S board
>>>    arm64: dts: rockchip: fix model name for FriendlyElec NanoPi R3S
>>>    arm64: dts: rockchip: replace deprecated snps,reset props for NanoPi
>>>      R3S
>>>    arm64: dts: rockchip: sort props in pmu_io_domains node for NanoPi 
>>> R3S
>>>    arm64: dts: rockchip: enable eMMC HS200 mode for NanoPi R3S
>>>    arm64: dts: rockchip: reorder mmc aliases for NanoPi R3S
>>
>> How did you backport the above patches?
>>
>> ./tools/update-subtree.sh pick dts <commit>
>>
>> is the tool to be used, it should have added a
>>
> 
> Thank you for the tip! I did not know there's such a script and
> I just copy&paste the commit message from linux tree manually.
> 

Mmmm, how did you apply the patch in your tree then? Trying to figure 
out how we can avoid this in the future.

I'm wondering if we shouldn't have tooling in place to detect when 
things aren't done the proper way (for maintainers I mean). We 
**really** want to have dts/upstream be upstream + some patches that 
were already merged in devicetree-rebasing tree. I don't know enough 
about subtree merges that Tom does when updating to a new tagged release 
to know if it's actually safe or if the possible mistake made when 
applying a commit by hand can persist without us noticing. I guess a 
mistake made in a manually applied patch would be caught by Tom during 
the merge from the next release with a merge conflict, but then that's 
pain for him to debug.

Cheers,
Quentin