lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 2 Oct 2020 21:26:07 +0300 From: Andy Shevchenko <andy.shevchenko@...il.com> To: Serge Semin <Sergey.Semin@...kalelectronics.ru> Cc: Serge Semin <fancer.lancer@...il.com>, Mark Brown <broonie@...nel.org>, Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>, Ramil Zaripov <Ramil.Zaripov@...kalelectronics.ru>, Pavel Parkhomenko <Pavel.Parkhomenko@...kalelectronics.ru>, Lars Povlsen <lars.povlsen@...rochip.com>, "wuxu . wu" <wuxu.wu@...wei.com>, Feng Tang <feng.tang@...el.com>, Rob Herring <robh+dt@...nel.org>, linux-spi <linux-spi@...r.kernel.org>, devicetree <devicetree@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: [PATCH v3 02/21] spi: dw: Add DWC SSI capability On Fri, Oct 2, 2020 at 8:18 PM Serge Semin <Sergey.Semin@...kalelectronics.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 -- With Best Regards, Andy Shevchenko
Powered by blists - more mailing lists