summaryrefslogtreecommitdiff
path: root/drivers/spi/spi-dw-bt1.c
AgeCommit message (Collapse)AuthorFilesLines
2021-11-16spi: dw: Put the driver entities naming in orderSerge Semin1-4/+4
Mostly due to a long driver history it's methods and macro names look a bit messy. In particularly that concerns the code their prefixes. A biggest part of the driver functions and macros have got the dw_spi/DW_SPI prefixes. But there are some entities which have been just "spi_/SPI_"-prefixed. Especially that concerns the CSR and their fields macro definitions. It makes the code harder to comprehend since such methods and macros can be easily confused with the global SPI-subsystem exports. In this case the only possible way to more or less quickly distinguish one naming space from another is either by context or by the argument type, which most of the times isn't that easy anyway. In addition to that a new DW SSI IP-core support has been added in the framework of commit e539f435cb9c ("spi: dw: Add support for DesignWare DWC_ssi"), which introduced a new set or macro-prefixes to describe CTRLR0-specific fields and worsen the situation. Finally there are methods with no DW SPI driver-reference prefix at all, that make the code reading even harder. So in order to ease the driver hacking let's bring the code naming to a common base: 1) Each method is supposed to have "dw_spi_" prefix so to be easily distinguished from the kernel API, e.g. SPI-subsystem methods and macros. (Exception is the local implementation of the readl/writel methods since being just the regspace accessors.) 2) Each generically used macro should have DW_SPI_-prefix thus being easily comprehended as the local driver definition. 3) DW APB SSI and DW SSI specific macros should have prefixes as DW_PSSI_ and DW_HSSI_ respectively so referring to the system buses they support (APB and AHB similarly to the DT clocks naming like pclk, hclk). Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-11-16spi: dw: Add a symbols namespace for the core moduleSerge Semin1-0/+1
The exported from the DW SPI driver core/DMA symbols are only used by the spi-dw-{mmio,pci,bt1}.o objects. Add these symbols to a separate namespace then and make sure the depended modules have it imported. Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20211115181917.7521-2-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2021-02-12spi: dw: Avoid stack content exposureKees Cook1-1/+1
Since "data" is u32, &data is a "u32 *" type, which means pointer math will move in u32-sized steps. This was meant to be a byte offset, so cast &data to "char *" to aim the copy into the correct location. Seen with -Warray-bounds (and found by Coverity): In file included from ./include/linux/string.h:269, from ./arch/powerpc/include/asm/paca.h:15, from ./arch/powerpc/include/asm/current.h:13, from ./include/linux/mutex.h:14, from ./include/linux/notifier.h:14, from ./include/linux/clk.h:14, from drivers/spi/spi-dw-bt1.c:12: In function 'memcpy', inlined from 'dw_spi_bt1_dirmap_copy_from_map' at drivers/spi/spi-dw-bt1.c:87:3: ./include/linux/fortify-string.h:20:29: warning: '__builtin_memcpy' offset 4 is out of the bounds [0, 4] of object 'data' with type 'u32' {aka 'unsigned int'} [-Warray-bounds] 20 | #define __underlying_memcpy __builtin_memcpy | ^ ./include/linux/fortify-string.h:191:9: note: in expansion of macro '__underlying_memcpy' 191 | return __underlying_memcpy(p, q, size); | ^~~~~~~~~~~~~~~~~~~ drivers/spi/spi-dw-bt1.c: In function 'dw_spi_bt1_dirmap_copy_from_map': drivers/spi/spi-dw-bt1.c:77:6: note: 'data' declared here 77 | u32 data; | ^~~~ Addresses-Coverity: CID 1497771 Out-of-bounds access Fixes: abf00907538e ("spi: dw: Add Baikal-T1 SPI Controller glue driver") Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20210211203714.1929862-1-keescook@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-11Merge remote-tracking branch 'spi/for-5.11' into spi-nextMark Brown1-1/+1
2020-12-07spi: dw: Fix error return code in dw_spi_bt1_probe()Zhang Changzhong1-1/+3
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: abf00907538e ("spi: dw: Add Baikal-T1 SPI Controller glue driver") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/1607071357-33378-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-25spi: dw: fixed missing resource_sizeTian Tao1-1/+1
fixed the coccicheck: drivers/spi/spi-dw-bt1.c:220:27-30: ERROR: Missing resource_size with mem. Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/1606114975-31362-1-git-send-email-tiantao6@hisilicon.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-10-09spi: dw: Add Baikal-T1 SPI Controller glue driverSerge Semin1-0/+339
Baikal-T1 is equipped with three DW APB SSI-based MMIO SPI controllers. Two of them are pretty much normal: with IRQ, DMA, FIFOs of 64 words depth, 4x CSs, but the third one as being a part of the Baikal-T1 System Boot Controller has got a very limited resources: no IRQ, no DMA, only a single native chip-select and Tx/Rx FIFO with just 8 words depth available. In order to provide a transparent initial boot code execution the Boot SPI controller is also utilized by an vendor-specific IP-block, which exposes an SPI flash direct mapping interface. Since both direct mapping and SPI controller normal utilization are mutual exclusive only one of these interfaces can be used to access an external SPI slave device. That's why a dedicated mux is embedded into the System Boot Controller. All of that is taken into account in the Baikal-T1-specific DW APB SSI glue driver implemented by means of the DW SPI core module. Co-developed-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201007235511.4935-22-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>