Message ID | 20240916134928.3654054-1-alexander.usyskin@intel.com (mailing list archive) |
---|---|
Headers | show |
Series | spi: add driver for Intel discrete graphics | expand |
On Mon, Sep 16, 2024 at 04:49:16PM +0300, Alexander Usyskin wrote: > Add driver for access to Intel discrete graphics card > internal SPI device. > Expose device on auxiliary bus by i915 and Xe drivers and > provide spi driver to register this device with MTD framework. As far as I can tell this does not actually provide a SPI driver, there is no call to any SPI API that I've noticed here. The SPI framework does have support for SPI controllers with specific flash support via spi_controller_mem_ops but this does not appear to use them. Either it should do that or it should just be a MTD driver. The series is also split up into too many patches with minimal explanation, making it hard to follow what's going on. I would recommend making the first patch be a minimal functional driver and then building on top of that.
> On Mon, Sep 16, 2024 at 04:49:16PM +0300, Alexander Usyskin wrote: > > Add driver for access to Intel discrete graphics card > > internal SPI device. > > Expose device on auxiliary bus by i915 and Xe drivers and > > provide spi driver to register this device with MTD framework. > > As far as I can tell this does not actually provide a SPI driver, there > is no call to any SPI API that I've noticed here. The SPI framework > does have support for SPI controllers with specific flash support via > spi_controller_mem_ops but this does not appear to use them. Either it > should do that or it should just be a MTD driver. > I have had some talks with Miquel on this and he was not sure where this driver belongs. Miquel - can this driver be put in drivers/mtd, as spi cleanly do not want it? > The series is also split up into too many patches with minimal > explanation, making it hard to follow what's going on. I would > recommend making the first patch be a minimal functional driver and then > building on top of that. As I understand, better to have small amount of big patches than big list of smaller patches? I'll try, according to your comments in other patches, but we have there three big parts (changes in i915, changes in Xe and actual spi/mtd driver) and they should come together as there is no point in any of them alone. - - Thanks, Sasha
On Thu, Sep 19, 2024 at 06:56:39AM +0000, Usyskin, Alexander wrote: > > On Mon, Sep 16, 2024 at 04:49:16PM +0300, Alexander Usyskin wrote: > > As far as I can tell this does not actually provide a SPI driver, there > > is no call to any SPI API that I've noticed here. The SPI framework > > does have support for SPI controllers with specific flash support via > > spi_controller_mem_ops but this does not appear to use them. Either it > > should do that or it should just be a MTD driver. > I have had some talks with Miquel on this and he was not sure where this driver belongs. > Miquel - can this driver be put in drivers/mtd, as spi cleanly do not want it? To be clear, it's not that this hardware shouldn't be supported in the SPI subsystem it's that if the driver is in the SPI subsystem it should be written in terms of the relevant APIs. Simply taking a MTD driver and dropping it in a random other directory with no further updates is clearly not the way forwards. > > The series is also split up into too many patches with minimal > > explanation, making it hard to follow what's going on. I would > > recommend making the first patch be a minimal functional driver and then > > building on top of that. > As I understand, better to have small amount of big patches > than big list of smaller patches? The patches should be individually standalone and useful, the problem here is that it's difficult to review any of the patches by themselves because they've not been split up with a clear goal.