RE: [PATCH 0/7] soc: aspeed: Add AST2600 eSPI controller support

Hi Mark, Conor,

>On Fri, Mar 13, 2026 at 04:32:31PM +0000, Mark Brown wrote:
>> On Fri, Mar 13, 2026 at 04:24:22PM +0000, Conor Dooley wrote:
>> > On Fri, Mar 13, 2026 at 06:07:35PM +0800, aspeedyh wrote:
>> > > This series adds initial support for the eSPI controller found on ASPEED
>> > > AST2600 BMC SoCs.
>> > >
>> > > The series introduces a eSPI controller framework for ASPEED SoCs under
>> > > drivers/soc/aspeed/, adds AST2600-specific controller support for
>> > > peripheral and flash channels, defines the corresponding devicetree
>> > > binding, and adds the AST2600 eSPI controller node to the SoC dtsi.
>> > >
>> > > The driver is intended to support host-BMC communication over the BMC-side
>> > > eSPI slave controller present on AST2600 systems.
>> >
>> > This all seems to be in the wrong places entirely, shouldn't an eSPI
>> > driver and bindings go in the spi subsystem? FSL's appears to be there.
>> > Mark?
>>
>> As documented in submitting-patches.rst please send patches to the
>> maintainers for the code you would like to change.  The normal kernel
>> workflow is that people apply patches from their inboxes, if they aren't
>> copied they are likely to not see the patch at all and it is much more
>> difficult to apply patches.
>>
>> Please submit patches using subject lines reflecting the style for the
>> subsystem, this makes it easier for people to identify relevant patches.
>> Look at what existing commits in the area you're changing are doing and
>> make sure your subject lines visually resemble what they're doing.
>> There's no need to resubmit to fix this alone.
>
>If this is a driver for SPI hardware it should be under drivers/spi and
>use the framework there.

Thanks for the kind guidance.

This driver is for the Intel eSPI interface used by the AST2600 BMC, for functions such as Super I/O that were previously handled over the LPC interface.
As there does not appear to be an in-tree eSPI subsystem at present, our initial thought was to place it under drivers/soc/aspeed/. If that is not the preferred upstream location, we are happy to restructure the series accordingly.