Re: [PATCH v2 00/24] rtw88: major fixes for 8822c to have stable functionalities

[Kalle Valo <kvalo@codeaurora.org>]

Tony Chuang <yhchuang@realtek.com> writes:

>> From: Yan-Hsuan Chuang <yhchuang@realtek.com>
>> 
>> Note this patch set is based on patch set "rtw88: mac80211 driver for
>> Realtek 802.11ac wireless network chips". For reference:
>> https://patchwork.kernel.org/cover/10811967/
>> https://lkml.kernel.org/linux-wireless/1550131671-2601-1-git-send-email-yhch
>> uang@realtek.com/
>> 
>> These patches are mean to make sure 8822c chip to operate normal for most
>> of the basic functionalities, such as power on, switch channel, scan,
>> connection establish and connection monitor.
>> 
>> As the original patch set was sent 3 months ago, progress has been made
>> by Realtek during the past months. Now we have tested on more chips and
>> released tables and parameters for them. Also the chips are all
>> programed with efuse map released for 8822c.
>> 
>> Most of the changes are about BB and RF, both control the tx/rx path.
>> PHY parameters/seq and efuse info make sure the hardware is powered on
>> correctly. And channel setting updates help driver to switch to target
>> channel accurately. Then trx mode setting and DACK will make hardware to
>> have stable performance to tx/rx to connect to AP.
>> 
>> Here tx power control is also required to transmit with a precise power.
>> Otherwise if the power is too high or too low, the peer might not be able
>> to receive the signal.
>> 
>> Finally, we need to report correct tx status for mac80211's connection
>> monitor system, this requires firmware's C2H of tx status report. After
>> this, users can use 8822c chips for more stable wireless communication.
>> 
>> 
>> v2
>> 
>> This v2 is sent for that https://patchwork.kernel.org/cover/10811967/
>> has many modifications and the original patch set would not apply.
>> Also with a few changes in this one. Listed below
>> 
>>  - report ACK for tx frames not have IEEE80211_TX_CTL_REQ_TX_STATUS,
>>    otherwise they will be marked as "drop"
>>  - add more rf register write protection for patch "rtw88: add a delay
>>    after writing a rf register"
>> 
>
> Can I ask that when will this patch set probably be applied into your tree?

Once everyone are happy about the driver, at least it needs a review
from Johannes and me but reviews from others is more than welcome. I
also saw that Brian gave good comments but not sure if he thinks the
driver is ready for upstream?

An ideal schedule is to apply the driver just after the -rc1 is release,
so within two weeks time. That way we have maximum time to fix any
problems which might arise.

Did Stanislaw already review this driver? I don't see any mentioning of
that in the cover letter[1].

For now freeze please the developement on the driver to make the review
easier. So don't do any changes unless asked by Johannes or me. You can
of course do development on a separate branch and submit fixes after the
driver is accepted upstream.

The cover letter mentions nothing about what features are supported,
that's the first thing I would like to see when I start reviewing a
driver. Also a list of missing features, problematic areas and major
bugs would be very helpful to understand the state of the driver.

I don't see any mention about firmware availability in the cover letter,
please add that.

Also in another thread I saw something about this driver conflicting
with a staging driver, is that true? That should be solved before the
driver is accepted as I don't think two drivers should race for the same
hardware and the driver is randomly chosen.

And in v6 please fold the fixes from this patchset to the original
patchset[1] adding the driver (using the one patch per file format).
That way there's one set of patches to review.

I have now applied both patchsets to the pending patch for build testing
and easier review:

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git/log/?h=pending

[1] https://patchwork.kernel.org/cover/10811967/

-- 
Kalle Valo