Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1638556 > unrolled thread

[PATCH] staging: typec: Fix sparse warnings about incorrect types

Started byGuru Das Srinagesh <gurooodas@gmail.com>
First post2017-05-10 06:40 +0200
Last post2017-05-10 21:20 +0200
Articles 4 — 3 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH] staging: typec: Fix sparse warnings about incorrect types Guru Das Srinagesh <gurooodas@gmail.com> - 2017-05-10 06:40 +0200
    Re: [PATCH] staging: typec: Fix sparse warnings about incorrect types Guenter Roeck <groeck@google.com> - 2017-05-10 17:30 +0200
      Re: [PATCH] staging: typec: Fix sparse warnings about incorrect types Guru Das S <gurooodas@gmail.com> - 2017-05-10 19:20 +0200
        Re: [PATCH] staging: typec: Fix sparse warnings about incorrect types Guenter Roeck <groeck@google.com> - 2017-05-10 21:20 +0200

#1638556 — [PATCH] staging: typec: Fix sparse warnings about incorrect types

FromGuru Das Srinagesh <gurooodas@gmail.com>
Date2017-05-10 06:40 +0200
Subject[PATCH] staging: typec: Fix sparse warnings about incorrect types
Message-ID<tFrzQ-4b3-17@gated-at.bofh.it>
Fix the following sparse warnings about incorrect type usage:

tcpci.c:290:38: warning: incorrect type in argument 1 (different base types)
tcpci.c:290:38:    expected unsigned short [unsigned] [usertype] header
tcpci.c:290:38:    got restricted __le16 const [usertype] header
tcpci.c:295:16: warning: incorrect type in assignment (different base types)
tcpci.c:295:16:    expected unsigned int [unsigned] header
tcpci.c:295:16:    got restricted __le16
tcpci.c:393:28: warning: incorrect type in assignment (different base types)
tcpci.c:393:28:    expected restricted __le16 [usertype] header
tcpci.c:393:28:    got unsigned int [unsigned] [addressable] reg

fusb302.c:1028:32: warning: incorrect type in argument 1 (different base types)
fusb302.c:1028:32:    expected unsigned short [unsigned] [usertype] header
fusb302.c:1028:32:    got restricted __le16 const [usertype] header
fusb302.c:1484:32: warning: incorrect type in argument 1 (different base types)
fusb302.c:1484:32:    expected unsigned short [unsigned] [usertype] header
fusb302.c:1484:32:    got restricted __le16 [usertype] header

Signed-off-by: Guru Das Srinagesh <gurooodas@gmail.com>
---
 drivers/staging/typec/fusb302/fusb302.c | 4 ++--
 drivers/staging/typec/tcpci.c           | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/typec/fusb302/fusb302.c b/drivers/staging/typec/fusb302/fusb302.c
index 2cee9a9..9612ef1 100644
--- a/drivers/staging/typec/fusb302/fusb302.c
+++ b/drivers/staging/typec/fusb302/fusb302.c
@@ -1025,7 +1025,7 @@ static int fusb302_pd_send_message(struct fusb302_chip *chip,
 	buf[pos++] = FUSB302_TKN_SYNC1;
 	buf[pos++] = FUSB302_TKN_SYNC2;
 
-	len = pd_header_cnt(msg->header) * 4;
+	len = pd_header_cnt(le16_to_cpu(msg->header)) * 4;
 	/* plug 2 for header */
 	len += 2;
 	if (len > 0x1F) {
@@ -1481,7 +1481,7 @@ static int fusb302_pd_read_message(struct fusb302_chip *chip,
 				     (u8 *)&msg->header);
 	if (ret < 0)
 		return ret;
-	len = pd_header_cnt(msg->header) * 4;
+	len = pd_header_cnt(le16_to_cpu(msg->header)) * 4;
 	/* add 4 to length to include the CRC */
 	if (len > PD_MAX_PAYLOAD * 4) {
 		fusb302_log(chip, "PD message too long %d", len);
diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 5e5be74..d0c22a7 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -287,12 +287,12 @@ static int tcpci_pd_transmit(struct tcpc_dev *tcpc,
 	unsigned int reg, cnt, header;
 	int ret;
 
-	cnt = msg ? pd_header_cnt(msg->header) * 4 : 0;
+	cnt = msg ? pd_header_cnt(le16_to_cpu(msg->header)) * 4 : 0;
 	ret = regmap_write(tcpci->regmap, TCPC_TX_BYTE_CNT, cnt + 2);
 	if (ret < 0)
 		return ret;
 
-	header = msg ? msg->header : 0;
+	header = msg ? le16_to_cpu(msg->header) : 0;
 	ret = tcpci_write16(tcpci, TCPC_TX_HDR, header);
 	if (ret < 0)
 		return ret;
@@ -390,7 +390,7 @@ static irqreturn_t tcpci_irq(int irq, void *dev_id)
 		regmap_read(tcpci->regmap, TCPC_RX_BYTE_CNT, &cnt);
 
 		tcpci_read16(tcpci, TCPC_RX_HDR, &reg);
-		msg.header = reg;
+		msg.header = cpu_to_le16(reg);
 
 		if (WARN_ON(cnt > sizeof(msg.payload)))
 			cnt = sizeof(msg.payload);
-- 
2.7.4

[toc] | [next] | [standalone]

#1638913

FromGuenter Roeck <groeck@google.com>
Date2017-05-10 17:30 +0200
Message-ID<tFBIS-2p1-17@gated-at.bofh.it>
In reply to#1638556
On Tue, May 9, 2017 at 9:39 PM, Guru Das Srinagesh <gurooodas@gmail.com> wrote:
> Fix the following sparse warnings about incorrect type usage:
>
> tcpci.c:290:38: warning: incorrect type in argument 1 (different base types)
> tcpci.c:290:38:    expected unsigned short [unsigned] [usertype] header
> tcpci.c:290:38:    got restricted __le16 const [usertype] header
> tcpci.c:295:16: warning: incorrect type in assignment (different base types)
> tcpci.c:295:16:    expected unsigned int [unsigned] header
> tcpci.c:295:16:    got restricted __le16
> tcpci.c:393:28: warning: incorrect type in assignment (different base types)
> tcpci.c:393:28:    expected restricted __le16 [usertype] header
> tcpci.c:393:28:    got unsigned int [unsigned] [addressable] reg
>
> fusb302.c:1028:32: warning: incorrect type in argument 1 (different base types)
> fusb302.c:1028:32:    expected unsigned short [unsigned] [usertype] header
> fusb302.c:1028:32:    got restricted __le16 const [usertype] header
> fusb302.c:1484:32: warning: incorrect type in argument 1 (different base types)
> fusb302.c:1484:32:    expected unsigned short [unsigned] [usertype] header
> fusb302.c:1484:32:    got restricted __le16 [usertype] header
>

Please the patch into two parts, one per file; the required changes
for endianness support in tcpci.c are much more complex.

> Signed-off-by: Guru Das Srinagesh <gurooodas@gmail.com>
> ---
>  drivers/staging/typec/fusb302/fusb302.c | 4 ++--
>  drivers/staging/typec/tcpci.c           | 6 +++---
>  2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/staging/typec/fusb302/fusb302.c b/drivers/staging/typec/fusb302/fusb302.c
> index 2cee9a9..9612ef1 100644
> --- a/drivers/staging/typec/fusb302/fusb302.c
> +++ b/drivers/staging/typec/fusb302/fusb302.c
> @@ -1025,7 +1025,7 @@ static int fusb302_pd_send_message(struct fusb302_chip *chip,
>         buf[pos++] = FUSB302_TKN_SYNC1;
>         buf[pos++] = FUSB302_TKN_SYNC2;
>
> -       len = pd_header_cnt(msg->header) * 4;
> +       len = pd_header_cnt(le16_to_cpu(msg->header)) * 4;

We have pd_header_cnt_le() for this purpose.

Yueyao, can you have a look into those changes for the fusb302 driver
? Is it safe to assume that we didn't hit a problem because the
hardware is little endian ?

>         /* plug 2 for header */
>         len += 2;
>         if (len > 0x1F) {
> @@ -1481,7 +1481,7 @@ static int fusb302_pd_read_message(struct fusb302_chip *chip,
>                                      (u8 *)&msg->header);
>         if (ret < 0)
>                 return ret;
> -       len = pd_header_cnt(msg->header) * 4;
> +       len = pd_header_cnt(le16_to_cpu(msg->header)) * 4;
>         /* add 4 to length to include the CRC */
>         if (len > PD_MAX_PAYLOAD * 4) {
>                 fusb302_log(chip, "PD message too long %d", len);
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> index 5e5be74..d0c22a7 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -287,12 +287,12 @@ static int tcpci_pd_transmit(struct tcpc_dev *tcpc,
>         unsigned int reg, cnt, header;
>         int ret;
>
> -       cnt = msg ? pd_header_cnt(msg->header) * 4 : 0;
> +       cnt = msg ? pd_header_cnt(le16_to_cpu(msg->header)) * 4 : 0;

pd_header_cnt_le()

>         ret = regmap_write(tcpci->regmap, TCPC_TX_BYTE_CNT, cnt + 2);
>         if (ret < 0)
>                 return ret;
>
> -       header = msg ? msg->header : 0;
> +       header = msg ? le16_to_cpu(msg->header) : 0;

Excellent catch, but the fix is wrong. We don't want to change the
endianness here, since the data is sent to the chip. This will require
a (much) more comprehensive fix - header should probably be le16, the
second parameter to tcpci_write16() needs to be le16, plus everything
that comes with it (currently the code is just not endianness clean).
tcpci_read16() is also incorrect and has the same problem (it is
really a bad idea to read 16 bit into an unsigned int pointer).

Let me know if you want to try to fix this; otherwise I'll do it.

Thanks,
Guenter

>         ret = tcpci_write16(tcpci, TCPC_TX_HDR, header);
>         if (ret < 0)
>                 return ret;
> @@ -390,7 +390,7 @@ static irqreturn_t tcpci_irq(int irq, void *dev_id)
>                 regmap_read(tcpci->regmap, TCPC_RX_BYTE_CNT, &cnt);
>
>                 tcpci_read16(tcpci, TCPC_RX_HDR, &reg);
> -               msg.header = reg;
> +               msg.header = cpu_to_le16(reg);
>
>                 if (WARN_ON(cnt > sizeof(msg.payload)))
>                         cnt = sizeof(msg.payload);
> --
> 2.7.4
>

[toc] | [prev] | [next] | [standalone]

#1638973

FromGuru Das S <gurooodas@gmail.com>
Date2017-05-10 19:20 +0200
Message-ID<tFDrj-3t7-1@gated-at.bofh.it>
In reply to#1638913
On 10 May 2017 at 08:23, Guenter Roeck <groeck@google.com> wrote:

> Please the patch into two parts, one per file; the required changes
> for endianness support in tcpci.c are much more complex.

I will send out a patch for the two simple fixes - the use of
pd_header_cnt_le().

> Excellent catch, but the fix is wrong. We don't want to change the
> endianness here, since the data is sent to the chip. This will require
> a (much) more comprehensive fix - header should probably be le16, the
> second parameter to tcpci_write16() needs to be le16, plus everything
> that comes with it (currently the code is just not endianness clean).
> tcpci_read16() is also incorrect and has the same problem (it is
> really a bad idea to read 16 bit into an unsigned int pointer).
>
> Let me know if you want to try to fix this; otherwise I'll do it.

Sure, I'd like to give this a try. I will take a closer look at the
code and get back to you with questions.

[toc] | [prev] | [next] | [standalone]

#1639044

FromGuenter Roeck <groeck@google.com>
Date2017-05-10 21:20 +0200
Message-ID<tFFjr-4By-7@gated-at.bofh.it>
In reply to#1638973
On Wed, May 10, 2017 at 10:15 AM, Guru Das S <gurooodas@gmail.com> wrote:
> On 10 May 2017 at 08:23, Guenter Roeck <groeck@google.com> wrote:
>
>> Please the patch into two parts, one per file; the required changes
>> for endianness support in tcpci.c are much more complex.
>
> I will send out a patch for the two simple fixes - the use of
> pd_header_cnt_le().
>
>> Excellent catch, but the fix is wrong. We don't want to change the
>> endianness here, since the data is sent to the chip. This will require
>> a (much) more comprehensive fix - header should probably be le16, the
>> second parameter to tcpci_write16() needs to be le16, plus everything
>> that comes with it (currently the code is just not endianness clean).
>> tcpci_read16() is also incorrect and has the same problem (it is
>> really a bad idea to read 16 bit into an unsigned int pointer).
>>
>> Let me know if you want to try to fix this; otherwise I'll do it.
>
> Sure, I'd like to give this a try. I will take a closer look at the
> code and get back to you with questions.

Thanks!
Guenter

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web