Message ID | cover.1705348269.git.u.kleine-koenig@pengutronix.de |
---|---|
Headers | show |
Series | spi: get rid of some legacy macros | expand |
On 15. 01. 24 21:12, Uwe Kleine-König wrote: > In commit 8caab75fd2c2 ("spi: Generalize SPI "master" to "controller"") > some functions and struct members were renamed. To not break all drivers > compatibility macros were provided. > > To be able to remove these compatibility macros push the renaming into > this driver. > > Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> > --- > drivers/media/pci/mgb4/mgb4_core.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/media/pci/mgb4/mgb4_core.c b/drivers/media/pci/mgb4/mgb4_core.c > index 5bfb8a06202e..9bcf10a77fd3 100644 > --- a/drivers/media/pci/mgb4/mgb4_core.c > +++ b/drivers/media/pci/mgb4/mgb4_core.c > @@ -144,7 +144,7 @@ static int match_spi_adap(struct device *dev, void *data) > return to_spi_device(dev) ? 1 : 0; > } > > -static struct spi_master *get_spi_adap(struct platform_device *pdev) > +static struct spi_controller *get_spi_adap(struct platform_device *pdev) > { > struct device *dev; > > @@ -152,7 +152,7 @@ static struct spi_master *get_spi_adap(struct platform_device *pdev) > dev = device_find_child(&pdev->dev, NULL, match_spi_adap); > mutex_unlock(&pdev->dev.mutex); > > - return dev ? container_of(dev, struct spi_master, dev) : NULL; > + return dev ? container_of(dev, struct spi_controller, dev) : NULL; > } > > static int init_spi(struct mgb4_dev *mgbdev, u32 devid) > @@ -179,7 +179,7 @@ static int init_spi(struct mgb4_dev *mgbdev, u32 devid) > }; > struct pci_dev *pdev = mgbdev->pdev; > struct device *dev = &pdev->dev; > - struct spi_master *master; > + struct spi_controller *ctlr; > struct spi_device *spi_dev; > u32 irq; > int rv, id; > @@ -207,8 +207,8 @@ static int init_spi(struct mgb4_dev *mgbdev, u32 devid) > return PTR_ERR(mgbdev->spi_pdev); > } > > - master = get_spi_adap(mgbdev->spi_pdev); > - if (!master) { > + ctlr = get_spi_adap(mgbdev->spi_pdev); > + if (!ctlr) { > dev_err(dev, "failed to get SPI adapter\n"); > rv = -EINVAL; > goto err_pdev; > @@ -242,8 +242,8 @@ static int init_spi(struct mgb4_dev *mgbdev, u32 devid) > > spi_info.platform_data = &mgbdev->flash_data; > > - spi_dev = spi_new_device(master, &spi_info); > - put_device(&master->dev); > + spi_dev = spi_new_device(ctlr, &spi_info); > + put_device(&ctlr->dev); > if (!spi_dev) { > dev_err(dev, "failed to create MTD device\n"); > rv = -EINVAL; Reviewed-by: Martin Tůma <martin.tuma@digiteqautomotive.com>
On Mon, Jan 15, 2024 at 09:12:46PM +0100, Uwe Kleine-König wrote: > In commit 8caab75fd2c2 ("spi: Generalize SPI "master" to "controller"") > some functions were renamed. Further some compat defines were introduced > to map the old names to the new ones. > Patch #18 and #19 touch the same driver, otherwise the patches #1 - #31 > are pairwise independent and could be applied by their respective > maintainers. The alternative is to let all patches go via the spi tree. > Mark, what's your preference here? I don't have a strong preference here, I'm happy to take all the patches if the maintainers for the other subsystem are OK with that - ideally I'd apply things at -rc1 but the timeline is a bit tight there. I think my plan here unless anyone objects (or I notice something myself) will be to queue things at -rc3, please shout if that doesn't seem reasonable.
Hello Mark, On Tue, Jan 16, 2024 at 02:40:39PM +0000, Mark Brown wrote: > On Mon, Jan 15, 2024 at 09:12:46PM +0100, Uwe Kleine-König wrote: > > > In commit 8caab75fd2c2 ("spi: Generalize SPI "master" to "controller"") > > some functions were renamed. Further some compat defines were introduced > > to map the old names to the new ones. > > > Patch #18 and #19 touch the same driver, otherwise the patches #1 - #31 > > are pairwise independent and could be applied by their respective > > maintainers. The alternative is to let all patches go via the spi tree. > > Mark, what's your preference here? > > I don't have a strong preference here, I'm happy to take all the patches > if the maintainers for the other subsystem are OK with that - ideally > I'd apply things at -rc1 but the timeline is a bit tight there. I think > my plan here unless anyone objects (or I notice something myself) will > be to queue things at -rc3, please shout if that doesn't seem > reasonable. From my side there is no rush, we lived with these defines since 4.13-rc1. Applying them during the next merge window is fine for me. Anyhow, I intend to resend the series for the feedback I received after -rc1. Up to you when you want to apply it. Watching out for offending patches using lore shouldn't be a big thing and I can do that. Best regards Uwe