| Message ID | 20250313183440.261872-1-Raju.Rangoju@amd.com |
|---|---|
| Headers | show |
| Series | spi: Add driver to support AMD eSPI controller | expand |
On Fri, Mar 14, 2025 at 12:04:30AM +0530, Raju Rangoju wrote: > The eSPI protocol serves as a communication interface between the main > processor and peripheral devices in computer systems. It offers several > advantages over the traditional LPC bus, including higher data transfer > rates, increased scalability and improved system management capabilities. > The eSPI protocol supports multiple channels, each serving a specific > purpose in the communication process. I see nothing in this series that registers a SPI controller with the SPI core. You need to use the standard frameworks the kernel offers to provide standard functionality.
On 3/17/2025 7:44 PM, Mark Brown wrote: Hi Mark, Thanks for reviewing the patch and apologies for delayed response. > On Fri, Mar 14, 2025 at 12:04:30AM +0530, Raju Rangoju wrote: >> The eSPI protocol serves as a communication interface between the main >> processor and peripheral devices in computer systems. It offers several >> advantages over the traditional LPC bus, including higher data transfer >> rates, increased scalability and improved system management capabilities. >> The eSPI protocol supports multiple channels, each serving a specific >> purpose in the communication process. > > I see nothing in this series that registers a SPI controller with the > SPI core. You need to use the standard frameworks the kernel offers to > provide standard functionality. The AMD SPI controller hardware has only the chip select line enabled, which is connected to the EC slave in AMD EMB platforms. Currently, there is no support from the slave device to register as an SPI slave device with the SPI framework and provide SPI communication. For this reason, the AMD eSPI driver is designed to handle device initialization itself and provide a character device file as an interface with user space for dynamic interaction and configurations.
On Wed, Mar 26, 2025 at 03:25:21PM +0530, Rangoju, Raju wrote: > On 3/17/2025 7:44 PM, Mark Brown wrote: > > I see nothing in this series that registers a SPI controller with the > > SPI core. You need to use the standard frameworks the kernel offers to > > provide standard functionality. > The AMD SPI controller hardware has only the chip select line enabled, which > is connected to the EC slave in AMD EMB platforms. Currently, there is no > support from the slave device to register as an SPI slave device with the > SPI framework and provide SPI communication. > For this reason, the AMD eSPI driver is designed to handle device > initialization itself and provide a character device file as an interface > with user space for dynamic interaction and configurations. If you want to ignore the SPI subsystem and just write a driver for your embedded controller then you should put the driver in the subsystem or subsystems for that embedded controller (possibly MFD if it does a bunch of things), not SPI. Even if there is no flexibility you may still want to have the controller side in the SPI subsystem in order to help with reuse with different controller/EC combinations but if you're going that way you need to use the SPI subsystem.
On 3/26/2025 4:35 PM, Mark Brown wrote: > On Wed, Mar 26, 2025 at 03:25:21PM +0530, Rangoju, Raju wrote: >> On 3/17/2025 7:44 PM, Mark Brown wrote: > >>> I see nothing in this series that registers a SPI controller with the >>> SPI core. You need to use the standard frameworks the kernel offers to >>> provide standard functionality. > >> The AMD SPI controller hardware has only the chip select line enabled, which >> is connected to the EC slave in AMD EMB platforms. Currently, there is no >> support from the slave device to register as an SPI slave device with the >> SPI framework and provide SPI communication. > >> For this reason, the AMD eSPI driver is designed to handle device >> initialization itself and provide a character device file as an interface >> with user space for dynamic interaction and configurations. > > If you want to ignore the SPI subsystem and just write a driver for your > embedded controller then you should put the driver in the subsystem or > subsystems for that embedded controller (possibly MFD if it does a bunch > of things), not SPI. Even if there is no flexibility you may still want > to have the controller side in the SPI subsystem in order to help with > reuse with different controller/EC combinations but if you're going that > way you need to use the SPI subsystem. Thanks for the suggestions Mark. We will rework on this.