| Message ID | 20210421140653.3964725-1-arnd@kernel.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | spi: stm32-qspi: fix debug format string | expand |
On Wed, Apr 21, 2021 at 04:06:48PM +0200, Arnd Bergmann wrote: > From: Arnd Bergmann <arnd@arndb.de> > > Printing size_t needs a special %zd format modifier to avoid a > warning like: This doesn't apply against current code, please check and resend.
On Wed, Apr 21, 2021 at 5:05 PM Mark Brown <broonie@kernel.org> wrote: > > On Wed, Apr 21, 2021 at 04:06:48PM +0200, Arnd Bergmann wrote: > > From: Arnd Bergmann <arnd@arndb.de> > > > > Printing size_t needs a special %zd format modifier to avoid a > > warning like: > > This doesn't apply against current code, please check and resend. It appears that you just applied 1b8a7d4282c0 ("spi: stm32-qspi: Fix compilation warning in ARM64") after today's linux-next was cut. I suspect Patrice's patch now causes a warning on all architectures on which size_t is defined as 'unsigned int'. Arnd
Hi Mark, Arnd Regarding this issue, how do you prefer to proceed ? Patrice On 4/21/21 5:22 PM, Arnd Bergmann wrote: > On Wed, Apr 21, 2021 at 5:05 PM Mark Brown <broonie@kernel.org> wrote: >> >> On Wed, Apr 21, 2021 at 04:06:48PM +0200, Arnd Bergmann wrote: >>> From: Arnd Bergmann <arnd@arndb.de> >>> >>> Printing size_t needs a special %zd format modifier to avoid a >>> warning like: >> >> This doesn't apply against current code, please check and resend. > > It appears that you just applied 1b8a7d4282c0 ("spi: stm32-qspi: > Fix compilation warning in ARM64") after today's linux-next was > cut. > > I suspect Patrice's patch now causes a warning on all architectures > on which size_t is defined as 'unsigned int'. > > Arnd >
On Thu, Apr 22, 2021 at 09:30:16AM +0200, Patrice CHOTARD wrote: Please don't top post, reply in line with needed context. This allows readers to readily follow the flow of conversation and understand what you are talking about and also helps ensure that everything in the discussion is being addressed. > Regarding this issue, how do you prefer to proceed ? To repeat my original mail: > > On Wed, Apr 21, 2021 at 5:05 PM Mark Brown <broonie@kernel.org> wrote: > >> This doesn't apply against current code, please check and resend.
On Wed, 21 Apr 2021 16:06:48 +0200, Arnd Bergmann wrote: > Printing size_t needs a special %zd format modifier to avoid a > warning like: > > drivers/spi/spi-stm32-qspi.c:481:41: note: format string is defined here > 481 | dev_dbg(qspi->dev, "%s len = 0x%x offs = 0x%llx buf = 0x%p\n", __func__, len, offs, buf); Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next Thanks! [1/1] spi: stm32-qspi: fix debug format string commit: 14ef64ebdc2a4564893022780907747567452f6c 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
diff --git a/drivers/spi/spi-stm32-qspi.c b/drivers/spi/spi-stm32-qspi.c index e2a99f054551..7e640ccc7e77 100644 --- a/drivers/spi/spi-stm32-qspi.c +++ b/drivers/spi/spi-stm32-qspi.c @@ -478,7 +478,7 @@ static ssize_t stm32_qspi_dirmap_read(struct spi_mem_dirmap_desc *desc, * all needed transfer information into struct spi_mem_op */ memcpy(&op, &desc->info.op_tmpl, sizeof(struct spi_mem_op)); - dev_dbg(qspi->dev, "%s len = 0x%x offs = 0x%llx buf = 0x%p\n", __func__, len, offs, buf); + dev_dbg(qspi->dev, "%s len = 0x%zx offs = 0x%llx buf = 0x%p\n", __func__, len, offs, buf); op.data.nbytes = len; op.addr.val = desc->info.offset + offs;