| Message ID | 20220123175201.34839-3-u.kleine-koenig@pengutronix.de (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | c222ea5d2f3361458672d1f52c78970aa021cb61 |
| Headers | show |
| Series | spi: make remove callback a void function | expand |
Hello Greg, On Sun, Jan 23, 2022 at 06:51:58PM +0100, Uwe Kleine-König wrote: > The two macros FBTFT_REGISTER_DRIVER and FBTFT_REGISTER_SPI_DRIVER > contain quite some duplication: Both define an spi driver and an of device > table and the differences are quite subtle. > > So create two new macros and use both twice. > > Link: https://lore.kernel.org/r/20220118181338.207943-2-u.kleine-koenig@pengutronix.de > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> You picked this patch into your staging-next branch, I guess from the original submission. Not sure how Mark wants to continue with the series from this thread, but at least my plan was that he will create an immutable branch on top of 5.17-rc2 (assuming 5.17-rc2 will contain "staging: fbtft: Fix error path in fbtft_driver_module_init()") with the remaining 4 patches in this series. In a private mail you agreed to this procedure, but this didn't stop you taking this patch?! What is your plan here? The obvious (to me) options are: - Delay this series until after the next merge window. - You back out this patch from staging-next and ack here for Mark to apply it to an immutable branch. - You keep this patch in staging-next and still ack here for Mark to apply it to an immutable branch. Then the patch would be included twice. Best regards Uwe
On Thu, Jan 27, 2022 at 10:36:07PM +0100, Uwe Kleine-König wrote: > Hello Greg, > > On Sun, Jan 23, 2022 at 06:51:58PM +0100, Uwe Kleine-König wrote: > > The two macros FBTFT_REGISTER_DRIVER and FBTFT_REGISTER_SPI_DRIVER > > contain quite some duplication: Both define an spi driver and an of device > > table and the differences are quite subtle. > > > > So create two new macros and use both twice. > > > > Link: https://lore.kernel.org/r/20220118181338.207943-2-u.kleine-koenig@pengutronix.de > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > > You picked this patch into your staging-next branch, I guess from the > original submission. Not sure how Mark wants to continue with the series > from this thread, but at least my plan was that he will create an > immutable branch on top of 5.17-rc2 (assuming 5.17-rc2 will contain > "staging: fbtft: Fix error path in fbtft_driver_module_init()") with the > remaining 4 patches in this series. That's fine, I can pull from that. > In a private mail you agreed to this procedure, but this didn't stop you > taking this patch?! What is your plan here? The obvious (to me) options > are: > > - Delay this series until after the next merge window. > - You back out this patch from staging-next and ack here for Mark to > apply it to an immutable branch. > - You keep this patch in staging-next and still ack here for Mark to > apply it to an immutable branch. Then the patch would be included > twice. Included twice is fine, or I can revert it in the staging tree. Don't let staging tree issues prevent you from doing real work in the other part of the kernel, I can manage merges and other issues like this very easily. thanks, greg k-h
diff --git a/drivers/staging/fbtft/fbtft.h b/drivers/staging/fbtft/fbtft.h index 55677efc0138..6a7545b5bcd2 100644 --- a/drivers/staging/fbtft/fbtft.h +++ b/drivers/staging/fbtft/fbtft.h @@ -272,21 +272,40 @@ void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...); void fbtft_write_reg16_bus8(struct fbtft_par *par, int len, ...); void fbtft_write_reg16_bus16(struct fbtft_par *par, int len, ...); +#define FBTFT_DT_TABLE(_compatible) \ +static const struct of_device_id dt_ids[] = { \ + { .compatible = _compatible }, \ + {}, \ +}; \ +MODULE_DEVICE_TABLE(of, dt_ids); + +#define FBTFT_SPI_DRIVER(_name, _compatible, _display, _spi_ids) \ + \ +static int fbtft_driver_probe_spi(struct spi_device *spi) \ +{ \ + return fbtft_probe_common(_display, spi, NULL); \ +} \ + \ +static int fbtft_driver_remove_spi(struct spi_device *spi) \ +{ \ + struct fb_info *info = spi_get_drvdata(spi); \ + \ + fbtft_remove_common(&spi->dev, info); \ + return 0; \ +} \ + \ +static struct spi_driver fbtft_driver_spi_driver = { \ + .driver = { \ + .name = _name, \ + .of_match_table = dt_ids, \ + }, \ + .id_table = _spi_ids, \ + .probe = fbtft_driver_probe_spi, \ + .remove = fbtft_driver_remove_spi, \ +}; + #define FBTFT_REGISTER_DRIVER(_name, _compatible, _display) \ \ -static int fbtft_driver_probe_spi(struct spi_device *spi) \ -{ \ - return fbtft_probe_common(_display, spi, NULL); \ -} \ - \ -static int fbtft_driver_remove_spi(struct spi_device *spi) \ -{ \ - struct fb_info *info = spi_get_drvdata(spi); \ - \ - fbtft_remove_common(&spi->dev, info); \ - return 0; \ -} \ - \ static int fbtft_driver_probe_pdev(struct platform_device *pdev) \ { \ return fbtft_probe_common(_display, NULL, pdev); \ @@ -300,22 +319,9 @@ static int fbtft_driver_remove_pdev(struct platform_device *pdev) \ return 0; \ } \ \ -static const struct of_device_id dt_ids[] = { \ - { .compatible = _compatible }, \ - {}, \ -}; \ - \ -MODULE_DEVICE_TABLE(of, dt_ids); \ +FBTFT_DT_TABLE(_compatible) \ \ - \ -static struct spi_driver fbtft_driver_spi_driver = { \ - .driver = { \ - .name = _name, \ - .of_match_table = dt_ids, \ - }, \ - .probe = fbtft_driver_probe_spi, \ - .remove = fbtft_driver_remove_spi, \ -}; \ +FBTFT_SPI_DRIVER(_name, _compatible, _display, NULL) \ \ static struct platform_driver fbtft_driver_platform_driver = { \ .driver = { \ @@ -351,42 +357,15 @@ module_exit(fbtft_driver_module_exit); #define FBTFT_REGISTER_SPI_DRIVER(_name, _comp_vend, _comp_dev, _display) \ \ -static int fbtft_driver_probe_spi(struct spi_device *spi) \ -{ \ - return fbtft_probe_common(_display, spi, NULL); \ -} \ - \ -static int fbtft_driver_remove_spi(struct spi_device *spi) \ -{ \ - struct fb_info *info = spi_get_drvdata(spi); \ - \ - fbtft_remove_common(&spi->dev, info); \ - return 0; \ -} \ - \ -static const struct of_device_id dt_ids[] = { \ - { .compatible = _comp_vend "," _comp_dev }, \ - {}, \ -}; \ - \ -MODULE_DEVICE_TABLE(of, dt_ids); \ +FBTFT_DT_TABLE(_comp_vend "," _comp_dev) \ \ static const struct spi_device_id spi_ids[] = { \ { .name = _comp_dev }, \ {}, \ }; \ - \ MODULE_DEVICE_TABLE(spi, spi_ids); \ \ -static struct spi_driver fbtft_driver_spi_driver = { \ - .driver = { \ - .name = _name, \ - .of_match_table = dt_ids, \ - }, \ - .id_table = spi_ids, \ - .probe = fbtft_driver_probe_spi, \ - .remove = fbtft_driver_remove_spi, \ -}; \ +FBTFT_SPI_DRIVER(_name, _comp_vend "," _comp_dev, _display, spi_ids) \ \ module_spi_driver(fbtft_driver_spi_driver);
The two macros FBTFT_REGISTER_DRIVER and FBTFT_REGISTER_SPI_DRIVER contain quite some duplication: Both define an spi driver and an of device table and the differences are quite subtle. So create two new macros and use both twice. Link: https://lore.kernel.org/r/20220118181338.207943-2-u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> --- drivers/staging/fbtft/fbtft.h | 93 ++++++++++++++--------------------- 1 file changed, 36 insertions(+), 57 deletions(-)