The function sdm845_slim_snd_hw_params() calls the functuion
snd_soc_dai_set_channel_map() but does not check its return
value. A proper implementation can be found in msm_snd_hw_params().
Add error handling for snd_soc_dai_set_channel_map(). If the
function fails and it is not a unsupported error, return the
error code immediately.
Fixes: 5caf64c633 ("ASoC: qcom: sdm845: add support to DB845c and Lenovo Yoga")
Cc: stable@vger.kernel.org # v5.6
Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://patch.msgid.link/20250519075739.1458-1-vulab@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Add an useful info when failed to get irq/wakeirq due to -EPROBE_DEFER.
Before:
[ 15.737361] i2c 2-0050: deferred probe pending: (reason unknown)
After:
[ 15.816295] i2c 2-0050: deferred probe pending: tcpci: can't get irq
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
Reviewed-by: Carlos Song <carlos.song@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Currently, it is possible that LPM is enabled while calling the set_lpm()
callback.
The current code performs a SET FEATURES command to disable DIPM if
policy < ATA_LPM_MED_POWER_WITH_DIPM, this means that it will currently
disable DIPM for policies:
ATA_LPM_UNKNOWN, ATA_LPM_MAX_POWER, ATA_LPM_MED_POWER
(but not for policy ATA_LPM_MED_POWER_WITH_DIPM).
The code called after calling the set_lpm() callback will later perform
a SET FEATURES command to enable DIPM, if
policy >= ATA_LPM_MED_POWER_WITH_DIPM.
As we can see DIPM will not be disabled before calling set_lpm() if the LPM
policy is: ATA_LPM_MED_POWER_WITH_DIPM, ATA_LPM_MIN_POWER_WITH_PARTIAL,
or ATA_LPM_MIN_POWER.
Make sure that we always disable DIPM before calling the set_lpm()
callback. This is because the set_lpm() callback is the function (for AHCI)
that sets the proper bits in PxSCTL.IPM, reflecting the support of the HBA.
PxSCTL.IPM controls the LPM states that the device is allowed to enter.
If the device tries to enter a state disabled by PxSCTL.IPM, the host will
NAK the transition.
If we do not disable DIPM before modifying PxSCTL.IPM, it is possible that
DIPM will try (and will be allowed to) enter a LPM state that the HBA does
not support (since we have not yet written PxSCTL.IPM, the HBA wasn't able
to NAK the transition).
While at it, remove the guard of host support for DIPM around the disabling
of DIPM. While it makes sense to take host support for DIPM into account
when enabling DIPM, it makes zero sense to take host support into account
when disabling DIPM.
If the host does not support DIPM, that is an even bigger reason why DIPM
should be disabled on the device side.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Rename the no_dipm variable to host_has_dipm, by inverting the
expression, and and also having a clearer name.
No functional change.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Rename the hipm and dipm variables to have a clearer name.
Also fold in the usage of no_dipm, as that is required in order to give
the dipm variable a more descriptive name.
No functional change.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
link->lpm_policy is initialized to ATA_LPM_UNKNOWN in ata_eh_reset().
ata_eh_set_lpm() is then only called if
link->lpm_policy != ap->target_lpm_policy (after reset)
and then only if link->lpm_policy > ATA_LPM_MAX_POWER (before
revalidation).
This means that ata_eh_set_lpm() is currently never called with
policy == ATA_LPM_UNKNOWN.
Add a WARN_ON_ONCE so that it is more obvious from reading the code that
this function is never called with policy == ATA_LPM_UNKNOWN.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
The comments describing which LPM policies that has DIPM enabled predates
the introduction of the LPM policies ATA_LPM_MIN_POWER_WITH_PARTIAL and
ATA_LPM_MED_POWER_WITH_DIPM. Update the DIPM comments to reflect reality.
Also remove the sentence that claims that "Order device and link
configurations such that the host always allows DIPM requests."
This comment is written before 24e0e61db3 ("ata: libata: disallow
dev-initiated LPM transitions to unsupported states").
Even though the set_lpm() call is done before enabling DIPM, the host will
not always allow DIPM requests. For all LPM polcies where DIPM is enabled,
only DIPM requests to LPM states that are supported by the HBA will be
allowed.
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Due to a problem in the iTBT DP-in adapter's firmware the sink on a TBT
link may get disconnected inadvertently if the SINK_COUNT_ESI and the
DP_LINK_SERVICE_IRQ_VECTOR_ESI0 registers are read in a single AUX
transaction. Work around the issue by reading these registers in
separate transactions.
The issue affects MTL+ platforms and will be fixed in the DP-in adapter
firmware, however releasing that firmware fix may take some time and is
not guaranteed to be available for all systems. Based on this apply the
workaround on affected platforms.
See HSD #13013007775.
v2: Cc'ing Mika Westerberg.
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13760
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14147
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250519133417.1469181-1-imre.deak@intel.com
Rename intel_update_active_dpll to intel_dpll_update_active in an
effort to have function names which are exported to start with
filenames they are exported from.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-15-suraj.kandpal@intel.com
Rename intel_compute_dpll to intel_dpll_compute in an
effort to make sure all function names that are exported have
the filename at start.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-14-suraj.kandpal@intel.com
Rename intel_<release/reserve>_dpll to
intel_dpll_<release/reserve> in an effort to keep names of
exported functions start with the filename.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-13-suraj.kandpal@intel.com
Rename intel_reference_dpll_crtc to intel_dpll_crtc_get in an
effort to have all the exported functions have the name start
with file name.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-12-suraj.kandpal@intel.com
Rename intel_unreference_dpll_crtc to intel_dpll_crtc_put
in an effort to keep names of exported functions start with the filename.
--v2
-Make the new name more sensible [Jani]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-11-suraj.kandpal@intel.com
Rename intel_[enable/disable]_dpll to intel_dpll_[enable/disable]
in an effort to make sure all functions that are exported
start with the filename.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-10-suraj.kandpal@intel.com
Rename crtc_get_shared_dpll to take into the individual PLL framework
which came in at DISPLAY_VER >= 14.
Also having shared dpll stuff also in intel_dpll.c is just confusing.
--v2
-Change naming to dpll_global to keep consistency with rest of the
naming
--v3
-Just use intel_dpll [Jani]
--v4
-Modify commit message [Jani]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-9-suraj.kandpal@intel.com
Rename functions to move away from using shared dpll in the dpll
framework as much as possible since dpll may not always be shared.
--v2
-Use intel_dpll_global instead of global_dpll [Jani]
--v3
-Just use intel_dpll [Jani]
--v4
-Drop the global from comments [Jani]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-8-suraj.kandpal@intel.com
Rename intel_shared_dpll to intel_dpll to represent both
shared and individual dplls. Since from MTL each PHY has it's
own PLL making the shared PLL naming a little outdated. In an
effort to make this framework accepting of future changes this
needs to be done.
--v2
-Use intel_dpll_global to make sure names start with the filename
[Jani/Ville]
-Explain the need of this rename [Jani]
--v3
-Just keep it intel_dpll [Jani]
--v4
-Fix comment [Jani]
-Use just num_dpll and dplls [Jani]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-7-suraj.kandpal@intel.com
Rename intel_shared_dpll_funcs to intel_dpll_funcs
since it needs to represent both shared and individual
dplls.
--v2
-Change intel_global_dpll to intel_dpll_global to be more
in line with the naming standard where the name should
start with the file name [Jani]
--v3
-Drop shared and global altogether [Jani]
--v4
-Keep declarations sorted [Jani]
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-6-suraj.kandpal@intel.com
Rename the macro for_each_shared_dpll to for_each_dpll since
this loop will not necessarily be used for only shared
dpll in future.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-5-suraj.kandpal@intel.com
Rename intel_shared_dpll_state to just intel_dpll_state since it may
not necessarily store share dpll state info specially since
DISPLAY_VER >= 14 PLL's are not shared.
Also change the name of variables which may have been associated as
a shared_dpll.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-4-suraj.kandpal@intel.com
Rename intel_dpll_funcs to intel_dpll_global_funcs so that later
on intel_shared_dpll_funcs can be renamed to intel_dpll_funcs.
This is done to move away from the shared naming convention since
starting MTL dpll's are not shared among PHYs.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-3-suraj.kandpal@intel.com
Rename intel_dpll to intel_dpll_global so that intel_shared_dpll
can be renamed to intel_dpll in an effort to move away from the shared
naming convention.
Also intel_dpll according to it's comment tracks global dpll rather
than individual hence making more sense this gets changed.
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250515071801.2221120-2-suraj.kandpal@intel.com
pci/iomap.c still contains warnings about those functions not behaving
in a managed manner if pcim_enable_device() was called. Since all hybrid
behavior that users could know about has been removed by now, those
explicit warnings are no longer necessary.
Remove the hybrid-devres usage warnings from the kernel-doc.
Signed-off-by: Philipp Stanner <phasta@kernel.org>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Link: https://lore.kernel.org/r/20250519112959.25487-8-phasta@kernel.org
When the demangling of the hybrid devres functions within PCI was
implemented, it was necessary to implement several PCI functions a
second time to avoid cyclic calls, since the hybrid functions in pci.c
call the managed functions in devres.c, which in turn can be directly
used outside of PCI and needed request infrastructure, too.
Therefore, __pcim_request_region_range(), __pci_release_region_range()
and wrappers around them were implemented.
The hybrid nature has recently been removed from all functions in pci.c.
Therefore, the functions in devres.c can now directly use their
counterparts in pci.c without causing a call-cycle.
Remove __pcim_request_region_range(), __pcim_request_region_range() and
the wrappers. Use the corresponding request functions from pci.c in
devres.c
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Link: https://lore.kernel.org/r/20250519112959.25487-7-phasta@kernel.org
pcim_request_region_exclusive(), the only user in PCI devres that needed
exclusive region requests, has been removed.
All features related to exclusive requests can, therefore, be removed,
too. Remove them.
Signed-off-by: Philipp Stanner <phasta@kernel.org>
[kwilczynski: commit log]
Signed-off-by: Krzysztof Wilczyński <kwilczynski@kernel.org>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20250519112959.25487-6-phasta@kernel.org
Add a MAINTAINERS entry as part of integration of the EcoNet MIPS platform.
Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Add DTS files in support of EcoNet platform, including SmartFiber XP8421-B,
a low cost commercially available board based on EN751221.
Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Add "smartfiber" vendor prefix for manufactorer of EcoNet based boards.
Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Add platform support for EcoNet MIPS SoCs.
Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Document the top-level device tree binding for EcoNet MIPS-based SoCs.
Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
bcm963xx_nvram_checksum() was using crc32_le_combine() to update a CRC
with four zero bytes. However, this is about 5x slower than just
CRC'ing four zero bytes in the normal way. Just do that instead.
(We could instead make crc32_le_combine() faster on short lengths. But
all its callers do just fine without it, so I'd like to just remove it.)
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Rename the sdhci nodename from "sdhci@" to "mmc@" to align with
linux common mmc-controller binding.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
When CONFIG_HOTPLUG_PARALLEL is enabled, the code executing before
cpuhp_ap_sync_alive() is executed in parallel, while after it is
serialized. The functions set_cpu_sibling_map() and set_cpu_core_map()
were not designed to be executed in parallel, so by moving the
cpuhp_ap_sync_alive() before cpuhp_ap_sync_alive(), we then ensure
they will be called serialized.
The measurement done on EyeQ5 did not show any relevant boot time
increase after applying this patch.
Fixes: 76c43eb507 ("MIPS: SMP: Implement parallel CPU bring up for EyeQ")
Reported-by: Huacai Chen <chenhuacai@kernel.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
High-level copy_to_user_* APIs already redact SA secret fields when
redaction is enabled, but the state teardown path still freed aead,
aalg and ealg structs with plain kfree(), which does not clear memory
before deallocation. This can leave SA keys and other confidential
data in memory, risking exposure via post-free vulnerabilities.
Since this path is outside the packet fast path, the cost of zeroization
is acceptable and prevents any residual key material. This patch
replaces those kfree() calls unconditionally with kfree_sensitive(),
which zeroizes the entire buffer before freeing.
Signed-off-by: Zilin Guan <zilin@seu.edu.cn>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Currently, all SCMI devices with performance domains attempt to register
a cpufreq driver, even if their performance domains aren't used to
control the CPUs. The cpufreq framework only supports registering a
single driver, so only the first device will succeed. And if that device
isn't used for the CPUs, then cpufreq will scale the wrong domains.
To avoid this, return early from scmi_cpufreq_probe() if the probing
SCMI device isn't referenced by the CPU device phandles.
This keeps the existing assumption that all CPUs are controlled by a
single SCMI device.
Signed-off-by: Mike Tipton <quic_mdtipton@quicinc.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Tested-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Introduce a Rust-based implementation of the cpufreq-dt driver, covering
most of the functionality provided by the existing C version. Some
features, such as retrieving platform data from `cpufreq-dt-platdev.c`,
are still pending.
The driver has been tested with QEMU, and frequency scaling works as
expected.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Extend the OPP abstractions to include support for interacting with the
cpufreq core, including the ability to retrieve frequency tables from
OPP table.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Extend the cpufreq abstractions to support driver registration from
Rust.
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Introduce initial Rust abstractions for the cpufreq core. This includes
basic representations for cpufreq flags, relation types, and the cpufreq
table.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
According to the ISL28022 datasheet, bit15 of the current register is
representing -32768. Fix the calculation to properly handle this bit,
ensuring correct measurements for negative values.
Signed-off-by: Yikai Tsai <yikai.tsai.wiwynn@gmail.com>
Link: https://lore.kernel.org/r/20250519084055.3787-2-yikai.tsai.wiwynn@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Introduce Rust abstractions for the OPP core configuration options,
enabling safe access to various configurable aspects of the OPP
framework.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
