| Age | Commit message (Collapse) | Author |
|---|
|
This renames TRBLIMITR_EL1 register fields per auto-gen tools format
without causing any functional change in the TRBE driver.
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: kvmarm@lists.linux.dev
Cc: coresight@lists.linaro.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20230614065949.146187-2-anshuman.khandual@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
|
|
Some of the regulators on the MT6358/MT6366 PMICs have just one linear
voltage range. These are the bulk regulators and VSRAM_* LDOs. Currently
they are modeled with one linear range, but also have their minimum,
maximum, and step voltage described.
Convert them to the linear voltage helpers. These helpers are a bit
simpler, and we can also drop the linear range definitions. Also reflow
the touched lines now that they are shorter.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230609083009.2822259-7-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
In the MT6358 regulator driver, each regulator is described by a
|struct regulator_desc| wrapped by a |struct mt6358_regulator_info|.
The latter was tied to the regulator device using the config's
driver_data field, which meant that the variables could not be constant.
Since each regulator device has a pointer to its regulator_desc, and
mt6358_regulator_info wraps that, the driver could use container_of()
to retrieve it instead.
Switch to using container_of(), drop tha driver_data setting, and
const-ify all the regulator descriptions.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230609083009.2822259-6-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The *_SSHUB regulators are actually alternate configuration interfaces
for their non *_SSHUB counterparts. They are not separate regulator
outputs. These registers are intended for the companion processor to
use to configure the power rails while the main processor is sleeping.
They are not intended for the main operating system to use.
Since they are not real outputs they shouldn't be modeled separately.
Remove them. Luckily no device tree actually uses them.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Link: https://lore.kernel.org/r/20230609083009.2822259-5-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The VCN33_BT and VCN33_WIFI regulators are actually the same regulator,
having the same voltage setting and output pin. There are simply two
enable bits that are ORed together to enable the regulator.
Having two regulators representing the same output pin is misleading
from a design matching standpoint, and also error-prone in driver
implementations. If consumers try to set different voltages on either
regulator, the one set later would override the one set before. There
are ways around this, such as chaining them together and having the
downstream one act as a switch. But given there's only one output pin,
such a workaround doesn't match reality.
Remove the VCN33_WIFI regulator. During the probe phase, have the driver
sync the enable status of VCN33_WIFI to VCN33_BT. Also drop the suffix
so that the regulator name matches the pin name in the datasheet.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230609083009.2822259-4-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Ensure that we don't return a spurious cache hit for unreadable registers
(eg, with the flat cache which doesn't understand sparseness) by checking
for readability before we do a cache lookup.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230613-b4-regmap-check-readability-before-cache-v1-1-b144c0b01ed9@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Ensure that a read only value in the register cache does not result in a
write during regcache_sync().
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230613-regmap-kunit-read-write-v1-3-2db337c52827@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Validate that attempts to read from write only registers fail and don't
somehow trigger spurious hardware accesses.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230613-regmap-kunit-read-write-v1-2-2db337c52827@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We should have error checking that verifies that writes to write only
registers are suppressed, verify that this happens as it should.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230613-regmap-kunit-read-write-v1-1-2db337c52827@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
mlxsw will need to keep track of certain devices that are not related to
any of its front panel ports. This includes IPIP netdevices. To be able to
query the list of supported IPIP types, router->ipip_ops_arr needs to be
initialized.
To that end, move the IPIP initialization up (and finalization
correspondingly down).
Signed-off-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
RIF configuration contains a number of parameters that cannot be changed
after the RIF is created. For the IPIP loopbacks, this is currently worked
around by creating a new RIF with the desired configuration changes
applied, and updating next hops to the new RIF, and then destroying the old
RIF. This operation will be useful as a reusable atom, so extract a helper
to that effect.
Signed-off-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
This function will be useful later as the driver will need to retroactively
create RIFs for new uppers with addresses.
Add another helper that assumes RCU lock, and restructure the code to
skip the IPv6 branch not through conditioning on the addr_list_empty
variable, but by directly returning the result value. This makes the skip
more obvious than it previously was.
Signed-off-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Right now freeing the object that mlxsw uses to keep track of a RIF is as
simple as calling a kfree. But later on as CRIF abstraction is brought in,
it will involve severing the link between CRIF and its RIF as well. Better
to have the logic encapsulated in a helper.
Since a helper is being introduced, make it a full-fledged destructor and
have it validate that the objects tracked at the RIF have been released.
Signed-off-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
To abstract away deduction of RIF from the corresponding next hop group
info (NHGI), mlxsw currently uses a macro. In its current form, that macro
is impossible to extend to more general computation. Therefore introduce a
helper, mlxsw_sp_nhgi_rif(), and use it throughout. This will make it
possible to change the deduction path easily later on.
Signed-off-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
In order to abstract away deduction of netdevice from the corresponding
next hop, introduce a helper, mlxsw_sp_nexthop_dev(), and use it
throughout. This will make it possible to change the deduction path easily
later on.
Signed-off-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The previous patch added a helper to access a netdevice given a RIF. Using
this helper in mlxsw_sp_rif_create() is unreasonable: the netdevice was
given in RIF creation parameters. Just take it there.
Signed-off-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
In order to abstract away deduction of netdevice from the corresponding
RIF, introduce a helper, mlxsw_sp_rif_dev(), and use it throughout. This
will make it possible to change the deduction path easily later on.
Signed-off-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Currently, joining a LAG very simply means that the LAG RIF should be
joined by the subport representing untagged traffic. If the RIF does not
exist, it does not have to be created: if the user wants there to be RIF
for the LAG device, they are supposed to add an IP address, and they are
supposed to do it after tha LAG becomes mlxsw upper.
We can also assume that the LAG has no uppers, otherwise the enslavement is
not allowed.
In the future, these ordering dependencies should be removed. That means
that joining LAG will be more complex operation, possibly involving a lazy
RIF creation, and possibly joining / lazily creating RIFs for VLAN uppers
of the LAG. It will be handy to have a dedicated function that handles all
this. The new function mlxsw_sp_router_port_join_lag() is that.
Signed-off-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Split out of mlxsw_sp_port_vlan_router_join() the part that checks for RIF
and dispatches to __mlxsw_sp_port_vlan_router_join(), leaving it as wrapper
that just manages the router lock.
The new function, mlxsw_sp_port_vlan_router_join_existing(), will be useful
as an atom in later patches.
Signed-off-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
When we restart the firmware, we shouldn't keep old debug data
around. Since the "allocate" function might not reallocate the
memory blocks (they're only freed when we unbind from the device),
clear the memory to have a clean slate for debug data.
This is a bit more complex since we normally don't enter into
the allocation function, but duplicating the logic didn't seem
enticing either, so rework the allocation a bit to always go
into the individual block allocation, but there clear if it's
already allocated, rather than allocating again.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230613155501.30b82881cfbf.I39520aff8ac95ee64d39dc5913525a1efd7995fa@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The iwl_pcie_alloc_fw_monitor_block() function has an argument
that's only ever hard-coded to 11, remove it and hard-code the
value into the function itself with a comment.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230613155501.737c153e8259.Ibe6250ca812cfa2f00ac47e5e0d1595c6b9b4875@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When we restart the firmware, we shouldn't keep old debug data
around. Since the "allocate" function might not reallocate the
memory block (it's only freed when we unbind from the device),
clear the memory to have a clean slate for debug data.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230613155501.73c32255a132.Ibd7101dcd285b01ee879fddfbf52c30d49ced3c0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Given the existing code in iwl_dbg_tlv_update_drams(), the
following can happen and cause firmware asserts, and even
the device to become unusable:
* We set the magic so the firmware will use the data;
* we try to fill multiple allocation IDs, with at least
one successful, but - crucially - one failing and thus
not touching the data;
* we don't clear the data since there was one success.
This doesn't seem like much of a problem just yet, however,
what happens now is that the allocation ID(s) that failed
are not initialized.
There are two additional things to know:
* we never free these allocations across FW restart or
interface down/up etc., in fact we never free them until
the driver is unbound from the device (e.g. unloaded)
* the firmware uses the DRAM info structure for real debug
data when it has used it completely
Given that, and the fact that we never initialize the data
on restart, we can be unlucky and end up with an allocation
that looks for the most part valid (valid ID, valid number
of buffers, etc.) but has bad sizes - causing the firmware
to throw an assert we can never recover from.
Fixing the code to have the entire buffers cleared (which
we should do so old debug data isn't sticking around) is a
bit more complex, so as a first step make the actual code
that fills the information more robust by clearing the
structure first, and filling the magic values only if it
actually succeeded for one, rather than doing it the other
way around.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230613155501.87cf5528f4bc.I26ac907a4162297808b33467fc7f5d8177474a34@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Newest firmware don't advertise the version of ADD_STA because it has
been replaced by another command. There are old firmware images
that also don't advertise it. Replace all the checks with a new
inline, and in that check for either MLD API or the ADD_STA
command version.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230613155501.4b9305510223.I7cc143d87186f8441e9b8435cc550b76734c7eef@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The firmware only supports a single IGTK, and due to some
changes it really doesn't like to have multiple programmed
in later versions. Since only newer firmware cannot remove
a key that isn't present any more, adjust only the MLD API
code to keep track of the previous IGTK and remove it when
a new one is added.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230613155501.3fde1ef09270.I2e12a3b0bba4325c07dc8fcce39b711f158bd621@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Account for IWL_SEC_WEP_KEY_OFFSET when needed while verifying
key_len size in iwl_mvm_sec_key_add().
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230613155501.f193b7493a93.I6948ba625b9318924b96a5e22602ac75d2bd0125@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Add support for C0 version of MAC and RF for BZ and GL devices.
Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230613155501.90ad8aab8a03.I86d1675095f0e4f5286d9b7c2b00a0220f524472@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Add support for Extra EHT LTF defined in 9.4.2.313
EHT Capabilities element.
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230613155501.de019d7cc174.I806f0f6042b89274192701a60b4f7900822db666@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The iwl_mvm_get_lmac_id() function is currently
defined as a static inline function under fw/api
and receives mvm's fw pointer. It will need the
ability to access other mvm struct members for
future capabilities such as debug. Move the function
out of the fw/api and into mvm proper as a regular
function and have it receive the pointer to mvm.
Signed-off-by: Ariel Malamud <ariel.malamud@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230613155501.507b2f9f64eb.I0ec91310e1911c33faf396b5e17bcb11a164f6ea@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Add prints of ETSI and China bits.
Check if need to mask the China bit (when the firmware doesn't
support it) in a separate flow, so it will be easier to follow
the conditions. Add a separate message for the command version.
Signed-off-by: Alon Giladi <alon.giladi@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230613155501.4ee455ec1ee8.I6f1a4b7dfa5cfd9b4f4a4b5bb5567849e629ae96@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Initialize the phy_data.rx_vec for both version-3 and above
where it is 4-byte data size and below version which has
data size of 2-byte.
The data will be sent uninitialized in called function if
notification version is less than three.
Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230613155501.a6bb856f04bc.I9a15075f3dad61dcabdcd1ed0d34cf3e8ec5453f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Currently, we only need to support BTM rejection.
However, in the future we might want to support other BTM modes.
Rephrase its naming.
Signed-off-by: Haim Dreyfuss <haim.dreyfuss@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230613155501.ad20f10668d1.Icbb3fbae50b2302b97225b183dd336b02a4f37ee@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Support new firmware that can validate the validate bits in
sniffer mode, and advertise that fact and the result of the
checks in the U-SIG radiotap field.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230613155501.c20480aa1171.Icc0d077dae01d662ccb948823e196aa9c5c87976@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
In AP mode, ERP slot changes weren't properly indicated to the FW.
Fix it.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230612184434.ef242b8ce245.I01eddee9d3a9a3208499c223eb8e70fe6663f42c@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Add a link configuration parameter to FTM responder start instead
of using the default link.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230612184434.b367f9bd19b8.I158c71998f39a6c15463ff5ae30129da8ad46d22@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The firmware needs to know the esr_transtition_timeout to time the
transition between EMLSR and single radio with the AP.
Add the EMLSR support bit to the wiphy extended capabilities so that
it'll be sent in our association request frame. There are some
limitations in the implementation so we cannot use zero
padding/transition delay; fill the correct values.
Also, feed the medium_synchronization delay to the firmware.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230612184434.09fa06820d03.Ie9a9fd37d4948f8c5dd91161de254184b1a093c0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Add information about ppag_china_bit_support capability.
Signed-off-by: Alon Giladi <alon.giladi@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230612184434.4655922aff4d.Ie934027940bd53d05124222aa6a8a8b7021952c4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Some versions of the new hardware don't have a functional
version of the new offload method, but still have stricter
checks on the MAC header (MH) length in the offload assist
word. Include that even if checksumming isn't offloaded to
hardware.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230612184434.bba713f7495a.Idbc8e3ce313b51af4060326e0191bd338b3163a2@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The program counter address is read from the TLV and
PC address is printed in debug messages.
Read the value at PC address and print the value
instead of the register address.
Fixes: 5e31b3df86ec ("wifi: iwlwifi: dbg: print pc register data once fw dump occurred")
Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230612184434.e5a5f18f1b2c.Ib6117a4e7f66a075913241cc81477c0059953d5d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The hardware, depending on which part fails or times out,
returns 0xA5A5A5A. or 0x5A5A5A5. with the lowest 4 bits
encoding some further reason/status. However, mostly we
don't really need to care about the exact reasons, so
unify the checks for this to avoid hardcoding those magic
values all over the driver.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230612184434.3e2959741a38.I1c297a53787b87e4e2b8f296c041921338573f4d@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Use flags field from struct ieee80211_tx_info in order to get
LDPC/STBC support. The rate parameter, used originally, is 16
bits only and does not have details of LDPC/STBC support.
Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230612184434.5a8856739b11.I6af4a55b22ed856f484ba77f87723dceec4904f2@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Start supporting API version 79 for AX devices.
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230612184434.c54013425732.I4df33c68ee3ef6b6a330f1cbef7f5bbf4f54b269@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Add support for the MCC update response version 8.
Versions 5-6 are already covered by the existing
flags conversion, and 7 isn't used.
The capabilities field in iwl_mcc_update_resp is 32 bits
wide now, and the flags moved, so some more changes are
needed.
While at it, convert the flags to bool (to avoid having
to deal with BIT(16) specially etc.) and use the
struct_size() macro for the memory allocation.
Signed-off-by: Abhishek Naik <abhishek.naik@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230612184434.71a7070aecd7.Ibddcb9fbfa74895f742c0ac20968720691c94853@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
When checking if the initiator is associated to the responder,
iterate over all active links.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230612184434.1737f26e9cf7.I8f140ca55094da1d73c387fc036394fb2c148c85@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
sta_init function can fail and if it returns an error then
driver should not send the request to fw to add a station.
Fixes: 69aef848052b ("wifi: iwlwifi: mvm: refactor iwl_mvm_add_sta(), iwl_mvm_rm_sta()")
Signed-off-by: Mukesh Sisodiya <mukesh.sisodiya@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230612184434.1ecd293539e8.I5ec6aab387bb2fe743a7402581beaeb9c801d31f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
All of the station elements are really elements for the link. Create
them from the correct callback and return the link specific information
rather than always using the default link.
Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230612184434.a8e0c40d325e.I374d9433c3b8694667e1ce550d65f6f1f0d23c05@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The call to mmc_request_done() can schedule, so it must not be called
from irq context. Wake the irq thread if it needs to be called, and let
its existing logic do its work.
Fixes the following kernel bug, which appears when running an RT patched
kernel on the AmLogic Meson AXG A113X SoC:
[ 11.111407] BUG: scheduling while atomic: kworker/0:1H/75/0x00010001
[ 11.111438] Modules linked in:
[ 11.111451] CPU: 0 PID: 75 Comm: kworker/0:1H Not tainted 6.4.0-rc3-rt2-rtx-00081-gfd07f41ed6b4-dirty #1
[ 11.111461] Hardware name: RTX AXG A113X Linux Platform Board (DT)
[ 11.111469] Workqueue: kblockd blk_mq_run_work_fn
[ 11.111492] Call trace:
[ 11.111497] dump_backtrace+0xac/0xe8
[ 11.111510] show_stack+0x18/0x28
[ 11.111518] dump_stack_lvl+0x48/0x60
[ 11.111530] dump_stack+0x18/0x24
[ 11.111537] __schedule_bug+0x4c/0x68
[ 11.111548] __schedule+0x80/0x574
[ 11.111558] schedule_loop+0x2c/0x50
[ 11.111567] schedule_rtlock+0x14/0x20
[ 11.111576] rtlock_slowlock_locked+0x468/0x730
[ 11.111587] rt_spin_lock+0x40/0x64
[ 11.111596] __wake_up_common_lock+0x5c/0xc4
[ 11.111610] __wake_up+0x18/0x24
[ 11.111620] mmc_blk_mq_req_done+0x68/0x138
[ 11.111633] mmc_request_done+0x104/0x118
[ 11.111644] meson_mmc_request_done+0x38/0x48
[ 11.111654] meson_mmc_irq+0x128/0x1f0
[ 11.111663] __handle_irq_event_percpu+0x70/0x114
[ 11.111674] handle_irq_event_percpu+0x18/0x4c
[ 11.111683] handle_irq_event+0x80/0xb8
[ 11.111691] handle_fasteoi_irq+0xa4/0x120
[ 11.111704] handle_irq_desc+0x20/0x38
[ 11.111712] generic_handle_domain_irq+0x1c/0x28
[ 11.111721] gic_handle_irq+0x8c/0xa8
[ 11.111735] call_on_irq_stack+0x24/0x4c
[ 11.111746] do_interrupt_handler+0x88/0x94
[ 11.111757] el1_interrupt+0x34/0x64
[ 11.111769] el1h_64_irq_handler+0x18/0x24
[ 11.111779] el1h_64_irq+0x64/0x68
[ 11.111786] __add_wait_queue+0x0/0x4c
[ 11.111795] mmc_blk_rw_wait+0x84/0x118
[ 11.111804] mmc_blk_mq_issue_rq+0x5c4/0x654
[ 11.111814] mmc_mq_queue_rq+0x194/0x214
[ 11.111822] blk_mq_dispatch_rq_list+0x3ac/0x528
[ 11.111834] __blk_mq_sched_dispatch_requests+0x340/0x4d0
[ 11.111847] blk_mq_sched_dispatch_requests+0x38/0x70
[ 11.111858] blk_mq_run_work_fn+0x3c/0x70
[ 11.111865] process_one_work+0x17c/0x1f0
[ 11.111876] worker_thread+0x1d4/0x26c
[ 11.111885] kthread+0xe4/0xf4
[ 11.111894] ret_from_fork+0x10/0x20
Fixes: 51c5d8447bd7 ("MMC: meson: initial support for GX platforms")
Cc: stable@vger.kernel.org
Signed-off-by: Martin Hundebøll <martin@geanix.com>
Link: https://lore.kernel.org/r/20230607082713.517157-1-martin@geanix.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
|
|
And instead use the vif getter functions, as a preparation for
supporting disabled/dormant links.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230608163202.8966bd5ce7c8.Ia73e3555aaf4ddf9917bced8d413fad08cc28f1b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
There's quite a bit of code accessing sband iftype data
(HE, HE 6 GHz, EHT) and we always need to remember to use
the ieee80211_vif_type_p2p() helper. Add new helpers to
directly get it from the sband/vif rather than having to
call ieee80211_vif_type_p2p().
Convert most code with the following spatch:
@@
expression vif, sband;
@@
-ieee80211_get_he_iftype_cap(sband, ieee80211_vif_type_p2p(vif))
+ieee80211_get_he_iftype_cap_vif(sband, vif)
@@
expression vif, sband;
@@
-ieee80211_get_eht_iftype_cap(sband, ieee80211_vif_type_p2p(vif))
+ieee80211_get_eht_iftype_cap_vif(sband, vif)
@@
expression vif, sband;
@@
-ieee80211_get_he_6ghz_capa(sband, ieee80211_vif_type_p2p(vif))
+ieee80211_get_he_6ghz_capa_vif(sband, vif)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Link: https://lore.kernel.org/r/20230604120651.db099f49e764.Ie892966c49e22c7b7ee1073bc684f142debfdc84@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
This code was added (long back) by commit 009acd196fc8 ("PM / OPP:
Support updating performance state of device's power domain") and at
that time the `opp->pstate` field was used to store the performance
state required by a device's OPP.
Over time that changed and the `->pstate` field is now used only for
genpd devices and consumer devices access that via the required-opps
instead.
Because of all these changes, _opp_table_kref_release() now drops the
constraint only when the genpd's OPP table gets freed and not the
device's. Which is definitely not what we wanted. And dropping the
constraint doesn't have much meaning as the genpd itself is going away.
Moreover, if we want to drop constraints here, then just dropping the
performance constraint alone isn't sufficient as there are other
resource constraints like clk, regulator, etc. too, which must be
handled.
Probably the right thing to do here is to leave this decision to the
consumers, which can call `dev_pm_opp_set_rate(dev, 0)` or similar APIs
to drop all constraints properly. Which many of the consumers already
do.
Remove the special code, which is broken anyway.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
|
