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
