From: Geert Uytterhoeven <geert@linux-m68k.org> To: Jerome Pouiller <Jerome.Pouiller@silabs.com> Cc: driverdevel <devel@driverdev.osuosl.org>, linux-wireless <linux-wireless@vger.kernel.org>, netdev <netdev@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Kalle Valo <kvalo@codeaurora.org>, "David S . Miller" <davem@davemloft.net> Subject: Re: [PATCH 13/17] staging: wfx: fix endianness of the field 'len' Date: Tue, 12 May 2020 09:43:34 +0200 [thread overview] Message-ID: <CAMuHMdVZxy+FZGPhDxotCBeEX3O4ZMkmGAwmVFXQE9ZoijDN5g@mail.gmail.com> (raw) In-Reply-To: <20200511154930.190212-14-Jerome.Pouiller@silabs.com> Hi Jerome, On Mon, May 11, 2020 at 5:53 PM Jerome Pouiller <Jerome.Pouiller@silabs.com> wrote: > From: Jérôme Pouiller <jerome.pouiller@silabs.com> > > The struct hif_msg is received from the hardware. So, it declared as > little endian. However, it is also accessed from many places in the > driver. Sparse complains about that: > > drivers/staging/wfx/bh.c:88:32: warning: restricted __le16 degrades to integer > drivers/staging/wfx/bh.c:88:32: warning: restricted __le16 degrades to integer > drivers/staging/wfx/bh.c:93:32: warning: restricted __le16 degrades to integer > drivers/staging/wfx/bh.c:93:32: warning: cast to restricted __le16 > drivers/staging/wfx/bh.c:93:32: warning: restricted __le16 degrades to integer > drivers/staging/wfx/bh.c:121:25: warning: incorrect type in argument 2 (different base types) > drivers/staging/wfx/bh.c:121:25: expected unsigned int len > drivers/staging/wfx/bh.c:121:25: got restricted __le16 [usertype] len > drivers/staging/wfx/hif_rx.c:27:22: warning: restricted __le16 degrades to integer > drivers/staging/wfx/hif_rx.c:347:39: warning: incorrect type in argument 7 (different base types) > drivers/staging/wfx/hif_rx.c:347:39: expected unsigned int [usertype] len > drivers/staging/wfx/hif_rx.c:347:39: got restricted __le16 const [usertype] len > drivers/staging/wfx/hif_rx.c:365:39: warning: incorrect type in argument 7 (different base types) > drivers/staging/wfx/hif_rx.c:365:39: expected unsigned int [usertype] len > drivers/staging/wfx/hif_rx.c:365:39: got restricted __le16 const [usertype] len > drivers/staging/wfx/./traces.h:195:1: warning: incorrect type in assignment (different base types) > drivers/staging/wfx/./traces.h:195:1: expected int msg_len > drivers/staging/wfx/./traces.h:195:1: got restricted __le16 const [usertype] len > drivers/staging/wfx/./traces.h:195:1: warning: incorrect type in assignment (different base types) > drivers/staging/wfx/./traces.h:195:1: expected int msg_len > drivers/staging/wfx/./traces.h:195:1: got restricted __le16 const [usertype] len > drivers/staging/wfx/debug.c:319:20: warning: restricted __le16 degrades to integer > drivers/staging/wfx/secure_link.c:85:27: warning: restricted __le16 degrades to integer > drivers/staging/wfx/secure_link.c:85:27: warning: restricted __le16 degrades to integer Thanks for your patch! > In order to make Sparse happy and to keep access from the driver easy, > this patch declare 'len' with native endianness. > > On reception of hardware data, this patch takes care to do byte-swap and > keep Sparse happy. Which means sparse can no longer do any checking on the field, and new bugs may/will creep in in the future, unnoticed. > --- a/drivers/staging/wfx/hif_api_general.h > +++ b/drivers/staging/wfx/hif_api_general.h > @@ -23,7 +23,10 @@ > #define HIF_COUNTER_MAX 7 > > struct hif_msg { > - __le16 len; > + // len is in fact little endian. However, it is widely used in the > + // driver, so we declare it in native byte order and we reorder just > + // before/after send/receive it (see bh.c). > + u16 len; While there's a small penalty associated with always doing the conversion on big-endian platforms, it will probably be lost in the noise anyway. 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
WARNING: multiple messages have this Message-ID (diff)
From: Geert Uytterhoeven <geert@linux-m68k.org> To: Jerome Pouiller <Jerome.Pouiller@silabs.com> Cc: driverdevel <devel@driverdev.osuosl.org>, netdev <netdev@vger.kernel.org>, linux-wireless <linux-wireless@vger.kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "David S . Miller" <davem@davemloft.net>, Kalle Valo <kvalo@codeaurora.org> Subject: Re: [PATCH 13/17] staging: wfx: fix endianness of the field 'len' Date: Tue, 12 May 2020 09:43:34 +0200 [thread overview] Message-ID: <CAMuHMdVZxy+FZGPhDxotCBeEX3O4ZMkmGAwmVFXQE9ZoijDN5g@mail.gmail.com> (raw) In-Reply-To: <20200511154930.190212-14-Jerome.Pouiller@silabs.com> Hi Jerome, On Mon, May 11, 2020 at 5:53 PM Jerome Pouiller <Jerome.Pouiller@silabs.com> wrote: > From: Jérôme Pouiller <jerome.pouiller@silabs.com> > > The struct hif_msg is received from the hardware. So, it declared as > little endian. However, it is also accessed from many places in the > driver. Sparse complains about that: > > drivers/staging/wfx/bh.c:88:32: warning: restricted __le16 degrades to integer > drivers/staging/wfx/bh.c:88:32: warning: restricted __le16 degrades to integer > drivers/staging/wfx/bh.c:93:32: warning: restricted __le16 degrades to integer > drivers/staging/wfx/bh.c:93:32: warning: cast to restricted __le16 > drivers/staging/wfx/bh.c:93:32: warning: restricted __le16 degrades to integer > drivers/staging/wfx/bh.c:121:25: warning: incorrect type in argument 2 (different base types) > drivers/staging/wfx/bh.c:121:25: expected unsigned int len > drivers/staging/wfx/bh.c:121:25: got restricted __le16 [usertype] len > drivers/staging/wfx/hif_rx.c:27:22: warning: restricted __le16 degrades to integer > drivers/staging/wfx/hif_rx.c:347:39: warning: incorrect type in argument 7 (different base types) > drivers/staging/wfx/hif_rx.c:347:39: expected unsigned int [usertype] len > drivers/staging/wfx/hif_rx.c:347:39: got restricted __le16 const [usertype] len > drivers/staging/wfx/hif_rx.c:365:39: warning: incorrect type in argument 7 (different base types) > drivers/staging/wfx/hif_rx.c:365:39: expected unsigned int [usertype] len > drivers/staging/wfx/hif_rx.c:365:39: got restricted __le16 const [usertype] len > drivers/staging/wfx/./traces.h:195:1: warning: incorrect type in assignment (different base types) > drivers/staging/wfx/./traces.h:195:1: expected int msg_len > drivers/staging/wfx/./traces.h:195:1: got restricted __le16 const [usertype] len > drivers/staging/wfx/./traces.h:195:1: warning: incorrect type in assignment (different base types) > drivers/staging/wfx/./traces.h:195:1: expected int msg_len > drivers/staging/wfx/./traces.h:195:1: got restricted __le16 const [usertype] len > drivers/staging/wfx/debug.c:319:20: warning: restricted __le16 degrades to integer > drivers/staging/wfx/secure_link.c:85:27: warning: restricted __le16 degrades to integer > drivers/staging/wfx/secure_link.c:85:27: warning: restricted __le16 degrades to integer Thanks for your patch! > In order to make Sparse happy and to keep access from the driver easy, > this patch declare 'len' with native endianness. > > On reception of hardware data, this patch takes care to do byte-swap and > keep Sparse happy. Which means sparse can no longer do any checking on the field, and new bugs may/will creep in in the future, unnoticed. > --- a/drivers/staging/wfx/hif_api_general.h > +++ b/drivers/staging/wfx/hif_api_general.h > @@ -23,7 +23,10 @@ > #define HIF_COUNTER_MAX 7 > > struct hif_msg { > - __le16 len; > + // len is in fact little endian. However, it is widely used in the > + // driver, so we declare it in native byte order and we reorder just > + // before/after send/receive it (see bh.c). > + u16 len; While there's a small penalty associated with always doing the conversion on big-endian platforms, it will probably be lost in the noise anyway. 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 _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
next prev parent reply other threads:[~2020-05-12 7:43 UTC|newest] Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-11 15:49 [PATCH 00/17] staging: wfx: fix support for big-endian hosts Jerome Pouiller 2020-05-11 15:49 ` Jerome Pouiller 2020-05-11 15:49 ` [PATCH 01/17] staging: wfx: fix use of cpu_to_le32 instead of le32_to_cpu Jerome Pouiller 2020-05-11 15:49 ` Jerome Pouiller 2020-05-11 15:49 ` [PATCH 02/17] staging: wfx: take advantage of le32_to_cpup() Jerome Pouiller 2020-05-11 15:49 ` Jerome Pouiller 2020-05-11 15:49 ` [PATCH 03/17] staging: wfx: fix cast operator Jerome Pouiller 2020-05-11 15:49 ` Jerome Pouiller 2020-05-11 15:49 ` [PATCH 04/17] staging: wfx: fix wrong bytes order Jerome Pouiller 2020-05-11 15:49 ` Jerome Pouiller 2020-05-11 15:49 ` [PATCH 05/17] staging: wfx: fix output of rx_stats on big endian hosts Jerome Pouiller 2020-05-11 15:49 ` Jerome Pouiller 2020-05-11 15:49 ` [PATCH 06/17] staging: wfx: fix endianness of fields media_delay and tx_queue_delay Jerome Pouiller 2020-05-11 15:49 ` Jerome Pouiller 2020-05-11 15:49 ` [PATCH 07/17] staging: wfx: fix endianness of hif_req_read_mib fields Jerome Pouiller 2020-05-11 15:49 ` Jerome Pouiller 2020-05-11 15:49 ` [PATCH 08/17] staging: wfx: fix access to le32 attribute 'ps_mode_error' Jerome Pouiller 2020-05-11 15:49 ` Jerome Pouiller 2020-05-11 15:49 ` [PATCH 09/17] staging: wfx: fix access to le32 attribute 'event_id' Jerome Pouiller 2020-05-11 15:49 ` Jerome Pouiller 2020-05-11 15:49 ` [PATCH 10/17] staging: wfx: fix access to le32 attribute 'indication_type' Jerome Pouiller 2020-05-11 15:49 ` Jerome Pouiller 2020-05-11 15:49 ` [PATCH 11/17] staging: wfx: declare the field 'packet_id' with native byte order Jerome Pouiller 2020-05-11 15:49 ` Jerome Pouiller 2020-05-11 15:49 ` [PATCH 12/17] staging: wfx: fix endianness of the struct hif_ind_startup Jerome Pouiller 2020-05-11 15:49 ` Jerome Pouiller 2020-05-11 15:49 ` [PATCH 13/17] staging: wfx: fix endianness of the field 'len' Jerome Pouiller 2020-05-11 15:49 ` Jerome Pouiller 2020-05-11 21:59 ` kbuild test robot 2020-05-11 21:59 ` kbuild test robot 2020-05-11 21:59 ` kbuild test robot 2020-05-12 7:43 ` Geert Uytterhoeven [this message] 2020-05-12 7:43 ` Geert Uytterhoeven 2020-05-12 9:25 ` Jérôme Pouiller 2020-05-12 9:25 ` Jérôme Pouiller 2020-05-11 15:49 ` [PATCH 14/17] staging: wfx: fix endianness of the field 'status' Jerome Pouiller 2020-05-11 15:49 ` Jerome Pouiller 2020-05-11 15:49 ` [PATCH 15/17] staging: wfx: fix endianness of the field 'num_tx_confs' Jerome Pouiller 2020-05-11 15:49 ` Jerome Pouiller 2020-05-11 15:49 ` [PATCH 16/17] staging: wfx: fix endianness of the field 'channel_number' Jerome Pouiller 2020-05-11 15:49 ` Jerome Pouiller 2020-05-11 15:49 ` [PATCH 17/17] staging: wfx: update TODO Jerome Pouiller 2020-05-11 15:49 ` Jerome Pouiller
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=CAMuHMdVZxy+FZGPhDxotCBeEX3O4ZMkmGAwmVFXQE9ZoijDN5g@mail.gmail.com \ --to=geert@linux-m68k.org \ --cc=Jerome.Pouiller@silabs.com \ --cc=davem@davemloft.net \ --cc=devel@driverdev.osuosl.org \ --cc=gregkh@linuxfoundation.org \ --cc=kvalo@codeaurora.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-wireless@vger.kernel.org \ --cc=netdev@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.