On Tuesday, August 24, 2021 10:53:35 AM CEST Pavel Skripkin wrote:

On 8/24/21 11:47 AM, Pavel Skripkin wrote:

quoted

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? :(

quoted

	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.

quoted

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.

quoted

+ 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