[PATCH 2/2] arm64: dts: rockchip: Add CM3588 NAS board

[Sebastian Kropatsch]

Hello Heiko,

Am 29.05.2024 um 09:57 schrieb Heiko Stübner:
> Hi Sebastian,
>
> Am Dienstag, 28. Mai 2024, 17:55:55 CEST schrieb Sebastian Kropatsch:
>> Am 27.05.2024 um 22:54 schrieb Heiko Stübner:
>>> Am Montag, 27. Mai 2024, 21:02:02 CEST schrieb Jonas Karlman:
>>>> On 2024-05-26 23:48, Sebastian Kropatsch wrote:
>>>>> The CM3588 NAS by FriendlyElec pairs the CM3588 compute module, based on
>>>>> the Rockchip RK3588 SoC, with the CM3588 NAS Kit carrier board.
>>>>>
>>>>> Hardware features:
>>>>>       - Rockchip RK3588 SoC
>>>>>       - 4GB/8GB/16GB LPDDR4x RAM
>>>>>       - 64GB eMMC
>>>>>       - MicroSD card slot
>>>>>       - 1x RTL8125B 2.5G Ethernet
>>>>>       - 4x M.2 M-Key with PCIe 3.0 x1 (via bifurcation) for NVMe SSDs
>>>>>       - 2x USB 3.0 (USB 3.1 Gen1) Type-A, 1x USB 2.0 Type-A
>>>>>       - 1x USB 3.0 Type-C with DP AltMode support
>>>>>       - 2x HDMI 2.1 out, 1x HDMI in
>>>>>       - MIPI-CSI Connector, MIPI-DSI Connector
>>>>>       - 40-pin GPIO header
>>>>>       - 4 buttons: power, reset, recovery, MASK, user button
>>>>>       - 3.5mm Headphone out, 2.0mm PH-2A Mic in
>>>>>       - 5V Fan connector, PWM buzzer, IR receiver, RTC battery connector
>>>>>
>>>>> PCIe bifurcation is used to handle all four M.2 sockets at PCIe 3.0 x1
>>>>> speed. Data lane mapping in the DT is done like described in commit
>>>>> f8020dfb311d ("phy: rockchip-snps-pcie3: fix bifurcation on rk3588").
>>>>>
>>>>> This device tree includes support for eMMC, SD card, ethernet, all USB2
>>>>> and USB3 ports, all four M.2 slots, GPU, RTC, buzzer, UART debugging as
>>>>> well as the buttons and LEDs.
>>>>> The GPIOs are labeled according to the schematics.
>>>>>
>>>>> Signed-off-by: Sebastian Kropatsch <seb-dev at web.de>
>>>>> ---
>>>>>    arch/arm64/boot/dts/rockchip/Makefile         |    1 +
>>>>>    .../boot/dts/rockchip/rk3588-cm3588-nas.dts   | 1269 +++++++++++++++++
>>>>>    2 files changed, 1270 insertions(+)
>>>>>    create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-cm3588-nas.dts
>>>>
>>>> Because the CM3588 is a SoM and the NAS is a carrier board this should
>>>> probably be split in two, cm3588.dtsi and cm3588-nas.dts.
>>>
>>> also, because of that way too generic name "cm", please incorporate the
>>> company name in the filename as well. For the same reason we named
>>> the rk3568-wolfvision-pf5.dts that way ;-) [Wolfvision being the company]
>>>
>>> So maybe:
>>> rk3588-friendlyelec-cm3588.dtsi and rk3588-friendlyelec-cm3588-nas.dts
>>>
>>
>> Yes, I agree that the name is very generic. I struggled with this as
>> well, but your suggestion sounds good!
>>
>> In this case, is it also preferred to change the commit message to
>> include the company name event though the commit message subject exceeds
>> 50 characters this way?
>> ("arm64: dts: rockchip: Add FriendlyElec CM3588 NAS board")
>
> Were does a 50 character limit even come from?
> In other words, the subject should be meaningful and with the needed
> prefixes adhering to a 50 chars maxlen would cause pretty unreadable
> subject in a lot of cases.
>
> So the proposed subject is absolutely fine :-) .
>
The 50 character limit is actually recommended in the Git docs:
   "Though not required, it’s a good idea to begin the commit message
   with a single short (no more than 50 characters) line summarizing
   the change, followed by a blank line and then a more thorough
   description." [1]

VS Code also has vertical lines in the commit editor indicating if your
line has more than 50 (first line) or 72 (other lines) chars.
And other outlets have mentioned the "50/72 rule" [2,3] as well. The
rule of word-wrapping at 72 characters was even mentioned by Linus,
albeit in 2012:
   "[...] the rule is simple: we use 72-character columns for word
   wrapping, except for quoted material that has a specific line
   format." [4]

But yeah as you're saying, while a subject should be short but
meaningful, such a limit probbaly doesn't make a lot of sense in this
current age.
I likely read too much into those rules trying to learn about all the
things on how to make a good contribution to the kernel, with mailing
lists, formatting and so on.
I won't try to stay on 50 chars too rigorously in the future :)

Thanks,
Sebastian

[1] https://git-scm.com/docs/git-commit#_discussion
[2] https://www.baeldung.com/ops/git-commit-messages#3-the-5072-rule
[3] https://preslav.me/2015/02/21/what-s-with-the-50-72-rule/
[4] https://github.com/torvalds/linux/pull/17#issuecomment-5661185