> From: Conor Dooley <conor@xxxxxxxxxx> > 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
