Re: [PATCH v2] staging: typec: Fix endianness warning discovered by sparse
Guenter Roeck<li...@roeck-us.net> / 2017-07-06T17:13-0700
> On 07/06/2017 03:54 PM, Thomas Gardner wrote:
> > The below warning is resolved by removing the cpu_to_le32() call. This
> > call was redundant; vdm_run_state_machine() ensures that SVDM responses
> > have the correct endianness before sending.
> >
> > typec/tcpm.c:1019:49: warning: incorrect type in assignment (different base
> > types)
> > typec/tcpm.c:1019:49:expected unsigned int [unsigned] [usertype]
> >
> > typec/tcpm.c:1019:49:got restricted __le32 [usertype]
> >
> > Signed-off-by: Thomas Gardner <t...@fastmail.com>
> > ---
> > drivers/staging/typec/tcpm.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/staging/typec/tcpm.c b/drivers/staging/typec/tcpm.c
> > index 20eb4ebcf8c3..0b596f56d18c 100644
> > --- a/drivers/staging/typec/tcpm.c
> > +++ b/drivers/staging/typec/tcpm.c
> > @@ -1015,8 +1015,7 @@ static int tcpm_pd_svdm(struct tcpm_port *port, const
> > __le32 *payload, int cnt,
> > if (port->data_role == TYPEC_DEVICE &&
> > port->nr_snk_vdo) {
> > for (i = 0; i < port->nr_snk_vdo; i++)
> > - response[i + 1]
> > - = cpu_to_le32(port->snk_vdo[i]);
> > + response[i + 1] = (port->snk_vdo[i]);
>
> Unnecessary ( ).
Is there an adaptation of Muphry's Law for patches claiming to remove
redundancy?
> Guenter
>
> > rlen = port->nr_snk_vdo + 1;
> > }
> > break;
> >
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v3] staging: typec: Fix endianness warning discovered by sparse
The below warning is resolved by removing the cpu_to_le32() call. This
call was redundant; vdm_run_state_machine() ensures that SVDM responses
have the correct endianness before sending.
typec/tcpm.c:1019:49: warning: incorrect type in assignment (different base
types)
typec/tcpm.c:1019:49:expected unsigned int [unsigned] [usertype]
typec/tcpm.c:1019:49:got restricted __le32 [usertype]
Signed-off-by: Thomas Gardner <t...@fastmail.com>
---
drivers/staging/typec/tcpm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/typec/tcpm.c b/drivers/staging/typec/tcpm.c
index 20eb4ebcf8c3..2195c80235a1 100644
--- a/drivers/staging/typec/tcpm.c
+++ b/drivers/staging/typec/tcpm.c
@@ -1015,8 +1015,7 @@ static int tcpm_pd_svdm(struct tcpm_port *port, const
__le32 *payload, int cnt,
if (port->data_role == TYPEC_DEVICE &&
port->nr_snk_vdo) {
for (i = 0; i < port->nr_snk_vdo; i++)
- response[i + 1]
- = cpu_to_le32(port->snk_vdo[i]);
+ response[i + 1] = port->snk_vdo[i];
rlen = port->nr_snk_vdo + 1;
}
break;
--
2.13.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2] staging: typec: Fix endianness warning discovered by sparse
The below warning is resolved by removing the cpu_to_le32() call. This
call was redundant; vdm_run_state_machine() ensures that SVDM responses
have the correct endianness before sending.
typec/tcpm.c:1019:49: warning: incorrect type in assignment (different base
types)
typec/tcpm.c:1019:49:expected unsigned int [unsigned] [usertype]
typec/tcpm.c:1019:49:got restricted __le32 [usertype]
Signed-off-by: Thomas Gardner <t...@fastmail.com>
---
drivers/staging/typec/tcpm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/typec/tcpm.c b/drivers/staging/typec/tcpm.c
index 20eb4ebcf8c3..0b596f56d18c 100644
--- a/drivers/staging/typec/tcpm.c
+++ b/drivers/staging/typec/tcpm.c
@@ -1015,8 +1015,7 @@ static int tcpm_pd_svdm(struct tcpm_port *port, const
__le32 *payload, int cnt,
if (port->data_role == TYPEC_DEVICE &&
port->nr_snk_vdo) {
for (i = 0; i < port->nr_snk_vdo; i++)
- response[i + 1]
- = cpu_to_le32(port->snk_vdo[i]);
+ response[i + 1] = (port->snk_vdo[i]);
rlen = port->nr_snk_vdo + 1;
}
break;
--
2.13.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: typec: Fix type mismatch found with sparse
Guenter Roeck<li...@roeck-us.net> / 2017-07-05T07:25-0700
> On 07/05/2017 07:00 AM, Thomas Gardner wrote:
> > The warning below is resolved by casting the LHS to __le32.
> >
> > typec/tcpm.c:1019:49: warning: incorrect type in assignment (different base
> > types)
> > typec/tcpm.c:1019:49:expected unsigned int [unsigned] [usertype]
> >
> > typec/tcpm.c:1019:49:got restricted __le32 [usertype]
> >
> > Signed-off-by: Thomas Gardner <t...@fastmail.com>
> > ---
> > drivers/staging/typec/tcpm.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/typec/tcpm.c b/drivers/staging/typec/tcpm.c
> > index 20eb4ebcf8c3..7699bb27a4d9 100644
> > --- a/drivers/staging/typec/tcpm.c
> > +++ b/drivers/staging/typec/tcpm.c
> > @@ -1015,7 +1015,7 @@ static int tcpm_pd_svdm(struct tcpm_port *port, const
> > __le32 *payload, int cnt,
> > if (port->data_role == TYPEC_DEVICE &&
> > port->nr_snk_vdo) {
> > for (i = 0; i < port->nr_snk_vdo; i++)
> > - response[i + 1]
> > + ((__le32 *)response)[i + 1]
> > = cpu_to_le32(port->snk_vdo[i]);
> > rlen = port->nr_snk_vdo + 1;
> > }
> >
> I think this would just hide a number of at least potential endianness issues
> in the driver. response[] should be of type __le32 instead, with everything
> that comes with it.
Greetings Guenter, is this conversion actually necessary? The state
machine tries to fix endianness of the response before sending at,
for (i = 0; i < port->vdo_count; i++)
msg.payload[i] = cpu_to_le32(port->vdo_data[i]);
Perhaps the patch should be,
- response[i + 1]
- = cpu_to_le32(port->snk_vdo[i]);
+ response[i + 1] = port->snk_vdo[i];
which also clears the warning.
> Which makes me wonder, since I don't see any of those warnings - what
> does it take to see them ?
I can see them by running,
make C=2 ./drivers/staging/typec/
> Guenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: typec: Fix type mismatch found with sparse
The warning below is resolved by casting the LHS to __le32.
typec/tcpm.c:1019:49: warning: incorrect type in assignment (different base
types)
typec/tcpm.c:1019:49:expected unsigned int [unsigned] [usertype]
typec/tcpm.c:1019:49:got restricted __le32 [usertype]
Signed-off-by: Thomas Gardner <t...@fastmail.com>
---
drivers/staging/typec/tcpm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/typec/tcpm.c b/drivers/staging/typec/tcpm.c
index 20eb4ebcf8c3..7699bb27a4d9 100644
--- a/drivers/staging/typec/tcpm.c
+++ b/drivers/staging/typec/tcpm.c
@@ -1015,7 +1015,7 @@ static int tcpm_pd_svdm(struct tcpm_port *port, const
__le32 *payload, int cnt,
if (port->data_role == TYPEC_DEVICE &&
port->nr_snk_vdo) {
for (i = 0; i < port->nr_snk_vdo; i++)
- response[i + 1]
+ ((__le32 *)response)[i + 1]
= cpu_to_le32(port->snk_vdo[i]);
rlen = port->nr_snk_vdo + 1;
}
--
2.13.2
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: fbtft: Fix type mismatch found with sparse
The warning below is resolved by changing the LHS cast to __be64. fbtft/fbtft-io.c:74:29: warning: incorrect type in assignment (different base types) fbtft/fbtft-io.c:74:29:expected unsigned long long [unsigned] [long] [long long] [usertype] fbtft/fbtft-io.c:74:29:got restricted __be64 [usertype] Signed-off-by: Thomas Gardner <t...@fastmail.com> --- drivers/staging/fbtft/fbtft-io.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/fbtft/fbtft-io.c b/drivers/staging/fbtft/fbtft-io.c index d86840548b74..ffb9a3b4d454 100644 --- a/drivers/staging/fbtft/fbtft-io.c +++ b/drivers/staging/fbtft/fbtft-io.c @@ -71,7 +71,7 @@ int fbtft_write_spi_emulate_9(struct fbtft_par *par, void *buf, size_t len) src++; } tmp |= ((*src & 0x0100) ? 1 : 0); - *(u64 *)dst = cpu_to_be64(tmp); + *(__be64 *)dst = cpu_to_be64(tmp); dst += 8; *dst++ = (u8)(*src++ & 0x00FF); added++; -- 2.13.2 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
