Message-Id: <20250926143855.4106-1-fushan.zeng@anlogic.com>
Date: Fri, 26 Sep 2025 22:38:55 +0800
From: "fushan.zeng" <fushan.zeng@...ogic.com>
To: conor@...nel.org
Cc: alex@...ti.fr,
	anup@...infault.org,
	aou@...s.berkeley.edu,
	conor+dt@...nel.org,
	daniel.lezcano@...aro.org,
	devicetree@...r.kernel.org,
	fushan.zeng@...ogic.com,
	gregkh@...uxfoundation.org,
	jirislaby@...nel.org,
	junhui.liu@...moral.tech,
	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,
	ruigang.wan@...ogic.com
Subject: Re: [PATCH v2 00/11] riscv: Add initial support for Anlogic DR1V90

On Thu, 25 Sep 2025 18:09:59 +0100, Conor Dooley wrote:
> On Thu, Sep 25, 2025 at 11:06:50AM +0800, fushan.zeng wrote:
> > 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 SO=
> Cs,
> > 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.

Hi all,
I realize that my previous message was inappropriate and may have
given the wrong impression - my apologies.

To clarify, I am not trying to control the community
or block upstream work. I misunderstood the right
way to express myself before, and I take my
previous mail back.

Thank you for your guidance and patience. As a
newcomer to the Linux community, I am still
learning how to properly contribute.

If Junhui has further technical questions, please
feel free to contact me in this thread. I am happy to
help and to welcome contributions from the
community.

Best regards,
fushan

Powered by blists - more mailing lists