Guenter Roeck<linux@xxxxxxxxxxxx> / 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] <noident>
> > typec/tcpm.c:1019:49: got restricted __le32 [usertype] <noident>
> >
> > Signed-off-by: Thomas Gardner <tmg@xxxxxxxxxxxx>
> > ---
> > 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
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
