| Message ID | 20170518202144.3482304-5-arnd@arndb.de |
|---|---|
| State | Accepted |
| Commit | 318fc2a867bc5bac688cb88f111eb75792675dc2 |
| Headers | show |
| Series | [v2,1/5] HID: intel_ish-hid: fix potential uninitialized data usage | expand |
On Thu, 2017-05-18 at 22:21 +0200, Arnd Bergmann wrote: > When building for 32-bit architectures, we get a harmless warning: > > intel-ish-hid/ishtp-hid-client.c: In function 'process_recv': > intel-ish-hid/ishtp-hid-client.c:139:7: error: format '%lu' expects > argument of type 'long unsigned int', but argument 3 has type > 'unsigned int' [-Werror=format=] > > This changes the format string to print size_t variables using %zu > instead. Is the ordering of patch correct? ISH config depends on X86_64, so it would not be enabled for 32 bit build. So your patch 5/5 will adding "|| COMPILE_TEST", hence it is building. Thanks, Srinivas > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> > --- > drivers/hid/intel-ish-hid/ishtp-hid-client.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/hid/intel-ish-hid/ishtp-hid-client.c > b/drivers/hid/intel-ish-hid/ishtp-hid-client.c > index 5c643d7a07b2..157b44aacdff 100644 > --- a/drivers/hid/intel-ish-hid/ishtp-hid-client.c > +++ b/drivers/hid/intel-ish-hid/ishtp-hid-client.c > @@ -136,10 +136,9 @@ static void process_recv(struct ishtp_cl > *hid_ishtp_cl, void *recv_buf, > if (1 + sizeof(struct device_info) * > i >= > payload_len) { > dev_err(&client_data- > >cl_device->dev, > - "[hid-ish]: > [ENUM_DEVICES]: content size %lu is bigger than payload_len %u\n", > + "[hid-ish]: > [ENUM_DEVICES]: content size %zu is bigger than payload_len %zu\n", > 1 + sizeof(struct > device_info) > - * i, > - (unsigned > int)payload_len); > + * i, payload_len); > } > > if (1 + sizeof(struct device_info) * > i >= -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, May 23, 2017 at 1:46 AM, Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> wrote: > On Thu, 2017-05-18 at 22:21 +0200, Arnd Bergmann wrote: >> When building for 32-bit architectures, we get a harmless warning: >> >> intel-ish-hid/ishtp-hid-client.c: In function 'process_recv': >> intel-ish-hid/ishtp-hid-client.c:139:7: error: format '%lu' expects >> argument of type 'long unsigned int', but argument 3 has type >> 'unsigned int' [-Werror=format=] >> >> This changes the format string to print size_t variables using %zu >> instead. > Is the ordering of patch correct? > ISH config depends on X86_64, so it would not be enabled for 32 bit > build. > So your patch 5/5 will adding "|| COMPILE_TEST", hence it is building. Right, that is intentional. Adding ||COMPILE_TEST first would be a regression by introducing the warning on 32-bit allmodconfig builds. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2017-05-18 at 22:21 +0200, Arnd Bergmann wrote: > When building for 32-bit architectures, we get a harmless warning: > > intel-ish-hid/ishtp-hid-client.c: In function 'process_recv': > intel-ish-hid/ishtp-hid-client.c:139:7: error: format '%lu' expects > argument of type 'long unsigned int', but argument 3 has type > 'unsigned int' [-Werror=format=] > > This changes the format string to print size_t variables using %zu > instead. > > Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> > --- > drivers/hid/intel-ish-hid/ishtp-hid-client.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/hid/intel-ish-hid/ishtp-hid-client.c > b/drivers/hid/intel-ish-hid/ishtp-hid-client.c > index 5c643d7a07b2..157b44aacdff 100644 > --- a/drivers/hid/intel-ish-hid/ishtp-hid-client.c > +++ b/drivers/hid/intel-ish-hid/ishtp-hid-client.c > @@ -136,10 +136,9 @@ static void process_recv(struct ishtp_cl > *hid_ishtp_cl, void *recv_buf, > if (1 + sizeof(struct device_info) * > i >= > payload_len) { > dev_err(&client_data- > >cl_device->dev, > - "[hid-ish]: > [ENUM_DEVICES]: content size %lu is bigger than payload_len %u\n", > + "[hid-ish]: > [ENUM_DEVICES]: content size %zu is bigger than payload_len %zu\n", > 1 + sizeof(struct > device_info) > - * i, > - (unsigned > int)payload_len); > + * i, payload_len); > } > > if (1 + sizeof(struct device_info) * > i >= -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/hid/intel-ish-hid/ishtp-hid-client.c b/drivers/hid/intel-ish-hid/ishtp-hid-client.c index 5c643d7a07b2..157b44aacdff 100644 --- a/drivers/hid/intel-ish-hid/ishtp-hid-client.c +++ b/drivers/hid/intel-ish-hid/ishtp-hid-client.c @@ -136,10 +136,9 @@ static void process_recv(struct ishtp_cl *hid_ishtp_cl, void *recv_buf, if (1 + sizeof(struct device_info) * i >= payload_len) { dev_err(&client_data->cl_device->dev, - "[hid-ish]: [ENUM_DEVICES]: content size %lu is bigger than payload_len %u\n", + "[hid-ish]: [ENUM_DEVICES]: content size %zu is bigger than payload_len %zu\n", 1 + sizeof(struct device_info) - * i, - (unsigned int)payload_len); + * i, payload_len); } if (1 + sizeof(struct device_info) * i >=
When building for 32-bit architectures, we get a harmless warning: intel-ish-hid/ishtp-hid-client.c: In function 'process_recv': intel-ish-hid/ishtp-hid-client.c:139:7: error: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'unsigned int' [-Werror=format=] This changes the format string to print size_t variables using %zu instead. Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- drivers/hid/intel-ish-hid/ishtp-hid-client.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) -- 2.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html