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.
Attachment:
signature.asc
Description: PGP signature
