回覆: [PATCH] Add eSPI device driver (flash channel)
ChiaWei Wang
chiawei_wang at aspeedtech.com
Wed Feb 14 03:34:31 PST 2024
Most of the implementation originates from Aspeed.
Please preserve the Aspeed copyright before adding the IBM one.
For removing IOCTL and adopting MTD interface, I thought we have already discussed this in public and in private many times.
The MTD interface acting as a master to control flash can NOT serve SAFS (a.k.a. eDAF), which is the major use case of eSPI flash channel on numerous Intel/AMD platforms.
Is SAFS not necessary on your platform?
If so, please consider to rename the driver to espi-mafs to be more specific. As the driver does not support SAFS actually.
I am not saying IOCTL is the best solution.
If there is a more user-firendly interface, I would be glad to revise the implementation as well.
But, the truth is that most existing kernel subsystems act in the master roles, which makes them hard to be applied on eSPI slave.
And this is also well explained in the previous mailing thread.
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.
Thanks,
Chiawei
> Sent by: Manojkiran Eda <manojkiran.eda at gmail.com>
> ---
> Hello everyone,
>
> I'm presenting a revised version of the eSPI device driver patch series found at the following link:
>
> https://lore.kernel.org/openbmc/20220516005412.4844-1-chiawei_wang@aspeedtech.com/
>
> This update addresses the issues identified during the review process.
>
> While the previous patch series attempted to incorporate support for all four different channels of eSPI,
> this new series focuses on upstreaming the flash channel initially, ensuring that all review comments are
> duly addressed, before progressing further.
>
> Results:
> Successfully conducted a flash update via eSPI.
> Note:
> This marks my inaugural endeavor in contributing code to the kernel subsystem. I kindly request reviewers
> to incorporate as many details as possible in the review comments.
More information about the linux-arm-kernel
mailing list