Re: [PATCH RFC v2 5/6] staging: r8188eu: add error handling of rtw_read32

["Fabio M. De Francesco" <fmdefrancesco@gmail.com>]

On Tuesday, August 24, 2021 10:53:35 AM CEST Pavel Skripkin wrote:
> On 8/24/21 11:47 AM, Pavel Skripkin wrote:
> > On 8/24/21 11:38 AM, Fabio M. De Francesco wrote:
> > 
> > Hi, Fabio!
> > 
> > previous usb_read16() realization, which is 100% right:
> > 
> > 
> > static u16 usb_read16(struct intf_hdl *pintfhdl, u32 addr)
> > {
> > 	u8 requesttype;
> > 	u16 wvalue;
> > 	u16 len;
> > 	__le32 data;

Ah, it was in plain sight! How didn't I notice it? :(

> > 
> > 	requesttype = 0x01;/* read_in */
> > 	wvalue = (u16)(addr & 0x0000ffff);
> > 	len = 2;
> > 	usbctrl_vendorreq(pintfhdl, wvalue, &data, len, requesttype);
> > 
> > 	return (u16)(le32_to_cpu(data) & 0xffff);
> > }
> > 
> > 
> > Bases on this code, I think, it's oblivious, that data comes in
> > little-endian. That's why I leaved temp variable for casting le32 to
> > cpu's endianess.

Yes you did well (if we trust the old code :)), anyway I guess it
was correct because I've just seen that data is __le32 also in other Realtek
drivers.

> > 
> > I could just read into u{16,32} * and then make smth like
> > 
> > *data = le32_to_cpu(*data)
> > 
> > but static analysis tools will complain about wrong data type passed to
> >    le32_to_cpu()

Obviously the (not broken) tools should catch that and complain.

> > + Phillip tested fixed v2 version and it worked well for him. I guess,
> > Phillip was able to spot weird driver behavior, if this cast is wrong.
> > 
> 		^^^^^&
> 
> I am wrong with this statement, I guess. Most likely, Phillip is testing 
> on smth like x64 and this arch is le, so...
> 
> With regards,
> Pavel Skripkin
> 
Thanks,

Fabio