| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
functions
Documentation/filesystems/sysfs.rst mentions that show() should only
use sysfs_emit() or sysfs_emit_at() when formating the value to be
returned to user space. So replace scnprintf() with sysfs_emit().
Signed-off-by: Chelsy Ratnawat <chelsyratnawat2001@gmail.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
Remove the export of tpm_crb_ffa_get_interface_version() as it has no
callers outside tpm_crb_ffa.
Fixes: eb93f0734ef1 ("tpm_crb: ffa_tpm: Implement driver compliant to CRB over FF-A")
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@opinsys.com>
Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
To generate the boot_aggregate log in the IMA subsystem using TPM PCR
values, the TPM driver must be built as built-in and must be probed
before the IMA subsystem is initialized.
However, when the TPM device operates over the FF-A protocol using the
CRB interface, probing fails and returns -EPROBE_DEFER if the
tpm_crb_ffa device — an FF-A device that provides the communication
interface to the tpm_crb driver — has not yet been probed.
This issue occurs because both crb_acpi_driver_init() and
tpm_crb_ffa_driver_init() are registered with device_initcall. As a
result, crb_acpi_driver_init() may be invoked before
tpm_crb_ffa_driver_init(), which is responsible for probing the
tpm_crb_ffa device.
When this happens, IMA fails to detect the TPM device and logs the
following message:
| ima: No TPM chip found, activating TPM-bypass!
Consequently, it cannot generate the boot_aggregate log with the PCR
values provided by the TPM.
To resolve this issue, the tpm_crb_ffa_init() function explicitly
attempts to probe the tpm_crb_ffa by register tpm_crb_ffa driver so that
when tpm_crb_ffa device is created before tpm_crb_ffa_init(), probe the
tpm_crb_ffa device in tpm_crb_ffa_init() to finish probe the TPM device
completely.
This ensures that the TPM device using CRB over FF-A can be successfully
probed, even if crb_acpi_driver_init() is called first.
[ jarkko: reformatted some of the paragraphs because they were going past
the 75 character boundary. ]
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
The Linux IMA (Integrity Measurement Architecture) subsystem used for
secure boot, file integrity, or remote attestation cannot be a loadable
module for few reasons listed below:
o Boot-Time Integrity: IMA’s main role is to measure and appraise files
before they are used. This includes measuring critical system files during
early boot (e.g., init, init scripts, login binaries). If IMA were a
module, it would be loaded too late to cover those.
o TPM Dependency: IMA integrates tightly with the TPM to record
measurements into PCRs. The TPM must be initialized early (ideally before
init_ima()), which aligns with IMA being built-in.
o Security Model: IMA is part of a Trusted Computing Base (TCB). Making it
a module would weaken the security model, as a potentially compromised
system could delay or tamper with its initialization.
IMA must be built-in to ensure it starts measuring from the earliest
possible point in boot which inturn implies TPM must be initialised and
ready to use before IMA.
To enable integration of tpm_event_log with the IMA subsystem, the TPM
drivers (tpm_crb and tpm_crb_ffa) also needs to be built-in. However with
FF-A driver also being initialised at device initcall level, it can lead to
an initialization order issue where:
- crb_acpi_driver_init() may run before tpm_crb_ffa_driver()_init and
ffa_init()
- As a result, probing the TPM device via CRB over FFA is deferred
- ima_init() (called as a late initcall) runs before deferred probe
completes, IMA fails to find the TPM and logs the below error:
| ima: No TPM chip found, activating TPM-bypass!
Eventually it fails to generate boot_aggregate with PCR values.
Because of the above stated dependency, the ffa driver needs to initialised
before tpm_crb_ffa module to ensure IMA finds the TPM successfully when
present.
[ jarkko: reformatted some of the paragraphs because they were going past
the 75 character boundary. ]
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
Enable synchronous send() with TPM_CHIP_FLAG_SYNC, which implies that
->send() already fills the provided buffer with a response, and ->recv()
is not implemented.
Keep using the same pre-allocated buffer to avoid having to allocate
it for each command. We need the buffer to have the header required by
the SVSM protocol and the command contiguous in memory.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
This driver does not support interrupts, and receiving the response is
synchronous with sending the command.
Enable synchronous send() with TPM_CHIP_FLAG_SYNC, which implies that
->send() already fills the provided buffer with a response, and ->recv()
is not implemented.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
Some devices do not support interrupts and provide a single synchronous
operation to send the command and receive the response on the same buffer.
Currently, these types of drivers must use an internal buffer where they
temporarily store the response between .send() and .recv() calls.
Introduce a new flag (TPM_CHIP_FLAG_SYNC) to support synchronous send().
If that flag is set by the driver, tpm_try_transmit() will use the send()
callback to send the command and receive the response on the same buffer
synchronously. In that case send() return the number of bytes of the
response on success, or -errno on failure.
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Suggested-by: Jason Gunthorpe <jgg@ziepe.ca>
Suggested-by: Jarkko Sakkinen <jarkko@kernel.org>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
Add a new `bufsiz` parameter to the `.send` callback in `tpm_class_ops`.
This parameter will allow drivers to differentiate between the actual
command length to send and the total buffer size. Currently `bufsiz` is
not used, but it will be used to implement devices with synchronous send()
to send the command and receive the response on the same buffer.
Also rename the previous parameter `len` to `cmd_len` in the declaration
to make it clear that it contains the length in bytes of the command
stored in the buffer. The semantics don't change and it can be used as
before by drivers. This is an optimization since the drivers could get it
from the header, but let's avoid duplicating code.
While we are here, resolve a checkpatch warning:
WARNING: Unnecessary space before function pointer arguments
#66: FILE: include/linux/tpm.h:90:
+ int (*send) (struct tpm_chip *chip, u8 *buf, size_t bufsiz,
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Suggested-by: Jarkko Sakkinen <jarkko@kernel.org>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
|
Query support for Immediate Readiness irrespective of whether or not the
device supports PM capabilities, as nothing in the PCIe spec suggests that
Immediate Readiness is in any way dependent on PM functionality.
Fixes: d6112f8def51 ("PCI: Add support for Immediate Readiness")
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: David Matlack <dmatlack@google.com>
Cc: Vipin Sharma <vipinsh@google.com>
Cc: Aaron Lewis <aaronlewis@google.com>
Link: https://patch.msgid.link/20250722155926.352248-1-seanjc@google.com
|
|
Convention is to define static data as 'static const ...', not 'static
... const' because of readability, even if the code is functionally
equal.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250707092200.48862-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
The M41T65 device does not support the "Halt Update Bit" (HT) feature
as per its datasheet.
This aligns the driver with the actual hardware capabilities.
Signed-off-by: Alexander Shiyan <eagle.alexander923@gmail.com>
Link: https://lore.kernel.org/r/20250704091144.45389-1-eagle.alexander923@gmail.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
Mux clocks are now described with a customized ccu_mux structure
consisting of ccu_internal and ccu_common substructures, and registered
later with devm_clk_hw_register_mux_parent_data_table(). As this helper
always allocates a new clk_hw structure, it's extremely hard to use mux
clocks as parents statically by clk_hw pointers, since CCF has no
knowledge about the clk_hw structure embedded in ccu_mux.
This scheme already causes issues for clock c910, which takes a mux
clock, c910-i0, as a possible parent. With mainline U-Boot that
reparents c910 to c910-i0 at boottime, c910 is considered as an orphan
by CCF.
This patch refactors handling of mux clocks, embeds a clk_mux structure
in ccu_mux directly. Instead of calling devm_clk_hw_register_mux_*(),
we could register mux clocks on our own without allocating any new
clk_hw pointer, fixing c910 clock's issue.
Fixes: ae81b69fd2b1 ("clk: thead: Add support for T-Head TH1520 AP_SUBSYS clocks")
Signed-off-by: Yao Zi <ziyao@disroot.org>
Signed-off-by: Drew Fustini <fustini@kernel.org>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/drivers
Qualcomm driver updates for v6.17
Perform input validation in the MDT loader, as this was not properly
done in the non-remoteproc cases.
Fix endian issues in the QMI encoder/decoder.
Support reading DDR statistic using the Qualcomm stats driver.
Add support for reading TME firmware details to the socinfo driver.
Document the Kryo 470 CPU, and add SM7150 to the DCC to DeviceTree
bindings.
* tag 'qcom-drivers-for-6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
soc: qcom: mdt_loader: Fix error return values in mdt_header_valid()
dt-bindings: sram: qcom,imem: Add a number of missing compatibles
dt-bindings: arm: cpus: Add Kryo 470 CPUs
dt-bindings: sram: qcom,imem: Add the SM7150 compatible
dt-bindings: soc: qcom: aoss-qmp: Add the SM7150 compatible
dt-bindings: soc: qcom,dcc: Add the SM7150 compatible
soc: qcom: socinfo: Add support to retrieve TME build details
soc: qcom: fix endianness for QMI header
soc: qcom: QMI encoding/decoding for big endian
dt-bindings: soc: qcom: add qcom,qcs615-imem compatible
soc: qcom: qcom_stats: Add QMP support for syncing ddr stats
soc: qcom: qcom_stats: Add support to read DDR statistic
soc: qcom: mdt_loader: Actually use the e_phoff
soc: qcom: mdt_loader: Rename mdt_phdr_valid()
soc: qcom: mdt_loader: Ensure we don't read past the ELF header
Link: https://lore.kernel.org/r/20250715021454.14516-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl into soc/drivers
Memory controller drivers for v6.17
1. Several cleanups: Use dev_fwnode() in OMAP GPMX, convert
arm,pl172.txt DT bindings to DT schema, use
syscon_regmap_lookup_by_phandle_args() wrapper, correct kerneldoc.
2. Mediatek MT8186 SMI: Extend hardware bandwidth limits to fix VENC
hardware during stress testing.
3. Broadcom brcmstb_memc: Add additional fallback compatible and
simplify device driver matching. The change comes from Broadcom
SoC maintainer (Florian Fainelli), thus its ABI impact is
acknowledged.
* tag 'memory-controller-drv-6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl:
dt-bindings: memory: renesas,rzg3e-xspi: Document RZ/V2H(P) and RZ/V2N support
memory: brcmstb_memc: Simplify compatible matching
dt-bindings: memory-controller: Define fallback compatible
memory: omap-gpmx: Use dev_fwnode()
memory: mtk-smi: Add ostd setting for mt8186
dt-bindings: memory-controllers: convert arm,pl172.txt to yaml format
memory: stm32_omm: Use syscon_regmap_lookup_by_phandle_args
memory: emif: Add missing kerneldoc for lpmode
Link: https://lore.kernel.org/r/20250715095315.59299-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into soc/drivers
i.MX drivers changes for 6.17:
- A couple of MAINTAINERS updates
- A new bus driver for i.MX AIPSTZ bridge and a follow-up fix from
Laurentiu Mihalcea
* tag 'imx-drivers-6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
bus: imx-aipstz: allow creating pdevs for child buses
MAINTAINERS: Update i.MX entry
bus: add driver for IMX AIPSTZ bridge
MAINTAINERS: add NXP S32G RTC driver
Link: https://lore.kernel.org/r/20250713055441.221235-1-shawnguo2@yeah.net
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/drivers
memory: tegra: Updates for v6.17-rc1
Enable support for the memory and external memory controllers found on
Tegra264.
* tag 'tegra-for-6.17-memory' of https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
memory: tegra: Add Tegra264 MC and EMC support
dt-bindings: memory: tegra: Add Tegra264 support
Link: https://lore.kernel.org/r/20250711220943.2389322-4-thierry.reding@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/drivers
firmware: tegra: Updates for v6.17-rc1
Add Tegra264 support for the BPMP, fix some dependency issues and clean
up some code using new OF helpers.
* tag 'tegra-for-6.17-firmware' of https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
firmware: tegra: bpmp: Fix build failure for tegra264-only config
firmware: tegra: bpmp: Use of_reserved_mem_region_to_resource() for "memory-region"
firmware: tegra: bpmp: Add support on Tegra264
firmware: tegra: Fix IVC dependency problems
Link: https://lore.kernel.org/r/20250711220943.2389322-2-thierry.reding@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Another utterly pointless aspect of the xgene-msi driver is that
it is built around CPU hotplug. Which is quite amusing since this
is one of the few arm64 platforms that, by construction, cannot
do CPU hotplug in a supported way (no EL3, no PSCI, no luck).
Drop the CPU hotplug nonsense and just setup the IRQs and handlers
in a less overdesigned way, grouping things more logically in the
process.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20250708173404.1278635-13-maz@kernel.org
|
|
Now that we have made the dependency between the PCI driver and
the MSI driver explicit, there is no need to use subsys_initcall()
as a probing hook, and we can rely on builtin_platform_driver()
instead.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20250708173404.1278635-12-maz@kernel.org
|
|
Since changing the affinity of an MSI really is about changing
the target address and that it isn't possible to mask an individual
MSI, it is completely possible for an interrupt to race with itself,
usually resulting in a lost interrupt.
Paper over the design blunder by informing the core code of this
sad state of affairs.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20250708173404.1278635-11-maz@kernel.org
|
|
Plugging a device that doesn't use managed affinity on an XGene-1
machine results in messages such as:
genirq: irq_chip PCI-MSIX-0000:01:00.0 did not update eff. affinity mask of irq 39
As it turns out, the driver was never updated to populate the effective
affinity on irq_set_affinity() call, and the core code is prickly about
that.
But upon further investigation, it appears that the driver keeps repainting
the hwirq field of the irq_data structure as a way to track the affinity
of the MSI, something that is very much frowned upon as it breaks the
fundamentals of an IRQ domain (an array indexed by hwirq).
Fixing this results more or less in a rewrite of the driver:
- Define how a hwirq and a CPU affinity map onto the MSI termination
registers
- Allocate a single entry in the bitmap per MSI instead of *8*
- Correctly track CPU affinity
- Fix the documentation so that it actually means something (to me)
- Use standard bitmap iterators
- and plenty of other cleanups
With this, the driver behaves correctly on my vintage Mustang board.
Signed-off-by: Marc Zyngier <maz@kernel.org>
[lpieralisi: replaced open coded GENMASK(6, 4) with MSInRx_HWIRQ_MASK]
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20250708173404.1278635-10-maz@kernel.org
|
|
The xgene-msi driver uses an odd construct in the form of an
intermediate tracking structure, evidently designed to deal with
multiple instances of the MSI widget. However, the existing HW
only has one set, and it is obvious that there won't be new HW
coming down that particular line.
Simplify the driver by using a bit of pointer arithmetic instead,
directly tracking the interrupt and avoiding extra memory allocation.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20250708173404.1278635-9-maz@kernel.org
|
|
Since the MSI driver is probed as a platform device, there is no
reason to not use device-managed allocations. That's including
the top-level bookkeeping structure, which is better dynamically
allocated than being static.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20250708173404.1278635-8-maz@kernel.org
|
|
The xgene_msi structure remembers both the of_node of the device
and the number of CPUs. All of which are perfectly useless.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20250708173404.1278635-7-maz@kernel.org
|
|
The way the per-CPU interrupts are dealt with in the XGene MSI
driver isn't great:
- the affinity is set after the interrupt is enabled
- nothing prevents userspace from moving the interrupt around
- the affinity setting code pointlessly allocates memory
- the driver checks for conditions that cannot possibly happen
Address all of this in one go, resulting in slightly simpler setup
code.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20250708173404.1278635-6-maz@kernel.org
|
|
XGENE_PCIE_IP_VER_UNKN is only refered to when probing for the
original XGene PCIe implementation, and get immediately overridden
if the device has the "apm,xgene-pcie" compatible string.
Given that the only way to get there is by finding this very string in
the DT, it is obvious that we will always overwrite the version with
XGENE_PCIE_IP_VER_1.
Drop the whole thing.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20250708173404.1278635-5-maz@kernel.org
|
|
pci-xgene.c only gets compiled if CONFIG_PCI_XGENE is selected.
It is therefore pointless to check for CONFIG_PCI_XGENE inside
the driver.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20250708173404.1278635-4-maz@kernel.org
|
|
As a preparatory work to make the XGene MSI driver probe less of
a sorry hack, make the PCI driver check for the availability of
the MSI parent domain, and defer the probing otherwise.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20250708173404.1278635-3-maz@kernel.org
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/defconfig
arm64: tegra: Default configuration updates for v6.17-rc1
Enable the HSP and BPMP via the configuration instead of selecting them,
which can lead to problems. Also enable support for Tegra241, which was
never done after support for it was added, and Tegra264.
* tag 'tegra-for-6.17-arm64-defconfig' of https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
arm64: defconfig: Enable Tegra241 and Tegra264
arm64: defconfig: Enable Tegra HSP and BPMP
Link: https://lore.kernel.org/r/20250711220943.2389322-8-thierry.reding@gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The compiler generates initialization instructions,
which consume additional CPU cycles. the
sysc_clockdomain_init should assign a value
to 'error' before it is read.so the var don't need init
to 0.
Signed-off-by: Li Jun <lijun01@kylinos.cn>
Link: https://lore.kernel.org/r/20250604081712.119523-1-lijun01@kylinos.cn
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
If devicetree describes power supplies related to a PCI device, we
unnecessarily created a pwrctrl device even if CONFIG_PCI_PWRCTL was not
enabled.
We only need pci_pwrctrl_create_device() when CONFIG_PCI_PWRCTRL is
enabled. Compile it out when CONFIG_PCI_PWRCTRL is not enabled.
When pci_pwrctrl_create_device() creates and returns a pwrctrl device,
pci_scan_device() doesn't enumerate the PCI device. It assumes the pwrctrl
core will rescan the bus after turning on the power. However, if
CONFIG_PCI_PWRCTRL is not enabled, the rescan never happens, which breaks
PCI enumeration on any system that describes power supplies in devicetree
but does not use pwrctrl.
Jim reported that some brcmstb platforms break this way. The brcmstb
driver is still broken if CONFIG_PCI_PWRCTRL is enabled, but this commit at
least allows brcmstb to work when it's NOT enabled.
Fixes: 957f40d039a9 ("PCI/pwrctrl: Move creation of pwrctrl devices to pci_scan_device()")
Reported-by: Jim Quinlan <james.quinlan@broadcom.com>
Link: https://lore.kernel.org/r/CA+-6iNwgaByXEYD3j=-+H_PKAxXRU78svPMRHDKKci8AGXAUPg@mail.gmail.com
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
[bhelgaas: commit log]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Lukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org # v6.15
Link: https://patch.msgid.link/20250701064731.52901-1-manivannan.sadhasivam@linaro.org
|
|
The maximum number of keycodes got bumped to 256 a very long time ago,
but the default keymaps were never adjusted to match. This is causing
the kernel to interpret keycodes above 127 as U+0000 if the shipped
generated keymap is used.
Fix this by mapping all keycodes above 127 to K_HOLE so the kernel
ignores them.
The contents of this patche were generated by rerunning `loadkeys
--mktable --unicode` and only including the changes to map keycodes
above 127 to K_HOLE.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Myrrh Periwinkle <myrrhperiwinkle@qtmlabs.xyz>
Cc: stable <stable@kernel.org>
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20250702-vt-misc-unicode-fixes-v1-2-c27e143cc2eb@qtmlabs.xyz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
We don't process Unicode characters if the virtual terminal is in raw
mode, so there's no reason why we shouldn't do the same for K_OFF
(especially since people would expect K_OFF to actually turn off all VT
key processing).
Fixes: 9fc3de9c8356 ("vt: Add virtual console keyboard mode OFF")
Signed-off-by: Myrrh Periwinkle <myrrhperiwinkle@qtmlabs.xyz>
Cc: stable <stable@kernel.org>
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
Link: https://lore.kernel.org/r/20250702-vt-misc-unicode-fixes-v1-1-c27e143cc2eb@qtmlabs.xyz
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The Qualcomm automotive SA8255p SoC relies on firmware to configure
platform resources, including clocks, interconnects and TLMM.
The driver requests resources operations over SCMI using power
and performance protocols.
The SCMI power protocol enables or disables resources like clocks,
interconnect paths, and TLMM (GPIOs) using runtime PM framework APIs,
such as resume/suspend, to control power states(on/off).
The SCMI performance protocol manages UART baud rates, with each baud
rate represented by a performance level. The driver uses the
dev_pm_opp_set_level() API to request the desired baud rate by
specifying the performance level.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Praveen Talari <quic_ptalari@quicinc.com>
Link: https://lore.kernel.org/r/20250721174532.14022-9-quic_ptalari@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The GENI serial driver currently handles power resource management
through calls to the statically defined geni_serial_resources_on() and
geni_serial_resources_off() functions. This approach reduces modularity
and limits support for platforms with diverse power management
mechanisms, including resource managed by firmware.
Improve modularity and enable better integration with platform-specific
power management, introduce support for runtime PM. Use
pm_runtime_resume_and_get() and pm_runtime_put_sync() within the
qcom_geni_serial_pm() callback to control resource power state
transitions based on UART power state changes.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Praveen Talari <quic_ptalari@quicinc.com>
Link: https://lore.kernel.org/r/20250721174532.14022-8-quic_ptalari@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Facilitates future modifications within the new function,
leading to better readability and maintainability of the code.
Move the code that handles the actual logic of clock-rate
calculations to a separate function geni_serial_set_rate()
which enhances code readability.
Signed-off-by: Praveen Talari <quic_ptalari@quicinc.com>
Link: https://lore.kernel.org/r/20250721174532.14022-7-quic_ptalari@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Supports use in PM system/runtime frameworks, helping to distinguish new
resource control mechanisms and facilitate future modifications within
the new API.
The code that handles the actual enable or disable of resources like clock
and ICC paths to a separate function (geni_serial_resources_on() and
geni_serial_resources_off()) which enhances code readability.
Introduced minor return checks in newly added function APIs to enhance
error detection and prevent silent failures.
Signed-off-by: Praveen Talari <quic_ptalari@quicinc.com>
Link: https://lore.kernel.org/r/20250721174532.14022-6-quic_ptalari@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Enhances code readability and future modifications within the new API.
Move the code that handles the actual initialization of resources
like clock and ICC paths to a separate function, making the
probe function cleaner.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Praveen Talari <quic_ptalari@quicinc.com>
Link: https://lore.kernel.org/r/20250721174532.14022-5-quic_ptalari@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
On the sa8255p platform, resources such as clocks,interconnects
and TLMM (GPIO) configurations are managed by firmware.
Use the `num_clks` field in platform data to distinguish whether
resource control is performed by firmware or directly by the driver
in linux.
Signed-off-by: Praveen Talari <quic_ptalari@quicinc.com>
Link: https://lore.kernel.org/r/20250721174532.14022-4-quic_ptalari@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
There is a spelling mistake of 'notifer' in the comment which
should be 'notifier'.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: WangYuli <wangyuli@uniontech.com>
Link: https://lore.kernel.org/r/BD4804BF4FBA1648+20250722073431.21983-6-wangyuli@uniontech.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
syzbot reports a use-after-free in comedi in the below link, which is
due to comedi gladly removing the allocated async area even though poll
requests are still active on the wait_queue_head inside of it. This can
cause a use-after-free when the poll entries are later triggered or
removed, as the memory for the wait_queue_head has been freed. We need
to check there are no tasks queued on any of the subdevices' wait queues
before allowing the device to be detached by the `COMEDI_DEVCONFIG`
ioctl.
Tasks will read-lock `dev->attach_lock` before adding themselves to the
subdevice wait queue, so fix the problem in the `COMEDI_DEVCONFIG` ioctl
handler by write-locking `dev->attach_lock` before checking that all of
the subdevices are safe to be deleted. This includes testing for any
sleepers on the subdevices' wait queues. It remains locked until the
device has been detached. This requires the `comedi_device_detach()`
function to be refactored slightly, moving the bulk of it into new
function `comedi_device_detach_locked()`.
Note that the refactor of `comedi_device_detach()` results in
`comedi_device_cancel_all()` now being called while `dev->attach_lock`
is write-locked, which wasn't the case previously, but that does not
matter.
Thanks to Jens Axboe for diagnosing the problem and co-developing this
patch.
Cc: stable <stable@kernel.org>
Fixes: 2f3fdcd7ce93 ("staging: comedi: add rw_semaphore to protect against device detachment")
Link: https://lore.kernel.org/all/687bd5fe.a70a0220.693ce.0091.GAE@google.com/
Reported-by: syzbot+01523a0ae5600aef5895@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=01523a0ae5600aef5895
Co-developed-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Tested-by: Jens Axboe <axboe@kernel.dk>
Link: https://lore.kernel.org/r/20250722155316.27432-1-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Merge miscellaneous power management updates and cpupower utility
updates for 6.17-rc1:
- Update contact information in the PM ABI docs and maintainer
information in the power domains DT binding (Rafael Wysocki)
- Update PM header inclusions to follow the IWYU (Include What You Use)
principle (Andy Shevchenko)
- Add flags to specify power on attach/detach for PM domains, make the
driver core detach PM domains in device_unbind_cleanup(), and drop
the dev_pm_domain_detach() call from the platform bus type (Claudiu
Beznea)
- Improve Python binding's Makefile for cpupower (John B. Wyatt IV)
- Fix printing of CORE, CPU fields in cpupower-monitor (Gautham Shenoy)
* pm-misc:
PM: docs: Use my kernel.org address in ABI docs and DT bindings
driver core: platform: Drop dev_pm_domain_detach() call
PM: domains: Detach on device_unbind_cleanup()
PM: domains: Add flags to specify power on attach/detach
PM: Don't use "proxy" headers
* pm-tools:
cpupower: Improve Python binding's Makefile
pm: cpupower: Fix printing of CORE, CPU fields in cpupower-monitor
pm: cpupower: Fix the snapshot-order of tsc,mperf, clock in mperf_stop()
|
|
Using device_find_child() to locate a probed virtual-device-port node
causes a device refcount imbalance, as device_find_child() internally
calls get_device() to increment the device’s reference count before
returning its pointer. vdc_port_mpgroup_check() directly returns true
upon finding a matching device without releasing the reference via
put_device(). We should call put_device() to decrement refcount.
As comment of device_find_child() says, 'NOTE: you will need to drop
the reference with put_device() after use'.
Found by code review.
Cc: stable@vger.kernel.org
Fixes: 3ee70591d6c4 ("sunvdc: prevent sunvdc panic when mpgroup disk added to guest domain")
Signed-off-by: Ma Ke <make24@iscas.ac.cn>
Link: https://lore.kernel.org/r/20250719075856.3447953-1-make24@iscas.ac.cn
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Merge runtime PM updates and power capping updates for 6.17-rc1:
- Document return values of suspend-related API functions in the
runtime PM framework (Sakari Ailus)
- Mark last busy stamp in multiple autosuspend-related functions in the
runtime PM framework and update its documentation (Sakari Ailus)
- Take active children into account in pm_runtime_get_if_in_use() for
consistency (Rafael Wysocki)
- Fix NULL pointer dereference in get_pd_power_uw() in the dtpm_cpu
power capping driver (Sivan Zohar-Kotzer)
- Add support for the Bartlett Lake platform to the Intel RAPL power
capping driver (Qiao Wei)
- Add PL4 support for Panther Lake to the intel_rapl_msr power capping
driver (Zhang Rui)
* pm-runtime:
PM: runtime: Take active children into account in pm_runtime_get_if_in_use()
Documentation: PM: *_autosuspend() functions update last busy time
PM: runtime: Mark last busy stamp in pm_request_autosuspend()
PM: runtime: Mark last busy stamp in pm_runtime_autosuspend()
PM: runtime: Mark last busy stamp in pm_runtime_put_sync_autosuspend()
PM: runtime: Mark last busy stamp in pm_runtime_put_autosuspend()
PM: runtime: Document return values of suspend-related API functions
* pm-powercap:
powercap: dtpm_cpu: Fix NULL pointer dereference in get_pd_power_uw()
powercap: intel_rapl: Add support for Bartlett Lake platform
powercap: intel_rapl_msr: Add PL4 support for Panther Lake
|
|
Merge updates related to system sleep for 6.17-rc1:
- Extend the asynchronous suspend and resume of devices to handle
suppliers like parents and consumers like children (Rafael Wysocki)
- Make pm_runtime_force_resume() work for drivers that set the
DPM_FLAG_SMART_SUSPEND flag and allow PCI drivers and drivers that
collaborate with the general ACPI PM domain to set it (Rafael
Wysocki)
- Add kernel parameter to disable asynchronous suspend/resume of
devices (Tudor Ambarus)
- Drop redundant might_sleep() calls from some functions in the device
suspend/resume core code (Zhongqiu Han)
- Fix the handling of monitors connected right before waking up the
system from sleep (tuhaowen)
- Clean up MAINTAINERS entries for suspend and hibernation (Rafael
Wysocki)
- Fix error code path in the KEXEC_JUMP flow and drop a redundant
pm_restore_gfp_mask() call from it (Rafael Wysocki)
- Rearrange suspend/resume error handling in the core device suspend
and resume code (Rafael Wysocki)
- Fix up white space that does not follow coding style in the
hibernation core code (Darshan Rathod)
* pm-sleep:
PM: hibernate: Fix up white space that does not follow coding style
PM: sleep: Rearrange suspend/resume error handling in the core
kexec_core: Drop redundant pm_restore_gfp_mask() call
kexec_core: Fix error code path in the KEXEC_JUMP flow
PM: sleep: Clean up MAINTAINERS entries for suspend and hibernation
PM: sleep: add kernel parameter to disable asynchronous suspend/resume
PCI/PM: Set power.strict_midlayer in pci_pm_init()
ACPI: PM: Set/clear power.strict_midlayer in prepare/complete
PM: sleep: Add strict_midlayer flag to struct dev_pm_info
PM: runtime: Introduce __rpm_get_driver_callback()
PM: Check power.needs_force_resume in pm_runtime_force_suspend()
PM: runtime: Clear power.needs_force_resume in pm_runtime_reinit()
PM: Make pm_runtime_force_resume() work with DPM_FLAG_SMART_SUSPEND
PM: Move two sleep-related functions under CONFIG_PM_SLEEP
PM: Use true/false as power.needs_force_resume values
PM: sleep: Make async suspend handle suppliers like parents
PM: sleep: Make async resume handle consumers like children
PM: sleep: Drop superfluous might_sleep() calls
PM: sleep: console: Fix the black screen issue
|
|
Merge a cpuidle update, a PM QoS update, devfreq updates, and an OPP
(operating performance points) update for 6.17-rc1:
- Fix opencoded for_each_cpu() in idle_state_valid() in the DT cpuidle
driver (Yury Norov)
- Remove info about non-existing QoS interfaces from the PM QoS
documentation (Ulf Hansson)
- Use c_* types via kernel prelude in Rust for OPP (Abhinav Ananthu)
- Add HiSilicon uncore frequency scaling driver to devfreq (Jie Zhan)
- Allow devfreq drivers to add custom sysfs ABIs (Jie Zhan)
- Simplify the sun8i-a33-mbus devfreq driver by using more devm
functions (Uwe Kleine-König)
- Fix an index typo in trans_stat() in devfreq (Chanwoo Choi)
- Check devfreq governor before using governor->name (Lifeng Zheng)
- Remove a redundant devfreq_get_freq_range() call from
devfreq_add_device() (Lifeng Zheng)
- Limit max_freq with scaling_min_freq in devfreq (Lifeng Zheng)
- Replace sscanf() with kstrtoul() in set_freq_store() (Lifeng Zheng)
* pm-cpuidle:
cpuidle: dt: fix opencoded for_each_cpu() in idle_state_valid()
* pm-qos:
Documentation: power: Remove info about non-existing QoS interfaces
* pm-devfreq:
PM / devfreq: Add HiSilicon uncore frequency scaling driver
PM / devfreq: Allow devfreq driver to add custom sysfs ABIs
PM / devfreq: sun8i-a33-mbus: Simplify by using more devm functions
PM / devfreq: Fix a index typo in trans_stat
PM / devfreq: Check governor before using governor->name
PM / devfreq: Remove redundant devfreq_get_freq_range() calling in devfreq_add_device()
PM / devfreq: Limit max_freq with scaling_min_freq
PM / devfreq: governor: Replace sscanf() with kstrtoul() in set_freq_store()
* pm-opp:
rust: opp: use c_* types via kernel prelude
|
|
Merge cpufreq updates for 6.17-rc1:
- Fix two initialization ordering issues in the cpufreq core and a
governor initialization error path in it, and clean it up (Lifeng
Zheng)
- Add Granite Rapids support in no-HWP mode to the intel_pstate cpufreq
driver (Li RongQing)
- Make intel_pstate always use HWP_DESIRED_PERF in passive mode (Rafael
Wysocki)
- Allow building the tegra124 cpufreq driver as a module (Aaron Kling)
- Do minor cleanups for Rust cpufreq and cpumask APIs and fix MAINTAINERS
entry for cpu.rs (Abhinav Ananthu, Ritvik Gupta, Lukas Bulwahn)
- Clean up assorted cpufreq drivers (Arnd Bergmann, Dan Carpenter,
Krzysztof Kozlowski, Sven Peter, Svyatoslav Ryhel, Lifeng Zheng)
- Add the NEED_UPDATE_LIMITS flag to the CPPC cpufreq driver (Prashant
Malani)
- Fix minimum performance state label error in the amd-pstate driver
documentation (Shouye Liu)
- Add the CPUFREQ_GOV_STRICT_TARGET flag to the userspace cpufreq
governor and explain HW coordination influence on it in the
documentation (Shashank Balaji)
* pm-cpufreq: (27 commits)
cpufreq: CPPC: Mark driver with NEED_UPDATE_LIMITS flag
Documentation: amd-pstate:fix minimum performance state label error
drivers: cpufreq: add Tegra114 support
rust: cpumask: Replace `MaybeUninit` and `mem::zeroed` with `Opaque` APIs
cpufreq: Exit governor when failed to start old governor
cpufreq: Move the check of cpufreq_driver->get into cpufreq_verify_current_freq()
cpufreq: Init policy->rwsem before it may be possibly used
cpufreq: Initialize cpufreq-based frequency-invariance later
cpufreq: Remove duplicate check in __cpufreq_offline()
cpufreq: Contain scaling_cur_freq.attr in cpufreq_attrs
cpufreq: intel_pstate: Add Granite Rapids support in no-HWP mode
cpufreq: intel_pstate: Always use HWP_DESIRED_PERF in passive mode
cpufreq: tegra124: Allow building as a module
cpufreq: dt: Add register helper
cpufreq: Export disable_cpufreq()
cpufreq: armada-8k: Fix off by one in armada_8k_cpufreq_free_table()
cpufreq: armada-8k: make both cpu masks static
rust: cpufreq: use c_ types from kernel prelude
rust: cpufreq: Ensure C ABI compatibility in all unsafe
cpufreq: brcmstb-avs: Fully open-code compatible for grepping
...
|
|
Fix kernel-doc warnings generated by following command:
`scripts/kernel-doc -Werror -Wshort-desc -Wall \
drivers/remoteproc/xlnx_r5_remoteproc.c > /dev/null`
warning: missing initial short description on line:
* struct mbox_info
...
Total 8 warnings fixed
Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Link: https://lore.kernel.org/r/20250716213048.2316424-3-tanmay.shah@amd.com
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
|
|
Merge an update fixing typos in ACPI documentation and comments for
6.17-rc1 (Bjorn Helgaas).
* acpi-misc:
ACPI: Fix typos
|
|
Fix typos in documentation and comments.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20250722132653.GA2781885@bhelgaas
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
