[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM4PR11MB59959F1AE3E9BDA36642000B93F22@DM4PR11MB5995.namprd11.prod.outlook.com>
Date: Wed, 29 May 2024 07:05:28 +0000
From: "Zhang, Lixu" <lixu.zhang@...el.com>
To: Arnd Bergmann <arnd@...nel.org>, Srinivas Pandruvada
<srinivas.pandruvada@...ux.intel.com>, Jiri Kosina <jikos@...nel.org>,
Benjamin Tissoires <bentiss@...nel.org>
CC: Arnd Bergmann <arnd@...db.de>, "linux-input@...r.kernel.org"
<linux-input@...r.kernel.org>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 2/2] HID: intel-ish-hid: fix endian-conversion
>-----Original Message-----
>From: Arnd Bergmann <arnd@...nel.org>
>Sent: Tuesday, May 28, 2024 7:58 PM
>To: Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>; Jiri Kosina
><jikos@...nel.org>; Benjamin Tissoires <bentiss@...nel.org>; Zhang, Lixu
><lixu.zhang@...el.com>
>Cc: Arnd Bergmann <arnd@...db.de>; linux-input@...r.kernel.org; linux-
>kernel@...r.kernel.org
>Subject: [PATCH 2/2] HID: intel-ish-hid: fix endian-conversion
>
>From: Arnd Bergmann <arnd@...db.de>
>
>The newly added file causes a ton of sparse warnings about the incorrect use of
>__le32 and similar types:
>
>drivers/hid/intel-ish-hid/ishtp/loader.c:179:17: warning: cast from restricted
>__le32
>drivers/hid/intel-ish-hid/ishtp/loader.c:182:50: warning: incorrect type in
>assignment (different base types)
>drivers/hid/intel-ish-hid/ishtp/loader.c:182:50: expected restricted __le32
>[usertype] length
>drivers/hid/intel-ish-hid/ishtp/loader.c:182:50: got restricted __le16
>[usertype]
>drivers/hid/intel-ish-hid/ishtp/loader.c:183:50: warning: incorrect type in
>assignment (different base types)
>drivers/hid/intel-ish-hid/ishtp/loader.c:183:50: expected restricted __le32
>[usertype] fw_off
>drivers/hid/intel-ish-hid/ishtp/loader.c:183:50: got restricted __le16
>[usertype]
>
>Add the necessary conversions and use temporary variables where appropriate
>to avoid converting back.
>
>Fixes: 579a267e4617 ("HID: intel-ish-hid: Implement loading firmware from
>host feature")
>Signed-off-by: Arnd Bergmann <arnd@...db.de>
>---
>I noticed this one while looking at the bug that was fixed in
>236049723826 ("HID: intel-ish-hid: Fix build error for COMPILE_TEST")
>---
> drivers/hid/intel-ish-hid/ishtp/loader.c | 69 +++++++++++++-----------
>drivers/hid/intel-ish-hid/ishtp/loader.h | 33 +++++++-----
> 2 files changed, 58 insertions(+), 44 deletions(-)
>
>diff --git a/drivers/hid/intel-ish-hid/ishtp/loader.c b/drivers/hid/intel-ish-
>hid/ishtp/loader.c
>index 062d1b25eaa7..1d4cb99d2130 100644
>--- a/drivers/hid/intel-ish-hid/ishtp/loader.c
>+++ b/drivers/hid/intel-ish-hid/ishtp/loader.c
..
>@@ -162,25 +165,30 @@ static void release_dma_bufs(struct ishtp_device
>*dev, static int prepare_dma_bufs(struct ishtp_device *dev,
> const struct firmware *ish_fw,
> struct loader_xfer_dma_fragment *fragment,
>- void **dma_bufs, u32 fragment_size)
>+ void **dma_bufs, u32 fragment_size, u32
>fragment_count)
See below.
> {
> dma_addr_t dma_addr;
> u32 offset = 0;
>+ u32 length;
> int i;
>
> for (i = 0; i < fragment->fragment_cnt && offset < ish_fw->size; i++) {
You added a parameter fragment_count, but you didn't use it. Did you intend to use it here?
Thanks,
Lixu
> dma_bufs[i] = dma_alloc_coherent(dev->devc, fragment_size,
>&dma_addr, GFP_KERNEL);
>+ dma_bufs[i] = dma_alloc_coherent(dev->devc, fragment_size,
>+ &dma, GFP_KERNEL);
> if (!dma_bufs[i])
> return -ENOMEM;
Powered by blists - more mailing lists