| Message ID | 20220529141250.1979827-1-u.kleine-koenig@pengutronix.de (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | d6f8168e4345cb00156743c19dc1a409126936e1 |
| Headers | show |
| Series | ASoC: Intel: avs: Fix build error on arc, m68k and sparc | expand |
On Sun, May 29, 2022 at 04:12:50PM +0200, Uwe Kleine-König wrote: > On some platforms (i.e. arc, m68k and sparc) __fls returns an int (while > on most platforms it returns an unsigned long). This triggers a format > warning on these few platforms as the driver uses %ld to print a warning. Please don't send new patches in reply to old patches or serieses, this makes it harder for both people and tools to understand what is going on - it can bury things in mailboxes and make it difficult to keep track of what current patches are, both for the new patches and the old ones.
Hello Mark, On Mon, May 30, 2022 at 03:29:48PM +0200, Mark Brown wrote: > On Sun, May 29, 2022 at 04:12:50PM +0200, Uwe Kleine-König wrote: > > On some platforms (i.e. arc, m68k and sparc) __fls returns an int (while > > on most platforms it returns an unsigned long). This triggers a format > > warning on these few platforms as the driver uses %ld to print a warning. > > Please don't send new patches in reply to old patches or serieses, this > makes it harder for both people and tools to understand what is going > on - it can bury things in mailboxes and make it difficult to keep track > of what current patches are, both for the new patches and the old ones. The motivation to do that is that the thread for a patch that broke something is the canonical place to look if someone already reported (or even fixed) the problem before. That b4 seems to fail to extract the patch is indeed unfortunate. For a MUA I'd expect that it sorts threads after the last received mail, so that part is only a matter of a sane mail reader configuration. Best regards Uwe
On Mon, May 30, 2022 at 10:19:46PM +0200, Uwe Kleine-König wrote: > On Mon, May 30, 2022 at 03:29:48PM +0200, Mark Brown wrote: > > Please don't send new patches in reply to old patches or serieses, this > > makes it harder for both people and tools to understand what is going > > on - it can bury things in mailboxes and make it difficult to keep track > > of what current patches are, both for the new patches and the old ones. > The motivation to do that is that the thread for a patch that broke > something is the canonical place to look if someone already reported (or > even fixed) the problem before. Once something is applied and as time marches on that starts to get less and less helpful, searches for Fixes: are probably better there. > That b4 seems to fail to extract the patch is indeed unfortunate. For a > MUA I'd expect that it sorts threads after the last received mail, so > that part is only a matter of a sane mail reader configuration. The sorting really is a user workflow/preference thing - for example I find it helpful to sort by age of the thread to highlight new patches which might be simple to deal with before older threads with complicated discussions in them.
diff --git a/sound/soc/intel/avs/board_selection.c b/sound/soc/intel/avs/board_selection.c index 80cb0164678a..87f9c18be238 100644 --- a/sound/soc/intel/avs/board_selection.c +++ b/sound/soc/intel/avs/board_selection.c @@ -326,7 +326,8 @@ static int avs_register_i2s_board(struct avs_dev *adev, struct snd_soc_acpi_mach num_ssps = adev->hw_cfg.i2s_caps.ctrl_count; if (fls(mach->mach_params.i2s_link_mask) > num_ssps) { dev_err(adev->dev, "Platform supports %d SSPs but board %s requires SSP%ld\n", - num_ssps, mach->drv_name, __fls(mach->mach_params.i2s_link_mask)); + num_ssps, mach->drv_name, + (unsigned long)__fls(mach->mach_params.i2s_link_mask)); return -ENODEV; }
On some platforms (i.e. arc, m68k and sparc) __fls returns an int (while on most platforms it returns an unsigned long). This triggers a format warning on these few platforms as the driver uses %ld to print a warning. So explicitly cast the return value to unsigned long to make the warning go away (and so fix allmodconfig build on the affected architectures). Fixes: beed983621fb ("ASoC: Intel: avs: Machine board registration") Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> --- sound/soc/intel/avs/board_selection.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) base-commit: beed983621fbdfd291e6e3a0cdc4d10517e60af8