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

[M, Krishnamoorthi]

Hi Greg,

On 8/4/2026 5:48 PM, 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...
>
> >    2. Is the blocking notifier chain the right mechanism for event
> >       delivery to slave drivers?
>
> Notifier chains are almost never the correct solution, especially for
> real data you wish to send to devices/drivers.  Just use a real
> callback function you have to register for, and a workqueue, or
> something like that.  Ideally just use the process context of the thread
> that created the data in the first place, why can't something simple
> work like that?

Thank you for the feedback. The notifier chain was chosen to support 
multiple slave drivers subscribing to events from a single controller. 
However, your concern is valid — it is not the right abstraction here. A 
cleaner approach is a typed per-device event callback on struct espi_driver:

void (*event)(struct espi_device *edev, struct espi_event *event);

When the controller decodes an ALERT#, it identifies the originating 
chip select# and calls the callback only on the driver bound to that 
device — no chain walking, no per-driver filtering, no untyped casts. 
The callback is invoked directly from the threaded IRQ context that 
decoded the event, keeping the delivery path simple as you suggested.

We will rework the event delivery along these lines in v2. Does this 
direction sound acceptable?

Thanks,
Krishna

> >    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?
>
> thanks,
>
> greg k-h