Re: [RFC PATCH 0/4] espi: introduce eSPI bus framework

[M, Krishnamoorthi]

Hi Andrew,

On 8/5/2026 6:12 AM, Andrew Jeffery wrote:
> Hi Greg, Krishnamoorthi,
>
> YH Chung has been working on eSPI support for ASPEED's BMC SoCs, so
> I've included them in the To line.
>
> On Tue, 2026-08-04 at 14:18 +0200, Greg KH wrote:
> > On Tue, Aug 04, 2026 at 05:22:55PM +0530, Krishnamoorthi M wrote:
> > > Feedback Requested
> > > ==================
> > >
> > >    1. We chose a dedicated bus_type for the reasons described above
> > >       (capability negotiation, four independent channels, asynchronous
> > >       ALERT#). Does the community agree this is the right direction, or
> > >       is there a strong preference to extend the SPI subsystem instead?
> >
> > That's up to the SPI maintainers and developers...
>
> There's concurrent discussion from YH regarding device-side eSPI
> support in the thread ending here:
>
> https://lore.kernel.org/all/KL1PR0601MB4276FA2C6347192CC45826E490ED2@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
>
> So far it's arrived at a matching proposal for drivers/espi.

Thank you for the introduction and for pointing to YH Chung's work. It 
is encouraging to see concurrent work arriving at a similar framework 
structure for drivers/espi — this gives us more confidence that the 
proposed design is on the right track.

> > >    3. Any concerns with the ops table design or the -EOPNOTSUPP fallback?
> > >    4. Naming and structure of the public API in include/linux/espi/espi.h.
> >
> > What specifically are you asking for for this?  Do you have userspace
> > code you want to integrate, if so, does it work with this?  And where
> > does it live?
>
> I've seen your follow-up realisation Greg, however, regarding
> userspace, the thread above suggests that we should be able to back
> existing subsystems (GPIO for VW, MCTP for OOB, MTD for some flash
> functionality) onto eSPI to minimise eSPI-specific interfaces:
>
> https://lore.kernel.org/all/KL1PR0601MB4276B5BE3B96C18E3A66AD709049A@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
>
> That doesn't cover the peripheral channel, as that's dealt with in
> hardware on the device side, but for the purpose of the controller the
> devices on the peripheral channel should all be driven by the kernel
> anyway.

I will go through YH Chung's complete thread on device-side eSPI support 
to understand the full picture. Reusing existing well-established kernel 
subsystems (GPIO for VWire, MCTP for OOB, MTD for Flash) to minimize 
eSPI-specific userspace interfaces is a sound direction.

YH Chung, would you be open to collaborating on the slave-side 
interfaces of the new eSPI framework? Happy to discuss further on the 
list or off-list to align on the design before the next revision.

Thanks,
Krishna

> Andrew