> -----Original Message----- > From: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> > Sent: Tuesday, April 18, 2023 4:58 PM > To: Ping-Ke Shih <pkshih@xxxxxxxxxxx> > Cc: linux-wireless <linux-wireless@xxxxxxxxxxxxxxx>; Hans Ulli Kroll <linux@xxxxxxxxxxxxx>; Larry Finger > <Larry.Finger@xxxxxxxxxxxx>; Tim K <tpkuester@xxxxxxxxx>; Alex G . <mr.nuke.me@xxxxxxxxx>; Nick Morrow > <morrownr@xxxxxxxxx>; Viktor Petrenko <g0000ga@xxxxxxxxx>; Andreas Henriksson <andreas@xxxxxxxx>; > ValdikSS <iam@xxxxxxxxxxxxxxx>; kernel@xxxxxxxxxxxxxx > Subject: Re: [PATCH v3 3/4] wifi: rtw88: set pkg_type correctly for specific rtw8821c variants > > On Tue, Apr 18, 2023 at 12:36:31AM +0000, Ping-Ke Shih wrote: > > > > > > > -----Original Message----- > > > From: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> > > > Sent: Monday, April 17, 2023 10:04 PM > > > To: linux-wireless <linux-wireless@xxxxxxxxxxxxxxx> > > > Cc: Hans Ulli Kroll <linux@xxxxxxxxxxxxx>; Larry Finger <Larry.Finger@xxxxxxxxxxxx>; Ping-Ke Shih > > > <pkshih@xxxxxxxxxxx>; Tim K <tpkuester@xxxxxxxxx>; Alex G . <mr.nuke.me@xxxxxxxxx>; Nick Morrow > > > <morrownr@xxxxxxxxx>; Viktor Petrenko <g0000ga@xxxxxxxxx>; Andreas Henriksson <andreas@xxxxxxxx>; > > > ValdikSS <iam@xxxxxxxxxxxxxxx>; kernel@xxxxxxxxxxxxxx; Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> > > > Subject: [PATCH v3 3/4] wifi: rtw88: set pkg_type correctly for specific rtw8821c variants > > > > > > According to the vendor driver the pkg_type has to be set to '1' > > > for some rtw8821c variants. As the pkg_type has been hardcoded to > > > '0', add a field for it in struct rtw_hal and set this correctly > > > in the rtw8821c part. > > > With this parsing of a rtw_table is influenced and check_positive() > > > in phy.c returns true for some cases here. The same is done in the > > > vendor driver. However, this has no visible effect on the driver > > > here. > > > > I agree this patch, but still want to know more about the meaning of > > "...no visible effect...". Do you mean your USB device works well with/without > > this patch? or, IO is absolutely the same when loading parameters with > > check_positive()? > > Yes, it works with and without this patch. With this patch > check_positive() returns true in some cases whereas without this patch > check_positive always returns false. > I don't know at all what effect this change could have, maybe I just > need the right test case to verify it really makes a change. > > I just realized that something like the below is missing, as the > cond.rfe part needs the raw rfe value from fuses >> 3. > > Maybe we just take 1/4 and 2/4 and drop the others. I am running out of > time for further debugging RTW8821C which is a chip our customer isn't > interested in. > I think we can take all patches, because they go forward to correct direction, and other flaws can be fixed after people can really get that kind of modules. Ping-Ke
