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.
Attachment:
signature.asc
Description: PGP signature
