On Mon, May 29, 2017 at 04:33:58PM +0200, Greg KH wrote:
> On Sun, May 21, 2017 at 10:15:11AM +0100, dick@xxxxxxx wrote:
> > From: Richard Porter <dick@xxxxxxx>
> >
> > Fixes sparse warnings:
> > drivers/staging/ks7010/ks_hostif.c:339:21: warning: cast to restricted __be16
> > drivers/staging/ks7010/ks_hostif.c:430:21: warning: cast to restricted __be16
> > drivers/staging/ks7010/ks_hostif.c:1226:21: warning: cast to restricted __be16
> >
> > Signed-off-by: Richard Porter <dick@xxxxxxx>
> > ---
> > drivers/staging/ks7010/eap_packet.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/ks7010/eap_packet.h b/drivers/staging/ks7010/eap_packet.h
> > index b2d25ef..eec4aa4 100644
> > --- a/drivers/staging/ks7010/eap_packet.h
> > +++ b/drivers/staging/ks7010/eap_packet.h
> > @@ -18,7 +18,7 @@ struct ether_hdr {
> > unsigned char h_source_snap;
> > unsigned char h_command;
> > unsigned char h_vendor_id[3];
> > - unsigned short h_proto; /* packet type ID field */
> > + __be16 h_proto; /* packet type ID field */
>
> How do you know this field is really this endian? Is this on the wire?
> On the device itself? How have you verified this is correct?
ether_hdr.h_proto is only ever read via ntohs(), on the lines highlighted
by sparse, apart from when it is copied directly into an sk_buff data buffer
(ks_hostif.c line 474) at offset ETH_ALEN * 2. The sk_buff data gets cast
to a struct ethhdr in eth_type_trans() (ks_hostif.c line 510), which already
has the h_proto field at the same offset with type __be16.
- Dick
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
