linux-kernel - Re: [PATCH v2 00/11] riscv: Add initial support for Anlogic DR1V90

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250925-jaundice-uneasy-ff8b3b595879@spud>
Date: Thu, 25 Sep 2025 18:09:59 +0100
From: Conor Dooley <conor@...nel.org>
To: "fushan.zeng" <fushan.zeng@...ogic.com>
Cc: junhui.liu@...moral.tech, alex@...ti.fr, anup@...infault.org,
	aou@...s.berkeley.edu, conor+dt@...nel.org,
	daniel.lezcano@...aro.org, devicetree@...r.kernel.org,
	gregkh@...uxfoundation.org, jirislaby@...nel.org,
	krzk+dt@...nel.org, krzysztof.kozlowski@...aro.org,
	linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
	linux-serial@...r.kernel.org, palmer@...belt.com, palmer@...ive.com,
	paul.walmsley@...ive.com, robh@...nel.org,
	samuel.holland@...ive.com, tglx@...utronix.de
Subject: Re: [PATCH v2 00/11] riscv: Add initial support for Anlogic DR1V90

On Thu, Sep 25, 2025 at 11:06:50AM +0800, fushan.zeng wrote:
> On Mon, 22 Sep 2025 20:46:30 +0800, Junhui Liu wrote:
> > This patch series introduces initial support for the Anlogic DR1V90 SoC
> > [1] and the Milianke MLKPAI-FS01 [2] board.
> > 
> > The DR1V90 is a RISC-V based FPSoC from Anlogic, featuring a Nuclei
> > UX900 [3] core as its processing system (PS) and 94,464 LUTs in the
> > programmable logic (PL) part. The Milianke MLKPAI-FS01 board is one of
> > the first platforms based on this SoC, with UART1 routed to a Type-C
> > interface for console access.
> > 
> > Tested on the Milianke MLKPAI-FS01 board with both the vendor's OpenSBI
> > and the not-yet-upstreamed mainline OpenSBI [4], as well as the vendor’s
> > U-Boot. Because the vendor’s OpenSBI is loaded at 0x1f300000, we have
> > to additionally reserve the DRAM region 0x1fe00000–0x1fffffff to prevent
> > overlap if using vendor's OpenSBI.
> > 
> > Notice: A "no4lvl" bootarg or dependency patch [5] is currently required
> > for successful boot on the DR1V90 platform, since the SoC hangs if the
> > kernel attempts to use unsupported 4-level or 5-level paging modes.
> 
> Thanks first.
> Anloigc already has the open source SDK at https://gitee.com/anlogic/sdk,
> and will submit it to mainline at suitable time.
> The code should be a full feature version after lots of tests, not the
> modified and simplified version from Anlogic open source.

The nature of the upstreaming process will require what you have to be
broken down into multiple parts and be upstreamed at different times,
depending on how long components take to review. This is normal and
expected. Of course there should be through testing done, but I don't
think that what is in this initial patchset really requires much
testing - if it boots then it's probably sufficiently tested!

> And we hope that there won't be two different versions code of anlogic SOCs,
> it may confuse customers.

If there's ever going to be complete upstream support for your device,
then there will be two versions, because looking at just the dts files
in the gitee sdk you linked I have noticed things that are not acceptable
in upstream. As others have said, you are not entitled to control the
upstreaming process for your device. The only way to have some control is
to submit patches yourself and to engage with the review process for other
components. It's in everybody's interest to keep differences with your
SDK to a minimum, but you need to accept that there will always be
differences because the upstream community simply has higher standards
than those in your SDK as well as a requirement for portable code that
you do not have.

> It is better that anlogic SOCs are long term maintained and supported
> by Anlogic officially in mainline and for customers.

It's only better if Anlogic submits better quality patches (no evidence
for that yet) or submits the patches more promptly than others (which
clearly has not happened here), and offers review commentary etc at a
higher standard and more frequently than a non-employee maintainer would
be able to do (there's no evidence for that so far either, given you're
trying to stall this patchset). Your claim seems to have no merit as
there is no proof that you'd do a better job.

Thanks,
Conor.

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)