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 <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. Which makes me wonder, since I don't see any of those warnings - what does it take to see them ? Guenter _______________________________________________ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
