| Message ID | 20201201085916.63543-1-fido_max@inbox.ru |
|---|---|
| State | Accepted |
| Commit | 2c2b3ad2c4c801bab1eec7264ea6991b1e4e8f2c |
| Headers | show |
| Series | spi: spi-fsl-dspi: Use max_native_cs instead of num_chipselect to set SPI_MCR | expand |
On Tue, 1 Dec 2020 11:59:16 +0300, Maxim Kochetkov wrote: > If cs-gpios property is used in devicetree then ctlr->num_chipselect value > may be changed by spi_get_gpio_descs(). > So use ctlr->max_native_cs instead of ctlr->num_chipselect to set SPI_MCR Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] spi: spi-fsl-dspi: Use max_native_cs instead of num_chipselect to set SPI_MCR (no commit info) All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark
Should I resend it? 01.12.2020 16:57, Mark Brown пишет: > On Tue, 1 Dec 2020 11:59:16 +0300, Maxim Kochetkov wrote: >> If cs-gpios property is used in devicetree then ctlr->num_chipselect value >> may be changed by spi_get_gpio_descs(). >> So use ctlr->max_native_cs instead of ctlr->num_chipselect to set SPI_MCR > > Applied to > > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next > > Thanks! > > [1/1] spi: spi-fsl-dspi: Use max_native_cs instead of num_chipselect to set SPI_MCR > (no commit info) > > All being well this means that it will be integrated into the linux-next > tree (usually sometime in the next 24 hours) and sent to Linus during > the next merge window (or sooner if it is a bug fix), however if > problems are discovered then the patch may be dropped or reverted. > > You may get further e-mails resulting from automated or manual testing > and review of the tree, please engage with people reporting problems and > send followup patches addressing any issues that are reported if needed. > > If any updates are required or you are submitting further changes they > should be sent as incremental updates against current git, existing > patches will not be replaced. > > Please add any relevant lists and maintainers to the CCs when replying > to this mail. > > Thanks, > Mark >
On Wed, Dec 02, 2020 at 05:20:00PM +0300, Maxim Kochetkov wrote:
> Should I resend it?
If the patch isn't actually applied then yes.
On Wed, Dec 02, 2020 at 02:22:20PM +0000, Mark Brown wrote: > On Wed, Dec 02, 2020 at 05:20:00PM +0300, Maxim Kochetkov wrote: > > > Should I resend it? > > If the patch isn't actually applied then yes. Do you frequently send out emails that you've applied a patch and then not apply it?
On Thu, Dec 03, 2020 at 01:55:34AM +0200, Vladimir Oltean wrote: > On Wed, Dec 02, 2020 at 02:22:20PM +0000, Mark Brown wrote: > > If the patch isn't actually applied then yes. > Do you frequently send out emails that you've applied a patch and then > not apply it? There was an issue the other day where b4 had a bug which caused it to send out mails for everything it had in its database, including things I'd downloaded to test but not applied for whatever reason.
diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c index 1a08c1d584ab..028736687488 100644 --- a/drivers/spi/spi-fsl-dspi.c +++ b/drivers/spi/spi-fsl-dspi.c @@ -1165,7 +1165,7 @@ static int dspi_init(struct fsl_dspi *dspi) unsigned int mcr; /* Set idle states for all chip select signals to high */ - mcr = SPI_MCR_PCSIS(GENMASK(dspi->ctlr->num_chipselect - 1, 0)); + mcr = SPI_MCR_PCSIS(GENMASK(dspi->ctlr->max_native_cs - 1, 0)); if (dspi->devtype_data->trans_mode == DSPI_XSPI_MODE) mcr |= SPI_MCR_XSPI; @@ -1250,7 +1250,7 @@ static int dspi_probe(struct platform_device *pdev) pdata = dev_get_platdata(&pdev->dev); if (pdata) { - ctlr->num_chipselect = pdata->cs_num; + ctlr->num_chipselect = ctlr->max_native_cs = pdata->cs_num; ctlr->bus_num = pdata->bus_num; /* Only Coldfire uses platform data */ @@ -1263,7 +1263,7 @@ static int dspi_probe(struct platform_device *pdev) dev_err(&pdev->dev, "can't get spi-num-chipselects\n"); goto out_ctlr_put; } - ctlr->num_chipselect = cs_num; + ctlr->num_chipselect = ctlr->max_native_cs = cs_num; of_property_read_u32(np, "bus-num", &bus_num); ctlr->bus_num = bus_num;
If cs-gpios property is used in devicetree then ctlr->num_chipselect value may be changed by spi_get_gpio_descs(). So use ctlr->max_native_cs instead of ctlr->num_chipselect to set SPI_MCR Fixes: 4fcc7c2292de (spi: spi-fsl-dspi: Don't access reserved fields in SPI_MCR) Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru> --- drivers/spi/spi-fsl-dspi.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)