Message ID | 20191015155044.11858-1-ben.dooks@codethink.co.uk (mailing list archive) |
---|---|
State | Mainlined |
Commit | 2457b2c1b44eeb022308bd524b34fa9b3ac3da11 |
Headers | show |
Series | usb: renesas_usbhs: fix __le16 warnings | expand |
On Tue, Oct 15, 2019 at 5:50 PM Ben Dooks (Codethink) <ben.dooks@codethink.co.uk> wrote: > Fix the warnings generated by casting to/from __le16 without > using the correct functions. > > Fixes the following sparse warnings: > > drivers/usb/renesas_usbhs/common.c:165:25: warning: incorrect type in assignment (different base types) > drivers/usb/renesas_usbhs/common.c:165:25: expected restricted __le16 [usertype] wValue > drivers/usb/renesas_usbhs/common.c:165:25: got unsigned short > drivers/usb/renesas_usbhs/common.c:166:25: warning: incorrect type in assignment (different base types) > drivers/usb/renesas_usbhs/common.c:166:25: expected restricted __le16 [usertype] wIndex > drivers/usb/renesas_usbhs/common.c:166:25: got unsigned short > drivers/usb/renesas_usbhs/common.c:167:25: warning: incorrect type in assignment (different base types) > drivers/usb/renesas_usbhs/common.c:167:25: expected restricted __le16 [usertype] wLength > drivers/usb/renesas_usbhs/common.c:167:25: got unsigned short > drivers/usb/renesas_usbhs/common.c:173:39: warning: incorrect type in argument 3 (different base types) > drivers/usb/renesas_usbhs/common.c:173:39: expected unsigned short [usertype] data > drivers/usb/renesas_usbhs/common.c:173:39: got restricted __le16 [usertype] wValue > drivers/usb/renesas_usbhs/common.c:174:39: warning: incorrect type in argument 3 (different base types) > drivers/usb/renesas_usbhs/common.c:174:39: expected unsigned short [usertype] data > drivers/usb/renesas_usbhs/common.c:174:39: got restricted __le16 [usertype] wIndex > drivers/usb/renesas_usbhs/common.c:175:39: warning: incorrect type in argument 3 (different base types) > drivers/usb/renesas_usbhs/common.c:175:39: expected unsigned short [usertype] data > > Note. I belive this to be correct, and should be a no-op on arm. Yep, the affected platforms are little-endian. > Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Gr{oetje,eeting}s, Geert
Hi Ben, > From: Ben Dooks (Codethink), Sent: Wednesday, October 16, 2019 12:51 AM > > Fix the warnings generated by casting to/from __le16 without > using the correct functions. > > Fixes the following sparse warnings: > > drivers/usb/renesas_usbhs/common.c:165:25: warning: incorrect type in assignment (different base types) > drivers/usb/renesas_usbhs/common.c:165:25: expected restricted __le16 [usertype] wValue > drivers/usb/renesas_usbhs/common.c:165:25: got unsigned short > drivers/usb/renesas_usbhs/common.c:166:25: warning: incorrect type in assignment (different base types) > drivers/usb/renesas_usbhs/common.c:166:25: expected restricted __le16 [usertype] wIndex > drivers/usb/renesas_usbhs/common.c:166:25: got unsigned short > drivers/usb/renesas_usbhs/common.c:167:25: warning: incorrect type in assignment (different base types) > drivers/usb/renesas_usbhs/common.c:167:25: expected restricted __le16 [usertype] wLength > drivers/usb/renesas_usbhs/common.c:167:25: got unsigned short > drivers/usb/renesas_usbhs/common.c:173:39: warning: incorrect type in argument 3 (different base types) > drivers/usb/renesas_usbhs/common.c:173:39: expected unsigned short [usertype] data > drivers/usb/renesas_usbhs/common.c:173:39: got restricted __le16 [usertype] wValue > drivers/usb/renesas_usbhs/common.c:174:39: warning: incorrect type in argument 3 (different base types) > drivers/usb/renesas_usbhs/common.c:174:39: expected unsigned short [usertype] data > drivers/usb/renesas_usbhs/common.c:174:39: got restricted __le16 [usertype] wIndex > drivers/usb/renesas_usbhs/common.c:175:39: warning: incorrect type in argument 3 (different base types) > drivers/usb/renesas_usbhs/common.c:175:39: expected unsigned short [usertype] data > > Note. I belive this to be correct, and should be a no-op on arm. > > Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Thank you for the patch! Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Best regards, Yoshihiro Shimoda
On Tue, Oct 15, 2019 at 04:50:44PM +0100, Ben Dooks (Codethink) wrote: > Fix the warnings generated by casting to/from __le16 without > using the correct functions. > > Fixes the following sparse warnings: > > drivers/usb/renesas_usbhs/common.c:165:25: warning: incorrect type in assignment (different base types) > drivers/usb/renesas_usbhs/common.c:165:25: expected restricted __le16 [usertype] wValue > drivers/usb/renesas_usbhs/common.c:165:25: got unsigned short > drivers/usb/renesas_usbhs/common.c:166:25: warning: incorrect type in assignment (different base types) > drivers/usb/renesas_usbhs/common.c:166:25: expected restricted __le16 [usertype] wIndex > drivers/usb/renesas_usbhs/common.c:166:25: got unsigned short > drivers/usb/renesas_usbhs/common.c:167:25: warning: incorrect type in assignment (different base types) > drivers/usb/renesas_usbhs/common.c:167:25: expected restricted __le16 [usertype] wLength > drivers/usb/renesas_usbhs/common.c:167:25: got unsigned short > drivers/usb/renesas_usbhs/common.c:173:39: warning: incorrect type in argument 3 (different base types) > drivers/usb/renesas_usbhs/common.c:173:39: expected unsigned short [usertype] data > drivers/usb/renesas_usbhs/common.c:173:39: got restricted __le16 [usertype] wValue > drivers/usb/renesas_usbhs/common.c:174:39: warning: incorrect type in argument 3 (different base types) > drivers/usb/renesas_usbhs/common.c:174:39: expected unsigned short [usertype] data > drivers/usb/renesas_usbhs/common.c:174:39: got restricted __le16 [usertype] wIndex > drivers/usb/renesas_usbhs/common.c:175:39: warning: incorrect type in argument 3 (different base types) > drivers/usb/renesas_usbhs/common.c:175:39: expected unsigned short [usertype] data > > Note. I belive this to be correct, and should be a no-op on arm. > > Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> > --- > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> > Cc: Simon Horman <horms+renesas@verge.net.au> > Cc: Geert Uytterhoeven <geert+renesas@glider.be> > Cc: linux-usb@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > --- > drivers/usb/renesas_usbhs/common.c | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/usb/renesas_usbhs/common.c b/drivers/usb/renesas_usbhs/common.c > index 4c3de777ef6c..a3c30b609433 100644 > --- a/drivers/usb/renesas_usbhs/common.c > +++ b/drivers/usb/renesas_usbhs/common.c > @@ -162,17 +162,17 @@ void usbhs_usbreq_get_val(struct usbhs_priv *priv, struct usb_ctrlrequest *req) > req->bRequest = (val >> 8) & 0xFF; > req->bRequestType = (val >> 0) & 0xFF; > > - req->wValue = usbhs_read(priv, USBVAL); > - req->wIndex = usbhs_read(priv, USBINDX); > - req->wLength = usbhs_read(priv, USBLENG); > + req->wValue = cpu_to_le16(usbhs_read(priv, USBVAL)); > + req->wIndex = cpu_to_le16(usbhs_read(priv, USBINDX)); > + req->wLength = cpu_to_le16(usbhs_read(priv, USBLENG)); usbhs_read is backed by readl which performs a le->cpu conversion. Rather than have a double conversion perhaps it would be nicer to introduce usbhs_read_le. Likewise for write. > } > > void usbhs_usbreq_set_val(struct usbhs_priv *priv, struct usb_ctrlrequest *req) > { > usbhs_write(priv, USBREQ, (req->bRequest << 8) | req->bRequestType); > - usbhs_write(priv, USBVAL, req->wValue); > - usbhs_write(priv, USBINDX, req->wIndex); > - usbhs_write(priv, USBLENG, req->wLength); > + usbhs_write(priv, USBVAL, le16_to_cpu(req->wValue)); > + usbhs_write(priv, USBINDX, le16_to_cpu(req->wIndex)); > + usbhs_write(priv, USBLENG, le16_to_cpu(req->wLength)); > > usbhs_bset(priv, DCPCTR, SUREQ, SUREQ); > } > -- > 2.23.0 >
Hi Simon-san, > From: Simon Horman, Sent: Wednesday, October 16, 2019 9:27 PM <snip> > > diff --git a/drivers/usb/renesas_usbhs/common.c b/drivers/usb/renesas_usbhs/common.c > > index 4c3de777ef6c..a3c30b609433 100644 > > --- a/drivers/usb/renesas_usbhs/common.c > > +++ b/drivers/usb/renesas_usbhs/common.c > > @@ -162,17 +162,17 @@ void usbhs_usbreq_get_val(struct usbhs_priv *priv, struct usb_ctrlrequest *req) > > req->bRequest = (val >> 8) & 0xFF; > > req->bRequestType = (val >> 0) & 0xFF; > > > > - req->wValue = usbhs_read(priv, USBVAL); > > - req->wIndex = usbhs_read(priv, USBINDX); > > - req->wLength = usbhs_read(priv, USBLENG); > > + req->wValue = cpu_to_le16(usbhs_read(priv, USBVAL)); > > + req->wIndex = cpu_to_le16(usbhs_read(priv, USBINDX)); > > + req->wLength = cpu_to_le16(usbhs_read(priv, USBLENG)); > > usbhs_read is backed by readl which performs > a le->cpu conversion. Rather than have a double conversion > perhaps it would be nicer to introduce usbhs_read_le. > Likewise for write. I'm afraid but, I could not understand these comments. At the moment, the usbhs_{read,write}() call io{read,write}16(), not {read,write}l(). https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/renesas_usbhs/common.c?h=v5.4-rc3#n62 Best regards, Yoshihiro Shimoda > > > } > > > > void usbhs_usbreq_set_val(struct usbhs_priv *priv, struct usb_ctrlrequest *req) > > { > > usbhs_write(priv, USBREQ, (req->bRequest << 8) | req->bRequestType); > > - usbhs_write(priv, USBVAL, req->wValue); > > - usbhs_write(priv, USBINDX, req->wIndex); > > - usbhs_write(priv, USBLENG, req->wLength); > > + usbhs_write(priv, USBVAL, le16_to_cpu(req->wValue)); > > + usbhs_write(priv, USBINDX, le16_to_cpu(req->wIndex)); > > + usbhs_write(priv, USBLENG, le16_to_cpu(req->wLength)); > > > > usbhs_bset(priv, DCPCTR, SUREQ, SUREQ); > > } > > -- > > 2.23.0 > >
Hi Shimoda-san, Simon, On Thu, Oct 17, 2019 at 4:18 AM Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> wrote: > > From: Simon Horman, Sent: Wednesday, October 16, 2019 9:27 PM > <snip> > > > diff --git a/drivers/usb/renesas_usbhs/common.c b/drivers/usb/renesas_usbhs/common.c > > > index 4c3de777ef6c..a3c30b609433 100644 > > > --- a/drivers/usb/renesas_usbhs/common.c > > > +++ b/drivers/usb/renesas_usbhs/common.c > > > @@ -162,17 +162,17 @@ void usbhs_usbreq_get_val(struct usbhs_priv *priv, struct usb_ctrlrequest *req) > > > req->bRequest = (val >> 8) & 0xFF; > > > req->bRequestType = (val >> 0) & 0xFF; > > > > > > - req->wValue = usbhs_read(priv, USBVAL); > > > - req->wIndex = usbhs_read(priv, USBINDX); > > > - req->wLength = usbhs_read(priv, USBLENG); > > > + req->wValue = cpu_to_le16(usbhs_read(priv, USBVAL)); > > > + req->wIndex = cpu_to_le16(usbhs_read(priv, USBINDX)); > > > + req->wLength = cpu_to_le16(usbhs_read(priv, USBLENG)); > > > > usbhs_read is backed by readl which performs > > a le->cpu conversion. Rather than have a double conversion > > perhaps it would be nicer to introduce usbhs_read_le. > > Likewise for write. > > I'm afraid but, I could not understand these comments. > At the moment, the usbhs_{read,write}() call io{read,write}16(), > not {read,write}l(). > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/renesas_usbhs/common.c?h=v5.4-rc3#n62 ioread16() and readw() don't do byteswapping on ARM, as ARM is little-endian. Likewise, cpu_to_le16() is a no-op on ARM. Double swapping would matter only on a big-endian platform, and could indeed be avoided by introducing usbhs_read_le*() functions that are just wrappers around __raw_read16() on big-endian. However, until the Renesas USBHS IP core ends up on a big-endian platform, it's not worth doing that, IMHO. > > > } > > > > > > void usbhs_usbreq_set_val(struct usbhs_priv *priv, struct usb_ctrlrequest *req) > > > { > > > usbhs_write(priv, USBREQ, (req->bRequest << 8) | req->bRequestType); > > > - usbhs_write(priv, USBVAL, req->wValue); > > > - usbhs_write(priv, USBINDX, req->wIndex); > > > - usbhs_write(priv, USBLENG, req->wLength); > > > + usbhs_write(priv, USBVAL, le16_to_cpu(req->wValue)); > > > + usbhs_write(priv, USBINDX, le16_to_cpu(req->wIndex)); > > > + usbhs_write(priv, USBLENG, le16_to_cpu(req->wLength)); > > > > > > usbhs_bset(priv, DCPCTR, SUREQ, SUREQ); > > > } Gr{oetje,eeting}s, Geert
On Thu, Oct 17, 2019 at 08:57:26AM +0200, Geert Uytterhoeven wrote: > Hi Shimoda-san, Simon, > > On Thu, Oct 17, 2019 at 4:18 AM Yoshihiro Shimoda > <yoshihiro.shimoda.uh@renesas.com> wrote: > > > From: Simon Horman, Sent: Wednesday, October 16, 2019 9:27 PM > > <snip> > > > > diff --git a/drivers/usb/renesas_usbhs/common.c b/drivers/usb/renesas_usbhs/common.c > > > > index 4c3de777ef6c..a3c30b609433 100644 > > > > --- a/drivers/usb/renesas_usbhs/common.c > > > > +++ b/drivers/usb/renesas_usbhs/common.c > > > > @@ -162,17 +162,17 @@ void usbhs_usbreq_get_val(struct usbhs_priv *priv, struct usb_ctrlrequest *req) > > > > req->bRequest = (val >> 8) & 0xFF; > > > > req->bRequestType = (val >> 0) & 0xFF; > > > > > > > > - req->wValue = usbhs_read(priv, USBVAL); > > > > - req->wIndex = usbhs_read(priv, USBINDX); > > > > - req->wLength = usbhs_read(priv, USBLENG); > > > > + req->wValue = cpu_to_le16(usbhs_read(priv, USBVAL)); > > > > + req->wIndex = cpu_to_le16(usbhs_read(priv, USBINDX)); > > > > + req->wLength = cpu_to_le16(usbhs_read(priv, USBLENG)); > > > > > > usbhs_read is backed by readl which performs > > > a le->cpu conversion. Rather than have a double conversion > > > perhaps it would be nicer to introduce usbhs_read_le. > > > Likewise for write. > > > > I'm afraid but, I could not understand these comments. > > At the moment, the usbhs_{read,write}() call io{read,write}16(), > > not {read,write}l(). > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/renesas_usbhs/common.c?h=v5.4-rc3#n62 > > ioread16() and readw() don't do byteswapping on ARM, as ARM is > little-endian. Likewise, cpu_to_le16() is a no-op on ARM. > > Double swapping would matter only on a big-endian platform, and could > indeed be avoided by introducing usbhs_read_le*() functions that are > just wrappers around __raw_read16() on big-endian. > However, until the Renesas USBHS IP core ends up on a big-endian > platform, it's not worth doing that, IMHO. Yes, that is all true. I'm fine with this patch as it is. > > > > > } > > > > > > > > void usbhs_usbreq_set_val(struct usbhs_priv *priv, struct usb_ctrlrequest *req) > > > > { > > > > usbhs_write(priv, USBREQ, (req->bRequest << 8) | req->bRequestType); > > > > - usbhs_write(priv, USBVAL, req->wValue); > > > > - usbhs_write(priv, USBINDX, req->wIndex); > > > > - usbhs_write(priv, USBLENG, req->wLength); > > > > + usbhs_write(priv, USBVAL, le16_to_cpu(req->wValue)); > > > > + usbhs_write(priv, USBINDX, le16_to_cpu(req->wIndex)); > > > > + usbhs_write(priv, USBLENG, le16_to_cpu(req->wLength)); > > > > > > > > usbhs_bset(priv, DCPCTR, SUREQ, SUREQ); > > > > } > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds >
diff --git a/drivers/usb/renesas_usbhs/common.c b/drivers/usb/renesas_usbhs/common.c index 4c3de777ef6c..a3c30b609433 100644 --- a/drivers/usb/renesas_usbhs/common.c +++ b/drivers/usb/renesas_usbhs/common.c @@ -162,17 +162,17 @@ void usbhs_usbreq_get_val(struct usbhs_priv *priv, struct usb_ctrlrequest *req) req->bRequest = (val >> 8) & 0xFF; req->bRequestType = (val >> 0) & 0xFF; - req->wValue = usbhs_read(priv, USBVAL); - req->wIndex = usbhs_read(priv, USBINDX); - req->wLength = usbhs_read(priv, USBLENG); + req->wValue = cpu_to_le16(usbhs_read(priv, USBVAL)); + req->wIndex = cpu_to_le16(usbhs_read(priv, USBINDX)); + req->wLength = cpu_to_le16(usbhs_read(priv, USBLENG)); } void usbhs_usbreq_set_val(struct usbhs_priv *priv, struct usb_ctrlrequest *req) { usbhs_write(priv, USBREQ, (req->bRequest << 8) | req->bRequestType); - usbhs_write(priv, USBVAL, req->wValue); - usbhs_write(priv, USBINDX, req->wIndex); - usbhs_write(priv, USBLENG, req->wLength); + usbhs_write(priv, USBVAL, le16_to_cpu(req->wValue)); + usbhs_write(priv, USBINDX, le16_to_cpu(req->wIndex)); + usbhs_write(priv, USBLENG, le16_to_cpu(req->wLength)); usbhs_bset(priv, DCPCTR, SUREQ, SUREQ); }
Fix the warnings generated by casting to/from __le16 without using the correct functions. Fixes the following sparse warnings: drivers/usb/renesas_usbhs/common.c:165:25: warning: incorrect type in assignment (different base types) drivers/usb/renesas_usbhs/common.c:165:25: expected restricted __le16 [usertype] wValue drivers/usb/renesas_usbhs/common.c:165:25: got unsigned short drivers/usb/renesas_usbhs/common.c:166:25: warning: incorrect type in assignment (different base types) drivers/usb/renesas_usbhs/common.c:166:25: expected restricted __le16 [usertype] wIndex drivers/usb/renesas_usbhs/common.c:166:25: got unsigned short drivers/usb/renesas_usbhs/common.c:167:25: warning: incorrect type in assignment (different base types) drivers/usb/renesas_usbhs/common.c:167:25: expected restricted __le16 [usertype] wLength drivers/usb/renesas_usbhs/common.c:167:25: got unsigned short drivers/usb/renesas_usbhs/common.c:173:39: warning: incorrect type in argument 3 (different base types) drivers/usb/renesas_usbhs/common.c:173:39: expected unsigned short [usertype] data drivers/usb/renesas_usbhs/common.c:173:39: got restricted __le16 [usertype] wValue drivers/usb/renesas_usbhs/common.c:174:39: warning: incorrect type in argument 3 (different base types) drivers/usb/renesas_usbhs/common.c:174:39: expected unsigned short [usertype] data drivers/usb/renesas_usbhs/common.c:174:39: got restricted __le16 [usertype] wIndex drivers/usb/renesas_usbhs/common.c:175:39: warning: incorrect type in argument 3 (different base types) drivers/usb/renesas_usbhs/common.c:175:39: expected unsigned short [usertype] data Note. I belive this to be correct, and should be a no-op on arm. Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> --- Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Cc: Simon Horman <horms+renesas@verge.net.au> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: linux-usb@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- drivers/usb/renesas_usbhs/common.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)