[PATCH 1/2] riscv: dts: spacemit: Add i2c buses on OrangePi RV2

[Michael Opdenacker]

Hi Johannes

On 12/17/25 23:10, Johannes Erdfelt wrote:
> On Wed, Dec 17, 2025, Michael Opdenacker <michael.opdenacker at rootcommit.com> wrote:
>> Wow, that would be awesome indeed, all the more as my time is quite limited.
>> Please do!
>> I'll have a look at other aspects if I can, like USB and PCI Express.
> If it helps, I have PCIe working on my RV2 board. I based it on the BPI
> F3 patches but RV2 also requires enabling 3.3v for the M.2 slot.
>
Great, please share... I needed this too on Orange Pi R2S to enable the 
two 2.5 Gb Ethernet links :)
>
> I haven't ever submitted a DT patch before, but I'd be willing to clean
> up my patch.


Sharing is always a great opportunity to learn. Here are my raw notes 
about the topic:

  * Most importantly, run scripts/checkpatch.pl on your patches before
    sending them
  * Very important too, run "make dtbs" and then "make dtbs_check" to
    validate your changes
    See https://static.sched.com/hosted_files/ossjapan2025/59/Status of
    DTS Validation in Linux Kernel - Krzysztof Kozlowski%2C Qualcomm -
    OSSJ 2025.pdf
    <https://static.sched.com/hosted_files/ossjapan2025/59/Status%20of%20DTS%20Validation%20in%20Linux%20Kernel%20-%20Krzysztof%20Kozlowski%2C%20Qualcomm%20-%20OSSJ%202025.pdf>
    for reasons why.
  * You won't be embarrassed if you already passed these first two checks ;)
  *

    Follow the DTS coding style:
    https://docs.kernel.org/devicetree/bindings/dts-coding-style.html
    - Nodes on any bus should be in ascending address order
    - If no address, order alphanumerically by node name
    - "status" right before child nodes
    - properties of the same type (like aliases) in "natural" order (1,
    3, 12...)

  *

    Don't enable features as static (default y) in Kconfig, unless you
    have a very strong reason. Otherwise, it makes the kernel bigger for
    everyone else.

  *

    When you submit first DTS support for one board, submit the DTS in
    one commit.
    https://lore.kernel.org/all/20251010-confider-raven-0ad7a810e5de@spud/

  * If someone replies "2 < v" to you, it means "Please send v2"
  *

    In commit messages, don't comment on where the DT is coming from
    (device tree is similar to...)

  *

    References should be like this, followed by a blank line before
    "Signed-off-by"

    [1] https://tinker-board.asus.com/series/tinker-board-3.html
    [2] https://tinker-board.asus.com/series/tinker-board-3s.html

  *

    Keep track of Reviewed-by and Tested-by tags (using b4 to manage
    your branch and submissions will help tremendously)
    https://b4.docs.kernel.org/en/latest/

  *

    Explain WHY you're doing something in a commit message (Krzysztof
    Kozlowski)

  * If anything is wrong or can be improved, we (the Linux kernel
    community) will be delighted to guide you, so that we end up with
    some code that's easy for others to maintain and expand.
  * Special gratitude to Krzysztof Kozlowski for always being there to
    help  on DT patches :)

I'm also available to test your patches, as I have Banana Pi F3, Orange 
Pi RV2 and R2S.

I hope you can do this in the next days, because there's a great window 
in the next days for contribution, when work slows down during the 
holidays :)
Thanks in advance
Cheers
Michael.

-- 
Michael Opdenacker
Root Commit
Yocto Project and OpenEmbedded Training course - Learn by doing:
https://rootcommit.com/training/yocto/