The Voyager is a 9.6” x 9.6” Micro ATX form factor development board
including Andes QiLai SoC. This patch series adds minimal device tree
files for the QiLai SoC and the Voyager board [1].

Now only support basic uart drivers to boot up into a basic console. Other
features will be added later.

The original patchset [2] has been reviewed positively in relevant mailing
lists. Thus, send a new patchset to soc@lists.linux.dev .

Also, there is a patch dependency in this patchset:
Patch 2 <- Patch 4 <- Patch 5 <- Patch 6

[1] https://www.andestech.com/en/products-solutions/andeshape-platforms/qilai-chip/
[2] https://lore.kernel.org/all/20250602060747.689824-1-ben717@andestech.com/

Ben Zong-You Xie (8):
  riscv: add Andes SoC family Kconfig support
  dt-bindings: riscv: add Andes QiLai SoC and the Voyager board bindings
  dt-bindings: interrupt-controller: add Andes QiLai PLIC
  dt-bindings: interrupt-controller: add Andes machine-level software
    interrupt controller
  dt-bindings: timer: add Andes machine timer
  riscv: dts: andes: add QiLai SoC device tree
  riscv: dts: andes: add Voyager board device tree
  riscv: defconfig: enable Andes SoC

 .../andestech,plicsw.yaml                     |  54 +++++
 .../sifive,plic-1.0.0.yaml                    |   1 +
 .../devicetree/bindings/riscv/andes.yaml      |  25 +++
 .../bindings/timer/andestech,plmt0.yaml       |  53 +++++
 MAINTAINERS                                   |   9 +
 arch/riscv/Kconfig.errata                     |   2 +-
 arch/riscv/Kconfig.socs                       |   9 +
 arch/riscv/boot/dts/Makefile                  |   1 +
 arch/riscv/boot/dts/andes/Makefile            |   2 +
 arch/riscv/boot/dts/andes/qilai-voyager.dts   |  28 +++
 arch/riscv/boot/dts/andes/qilai.dtsi          | 186 ++++++++++++++++++
 arch/riscv/configs/defconfig                  |   1 +
 12 files changed, 370 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/andestech,plicsw.yaml
 create mode 100644 Documentation/devicetree/bindings/riscv/andes.yaml
 create mode 100644 Documentation/devicetree/bindings/timer/andestech,plmt0.yaml
 create mode 100644 arch/riscv/boot/dts/andes/Makefile
 create mode 100644 arch/riscv/boot/dts/andes/qilai-voyager.dts
 create mode 100644 arch/riscv/boot/dts/andes/qilai.dtsi

--
2.34.1

On 04/07/2025 10:14, Ben Zong-You Xie wrote:
> The Voyager is a 9.6” x 9.6” Micro ATX form factor development board
> including Andes QiLai SoC. This patch series adds minimal device tree
> files for the QiLai SoC and the Voyager board [1].
> 
> Now only support basic uart drivers to boot up into a basic console. Other
> features will be added later.
> 
> The original patchset [2] has been reviewed positively in relevant mailing
> lists. Thus, send a new patchset to soc@lists.linux.dev .
> 
> Also, there is a patch dependency in this patchset:
> Patch 2 <- Patch 4 <- Patch 5 <- Patch 6

How? These are bindings. How DTS can depend on the binding? Do you have
akcs from their subsystem maintainers that you are sending it here?

Sorry, but no, this should go via their maintainers, unless they did not
want to pick it up. Is this the case here?

Best regards,
Krzysztof

On Fri, Jul 04, 2025 at 11:15:43AM +0200, Krzysztof Kozlowski wrote:
> > Also, there is a patch dependency in this patchset:
> > Patch 2 <- Patch 4 <- Patch 5 <- Patch 6
> 
> How? These are bindings. How DTS can depend on the binding? Do you have
> akcs from their subsystem maintainers that you are sending it here?
>
> Sorry, but no, this should go via their maintainers, unless they did not
> want to pick it up. Is this the case here?

The dependency chain arises because each of these patches introduces a new file,
requiring a corresponding update to the MAINTAINERS file.

In v4 [1], Rob and Daniel attempted to merge Patch 4 and Patch 5, respectively,
but encountered conflicts in the MAINTAINERS file. That's why I specified the
patch dependencies in v5 and this patchset.

Now, I understand that binding patches are typically handled by subsystem
maintainers. To prevent the conflicts again, I think I should gather all
MAINTAINERS file changes into a single patch. Is that right?

[1] https://lore.kernel.org/all/20250514095350.3765716-1-ben717@andestech.com/

Thanks,
Ben

On Fri, Jul 4, 2025, at 15:07, Ben Zong-You Xie wrote:
> On Fri, Jul 04, 2025 at 11:15:43AM +0200, Krzysztof Kozlowski wrote:
>> > Also, there is a patch dependency in this patchset:
>> > Patch 2 <- Patch 4 <- Patch 5 <- Patch 6
>> 
>> How? These are bindings. How DTS can depend on the binding? Do you have
>> akcs from their subsystem maintainers that you are sending it here?
>>
>> Sorry, but no, this should go via their maintainers, unless they did not
>> want to pick it up. Is this the case here?
>
> The dependency chain arises because each of these patches introduces a new file,
> requiring a corresponding update to the MAINTAINERS file.
>
> In v4 [1], Rob and Daniel attempted to merge Patch 4 and Patch 5, respectively,
> but encountered conflicts in the MAINTAINERS file. That's why I specified the
> patch dependencies in v5 and this patchset.
>
> Now, I understand that binding patches are typically handled by subsystem
> maintainers. To prevent the conflicts again, I think I should gather all
> MAINTAINERS file changes into a single patch. Is that right?

Don't overthink that part, the MAINTAINERS file doesn't have to cleanly
bisect, so I'd just create the full entry there in the same patch
that adds the arch/riscv/Kconfig entry.

     Arnd