Move the cpuidle driver check from __acpi_processor_start() to
acpi_processor_power_init() which allows variable acpi_idle_driver to
become static.
No intentional functional impact.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Tested-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20251223100914.2407069-7-lihuisong@huawei.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Group all of the declarations of functions that belong to the ACPI
processor idle driver together in one place in processor.h.
While at it, drop the unnecessary extern modifier from the declaraions
of two functions.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Tested-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20251223100914.2407069-6-lihuisong@huawei.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Notice that acpi_processor_power_init() and acpi_processor_power_exit()
don't need to return any values because their callers don't check them
anyway, so redefine those functions as void.
While at it, rearrange the code in acpi_processor_power_init() to
reduce the indentation level, get rid of a redundant local variable
in that function, and rephrase a code comment in it.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Tested-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20251223100914.2407069-5-lihuisong@huawei.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit 7a8c994cbb ("ACPI: processor: idle: Optimize ACPI idle
driver registration") moved the ACPI idle driver registration to
acpi_processor_driver_init() and acpi_processor_power_init() does
not register an idle driver any more.
Accordingly, the cpuidle driver check in __acpi_processor_start() needs
to be updated to avoid calling acpi_processor_power_init() without a
cpuidle driver, in which case the registration of the cpuidle device
in that function would lead to a NULL pointer dereference in
__cpuidle_register_device().
Fixes: 7a8c994cbb ("ACPI: processor: idle: Optimize ACPI idle driver registration")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Tested-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20251223100914.2407069-4-lihuisong@huawei.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Empty stubs are defined in processor.h for some functions provided by
the ACPI processor idle driver, but those functions are only used in
the main ACPI processor driver which requires the ACPI processor idle
driver to be present (selecting CONFIG_ACPI_PROCESSOR causes
CONFIG_ACPI_PROCESSOR_IDLE to be selected too automatically).
This means that the empty stubs in question are not really necessary and
if both CONFIG_ACPI_PROCESSOR and CONFIG_ACPI_PROCESSOR_IDLE are unset,
the compiler complains that they are defined, but not used. Drop them
to get rid of the compiler warning.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Tested-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://patch.msgid.link/20251223100914.2407069-3-lihuisong@huawei.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Currently, the ACPI idle driver is registered from within a CPU
hotplug callback. Although this didn't cause any functional issues,
this is questionable and confusing. And it is better to register
the cpuidle driver when all of the CPUs have been brought up.
So add a new function to initialize acpi_idle_driver based on the
power management information of an available CPU and register cpuidle
driver in acpi_processor_driver_init().
This commit has four changes under the commit 7a8c994cbb (ACPI:
processor: idle: Optimize ACPI idle driver registration):
1) move acpi_processor_register_idle_driver() ahead of the
driver_register().
2) add acpi_processor_cstate_first_run_checks() before calling
acpi_processor_get_power_info().
3) squash the commit 9d68320b2b (ACPI: processor: idle: Fix
function defined but not used warning) into this change.
4) use for_each_possible_cpu(cpu) to scan all possible cpus.
Signed-off-by: Huisong Li <lihuisong@huawei.com>
Tested-by: Borislav Petkov (AMD) <bp@alien8.de>
[ rjw: New comment edits, changelog tweak ]
Link: https://patch.msgid.link/20251223100914.2407069-2-lihuisong@huawei.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The comapt_xxx_class symbols aren't declared in anything that
lib/comapt_audit.c is including (arm64 build) which is causing
the following sparse warnings:
lib/compat_audit.c:7:10: warning: symbol 'compat_dir_class'
was not declared. Should it be static?
lib/compat_audit.c:12:10: warning: symbol 'compat_read_class'
was not declared. Should it be static?
lib/compat_audit.c:17:10: warning: symbol 'compat_write_class'
was not declared. Should it be static?
lib/compat_audit.c:22:10: warning: symbol 'compat_chattr_class'
was not declared. Should it be static?
lib/compat_audit.c:27:10: warning: symbol 'compat_signal_class'
was not declared. Should it be static?
Trying to fix this by chaning compat_audit.c to inclde <linux/audit.h>
does not work on arm64 due to compile errors with the extra includes
that changing this header makes. The simpler thing would be just to
move the definitons of these symbols out of <linux/audit.h> into
<linux/audit_arch.h> which is included.
Fixes: 4b58841149 ("audit: Add generic compat syscall support")
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
[PM: rewrite subject line, fixed line length in description]
Signed-off-by: Paul Moore <paul@paul-moore.com>
Enable the PA Sync Lost event mask to ensure PA sync loss is properly
reported and handled.
Fixes: 485e0626e5 ("Bluetooth: hci_event: Fix not handling PA Sync Lost event")
Signed-off-by: Yang Li <yang.li@amlogic.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
I've been reviewing cpuidle changes, for governors in particular, for
the last couple of years and will continue to do so.
Signed-off-by: Christian Loehle <christian.loehle@arm.com>
Link: https://patch.msgid.link/71f63cb7-2d9b-49a3-9b04-a47e2edef5e0@arm.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The unlikely() annotation on the early-return condition in menu_select()
is incorrect on systems with only one idle state (e.g., ARM64 servers
with a single ACPI LPI state). Branch profiling shows 100% misprediction
on such systems since drv->state_count <= 1 is always true.
On platforms where only state0 is available, this path is the common
case, not an unlikely edge case. Remove the misleading annotation to
let the branch predictor learn the actual behavior.
Signed-off-by: Breno Leitao <leitao@debian.org>
Link: https://patch.msgid.link/20260105-annotated_idle-v1-1-10ddf0771b58@debian.org
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add dump to get-perf-domains, so that a user can fetch either information
about a specific performance domain with do or information about all
performance domains with dump. Share the reply format of do and dump using
perf-domain-attrs, so remove perf-domains. The YNL spec, autogenerated
files, and the do implementation are updated, and the dump implementation
is added.
Suggested-by: Donald Hunter <donald.hunter@gmail.com>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
Signed-off-by: Changwoo Min <changwoo@igalia.com>
Link: https://patch.msgid.link/20260108053212.642478-5-changwoo@igalia.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Previously, the cpus attribute was a string format which was a "%*pb"
stringification of a bitmap. That is not very consumable for a UAPI,
so let’s change it to an u64 array of CPU ids.
Suggested-by: Donald Hunter <donald.hunter@gmail.com>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
Signed-off-by: Changwoo Min <changwoo@igalia.com>
Link: https://patch.msgid.link/20260108053212.642478-4-changwoo@igalia.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The EM YNL specification used many acronyms, including ‘em’, ‘pd’,
‘ps’, etc. While the acronyms are short and convenient, they could be
confusing. So, let’s spell them out to be more specific. The following
changes were made in the spec. Note that the protocol name cannot exceed
GENL_NAMSIZ (16).
em -> dev-energymodel
pds -> perf-domains
pd -> perf-domain
pd-id -> perf-domain-id
pd-table -> perf-table
ps -> perf-state
get-pds -> get-perf-domains
get-pd-table -> get-perf-table
pd-created -> perf-domain-created
pd-updated -> perf-domain-updated
pd-deleted -> perf-domain-deleted
In addition. doc strings were added to the spec. based on the comments in
energy_model.h. Two flag attributes (perf-state-flags and
perf-domain-flags) were added for easily interpreting the bit flags.
Finally, the autogenerated files and em_netlink.c were updated accordingly
to reflect the name changes.
Suggested-by: Donald Hunter <donald.hunter@gmail.com>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
Signed-off-by: Changwoo Min <changwoo@igalia.com>
Link: https://patch.msgid.link/20260108053212.642478-3-changwoo@igalia.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The energy model YNL spec has the following two warnings
when checking with yamlint:
3:1 warning missing document start "---" (document-start)
107:13 error wrong indentation: expected 10 but found 12 (indentation)
So let’s fix whose lint warnings.
Fixes: bd26631ccd ("PM: EM: Add em.yaml and autogen files")
Suggested-by: Donald Hunter <donald.hunter@gmail.com>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
Signed-off-by: Changwoo Min <changwoo@igalia.com>
Link: https://patch.msgid.link/20260108053212.642478-2-changwoo@igalia.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Add PCI_VENDOR_ID_ASPEED to the shared pci_ids.h header and remove the
duplicate local definition from ehci-pci.c.
This prepares for adding a PCI quirk for ASPEED devices.
Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Link: https://patch.msgid.link/20251217154529.377586-1-nirmoyd@nvidia.com
Add the vdpu383 Video Decoder variant to the RK3576 device tree.
Also allow using the dedicated SRAM as a pool.
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Link: https://patch.msgid.link/20251020212009.8852-3-detlev.casanova@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add the vdpu381 Video Decoders to the rk3588-base devicetree.
The RK3588 based SoCs all embed 2 vdpu381 decoders.
This also adds the dedicated IOMMU controllers.
Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>
Link: https://patch.msgid.link/20251020212009.8852-2-detlev.casanova@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
"pinctrl-names" is not valid without a pinctrl-N property.
"max-freq" is not a defined property name. Maybe it was supposed to be
"spi-max-frequency", but changing to that would be a change in behavior.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260108230607.1348879-1-robh@kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The pinctrl node names "gpios" or with "-gpio" suffix collide with GPIO
property names creating false warnings. Add a "-pins?" suffix to avoid
the issue.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260108230623.1349310-1-robh@kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
"pinctrl" is not a defined property name. The correct name is
"pinctrl-0".
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
[added missing pinctrl-names property]
Link: https://patch.msgid.link/20260108230613.1349060-1-robh@kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
"sitronix,st7789v" is not a defined fallback for
"jasonic,jt240mhqs-hwt-ek-e3", so drop it.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260108230600.1348699-1-robh@kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Orange Pi CM5 Base board is a carrier board for the Orange Pi CM5
compute module. It has 3 ethernet ports, 2 USB ports, one HDMI output
and 4 CSI-2 inputs.
The device tree is split in two files, a .dtsi for the compute module
and a .dts for the carrier board. All the devices present on the carrier
board are enabled and tested, with the exception of the IR receiver due
to missing support for input capture in the PWM device's DT binding (and
driver).
This work is based on a combination of the Orange Pi 5 device tree from
the upstream kernel and the Orange Pi CM5 device tree from the BSP
kernel. All nodes and properties have been carefully checked to the best
of my abilities against the schematics of the carrier board. The
schematics of the compute module is not available publicly, so the
configuration of the PMIC hasn't been double-checked.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patch.msgid.link/20251027215637.20715-3-laurent.pinchart@ideasonboard.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Orange Pi CM5 Base board is a carrier board for the Orange Pi CM5
compute module. It has 3 ethernet ports, 2 USB ports, one HDMI output
and 4 CSI-2 inputs.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20251027215637.20715-2-laurent.pinchart@ideasonboard.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add support for the HDMI port for the Gameforce Ace. The HDMI port
has no HPD pin present (the manufacturer's devicetree states the pin
is reused for an additional face button) so add the attribute of
no-hpd to poll for connected devices.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Link: https://patch.msgid.link/20251119225526.70588-4-macroalpha82@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add support for the dw-hdmi-qp driver to handle devices with missing
HPD pins.
Since in this situation we are now polling for the EDID data via i2c
change the error message to a rate limited debug message when we are
unable to complete an i2c read, as a disconnected device would
otherwise fill dmesg with i2c read errors.
Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251119225526.70588-3-macroalpha82@gmail.com
Add an attribute of "no-hpd" for the Rockchip dw-hdmi-qp controller.
This is used to describe implementations where the HPD pin is not
connected or used for other purposes, such as in the RK3588S based
Gameforce Ace which repurposed the GPIO for an additional face
button.
The "no-hpd" option was chosen to be consistent with other devices
which already define this parameter for broken or missing hpd
functionality.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251119225526.70588-2-macroalpha82@gmail.com
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
system_wq should be the per-cpu workqueue, yet in this name nothing makes
that clear, so replace system_wq with system_percpu_wq.
The old wq (system_wq) will be kept for a few release cycles.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251031104846.119503-3-marco.crivellari@suse.com
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
system_unbound_wq should be the default workqueue so as not to enforce
locality constraints for random work whenever it's not required.
Adding system_dfl_wq to encourage its use when unbound work should be used.
The old system_unbound_wq will be kept for a few release cycles.
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20251031104846.119503-2-marco.crivellari@suse.com
The ARM PMUs shares the same per-cpu (PPI) interrupt, so we need to switch
to interrupt-cells = <4> in the GIC node to allow adding an interrupt
partition map phandle as the 4th cell value for GIC_PPI interrupts.
Signed-off-by: Yuanjie Yang <yuanjie.yang@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260108092542.1371-2-yuanjie.yang@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Complete interrupts for DWC3 node to match what is required by
Devicetree bindings, as reported by dtbs_check:
ipq9574-rdp433.dtb: usb@8af8800 (qcom,ipq9574-dwc3): interrupt-names: ['pwr_event'] is too short
The actual interrupt numbers are taken from reference manual of similar
chip, but not IPQ9574, due to lack of access to it.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
Tested-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260106185123.19929-4-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Interrupts for DWC3 node were completely mixed up - SPI interrupt 62 is
not listed in reference manual at all. It was also causing dtbs_check
warnings:
ipq5018-rdp432-c2.dtb: usb@8af8800 (qcom,ipq5018-dwc3): interrupt-names:0: 'pwr_event' was expected
ipq5018-rdp432-c2.dtb: usb@8af8800 (qcom,ipq5018-dwc3): interrupt-names: ['hs_phy_irq'] is too short
Warning itself was introduced by commit 53c6d854be ("dt-bindings: usb:
dwc3: Clean up hs_phy_irq in binding"), but this was trying to bring
sanity to the interrupts overall, although did a mistake for IPQ5018.
IPQ5018 does not have QUSB2 PHY and its interrupts should rather match
ones used in IPQ5332.
Correct it by using interrupts matching the bindings and reference
manual.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Tested-by: George Moussalem <george.moussalem@outlook.com>
Link: https://lore.kernel.org/r/20260106185123.19929-3-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The divider_round_rate() function is now deprecated, so let's migrate
to divider_determine_rate() instead so that this deprecated API can be
removed.
Note that when the main function itself was migrated to use
determine_rate, this was mistakenly converted to:
req->rate = divider_round_rate(...)
This is invalid in the case when an error occurs since it can set the
rate to a negative value.
Fixes: 0e56e3369b ("clk: qcom: alpha-pll: convert from round_rate() to determine_rate()")
Signed-off-by: Brian Masney <bmasney@redhat.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260108-clk-divider-round-rate-v1-14-535a3ed73bf3@redhat.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
HAMAO IoT EVK uses PCIe5 to connect an SDX65 module for WWAN functionality
and PCIe3 to connect a SATA controller. These interfaces require multiple
voltage rails: PCIe5 needs 3.3V supplied by vreg_wwan, while PCIe3 requires
12V, 3.3V, and 3.3V AUX rails, controlled via PMIC GPIOs.
Add the required fixed regulators with related pin configuration, and
connect them to the PCIe3 and PCIe5 ports to ensure proper power for the
SDX65 module and SATA controller.
Move reset and wake GPIO properties from RC nodes to port nodes.
Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
Reviewed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260109104504.3147745-4-ziyue.zhang@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
HAMOA IoT SOM requires PCIe3 and PCIe5 connectivity for SATA controller
and SDX65.
Add the required sideband signals (PERST#, WAKE#, CLKREQ#), pinctrl states
and power supply properties in the device tree, which PCIe3 and PCIe5
require.
Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
Reviewed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260109104504.3147745-3-ziyue.zhang@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Since describing the PCIe PHY directly under the RC node is now
deprecated, move the references to the respective PCIe port nodes,
creating them where necessary.Also add port nodes for PCIe5 and PCIe6a
with proper PHY references.
And also move the PCIe PERST and wake GPIOs from the controller nodes to
the corresponding PCIe port nodes on Hamoa-based platforms:
- x1e001de-devkit
- x1e78100-lenovo-thinkpad-t14s
- x1e80100-asus-vivobook-s15
- x1e80100-asus-zenbook-a14
- x1e80100-dell-xps13-9345
- x1e80100-lenovo-yoga-slim7x
- x1e80100-microsoft-romulus
- x1e80100-qcp
Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260109104504.3147745-2-ziyue.zhang@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Add comprehensive KUnit tests for the namespace-related capability
functions that Serge Hallyn refactored in commit 9891d2f79a
("Clarify the rootid_owns_currentns").
The tests verify:
- Basic functionality: UID 0 in init namespace, invalid vfsuid,
non-zero UIDs
- Actual namespace traversal: Creating user namespaces with different
UID mappings where uid 0 maps to different kuids (e.g., 1000, 2000,
3000)
- Hierarchy traversal: Testing multiple nested namespaces to verify
correct namespace hierarchy traversal
This addresses the feedback to "test the actual functionality" by
creating real user namespaces with different values for the
namespace's uid 0, rather than just basic input validation.
The test file is included at the end of commoncap.c when
CONFIG_SECURITY_COMMONCAP_KUNIT_TEST is enabled, following the
standard kernel pattern (e.g., scsi_lib.c, ext4/mballoc.c). This
allows tests to access static functions in the same compilation unit
without modifying production code based on test configuration.
The tests require CONFIG_USER_NS to be enabled since they rely on user
namespace mapping functionality. The Kconfig dependency ensures the
tests only build when this requirement is met.
All 7 tests pass:
- test_vfsuid_root_in_currentns_init_ns
- test_vfsuid_root_in_currentns_invalid
- test_vfsuid_root_in_currentns_nonzero
- test_kuid_root_in_ns_init_ns_uid0
- test_kuid_root_in_ns_init_ns_nonzero
- test_kuid_root_in_ns_with_mapping
- test_kuid_root_in_ns_with_different_mappings
Updated MAINTAINER capabilities to include commoncap test
Signed-off-by: Ryan Foster <foster.ryan.r@gmail.com>
Signed-off-by: Serge Hallyn <sergeh@kernel.org>
Some USB-C hubs and adapters have buggy firmware where multi-byte AUX
reads consistently timeout, while single-byte reads from the same address
work correctly.
Known affected devices that exhibit this issue:
- Lenovo USB-C to VGA adapter (VIA VL817 chipset)
idVendor=17ef, idProduct=7217
- Dell DA310 USB-C mobile adapter hub
idVendor=413c, idProduct=c010
Analysis of the failure pattern shows:
- Single-byte probes to 0xf0000 (LTTPR) succeed
- Single-byte probes to 0x00102 (TRAINING_AUX_RD_INTERVAL) succeed
- Multi-byte reads from 0x00000 (DPCD capabilities) timeout with -ETIMEDOUT
- Retrying does not help - the failure is consistent across all attempts
The issue appears to be a firmware bug in the AUX transaction handling
that specifically affects multi-byte reads.
Add a fallback mechanism in drm_dp_dpcd_read_data() that attempts
byte-by-byte reading when the normal multi-byte read fails. This
workaround only activates for adapters that fail the standard read path,
ensuring no impact on correctly functioning hardware.
Tested with:
- Lenovo USB-C to VGA adapter (VIA VL817) - now works with fallback
- Dell DA310 USB-C hub - now works with fallback
- Dell/Analogix Slimport adapter - continues to work with normal path
Signed-off-by: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Link: https://patch.msgid.link/20251204024647.1462866-1-acelan.kao@canonical.com
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
In many functions the Return section is missing. Fix kernel-doc
descriptions to address that and other warnings.
Before the change:
$ scripts/kernel-doc -none -Wreturn drivers/net/ethernet/intel/idpf/idpf_txrx.c 2>&1 | wc -l
85
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Tested-by: Krishneil Singh <krishneil.k.singh@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
idpf_up_complete() function always returns 0 and no callers use this return
value. Although idpf_vport_open() checks the return value, it only handles
error cases which never occur. Change the return type to void to simplify
the code.
Signed-off-by: Sreedevi Joshi <sreedevi.joshi@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
On some high-core systems (like AMD EPYC Bergamo, Intel Clearwater
Forest) loading ice driver with default values can lead to queue/irq
exhaustion. It will result in no additional resources for SR-IOV.
In most cases there is no performance reason for more than half
num_cpus(). Limit the default value to it using generic
netif_get_num_default_rss_queues().
Still, using ethtool the number of queues can be changed up to
num_online_cpus(). It can be done by calling:
$ethtool -L ethX combined $(nproc)
This change affects only the default queue amount.
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Add support for 10G-BX modules, i.e. 10GBit Ethernet over a single strand
Single-Mode fiber.
The initialization of a 10G-BX SFP+ is the same as for a 10G SX/LX module,
and is identified according to SFF-8472 table 5-3, footnote 3 by the
10G Ethernet Compliance Codes field being empty, the Nominal Bit
Rate being compatible with 12.5GBit, and the module being a fiber module
with a Single Mode fiber link length.
This was tested using a Lightron WSPXG-HS3LC-IEA 1270/1330nm 10km
transceiver:
$ sudo ethtool -m enp1s0f1
Identifier : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector : 0x07 (LC)
Transceiver codes : 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Encoding : 0x01 (8B/10B)
BR Nominal : 10300MBd
Rate identifier : 0x00 (unspecified)
Length (SMF) : 10km
Length (OM2) : 0m
Length (OM1) : 0m
Length (Copper or Active cable) : 0m
Length (OM3) : 0m
Laser wavelength : 1330nm
Vendor name : Lightron Inc.
Vendor OUI : 00:13:c5
Vendor PN : WSPXG-HS3LC-IEA
Vendor rev : 0000
Option values : 0x00 0x1a
Option : TX_DISABLE implemented
BR margin max : 0%
BR margin min : 0%
Vendor SN : S142228617
Date code : 140611
Optical diagnostics support : Yes
Signed-off-by: Birger Koblitz <mail@birger-koblitz.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Tested-by: Rinitha S <sx.rinitha@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Unify handling of PHY firmware load delays across all E800 family
devices. There is an existing mechanism to poll GL_MNG_FWSM_FW_LOADING_M
bit of GL_MNG_FWSM register in order to verify whether PHY FW loading
completed or not. Previously, this logic was limited to E827 variants
only.
Also, inform a user of possible delay in initialization process, by
dumping informational message in dmesg log ("Link initialization is
blocked by PHY FW initialization. Link initialization will continue
after PHY FW initialization completes.").
Signed-off-by: Grzegorz Nitka <grzegorz.nitka@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE8rQSAMVO+zA4DBdWxWXV+ddtWDsFAmlhIx0ACgkQxWXV+ddt
WDszVRAAik5HCuE0AwSmn/9VlN4ZFIZDKNUF1RnctsJuKkqEVTXLvpf7exM+C+WR
HKTNlRxCcKikAgtk4vlh7XI3bydaeYZpxyQmfVqn1prBXvL1NUPzdKjCOkhQL9yi
9uJAGPjekrVGc/l805DlQxZ19Jzc/HxWV6/uUBO2djKNVXOljxFK9IIL6rHHzwHe
pMR6n0zkdDUUxz0+x6BaJfvz1Vn8HyNd64MgVsOYsguaOmyHpn3/gxQ17jMcIvKu
Zh3Y+3vmZBdHP4t9USi0whc5tKiM2xOAzYm10ZQLhXDFWXNWnIoLmX+QrDhPZiyJ
r99ILwFBpoxHyuACNhZJK6YaNaukp97pmgfhO8k226FpAkTsBymdSYp5il8utAIE
/mBulniqkDKA2XTyv+KtRHPCeStUK427t/ZDTzmlBxYxtdcLSvrKtiXempYQ41vt
SQZGOt4psEhR7ZuFvFI7TgtbPoEq7z2O2WukX1ujx/9gjjZTLppst7EnKfdsRT8B
KygNl8W4wWo3yhP8RSlt8XBfF+KxCO75HnpBm78yoJqxOgle6h+Vx2WzsVi06o6R
06SzEHkzNMWW6Tj68xvGcm0DTmScvY5uiElf9MgyZBY69I7/q4U8SnnlTnwiru6g
wNaDLT0y2FWrH+RhKqUmWbWQGDyKdAdA5rZdI9eXoJRNxegOMkA=
=Euzv
-----END PGP SIGNATURE-----
Merge tag 'for-6.19-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux
Pull btrfs fixes from David Sterba:
- fix potential NULL pointer dereference when replaying tree log after
an error
- release path before initializing extent tree to avoid potential
deadlock when allocating new inode
- on filesystems with block size > page size
- fix potential read out of bounds during encoded read of an inline
extent
- only enforce free space tree if v1 cache is required
- print correct tree id in error message
* tag 'for-6.19-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
btrfs: show correct warning if can't read data reloc tree
btrfs: fix NULL pointer dereference in do_abort_log_replay()
btrfs: force free space tree for bs > ps cases
btrfs: only enforce free space tree if v1 cache is required for bs < ps cases
btrfs: release path before initializing extent tree in btrfs_read_locked_inode()
btrfs: avoid access-beyond-folio for bs > ps encoded writes
