Instead of relying on RTNL, fq_pie_dump() can use READ_ONCE()
annotations, paired with WRITE_ONCE() ones in fq_pie_change().
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Instead of relying on RTNL, fq_codel_dump() can use READ_ONCE()
annotations, paired with WRITE_ONCE() ones in fq_codel_change().
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Instead of relying on RTNL, __fifo_dump() can use READ_ONCE()
annotations, paired with WRITE_ONCE() ones in __fifo_init().
Also add missing READ_ONCE(sh->limit) in bfifo_enqueue(),
pfifo_enqueue() and pfifo_tail_enqueue().
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Instead of relying on RTNL, ets_dump() can use READ_ONCE()
annotations, paired with WRITE_ONCE() ones in ets_change().
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Instead of relying on RTNL, codel_dump() can use READ_ONCE()
annotations.
There is no etf_change() yet, this patch imply aligns
this qdisc with others.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Instead of relying on RTNL, codel_dump() can use READ_ONCE()
annotations, paired with WRITE_ONCE() ones in codel_change().
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Instead of relying on RTNL, choke_dump() can use READ_ONCE()
annotations, paired with WRITE_ONCE() ones in choke_change().
v2: added a WRITE_ONCE(p->Scell_log, Scell_log)
per Simon feedback in V1
Removed the READ_ONCE(q->limit) in choke_enqueue()
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Instead of relying on RTNL, cbs_dump() can use READ_ONCE()
annotations, paired with WRITE_ONCE() ones in cbs_change().
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Instead of relying on RTNL, cake_dump() can use READ_ONCE()
annotations, paired with WRITE_ONCE() ones in cake_change().
v2: addressed Simon feedback in V1: https://lore.kernel.org/netdev/20240417083549.GA3846178@kernel.org/
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Toke Høiland-Jørgensen <toke@toke.dk>
Reviewed-by: Simon Horman <horms@kernel.org>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Instead of relying on RTNL, fq_dump() can use READ_ONCE()
annotations, paired with WRITE_ONCE() in fq_change()
v2: Addressed Simon feedback in V1: https://lore.kernel.org/netdev/20240416181915.GT2320920@kernel.org/
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
driver needs queue msix vectors and one misc irq vector,
but only queue vectors need irq affinity.
when num_online_cpus is less than chip max msix vectors,
driver will acquire (num_online_cpus + 1) vecotrs, and
call pci_alloc_irq_vectors_affinity functions with affinity
params without setting pre_vectors or post_vectors, it will
cause return error code -ENOSPC.
Misc irq vector is vector 0, driver need to set affinity params
.pre_vectors = 1.
Fixes: 3f70318611 ("net: libwx: Add irq flow functions")
Signed-off-by: Duanqiang Wen <duanqiangwen@net-swift.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Although the purpose of dummy seq client is a direct pass-through,
it's sometimes helpful for debugging if it can convert to a certain
UMP MIDI version. This patch adds an option to specify the UMP event
conversion. As default, it skips the conversion and does
passthrough, while user can pass ump=1 or ump=2 to enforce the
conversion to UMP MIDI1 or MIDI2 format.
Message-ID: <20240419101105.15571-1-tiwai@suse.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The conversion from MIDI2 to MIDI1 UMP messages had a leftover
artifact (superfluous bit shift), and this resulted in the bogus type
check, leading to empty outputs. Let's fix it.
Fixes: e9e02819a9 ("ALSA: seq: Automatic conversion of UMP events")
Cc: <stable@vger.kernel.org>
Link: https://github.com/alsa-project/alsa-utils/issues/262
Message-ID: <20240419100442.14806-1-tiwai@suse.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The Haier Boyue G42 with ALC269VC cannot detect the MIC of headset,
the line out and internal speaker until
ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS quirk applied.
Signed-off-by: Ai Chao <aichao@kylinos.cn>
Cc: <stable@vger.kernel.org>
Message-ID: <20240419082159.476879-1-aichao@kylinos.cn>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Most IRQ-related code is duplicated in the driver. Switch to the new
implementation and remove unused members.
While the change is non-trivial, from functional perspective status quo
is achieved.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20240419084857.2719593-3-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The existing code can be both improved and simplified. To make this
change easier to manage, first add new implementation and then remove
deadcode in a separate patch.
Simplification achieved with:
- reduce the amount of resources requested by the driver i.e.: IPC and
CLDMA request_irq() merged into one
- reduce the number of DSP ops from 2 to 1:
irq_handler/thread() vs dsp_interrupt()
- drop ambiguity around CLDMA interrupt, let skl.c handle that
explicitly as it is the only user
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20240419084857.2719593-2-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
During non-STA management Tx, when source address is same as one of the
link addresses and even when userspace requested Tx on a specific link,
the link ID is not set in the TX control information. Now if the MLD
address is also the same as that of the link address, then mac80211
fills link as "unspecified", since it looks like MLD TX.
This is unexpected, however, since non-STA TX must specify which link
to use. In hwsim, this will (after warnings) result in dropping such
frames as well.
Use and set the link id if the link bss is matching the address and
requested channel.
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
Link: https://msgid.link/20240410052705.169865-1-quic_adisi@quicinc.com
Link: https://lore.kernel.org/r/0496fb7e-53cc-476f-8052-985d82fd8d01@quicinc.com
[reword commit message, should spell out hwsim etc.]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently whenever link AP beacon is assigned, sdata->u.ap.active flag is
set and whenever it is brought down, the flag is reset. However, with MLO,
all the links of the same MLD would use the same sdata. Hence there is no
need to set/reset for each link up/down. Also, resetting it when only one
of the links went down is not desirable.
Add changes to set the active flag only when first link is assigned
beacon. Similarly, add changes to reset that flag only when last link is
brought down.
Signed-off-by: Aditya Kumar Singh <quic_adisi@quicinc.com>
Link: https://msgid.link/20240409094017.3165560-1-quic_adisi@quicinc.com
[remove unnecessary check before constant true assignment]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fixed regulators are not part of any MMIO bus, so they should not have
unit addresses. This fixes dtc W=1 warnings:
hi6220-hikey.dts:85.26-92.4: Warning (unit_address_vs_reg): /regulator@0: node has a unit name, but no reg or ranges property
hi6220-hikey.dts:94.27-102.4: Warning (unit_address_vs_reg): /regulator@1: node has a unit name, but no reg or ranges property
hi6220-hikey.dts:104.26-113.4: Warning (unit_address_vs_reg): /regulator@2: node has a unit name, but no reg or ranges property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
adv7533 ports should have "reg" propeties, as reported by dtc W=1
warnings:
hi6220-hikey.dts:516.11-520.6: Warning (unit_address_vs_reg): /soc/i2c@f7102000/adv7533@39/ports/port@0: node has a unit name, but no reg or ranges property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
Non-MMIO devices, which are BTW not really part of the SoC, should not
be within simple-bus, as reported by dtc W=1 warning:
hip07.dtsi:1486.20-1493.5: Warning (unit_address_vs_reg): /soc/ethernet@4: node has a unit name, but no reg or ranges property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
The return value of regulatory_hint_indoor() is always 0 for
success, and the return value of regulatory_hint_found_beacon()
is always ignored. Make them both have void return.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Use the Return: annotation instead of spelling out "Returns" in
the documentation, for both sta_info_flush()/__sta_info_flush().
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In the past, the noresume function was used by the GEM code to ensure
wakelocks were held and bump its usage. This is no longer the case
and this function was totally unused until it started to be used again
by display with commit 77e619a82f ("drm/i915/display: convert inner
wakeref get towards get_if_in_use")
However, on the display code, most of the callers are using the
raw wakeref, rather then the wakelock version. What caused a
major regression caught by CI.
Another option to this patch is to go with the original plan and
use the get_if_in_use variant in the display code, what is enough
to fulfil our needs. Then, an extra patch to delete the unused
_noresume variant.
v2: Keep grabbing wakelock but only assert for wakeref. (Imre)
Cc: Imre Deak <imre.deak@intel.com>
Cc: Francois Dugast <francois.dugast@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: 77e619a82f ("drm/i915/display: convert inner wakeref get towards get_if_in_use")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10875
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240418223756.68427-1-rodrigo.vivi@intel.com
In the unlikely event that link_use_channel fails while activating a
link, mac80211 would go into a bad state. Unfortunately, we cannot
completely avoid failures from drivers in this case.
However, what we can do is to just continue internally anyway and assume
the driver is going to trigger a recovery flow from its side. Doing that
means that we at least have a consistent state in mac80211 allowing such
a recovery flow to succeed.
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240418115219.1129e89f4b55.I6299678353e50e88b55c99b0bce15c64b52c2804@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's no need for a label/goto here, the only thing is
that drv_assign_vif_chanctx() must succeed to set 'conf'
and add the new context to the list, the remaining code
is (and must be) the same regardless.
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240418115219.a94852030d33.I9d647178ab25636372ed79e5312c68a06e0bf60c@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When searching for a chanctx for re-use, it's later adjusted and
assigned. It may also be that another one is already assigned to
the link in question, so unassign can also happen. In short, the
driver is called multiple times. During these callbacks, it may
thus change active links (on another interface), which then can
in turn cause the found chanctx (that's going to be reused) to
get removed and freed.
To avoid this, temporarily assign it to the reserved chanctx and
track the link that wants to use it in the reserved_links list.
This causes the ieee80211_chanctx_refcount() to be increased by
one during these operations, thus avoiding the free.
Reviewed-by: Miriam Rachel Korenblit <miriam.rachel.korenblit@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240418115219.94ea84c8ee1e.I0b247dbc0cd937ae6367bc0fc7e8d156b5d5f9b1@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Running "scripts/kernel-doc -Wall -Werror -none include/net/cfg80211.h"
produces many warnings of the form "warning: No description found for
return value of <function>", so make sure all of them have a Return:
clause. In some instances also add a Context: clause.
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Link: https://msgid.link/20240417-cfg80211-kdoc-v1-1-d54cb7143417@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If a custom regulatory is being used, use the 6GHz regulatory for
testing 6GHz channels.
Signed-off-by: Chaitanya Tata <Chaitanya.Tk17@gmail.com>
Link: https://msgid.link/20240417074022.423432-1-Chaitanya.Tk17@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If the RSSI of a link is low enough, don't use it for EMLSR.
If EMLSR is already active and the RSSI of one of the links gets low,
exit EMLSR by deactivating that link.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240416134215.73263c000263.Ieb2b18855a2719b5e18ad2fa8a3e855ca4e23938@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We can't be an EMLSR while suspended with wowlan. De-activate the
secondary link upon wowlan entring.
Set the blocking reason upon suspension and clear it upon resume.
Signed-off-by: Yedidya Benshimol <yedidya.ben.shimol@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240416134215.6ea884b3f095.I84233cb1c79ba538defafb8ddb983c47f04a400a@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In EMLSR we need to track the RSSI of both links, and exit if the RSSI of
one of the links got too low.
For that request the FW to send statistics every 5 seconds when in EMLSR.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240416134215.6e19d596d77f.Ica2a75a031b1bced0dc2e18c5d365b5eb0d3ec07@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211 invokes the driver callback drv_can_activate_links() from
ieee80211_set_active_links to verify it can activate the desired link
combination.
However, ieee80211_set_active_links is called with more than one link in
2 cases:
- After driver's link selection decided to enter EMLSR
- From debugfs, for testing purposes.
For both cases there is no need to recompute all the considerations
determining whether to activate EMLSR.
Instead, only check if the vif is not blocked for EMLSR.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240416134215.202cf5a9ef2c.I65e4698b730a8652ad8d1c01420aabb41a1d04fd@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Address scenarios where repeated entry and exit from EMLSR occur, such as
encountering missed beacons on a specific link,
while still discovering that link during a scan.
To mitigate this, introduce the EMLSR prevention mechanism, which operates
as follows:
- On each exit from EMLSR event, record the timestamp and the exit
reason.
- If two consecutive exits happen for the same reason within a
400-second window, enforce a 300-second EMLSR prevention.
- If a third exit for the same reason occurs within 400 seconds from the
second exit, enforce an extended EMLSR prevention of 600 seconds.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240416134215.d820ee98b300.I6406db40cf25eabdba602afd783466473b909216@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
It's dangerous to re-initialize works repeatedly, especially
delayed ones that have an associated timer, and even more so
if they're not necessarily canceled inbetween. This can be
the case for these workers here during FW restart scenarios,
so make sure to initialize it only once.
While at it, also ensure it is cancelled correctly.
Fixes: f678061402 ("iwlwifi: mvm: disconnect in case of bad channel switch parameters")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240416134215.ddf8eece5eac.I4164f5c9c444b64a9abbaab14c23858713778e35@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There are reasons for which we need to exit EMLSR, but not to block it
completely, and there are reasons for which we need to block EMLSR.
For both reason types we have the enum iwl_mvm_esr_state, when the
blocking reasons are stored in the `mvmvif::esr_disable_reason` bitmap.
This change introduces the APIs to use in the different cases:
- iwl_mvm_exit_esr - will exit from EMLSR mode.
- iwl_mvm_block_esr - will update the bitmap and exit EMLSR, to
be used for the blocking reasons only.
- iwl_mvm_unblock_esr - will update the bitmap. To be used for the
blocking reasons only.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240416134215.d54142a75876.I552926065521f5f848c37b0bd845494bd7865fb7@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Replaces the current logic with a new algorithm based on the link
grading introduced in a previous patch.
The new selection algorithm will be invoked upon successful scan to ensure
it has the necessary updated data it needs.
This update delegates the selection logic as the primary link
determiner in EMLSR mode, storing it in mvmvif to avoid repeated
calculations, as the result may vary.
Additionally, includes tests for iwl_mvm_valid_link_pair to validate
link pairs for EMLSR.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240416134215.309fb1b3fe44.I5baf0c293c89a5a28bd1a6386bf9ca6d2bf61ab8@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The functions that are link related, so they should be in link.c and
not in mld-mac80211.c. Move them.
Also move the different prototypes to the right place in mvm.h
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240416134215.e7c368256fa0.I6b15805a7c8a75d1814f1a829601daf4d3788731@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currenty iwl_mvm_mld_select_links() doesn't fully check that
EMLSR is allowed before selecting the 2 best links.
Although it will fail in ieee80211_set_active_links(), it is preferred
to avoid the redundent calculations.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240416134215.3578a93feb1a.I1cd91608bb73fbe19b8dfdf90e14ce40b98c3430@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2.4 GHz/LB (low band) link can't be used in an EMLSR links pair when
BT is on. But EMLSR is still allowed for a pair of links which none of
them operates in LB.
In the existing code, EMLSR will always be disabled if one of the
usable links is in LB (and BT is on).
Move this check to the code that verifies a specific pair of links,
and only if one of these links operates on LB - disable EMLSR.
Fixes: 10159a4566 ("wifi: iwlwifi: disable eSR when BT is active")
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240416134215.2841006b5cc4.I45ffd583f593daa950322852ceb9454cbf497e24@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The function iwl_mvm_can_enter_esr() is (among others) calculating
if EMLSR mode is disabled due to BT coex by calling
iwl_mvm_bt_coex_calculate_esr_mode(), then stores the decision in
mvmvif::esr_disable_reason.
But there is no need to calculate this every time iwl_mvm_can_enter_esr
is called. Fix this by calculating it once after authorization,
and in iwl_mvm_can_enter_esr only check mvmvif::esr_disable_reason.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240416134215.a767e243366e.I3b32d36cda23f67dc103a28a9bdccb0039d22574@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
For selecting what link(s) out of the usable ones
to activate, calculate a grade for a given link.
Calculation of a link grade is done as follows:
1. get the estimated throughput according to the RSSI of the link, this
will be the base grade
2. get the channel load from the BSS Load Element, subtracting the load
caused by us. Apply the factor on the grade.
3. puncturing factor: calculate the percentage of the punctured
subchannels (out of the total subchannels). Apply this on the grade.
The link grading will be used by the link selection mechanism in a later
patch.
Also add KUnit tests for it.
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reviewed-by: Johannes Berg <johannes.berg@intel.com>
Link: https://msgid.link/20240416134215.a6799dbd5643.If137ca6dc443606c7d8c99ec1fc38b325003a7c1@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Send AP_TX_POWER_CONSTRAINTS_CMD with no local maximum transmit
power constraint to FW and FW will update the TPE element with
required tx power limits.
Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240416134215.b6af4ecfcfe8.I07e8db349190e0c58c468c18477d8551288ac069@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This will maintain a bitmap of reasons for which we want to avoid
enabling EMLSR.
For now, we have a single reason: BT coexistence, but we will add soon
more reasons. Make it a bitmap to make it easier to manage.
Since we'll impact the parameters that impact the enablement /
disablement of EMLSR from several places, introduce a generic function
that takes into account the current state and execute the decision that
must be taken.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240416134215.94c3590c6f27.I6a190da5025d0523ef483ffac0c64e26675041e6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add support for enable/disable 320 MHz for Japan and South Korea
by reading WBEM (WiFi Bandwidth Enablement per MCC) variable from
UEFI or ACPI and sending it to the FW.
Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240415114847.7946c3befbe1.I453c33f7ea48156ea2a3961f50a9003103fca5a5@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add support for enablement of PPAG for
- VLP for 6 GHz mode in CANADA, USA and ETSI countries.
- LPI for 6 GHz mode in CANADA.
- SP for 6 GHz mode in CANADA, USA and ETSI countries.
Signed-off-by: Anjaneyulu <pagadala.yesu.anjaneyulu@intel.com>
Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Link: https://msgid.link/20240415114847.e1893fe24ea3.Ic84cf576de0883c2184c939bdfad4b110a8a1815@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
