On Fri, Oct 02, 2020 at 09:26:07PM +0300, Andy Shevchenko wrote: > On Fri, Oct 2, 2020 at 8:18 PM Serge Semin > <sergey.se...@baikalelectronics.ru> wrote: > > > > On Fri, Oct 02, 2020 at 01:19:29PM +0300, Andy Shevchenko wrote: > > > On Fri, Oct 02, 2020 at 01:28:10AM +0300, Serge Semin wrote: > > > > Currently DWC SSI core is supported by means of setting up the > > > > core-specific update_cr0() callback. It isn't suitable for multiple > > > > reasons. First of all having exported several methods doing the same > > > > thing > > > > but for different chips makes the code harder to maintain. Secondly the > > > > spi-dw-core driver exports the methods, then the spi-dw-mmio driver sets > > > > the private data callback with one of them so to be called by the core > > > > driver again. That makes the code logic too complicated. Thirdly using > > > > callbacks for just updating the CR0 register is problematic, since in > > > > case > > > > if the register needed to be updated from different parts of the code, > > > > we'd have to create another callback (for instance the SPI > > > > device-specific > > > > parameters don't need to be calculated each time the SPI transfer is > > > > submitted, so it's better to pre-calculate the CR0 data at the > > > > SPI-device > > > > setup stage). > > > > > > > > So keeping all the above in mind let's discard the update_cr0() > > > > callbacks, > > > > define a generic and static dw_spi_update_cr0() method and create the > > > > DW_SPI_CAP_DWC_SSI capability, which when enabled would activate the > > > > alternative CR0 register layout. > > > > > > > > While at it add the comments to the code path of the normal DW APB SSI > > > > controller setup to make the dw_spi_update_cr0() method looking > > > > coherent. > > > > > > > > What the point to increase indentation level and produce additional churn? > > > Can't you simply leave functions, unexport them, and call in one > > > conditional of > > > whatever new function is called? > > > > I forgot to mention that in the commit log, there is another reason why it's > > better to create a generic dw_spi_update_cr0() instead of doing what you > > suggest. > > As it will be seen from the following up patches, the dw_spi_update_cr0() > > function > > (to be more precise it's successor, but anyway) will be used from the SPI > > memory > > ops implementation. So if-else-ing here and there isn't a good idea for > > maintainability. For the same reason of the maintainability it's better to > > have a > > generic method which reflects all the config peculiarities, so in case of > > any > > changes they would be not be forgotten to be introduced for both DWC SSI > > and DW > > APB SSI parts of the setup procedures. As I see it that overbeats the > > additional > > indentation level drawback. >
> What I meant is to leave functions as is and call them under conditional > > if () > call one > else > call another Yeah, I understood what you meant. What you suggest would be a better solution if I needed to call the dw_spi_update_cr0() method just from a single place of the driver (but in that case I wouldn't need to replace the callback-based approach with the Capabilities-based one at all). The thing is that the dw_spi_update_cr0() will be also called from the SPI memory exec_op() callback (see patch "[PATCH v3 17/21] spi: dw: Add memory operations support" and the method dw_spi_update_config() invocation) in the same way as it is called from the SPI core transfer-one callback. Following your suggestion I would have to implement the same "if () call one else call another" pattern there too. Copying it here and there would be a weak design from the maintainability point of view and from the coding style too. Much better is to create a generic dw_spi_update_cr0() (later in this patchset it will be renamed to dw_spi_update_config()...), which would work for both DWC SSI and DW APB SSI by embedding the "if (is_CAP) call one else call another" into the method itself as I suggested in this patch. -Sergey > > > -- > With Best Regards, > Andy Shevchenko
