Re: [GIT PULL] ~RISC-V~Starfive devicetrees fixes for v7.0-rc6

[E Shattow <e@freeshell.de>]

Hi Ilya,

On 3/27/26 01:52, Ilya Sorochan wrote:
>> On 3/26/26 12:27, Ilya Sorochan wrote:
>>> On Thu, Mar 26, 2026 at 07:36:07AM -0700, E Shattow wrote:
>> ...
> 
> Sorry, I'm not trying to be disrespectful. Yes, it's my first time. Kernel docs
> bewarn of spamming therefore I trimmed CC based on the assumption that those who
> interested in devicetrees are present in devicetree lists. I guess it is not
> true which seems strange to me, but okay.

$ scripts/get_maintainer.pl arch/riscv/boot/dts/starfive/jh7110-common.dtsi
...Conor... (maintainer:STARFIVE DEVICETREES)
...linux-riscv... (open list:STARFIVE DEVICETREES)
...devicetree... (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE
BINDINGS)
...linux-kernel... (open list)
RISC-V ARCHITECTURE status: Supported

Not all maintainers are subscribed to all lists or even any lists. Some
just occasionally search lore mailing list archives

https://lore.kernel.org/linux-riscv
https://lore.kernel.org/linux-devicetree
https://lore.kernel.org/lkml/

if there's not CC directly to them.

Additionally to making sure your patch reaches its audience for review,
there are automated testing "Patchwork" which for LKML RISC-V

https://patchwork.kernel.org/project/linux-riscv/list/

breaks if you are not CC at least linux-riscv mail list. Threading
breaks in multi-patch series or series with cover letter if any of the
messages have different recipient ordering. Broken threading and missing
automated testing equals confused reviewers.

Note that special for StarFive SoC is Conor has responsibility for this
whereas the more recent usual delegation of responsibility to SoC or
vendor specific mail lists and git trees. SpacemiT development as a
recent example following the new pattern of delegation has its own
spacemit mailing list and git repo whereas starfive development sits on
linux-devicetree mailing list and co-habitation of Conor's devicetree
git repo because Conor is both a devicetree maintainer and adopted this
responsibility years ago when the StarFive SoC's were new.

Congratulations on your first patch to Linux Kernel :)

> 
> I'm not asking to support this feature properly. It would be nice to have but
> it is hard and StarFive is not making it any easier. However I'm asking to keep
> it working while you can if you can. It worked for me and other people and we
> would appreciate if you can delay breaking it as long as possible.
> 
>>> I traced this property a little in the U-Boot repo:
>>> - 503fc8548197 Hal added it to VisionFive v1.3b (with mmc pins)
>>> - 6bbe95ef7208 Hal moved it (and other common things) into
>>>   jh7110-common-u-boot.dtsi
>>> - 27f617019dd0 E removed it with jh7110-common-u-boot.dtsi
>>> - 762f85bb2e36 Tom squash-updated upstream dts
>>>
>>> New device trees did not contain this property. This is how they were introduced
>>> into the Linux: b127dbf9e1ebbfbcded4 ("riscv: dts: starfive: Add mmc nodes on
>>> VisionFive 2 board")
>>>
>>> I do not know if this miss is intentional or not. However it would be nice to
>>> be able to boot from SD-card again.
>>
>> There is already nothing to prevent you from booting Linux from SD-card,
>> with U-Boot SPL and U-Boot Main located in SPI Flash as is recommended
>> by StarFive officially.
> 
> Yes. However I'm implying the deprecated SDIO3.0 way. I agree that this would be
> nice to have in the commit message - if this what are you talking about.
> 
>> I'm glad you sent a patch, but I still object for the other reasons
>> mentioned.
> 
> I'm glad to talk to competent people in this space, however I still hope that
> the kernel will refrain from breaking this feature until it is really necessary.

I hope you'll continue on to review the BootROM r.e. effort and cite its
code snippets in patches so adding bootph-pre-ram hints covering the
eMMC SPL boot method from StarFive Loader, retrospectively describing
the SD Card SPL boot method from StarFive Loader, and/or secure boot
crypto accelerator functionality in the starfive crypto driver (what
does command=8 and command=9 do exactly?) The exact nature of the bug in
StarFive Loader UART XMODEM incompatibility could use a proper
description, and SPI Flash configuration parameter analysis, too.

-E