From: Johan Hovold <johan@kernel.org> To: Lee Jones <lee.jones@linaro.org> Cc: Johan Hovold <johan@kernel.org>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Johan Hovold <jhovold@gmail.com> Subject: Re: [PATCH 2/5] mfd: lm3533-ctrlbank: Cap BRIGHTNESS_MAX to 127 since API uses u8 as carrier Date: Tue, 30 Jun 2020 10:38:10 +0200 [thread overview] Message-ID: <20200630083810.GY3334@localhost> (raw) In-Reply-To: <20200629132506.GJ177734@dell> On Mon, Jun 29, 2020 at 02:25:06PM +0100, Lee Jones wrote: > On Mon, 29 Jun 2020, Johan Hovold wrote: > > > On Mon, Jun 29, 2020 at 01:32:12PM +0100, Lee Jones wrote: > > > Since its conception in 2012 brightness has been artificially capped > > > at 127 since the variable carrying the value is u8. We could go to > > > the trouble of changing the whole API (crossing 3 different subsystems), > > > but clearly this hasn't bothered anyone in the best part of a decade. > > > > > > Simply, cap BRIGHTNESS_MAX to 127 instead (for now at least). > > > > Hmm. This patch is clearly broken and would contrary to the claim be > > introducing an artificial cap at half brightness. u8 can hold the max > > brightness value 255 just fine. > > Yes, of course it can. Senior moment on my account. > > > > Fixes the following W=1 warning(s): > > > > > > drivers/mfd/lm3533-ctrlbank.c: In function ‘lm3533_ctrlbank_set_brightness’: > > > drivers/mfd/lm3533-ctrlbank.c:98:10: warning: comparison is always false due to limited range of data type [-Wtype-limits] > > > 98 | if (val > LM3533_##_NAME##_MAX) | ^ > > > drivers/mfd/lm3533-ctrlbank.c:125:1: note: in expansion of macro ‘lm3533_ctrlbank_set’ > > > 125 | lm3533_ctrlbank_set(brightness, BRIGHTNESS); > > > | ^~~~~~~~~~~~~~~~~~~ > > > > This warning is benign. The same macro is used to defined two function > > where in one case the max value coincides with U8_MAX so that the sanity > > check becomes redundant. > > A benign warning, as most W=1 warnings are, is still a warning. Not every warning needs to be addressed, there's a reason some of these are hidden behind W=1 or higher. > So how do you propose we fix it? > > Is 255 a valid and used brightness level? Yes. > If so, how do you feel about: > > /* Avoid 'always false' check '(u8) > 255' */ > if (LM3533_##_NAME##_MAX != 0xff && val > LM3533_##_NAME##_MAX) > return -EINVAL; I'm afraid that's not sufficient to shut the compiler up. I'll send you patch expanding these accessors instead. Having exported functions implemented by macros is particularly nice (hard to grep for etc). There are a couple of more sets of control-bank registers that could potentially have shared the implementation and which motivated the use of macros, but it does not seem very likely that we'll be adding those anytime soon anyway. Johan
WARNING: multiple messages have this Message-ID (diff)
From: Johan Hovold <johan@kernel.org> To: Lee Jones <lee.jones@linaro.org> Cc: Johan Hovold <jhovold@gmail.com>, Johan Hovold <johan@kernel.org>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/5] mfd: lm3533-ctrlbank: Cap BRIGHTNESS_MAX to 127 since API uses u8 as carrier Date: Tue, 30 Jun 2020 10:38:10 +0200 [thread overview] Message-ID: <20200630083810.GY3334@localhost> (raw) In-Reply-To: <20200629132506.GJ177734@dell> On Mon, Jun 29, 2020 at 02:25:06PM +0100, Lee Jones wrote: > On Mon, 29 Jun 2020, Johan Hovold wrote: > > > On Mon, Jun 29, 2020 at 01:32:12PM +0100, Lee Jones wrote: > > > Since its conception in 2012 brightness has been artificially capped > > > at 127 since the variable carrying the value is u8. We could go to > > > the trouble of changing the whole API (crossing 3 different subsystems), > > > but clearly this hasn't bothered anyone in the best part of a decade. > > > > > > Simply, cap BRIGHTNESS_MAX to 127 instead (for now at least). > > > > Hmm. This patch is clearly broken and would contrary to the claim be > > introducing an artificial cap at half brightness. u8 can hold the max > > brightness value 255 just fine. > > Yes, of course it can. Senior moment on my account. > > > > Fixes the following W=1 warning(s): > > > > > > drivers/mfd/lm3533-ctrlbank.c: In function ‘lm3533_ctrlbank_set_brightness’: > > > drivers/mfd/lm3533-ctrlbank.c:98:10: warning: comparison is always false due to limited range of data type [-Wtype-limits] > > > 98 | if (val > LM3533_##_NAME##_MAX) | ^ > > > drivers/mfd/lm3533-ctrlbank.c:125:1: note: in expansion of macro ‘lm3533_ctrlbank_set’ > > > 125 | lm3533_ctrlbank_set(brightness, BRIGHTNESS); > > > | ^~~~~~~~~~~~~~~~~~~ > > > > This warning is benign. The same macro is used to defined two function > > where in one case the max value coincides with U8_MAX so that the sanity > > check becomes redundant. > > A benign warning, as most W=1 warnings are, is still a warning. Not every warning needs to be addressed, there's a reason some of these are hidden behind W=1 or higher. > So how do you propose we fix it? > > Is 255 a valid and used brightness level? Yes. > If so, how do you feel about: > > /* Avoid 'always false' check '(u8) > 255' */ > if (LM3533_##_NAME##_MAX != 0xff && val > LM3533_##_NAME##_MAX) > return -EINVAL; I'm afraid that's not sufficient to shut the compiler up. I'll send you patch expanding these accessors instead. Having exported functions implemented by macros is particularly nice (hard to grep for etc). There are a couple of more sets of control-bank registers that could potentially have shared the implementation and which motivated the use of macros, but it does not seem very likely that we'll be adding those anytime soon anyway. Johan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-06-30 8:38 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-29 12:32 [PATCH 0/5] Last batch of W=1 warning fixes in MFD Lee Jones 2020-06-29 12:32 ` Lee Jones 2020-06-29 12:32 ` [PATCH 1/5] mfd: si476x-cmd: Add missing documentation for si476x_cmd_fm_rds_status()'s arg 'report' Lee Jones 2020-06-29 12:32 ` Lee Jones 2020-06-29 12:32 ` [PATCH 2/5] mfd: lm3533-ctrlbank: Cap BRIGHTNESS_MAX to 127 since API uses u8 as carrier Lee Jones 2020-06-29 12:32 ` Lee Jones 2020-06-29 12:51 ` Johan Hovold 2020-06-29 12:51 ` Johan Hovold 2020-06-29 13:25 ` Lee Jones 2020-06-29 13:25 ` Lee Jones 2020-06-30 8:38 ` Johan Hovold [this message] 2020-06-30 8:38 ` Johan Hovold 2020-06-29 12:32 ` [PATCH 3/5] mfd: rave-sp: Fix mistake in 'struct rave_sp_deframer's kerneldoc Lee Jones 2020-06-29 12:32 ` Lee Jones 2020-06-29 12:32 ` [PATCH 4/5] mfd: sprd-sc27xx-spi: Fix divide by zero when allocating register offset/mask Lee Jones 2020-06-29 12:32 ` Lee Jones 2020-06-29 13:06 ` Johan Hovold 2020-06-29 13:06 ` Johan Hovold 2020-06-29 14:01 ` Lee Jones 2020-06-29 14:01 ` Lee Jones 2020-06-29 14:35 ` Baolin Wang 2020-06-29 14:35 ` Baolin Wang 2020-06-29 14:43 ` Johan Hovold 2020-06-29 14:43 ` Johan Hovold 2020-06-29 15:08 ` Baolin Wang 2020-06-29 15:08 ` Baolin Wang 2020-06-29 15:45 ` Lee Jones 2020-06-29 15:45 ` Lee Jones 2020-07-01 9:15 ` [PATCH] mfd: sprd-sc27xx-spi: Fix-up bogus IRQ register offset and mask setting Lee Jones 2020-07-01 9:15 ` Lee Jones 2020-07-01 14:10 ` Baolin Wang 2020-07-01 14:10 ` Baolin Wang 2020-06-29 12:32 ` [PATCH 5/5] mfd: axp20x-i2c: Do not define 'struct acpi_device_id' when !CONFIG_ACPI Lee Jones 2020-06-29 12:32 ` Lee Jones 2020-06-29 15:38 ` Chen-Yu Tsai 2020-06-29 15:38 ` Chen-Yu Tsai 2020-07-06 7:31 ` Lee Jones 2020-07-06 7:31 ` Lee Jones 2020-07-01 6:59 ` [PATCH v2] mfd: axp20x-i2c: Tell the compiler that ACPI functions may not be used Lee Jones 2020-07-01 6:59 ` Lee Jones 2020-07-01 8:38 ` Chen-Yu Tsai 2020-07-01 8:38 ` Chen-Yu Tsai
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200630083810.GY3334@localhost \ --to=johan@kernel.org \ --cc=jhovold@gmail.com \ --cc=lee.jones@linaro.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.