[PATCH v12 0/6] Driver for at91 usart in spi mode
From: alexandre.belloni@bootlin.com (Alexandre Belloni)
Date: 2018-09-11 09:39:32
Also in:
linux-devicetree, linux-serial, linux-spi, lkml
On 11/09/2018 10:33:56+0100, Lee Jones wrote:
On Tue, 04 Sep 2018, Radu Pirea wrote:quoted
Radu Pirea (6): MAINTAINERS: add at91 usart mfd driver dt-bindings: add binding for atmel-usart in SPI mode mfd: at91-usart: added mfd driver for usart MAINTAINERS: add at91 usart spi driver spi: at91-usart: add driver for at91-usart as spi tty/serial: atmel: change the driver to work under at91-usart mfd .../bindings/{serial => mfd}/atmel-usart.txt | 25 +- MAINTAINERS | 16 + drivers/mfd/Kconfig | 9 + drivers/mfd/Makefile | 1 + drivers/mfd/at91-usart.c | 71 +++ drivers/spi/Kconfig | 8 + drivers/spi/Makefile | 1 + drivers/spi/spi-at91-usart.c | 432 ++++++++++++++++++ drivers/tty/serial/Kconfig | 1 + drivers/tty/serial/atmel_serial.c | 42 +- include/dt-bindings/mfd/at91-usart.h | 17 + 11 files changed, 606 insertions(+), 17 deletions(-) rename Documentation/devicetree/bindings/{serial => mfd}/atmel-usart.txt (76%) create mode 100644 drivers/mfd/at91-usart.c create mode 100644 drivers/spi/spi-at91-usart.c create mode 100644 include/dt-bindings/mfd/at91-usart.hSeeing as this patch-set has caused some issues this morning, I took the liberty to peruse back into its history to figure out where things started to go wrong. I also re-reviewed the MFD driver - and I'm glad I did! My Acked-by has been attached to the MFD portion since v5, which is why the code hasn't caught my eye before today. I reviewed the relocation of the *binding document* (serial => mfd with no changes) in v4 and nothing else. It appears as though you mistakenly added it to the *MFD driver* instead. This explains my confusion in v10 when I told you I'd already reviewed the binding document. As I said, I have re-reviewed the MFD driver and I'm afraid to say that I do not like what I see. Besides the missing header file and the whitespace tabbing errors, I do not agree with the implementation. Using MFD as a shim to hack around driver selection is not a valid use-case. What's stopping you from just using the compatible string directly to select which driver you need to probe?
Then you'd have multiple compatible strings for the same IP which is a big no-no. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com