linux-kernel - RE: 回覆: [PATCH] Add eSPI device driver (flash channel)

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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Sun, 18 Feb 2024 09:36:27 +0000
From: ChiaWei Wang <chiawei_wang@...eedtech.com>
To: Conor Dooley <conor@...nel.org>
CC: Manojkiran Eda <manojkiran.eda@...il.com>, Rob Herring
	<robh+dt@...nel.org>, Krzysztof Kozlowski
	<krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>, Joel
 Stanley <joel@....id.au>, Andrew Jeffery <andrew@...econstruct.com.au>,
	Miquel Raynal <miquel.raynal@...tlin.com>, Richard Weinberger
	<richard@....at>, Vignesh Raghavendra <vigneshr@...com>,
	"jk@...econstruct.com.au" <jk@...econstruct.com.au>, Patrick Rudolph
	<patrick.rudolph@...ements.com>, Ryan Chen <ryan_chen@...eedtech.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-aspeed@...ts.ozlabs.org"
	<linux-aspeed@...ts.ozlabs.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-mtd@...ts.infradead.org"
	<linux-mtd@...ts.infradead.org>, "openbmc@...ts.ozlabs.org"
	<openbmc@...ts.ozlabs.org>, "zev@...ilderbeest.net" <zev@...ilderbeest.net>
Subject:
 RE: 回覆: [PATCH] Add eSPI device driver (flash channel)

> From: Conor Dooley <conor@...nel.org>
> Sent: Friday, February 16, 2024 1:13 AM
> 
> On Thu, Feb 15, 2024 at 01:56:00AM +0000, ChiaWei Wang wrote:
> > >
> > > On Wed, Feb 14, 2024 at 11:34:31AM +0000, ChiaWei Wang wrote:
> > > > We appreciate that you are willing to help on the open source
> contribution.
> > > > However, please co-work with Aspeed before submitting drivers of
> > > > Aspeed
> > > HW.
> > > > Otherwise, a misleading driver on the community are going to bring
> > > > tons of
> > > customer issues to Aspeed.
> > >
> > > It may not apply in this particular case as Aspeed did write the
> > > original driver and it is polite to work with previous authors when
> > > respinning a patchset, but in general there is no need to work with
> > > a hardware vendor before writing drivers for their hardware.
> > >
> > > Blocking a driver because that company might receive more support
> > > requests is not the kernel's problem.
> >
> > I agree with that and Aspeed will not refuse to support.
> >
> > However, in this case, the authors, IBM, and Aspeed already have discussion
> (at least 4 times) before and foresee "issues" on practical eSPI SAFS use.
> > If there is already a known issue of the driver, why ignoring the previous
> discussion and push it?
> > A compromise is to ask for driver renaming to espi-mafs to avoid confusion.
> > Otherwise we need to explain, again, why the driver does not fulfill the SAFS
> expectation.
> 
> To be clear, in case you misunderstood, I was making a general point and not
> about this particular patchset.

Thanks for the clarification and I understand your point.

Most Aspeed-related drivers are from the Aspeed SDK.
And we keep revising the SDK based on our customers' feedback and issues reported.
We only wish that the version submitted to the community will not result in unnecessary misunderstanding and thus more customer issues.

Regards,
Chiawei