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 <[email protected]>
---
drivers/mmc/host/mmc_spi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
index b8dda8160c4e..bf35761f783a 100644
--- a/drivers/mmc/host/mmc_spi.c
+++ b/drivers/mmc/host/mmc_spi.c
@@ -935,7 +935,7 @@ static void mmc_spi_request(struct mmc_host *mmc, struct mmc_request *mrq)
#endif
/* request exclusive bus access */
- spi_bus_lock(host->spi->master);
+ spi_bus_lock(host->spi->controller);
crc_recover:
/* issue command; then optionally data and stop */
@@ -967,7 +967,7 @@ static void mmc_spi_request(struct mmc_host *mmc, struct mmc_request *mrq)
}
/* release the bus */
- spi_bus_unlock(host->spi->master);
+ spi_bus_unlock(host->spi->controller);
mmc_request_done(host->mmc, mrq);
}
@@ -1157,7 +1157,7 @@ static int mmc_spi_probe(struct spi_device *spi)
/* We rely on full duplex transfers, mostly to reduce
* per-transfer overheads (by making fewer transfers).
*/
- if (spi->master->flags & SPI_CONTROLLER_HALF_DUPLEX)
+ if (spi->controller->flags & SPI_CONTROLLER_HALF_DUPLEX)
return -EINVAL;
/* MMC and SD specs only seem to care that sampling is on the
--
2.43.0
On Mon, 22 Jan 2024 at 19:08, Uwe Kleine-König
<[email protected]> 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 <[email protected]>
It looks like we need a decision if this should go via Mark's tree,
the series altogether - or if each subsystem maintainer should apply
each patch separately and postpone the final cleanups.
While waiting for a conclusion, here's my ack.
Acked-by: Ulf Hansson <[email protected]>
Kind regards
Uffe
> ---
> drivers/mmc/host/mmc_spi.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
> index b8dda8160c4e..bf35761f783a 100644
> --- a/drivers/mmc/host/mmc_spi.c
> +++ b/drivers/mmc/host/mmc_spi.c
> @@ -935,7 +935,7 @@ static void mmc_spi_request(struct mmc_host *mmc, struct mmc_request *mrq)
> #endif
>
> /* request exclusive bus access */
> - spi_bus_lock(host->spi->master);
> + spi_bus_lock(host->spi->controller);
>
> crc_recover:
> /* issue command; then optionally data and stop */
> @@ -967,7 +967,7 @@ static void mmc_spi_request(struct mmc_host *mmc, struct mmc_request *mrq)
> }
>
> /* release the bus */
> - spi_bus_unlock(host->spi->master);
> + spi_bus_unlock(host->spi->controller);
>
> mmc_request_done(host->mmc, mrq);
> }
> @@ -1157,7 +1157,7 @@ static int mmc_spi_probe(struct spi_device *spi)
> /* We rely on full duplex transfers, mostly to reduce
> * per-transfer overheads (by making fewer transfers).
> */
> - if (spi->master->flags & SPI_CONTROLLER_HALF_DUPLEX)
> + if (spi->controller->flags & SPI_CONTROLLER_HALF_DUPLEX)
> return -EINVAL;
>
> /* MMC and SD specs only seem to care that sampling is on the
> --
> 2.43.0
>
On Tue, Jan 23, 2024 at 02:09:42PM +0100, Ulf Hansson wrote:
> It looks like we need a decision if this should go via Mark's tree,
> the series altogether - or if each subsystem maintainer should apply
> each patch separately and postpone the final cleanups.
> While waiting for a conclusion, here's my ack.
As far as I'm concerned at this point it's going via my tree, I've got
it queued for -rc3.