aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2022-09-02xen-blkfront: Cache feature_persistent value before advertisementSeongJae Park1-7/+7
Xen blkfront advertises its support of the persistent grants feature when it first setting up and when resuming in 'talk_to_blkback()'. Then, blkback reads the advertised value when it connects with blkfront and decides if it will use the persistent grants feature or not, and advertises its decision to blkfront. Blkfront reads the blkback's decision and it also makes the decision for the use of the feature. Commit 402c43ea6b34 ("xen-blkfront: Apply 'feature_persistent' parameter when connect"), however, made the blkfront's read of the parameter for disabling the advertisement, namely 'feature_persistent', to be done when it negotiate, not when advertise. Therefore blkfront advertises without reading the parameter. As the field for caching the parameter value is zero-initialized, it always advertises as the feature is disabled, so that the persistent grants feature becomes always disabled. This commit fixes the issue by making the blkfront does parmeter caching just before the advertisement. Fixes: 402c43ea6b34 ("xen-blkfront: Apply 'feature_persistent' parameter when connect") Cc: <stable@vger.kernel.org> # 5.10.x Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Signed-off-by: SeongJae Park <sj@kernel.org> Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20220831165824.94815-4-sj@kernel.org Signed-off-by: Juergen Gross <jgross@suse.com>
2022-09-02xen-blkfront: Advertise feature-persistent as user requestedSeongJae Park1-2/+6
The advertisement of the persistent grants feature (writing 'feature-persistent' to xenbus) should mean not the decision for using the feature but only the availability of the feature. However, commit 74a852479c68 ("xen-blkfront: add a parameter for disabling of persistent grants") made a field of blkfront, which was a place for saving only the negotiation result, to be used for yet another purpose: caching of the 'feature_persistent' parameter value. As a result, the advertisement, which should follow only the parameter value, becomes inconsistent. This commit fixes the misuse of the semantic by making blkfront saves the parameter value in a separate place and advertises the support based on only the saved value. Fixes: 74a852479c68 ("xen-blkfront: add a parameter for disabling of persistent grants") Cc: <stable@vger.kernel.org> # 5.10.x Suggested-by: Juergen Gross <jgross@suse.com> Signed-off-by: SeongJae Park <sj@kernel.org> Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20220831165824.94815-3-sj@kernel.org Signed-off-by: Juergen Gross <jgross@suse.com>
2022-09-02xen-blkback: Advertise feature-persistent as user requestedSeongJae Park2-2/+7
The advertisement of the persistent grants feature (writing 'feature-persistent' to xenbus) should mean not the decision for using the feature but only the availability of the feature. However, commit aac8a70db24b ("xen-blkback: add a parameter for disabling of persistent grants") made a field of blkback, which was a place for saving only the negotiation result, to be used for yet another purpose: caching of the 'feature_persistent' parameter value. As a result, the advertisement, which should follow only the parameter value, becomes inconsistent. This commit fixes the misuse of the semantic by making blkback saves the parameter value in a separate place and advertises the support based on only the saved value. Fixes: aac8a70db24b ("xen-blkback: add a parameter for disabling of persistent grants") Cc: <stable@vger.kernel.org> # 5.10.x Suggested-by: Juergen Gross <jgross@suse.com> Signed-off-by: SeongJae Park <sj@kernel.org> Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reviewed-by: Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20220831165824.94815-2-sj@kernel.org Signed-off-by: Juergen Gross <jgross@suse.com>
2022-09-02powerpc/papr_scm: Ensure rc is always initialized in papr_scm_pmu_register()Nathan Chancellor1-1/+3
Clang warns: arch/powerpc/platforms/pseries/papr_scm.c:492:6: warning: variable 'rc' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] if (!p->stat_buffer_len) ^~~~~~~~~~~~~~~~~~~ arch/powerpc/platforms/pseries/papr_scm.c:523:64: note: uninitialized use occurs here dev_info(&p->pdev->dev, "nvdimm pmu didn't register rc=%d\n", rc); ^~ include/linux/dev_printk.h:150:67: note: expanded from macro 'dev_info' dev_printk_index_wrap(_dev_info, KERN_INFO, dev, dev_fmt(fmt), ##__VA_ARGS__) ^~~~~~~~~~~ include/linux/dev_printk.h:110:23: note: expanded from macro 'dev_printk_index_wrap' _p_func(dev, fmt, ##__VA_ARGS__); \ ^~~~~~~~~~~ arch/powerpc/platforms/pseries/papr_scm.c:492:2: note: remove the 'if' if its condition is always false if (!p->stat_buffer_len) ^~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/platforms/pseries/papr_scm.c:484:8: note: initialize the variable 'rc' to silence this warning int rc, nodeid; ^ = 0 1 warning generated. The call to papr_scm_pmu_check_events() was eliminated but a return code was not added to the if statement. Add the same return code from papr_scm_pmu_check_events() for this condition so there is no more warning. Fixes: 9b1ac04698a4 ("powerpc/papr_scm: Fix nvdimm event mappings") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://github.com/ClangBuiltLinux/linux/issues/1701 Link: https://lore.kernel.org/r/20220830151256.1473169-1-nathan@kernel.org
2022-09-02Revert "powerpc/irq: Don't open code irq_soft_mask helpers"Michael Ellerman1-7/+36
This reverts commit ef5b570d3700fbb8628a58da0487486ceeb713cd. Zhouyi reported that commit is causing crashes when running rcutorture with KASAN enabled: BUG: using smp_processor_id() in preemptible [00000000] code: rcu_torture_rea/100 caller is rcu_preempt_deferred_qs_irqrestore+0x74/0xed0 CPU: 4 PID: 100 Comm: rcu_torture_rea Tainted: G W 5.19.0-rc5-next-20220708-dirty #253 Call Trace: dump_stack_lvl+0xbc/0x108 (unreliable) check_preemption_disabled+0x154/0x160 rcu_preempt_deferred_qs_irqrestore+0x74/0xed0 __rcu_read_unlock+0x290/0x3b0 rcu_torture_read_unlock+0x30/0xb0 rcutorture_one_extend+0x198/0x810 rcu_torture_one_read+0x58c/0xc90 rcu_torture_reader+0x12c/0x360 kthread+0x1e8/0x220 ret_from_kernel_thread+0x5c/0x64 KASAN will generate instrumentation instructions around the WRITE_ONCE(local_paca->irq_soft_mask, mask): 0xc000000000295cb0 <+0>: addis r2,r12,774 0xc000000000295cb4 <+4>: addi r2,r2,16464 0xc000000000295cb8 <+8>: mflr r0 0xc000000000295cbc <+12>: bl 0xc00000000008bb4c <mcount> 0xc000000000295cc0 <+16>: mflr r0 0xc000000000295cc4 <+20>: std r31,-8(r1) 0xc000000000295cc8 <+24>: addi r3,r13,2354 0xc000000000295ccc <+28>: mr r31,r13 0xc000000000295cd0 <+32>: std r0,16(r1) 0xc000000000295cd4 <+36>: stdu r1,-48(r1) 0xc000000000295cd8 <+40>: bl 0xc000000000609b98 <__asan_store1+8> 0xc000000000295cdc <+44>: nop 0xc000000000295ce0 <+48>: li r9,1 0xc000000000295ce4 <+52>: stb r9,2354(r31) 0xc000000000295ce8 <+56>: addi r1,r1,48 0xc000000000295cec <+60>: ld r0,16(r1) 0xc000000000295cf0 <+64>: ld r31,-8(r1) 0xc000000000295cf4 <+68>: mtlr r0 If there is a context switch before "stb r9,2354(r31)", r31 may not equal to r13, in such case, irq soft mask will not work. The usual solution of marking the code ineligible for instrumentation forces the code out-of-line, which we would prefer to avoid. Christophe proposed a partial revert, but Nick raised some concerns with that. So for now do a full revert. Reported-by: Zhouyi Zhou <zhouzhouyi@gmail.com> [mpe: Construct change log based on Zhouyi's original report] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220831131052.42250-1-mpe@ellerman.id.au
2022-09-02dt-bindings: clock: renesas,rzg2l: Document RZ/Five SoCLad Prabhakar1-1/+1
The CPG block on the RZ/Five SoC is almost identical to one found on the RZ/G2UL SoC. "renesas,r9a07g043-cpg" compatible string will be used on the RZ/Five SoC so to make this clear, update the comment to include RZ/Five SoC. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20220726174525.620-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2022-09-02wifi: move from strlcpy with unused retval to strscpyWolfram Sang22-36/+36
Follow the advice of the below link and prefer 'strscpy' in this subsystem. Conversion is 1:1 because the return value is not used. Generated by a coccinelle script. Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/ Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220830201457.7984-2-wsa+renesas@sang-engineering.com
2022-09-02wifi: wilc1000: remove redundant ret variableJinpeng Cui1-3/+2
Return value from cfg80211_rx_mgmt() directly instead of taking this in another redundant variable. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Jinpeng Cui <cui.jinpeng2@zte.com.cn> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220830105505.287564-1-cui.jinpeng2@zte.com.cn
2022-09-02wifi: rtw88: add missing destroy_workqueue() on error path in rtw_core_init()Yang Yingliang1-2/+6
Add the missing destroy_workqueue() before return from rtw_core_init() in error path. Fixes: fe101716c7c9 ("rtw88: replace tx tasklet with work queue") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220826023817.3908255-1-yangyingliang@huawei.com
2022-09-02arm64: dts: renesas: Add V3H2 Condor-I board supportKuninori Morimoto2-0/+16
This patch adds r8a77980A V3H2 (= r8a77980 ES2) Condor-I board basic support. Signed-off-by: Andrey Dolnikov <andrey.dolnikov@cogentembedded.com> Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com> Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87y1v64nko.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2022-09-02arm64: dts: renesas: Add r8a77980a.dtsiKuninori Morimoto1-0/+11
This patch adds r8a77980A V3H2 (= r8a77980 ES2) basic SoC support. It is using r8a77980 (= V3H) setting as-is for now. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87zgfm4nkw.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2022-09-02arm64: dts: renesas: Add condor-common.dtsiKuninori Morimoto2-539/+549
We have V3H Condor board, and will have V3H2 Condor-I board. This patch adds condor-common.dtsi to share the common settings between these boards. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/871qsy625m.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2022-09-02arm64: dts: renesas: Drop clock-names property from RPC nodeLad Prabhakar7-7/+0
With 'unevaluatedProperties' support implemented, there are a number of warnings when running dtbs_check: arch/arm64/boot/dts/renesas/r8a774b1-hihope-rzg2n-rev2-ex-idk-1110wr.dtb: spi@ee200000: Unevaluated properties are not allowed ('clock-names' was unexpected) From schema: Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml The main problem is that the DT bindings do not allow clock-names. So just drop the clock-names properties from the SoC DTSI files. Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20220829215128.5983-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2022-09-02wifi: wfx: prevent underflow in wfx_send_pds()Dan Carpenter1-1/+1
This does a "chunk_len - 4" subtraction later when it calls: ret = wfx_hif_configuration(wdev, buf + 4, chunk_len - 4); so check for "chunk_len" is less than 4. Fixes: dcbecb497908 ("staging: wfx: allow new PDS format") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Jérôme Pouiller <jerome.pouiller@silabs.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/Yv8eX7Xv2ubUOvW7@kili
2022-09-02wifi: rtl8xxxu: tighten bounds checking in rtl8xxxu_read_efuse()Dan Carpenter1-7/+7
There some bounds checking to ensure that "map_addr" is not out of bounds before the start of the loop. But the checking needs to be done as we iterate through the loop because "map_addr" gets larger as we iterate. Fixes: 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Jes Sorensen <Jes.Sorensen@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/Yv8eGLdBslLAk3Ct@kili
2022-09-02x86/defconfig: Enable CONFIG_DEBUG_WX=yIngo Molnar2-0/+2
7 years after it got introduced it's time to make this the default, at least in the x86 defconfigs. Signed-off-by: Ingo Molnar <mingo@kernel.org>
2022-09-02x86/defconfig: Refresh the defconfigsIngo Molnar2-4/+5
Just go through a 'make savedefconfig' cycle to pick up fresh Kconfig details, no change in settings, just reordering of some entries. ( This makes followup changes generated via 'make savedefconfig' contain less noise. ) Signed-off-by: Ingo Molnar <mingo@kernel.org>
2022-09-02wifi: rtw89: declare to support beamformee above bandwidth 80MHzPing-Ke Shih1-0/+2
Declare this to tell AP we can support beamformee over bandwidth 160M, and then yield better performance in field. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220826061011.9037-3-pkshih@realtek.com
2022-09-02wifi: rtw89: correct polling address of address CAMPing-Ke Shih1-1/+1
Writing address to kick hardware to initialize address CAM, and then poll ready bit to determine completed. Old wrong code poll wrong register address, so it can lead error and fail to bring up interface. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220826061011.9037-2-pkshih@realtek.com
2022-09-02wifi: rtw89: no HTC field if TX rate might fallback to legacyPing-Ke Shih4-12/+14
Packets containing HTC field with legacy rate could be dropped by AP. If TX rate of report is lower than MCS2, hardware might fall back rate to legacy. Therefore, add a checking rule to avoid HTC field in this situation. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220826061011.9037-1-pkshih@realtek.com
2022-09-02wifi: rtw89: pci: correct TX resource checking in low power modePing-Ke Shih1-0/+2
Number of TX resource must be minimum of TX_BD and TX_WD. Only considering TX_BD could drop TX packets pulled from mac80211 if TX_WD is unavailable. Fixes: 52edbb9fb78a ("rtw89: ps: access TX/RX rings via another registers in low power mode") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220824063312.15784-2-pkshih@realtek.com
2022-09-02wifi: rtw89: pci: fix interrupt stuck after leaving low power modePing-Ke Shih1-1/+2
We turn off interrupt in ISR, and re-enable interrupt in threadfn or napi_poll according to the mode it stays. If we are turning off interrupt, rtwpci->running flag is unset and interrupt handler stop processing even if it was called, so disallow to re-enable interrupt in this situation. Or, wifi chip doesn't trigger interrupt events anymore because interrupt status (ISR) isn't clear by interrupt handler anymore. Fixes: c83dcd0508e2 ("rtw89: pci: add a separate interrupt handler for low power mode") Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220824063312.15784-1-pkshih@realtek.com
2022-09-02wifi: rtw89: enlarge the CFO tracking boundaryCheng-Chieh Hsieh1-1/+1
The calibration value of XTAL offset may be too large in some wifi modules, that the CFO tracking mechanism under the existing tracking boundary can not adjust the CFO to the tolerable range. So we enlarge it. Signed-off-by: Cheng-Chieh Hsieh <cj.hsieh@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220824061425.13764-1-pkshih@realtek.com
2022-09-02wifi: rtw89: pci: correct suspend/resume setting for variant chipsChin-Yen Lee1-8/+23
We find that suspend/resume tests cause 8852CE lost, because some pci registers are changed for 8852CE. So, correct them accordingly. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220819064811.37700-6-pkshih@realtek.com
2022-09-02wifi: rtw89: pci: enable CLK_REQ, ASPM, L1 and L1ss for 8852cChin-Yen Lee2-24/+79
8852CE controls CLKREQ, ASPM L1, L1ss via wifi registers instead, so change them accordingly. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220819064811.37700-5-pkshih@realtek.com
2022-09-02wifi: rtw89: pci: fix PCI PHY auto adaption by using software restoreChia-Yuan Li3-2/+110
There is chance that PCI PHY auto adaption fail. When first time boot up, software restore the right adaption value and close PHY auto adaption mechanism. Signed-off-by: Chia-Yuan Li <leo.li@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220819064811.37700-4-pkshih@realtek.com
2022-09-02wifi: rtw89: 8852c: set TBTT shift configurationChia-Yuan Li2-0/+23
It is found that 8852ce loses some beacon after enabling deep ps mode. We set TBTT shift to wake up firmware early to open RF/BB for receiving beacon in time. Signed-off-by: Chia-Yuan Li <leo.li@realtek.com> Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220819064811.37700-3-pkshih@realtek.com
2022-09-02wifi: rtw89: add retry to change power_mode stateChin-Yen Lee2-6/+18
When starting to send heavy traffic in low power mode, driver will call multiple tx wake notify to wake firmware within a short time. In this situation, firmware may miss power mode change request from driver and leads to status error. So we change driver to call power_mode_change at most three times to make sure firmware could get the request. Signed-off-by: Chin-Yen Lee <timlee@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220819064811.37700-2-pkshih@realtek.com
2022-09-02wifi: rtw89: correct BA CAM allocationPing-Ke Shih4-20/+73
BA CAM entries are global resource of hardware, so move the bitmap and instances to rtw89_cam_info, and then use link list from rtw89_sta to these instances. To check the allocation, add ba_cam to debugfs: map: mac_id: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 addr_cam: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bssid_cam: 01 00 00 00 00 00 00 00 sec_cam: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ba_cam: 03 00 00 00 00 00 00 00 VIF [0] 94:08:53:8e:ef:21 bssid_cam_idx=0 addr_cam_idx=0 -> bssid_cam_idx=0 sec_cam_bitmap=00 00 00 00 00 00 00 00 STA [0] 38:78:62:8b:cb:c6 addr_cam_idx=0 -> bssid_cam_idx=0 sec_cam_bitmap=00 00 00 00 00 00 00 00 ba_cam tid[6]=0, tid[1]=1 Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220816013247.6243-4-pkshih@realtek.com
2022-09-02wifi: rtw89: 8852c: initialize and correct BA CAM contentPing-Ke Shih6-1/+77
The bacam_v1 must do additional initialization, and H2C content of BA CAM is also different. So, correct them accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220816013247.6243-3-pkshih@realtek.com
2022-09-02wifi: rtw89: 8852c: declare correct BA CAM numberPing-Ke Shih5-13/+21
8852A has 2 BA CAM entries, but 8852C has 8 entries. Add a field to discriminate their differences. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220816013247.6243-2-pkshih@realtek.com
2022-09-02wifi: rtw89: 8852c: update TX power tables to R49Zong-Zhe Yang1-3279/+6546
TX power byrate: doesn't change TX power limit: configure values for KCC and UK refine a bit configuration vales TX power limit_ru: configure values for KCC and UK refine a bit configuration values change 6GHz to follow indoor setting configure 6GHz values for ETSI TX power shape: change with TX power limit/limit_ru Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220812093116.56791-4-pkshih@realtek.com
2022-09-02wifi: rtw89: 8852c: update RF radio A/B parameters to R49Ping-Ke Shih1-2538/+16505
Update 8852c radio A/B parameters from internal HALRF_027_00_071 R49. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220812093116.56791-3-pkshih@realtek.com
2022-09-02wifi: rtw89: TX power limit/limit_ru consider negativeZong-Zhe Yang2-16/+20
Some chips' RF TX power limit/limit_ru tables start to configure some negative values. Fix the setting logic to prevent negative values from polluting fields of others. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220812093116.56791-2-pkshih@realtek.com
2022-09-02Merge branch 'linus' into x86/mm, to refresh the branchIngo Molnar13155-261441/+1352927
This branch is ~14k commits behind upstream, and has an old merge base from early into the merge window, refresh it to v6.0-rc3+fixes before queueing up new commits. Signed-off-by: Ingo Molnar <mingo@kernel.org>
2022-09-02rtw89: coex: Update Wi-Fi driver/firmware TDMA cycle report for RTL8852cChing-Te Ku2-8/+113
Because RTL8852c firmware handshake use different structure definition with RTL8852a, so it's necessary to update a version for RTL8852c. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220725023509.43114-10-pkshih@realtek.com
2022-09-02rtw89: coex: Add v1 Wi-Fi SCC coexistence policyChing-Te Ku2-2/+112
Because the later firmware had patched some new feature, it can control the Wi-Fi/BT slots more efficiently. This patch enhance it for better Wi-Fi SCC mode performance. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220725023509.43114-9-pkshih@realtek.com
2022-09-02rtw89: coex: Move _set_policy to chip_opsChing-Te Ku5-1/+386
Due to the difference of Wi-Fi firmware supported feature, RTL8852C need to defined more policy to enable the features. (Ex: DBCC, Wi-Fi multi-role, TDMA instant and so on) Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220725023509.43114-8-pkshih@realtek.com
2022-09-02rtw89: coex: update WL role info v1 for RTL8852C branch usingChing-Te Ku4-74/+458
The H2C format and support feature are different. The newer Wi-Fi firmware and driver branch need to handshake more information like DBCC or P2P connection info. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220725023509.43114-7-pkshih@realtek.com
2022-09-02rtw89: coex: Add v1 version TDMA format and parametersChing-Te Ku2-17/+75
RTL8852C use a later version Wi-Fi firmware, there are some parameters need to be defined. These new parameter can avoid some unexpected TDMA mode while Wi-Fi enter/leave lps. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220725023509.43114-6-pkshih@realtek.com
2022-09-02rtw89: coex: Define BT B1 slot lengthChing-Te Ku1-65/+66
It is for setting up BT slot max length at BT auto slot mechanism. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220725023509.43114-5-pkshih@realtek.com
2022-09-02rtw89: coex: Add logic to parsing rtl8852c firmware type ctrl reportChing-Te Ku3-27/+98
Add a part of logic to parse type of ctrl report from firmware, and remove Bluetooth packet counter count from driver, the feature was moved to firmware at rtl8852c. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220725023509.43114-4-pkshih@realtek.com
2022-09-02rtw89: coex: Move Wi-Fi firmware coexistence matching version to chipChing-Te Ku4-37/+66
To configure the different chips with different coexistence version, separated the firmware feature version matching number is necessary. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220725023509.43114-3-pkshih@realtek.com
2022-09-02rtw89: coex: update radio state for RTL8852A/RTL8852CChing-Te Ku2-9/+19
Update scoreboard setting to let Bluetooth know Wi-Fi power save state. Signed-off-by: Ching-Te Ku <ku920601@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220725023509.43114-2-pkshih@realtek.com
2022-09-02rtw89: 8852c: adjust mactxen delay of mac/phy interfaceChia-Yuan Li2-1/+7
mac_txen time is to inform TMAC tx after rx air end. Modify 8852c value to meet TB SIFS time. Signed-off-by: Chia-Yuan Li <leo.li@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220704023453.19935-7-pkshih@realtek.com
2022-09-02rtw89: 8852c: modify PCIE prebkf timeChia-Yuan Li1-1/+11
Prebkf time is to inform generating tx command if remaining backoff time less than this setting value. It might cause SER if generating tx command early in security mode. Signed-off-by: Chia-Yuan Li <leo.li@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220704023453.19935-6-pkshih@realtek.com
2022-09-02rtw89: ser: leave lps with mutexZong-Zhe Yang1-0/+3
Calling rtw89_leave_lps() should hold rtwdev::mutex. So, fix it. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220704023453.19935-5-pkshih@realtek.com
2022-09-02rtw89: declare support HE HTC alwaysPing-Ke Shih1-2/+1
Correct ability of HE HTC that both STA and AP mode can support. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220704023453.19935-4-pkshih@realtek.com
2022-09-02rtw89: 8852a: update HW setting on BBZong-Zhe Yang2-2/+4
Sometimes, BB might encounter RX problem on OFDM 6M. It's not quite easy to happen, but if it happens, we will keep getting stuck on RX. And, since we cannot properly receive layer 2 ACK, it also casues TX problem, e.g. constantly retrying TX. Eventually, after some time, we would get disconnected due to abnormal behavior. Update break setting and phy status parsing time to make BB get out of stuck state faster. Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220704023453.19935-3-pkshih@realtek.com
2022-09-02rtw89: 8852c: disable dma during mac initPo-Hao Huang1-0/+2
Without this patch, our hardware attempts to perform dma while device cpu restarts, and leads to iommu page faults caused by invalid requests. Some platforms show warning messages as below: rtw89_8852ce 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000a address=0x10000000004 flags=0x0030] Signed-off-by: Po-Hao Huang <phhuang@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20220704023453.19935-2-pkshih@realtek.com
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.