| Message ID | 20220207104830.83882-1-andriy.shevchenko@linux.intel.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2,1/3] iio: temperature: ltc2983: Don't hard code defined constants in messages | expand |
On Mon, 2022-02-07 at 12:48 +0200, Andy Shevchenko wrote: > In a couple of messages the constants, which have their definitions, > are hard coded into the message text. Unhardcode them. Found by inspection or tool? > diff --git a/drivers/iio/temperature/ltc2983.c b/drivers/iio/temperature/ltc2983.c [] > @@ -409,8 +409,8 @@ static struct ltc2983_custom_sensor *__ltc2983_custom_sensor_new( > new_custom->size = n_entries * n_size; > /* check Steinhart size */ > if (is_steinhart && new_custom->size != LTC2983_CUSTOM_STEINHART_SIZE) { > - dev_err(dev, "Steinhart sensors size(%zu) must be 24", > - new_custom->size); > + dev_err(dev, "Steinhart sensors size(%zu) must be %d", new_custom->size, > + LTC2983_CUSTOM_STEINHART_SIZE); probably better using "%u" and not "%d" and better with a \n termination too. > return ERR_PTR(-EINVAL); > } > /* Check space on the table. */ > @@ -1299,8 +1299,8 @@ static int ltc2983_parse_dt(struct ltc2983_data *st) > if (sensor.chan < LTC2983_MIN_CHANNELS_NR || > sensor.chan > LTC2983_MAX_CHANNELS_NR) { > ret = -EINVAL; > - dev_err(dev, > - "chan:%d must be from 1 to 20\n", sensor.chan); > + dev_err(dev, "chan:%d must be from %d to %d\n", sensor.chan, > + LTC2983_MIN_CHANNELS_NR, LTC2983_MAX_CHANNELS_NR); > goto put_child; > } else if (channel_avail_mask & BIT(sensor.chan)) { > ret = -EINVAL;
On Mon, Feb 07, 2022 at 08:37:55AM -0800, Joe Perches wrote: > On Mon, 2022-02-07 at 12:48 +0200, Andy Shevchenko wrote: > > In a couple of messages the constants, which have their definitions, > > are hard coded into the message text. Unhardcode them. > > Found by inspection or tool? Does it matter? No, a side effect of the following patch. ... > > + dev_err(dev, "Steinhart sensors size(%zu) must be %d", new_custom->size, > > + LTC2983_CUSTOM_STEINHART_SIZE); > > probably better using "%u" and not "%d" > > and better with a \n termination too. I think it would be a separate change if we wish so. Let Jonathan to tell what to do here.
On Mon, 2022-02-07 at 19:21 +0200, Andy Shevchenko wrote: > On Mon, Feb 07, 2022 at 08:37:55AM -0800, Joe Perches wrote: > > On Mon, 2022-02-07 at 12:48 +0200, Andy Shevchenko wrote: > > > In a couple of messages the constants, which have their definitions, > > > are hard coded into the message text. Unhardcode them. > > > > Found by inspection or tool? > > Does it matter? Yes. If it was done using a tool, then it could used treewide. > No, a side effect of the following patch. k
On Mon, 7 Feb 2022 19:21:25 +0200 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > On Mon, Feb 07, 2022 at 08:37:55AM -0800, Joe Perches wrote: > > On Mon, 2022-02-07 at 12:48 +0200, Andy Shevchenko wrote: > > > In a couple of messages the constants, which have their definitions, > > > are hard coded into the message text. Unhardcode them. > > > > Found by inspection or tool? > > Does it matter? No, a side effect of the following patch. > > ... > > > > + dev_err(dev, "Steinhart sensors size(%zu) must be %d", new_custom->size, > > > + LTC2983_CUSTOM_STEINHART_SIZE); > > > > probably better using "%u" and not "%d" > > > > and better with a \n termination too. > > I think it would be a separate change if we wish so. Let Jonathan to tell what > to do here. > Either way is fine by me. I tend to be a little flexible of trivial fixes in patches that are as simple as this one. Thanks, Jonathan
On Mon, Feb 07, 2022 at 08:44:21PM +0000, Jonathan Cameron wrote: > On Mon, 7 Feb 2022 19:21:25 +0200 > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > > On Mon, Feb 07, 2022 at 08:37:55AM -0800, Joe Perches wrote: > > > On Mon, 2022-02-07 at 12:48 +0200, Andy Shevchenko wrote: > > > > In a couple of messages the constants, which have their definitions, > > > > are hard coded into the message text. Unhardcode them. > > > > > > Found by inspection or tool? > > > > Does it matter? No, a side effect of the following patch. > > > > ... > > > > > > + dev_err(dev, "Steinhart sensors size(%zu) must be %d", new_custom->size, > > > > + LTC2983_CUSTOM_STEINHART_SIZE); > > > > > > probably better using "%u" and not "%d" > > > > > > and better with a \n termination too. > > > > I think it would be a separate change if we wish so. Let Jonathan to tell what > > to do here. > > > Either way is fine by me. I tend to be a little flexible of trivial fixes > in patches that are as simple as this one. v3 has been just sent.
diff --git a/drivers/iio/temperature/ltc2983.c b/drivers/iio/temperature/ltc2983.c index 301c3f13fb26..d272c303c1b0 100644 --- a/drivers/iio/temperature/ltc2983.c +++ b/drivers/iio/temperature/ltc2983.c @@ -409,8 +409,8 @@ static struct ltc2983_custom_sensor *__ltc2983_custom_sensor_new( new_custom->size = n_entries * n_size; /* check Steinhart size */ if (is_steinhart && new_custom->size != LTC2983_CUSTOM_STEINHART_SIZE) { - dev_err(dev, "Steinhart sensors size(%zu) must be 24", - new_custom->size); + dev_err(dev, "Steinhart sensors size(%zu) must be %d", new_custom->size, + LTC2983_CUSTOM_STEINHART_SIZE); return ERR_PTR(-EINVAL); } /* Check space on the table. */ @@ -1299,8 +1299,8 @@ static int ltc2983_parse_dt(struct ltc2983_data *st) if (sensor.chan < LTC2983_MIN_CHANNELS_NR || sensor.chan > LTC2983_MAX_CHANNELS_NR) { ret = -EINVAL; - dev_err(dev, - "chan:%d must be from 1 to 20\n", sensor.chan); + dev_err(dev, "chan:%d must be from %d to %d\n", sensor.chan, + LTC2983_MIN_CHANNELS_NR, LTC2983_MAX_CHANNELS_NR); goto put_child; } else if (channel_avail_mask & BIT(sensor.chan)) { ret = -EINVAL;