* Re: [PATCH RFC 05/12] usb: hub: Power on connected M.2 E-key connectors
From: Alan Stern @ 2026-05-15 14:39 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, linux-pm, linux-usb, devicetree,
linux-mediatek, linux-arm-kernel, linux-kernel,
Manivannan Sadhasivam
In-Reply-To: <20260515090149.3169406-6-wenst@chromium.org>
On Fri, May 15, 2026 at 05:01:41PM +0800, Chen-Yu Tsai wrote:
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 90ea597d42ae..4165f71e212b 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -31,7 +31,9 @@
> #include <linux/minmax.h>
> #include <linux/mutex.h>
> #include <linux/random.h>
> +#include <linux/of_graph.h>
> #include <linux/pm_qos.h>
> +#include <linux/pwrseq/consumer.h>
> #include <linux/kobject.h>
>
> #include <linux/bitfield.h>
> @@ -888,13 +890,25 @@ int usb_hub_set_port_power(struct usb_device *hdev, struct usb_hub *hub,
> {
> int ret;
>
> + if (set)
> + ret = pwrseq_power_on(hub->ports[port1 - 1]->pwrseq);
> + else
> + ret = pwrseq_power_off(hub->ports[port1 - 1]->pwrseq);
> + if (ret)
> + return ret;
> +
> if (set)
> ret = set_port_feature(hdev, port1, USB_PORT_FEAT_POWER);
> else
> ret = usb_clear_port_feature(hdev, port1, USB_PORT_FEAT_POWER);
>
> - if (ret)
> + if (ret) {
> + if (set)
> + pwrseq_power_off(hub->ports[port1 - 1]->pwrseq);
> + else
> + pwrseq_power_on(hub->ports[port1 - 1]->pwrseq);
> return ret;
> + }
>
> if (set)
> set_bit(port1, hub->power_bits);
> @@ -1867,6 +1881,7 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id)
> struct usb_host_interface *desc;
> struct usb_device *hdev;
> struct usb_hub *hub;
> + int ret;
>
> desc = intf->cur_altsetting;
> hdev = interface_to_usbdev(intf);
This change is totally useless. Didn't you get a warning from the
compiler when you built it?
> diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
> index 9ebc5ef54a32..6039e5f5dcd7 100644
> --- a/drivers/usb/core/hub.h
> +++ b/drivers/usb/core/hub.h
> @@ -85,6 +85,7 @@ struct usb_hub {
> * @port_owner: port's owner
> * @peer: related usb2 and usb3 ports (share the same connector)
> * @connector: USB Type-C connector
> + * @pwrseq: power sequencing descriptor for the port
> * @req: default pm qos request for hubs without port power control
> * @connect_type: port's connect type
> * @state: device state of the usb device attached to the port
> @@ -104,6 +105,7 @@ struct usb_port {
> struct usb_dev_state *port_owner;
> struct usb_port *peer;
> struct typec_connector *connector;
> + struct pwrseq_desc *pwrseq;
> struct dev_pm_qos_request *req;
> enum usb_port_connect_type connect_type;
> enum usb_device_state state;
The fact that hub.h uses struct pwrseq_desc indicates that it ought to
#include <linux/pwrseq/consumer.h>, instead of making the .c files do
so themselves. Then you wouldn't have to add the #include lines to
hub.c and port.c.
> diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
> index b1364f0c384c..2d09037fee93 100644
> --- a/drivers/usb/core/port.c
> +++ b/drivers/usb/core/port.c
> @@ -7,11 +7,14 @@
> * Author: Lan Tianyu <tianyu.lan@intel.com>
> */
>
> +#include <linux/cleanup.h>
Why is this needed?
> #include <linux/kstrtox.h>
> #include <linux/slab.h>
> #include <linux/string_choices.h>
> #include <linux/sysfs.h>
> +#include <linux/of_graph.h>
> #include <linux/pm_qos.h>
> +#include <linux/pwrseq/consumer.h>
> #include <linux/component.h>
> #include <linux/usb/of.h>
>
Alan Stern
^ permalink raw reply
* [PATCH 5/5] PCI: Make pci_root_buses private to PCI core
From: Gerd Bayer @ 2026-05-15 14:22 UTC (permalink / raw)
To: Richard Henderson, Matt Turner, Magnus Lindholm, Russell King,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Bjorn Helgaas, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin
Cc: Yinghai Lu, linux-alpha, linux-kernel, linux-arm-kernel,
linuxppc-dev, linux-pci, Gerd Bayer
In-Reply-To: <20260515-priv_root_buses-v1-0-f8e393c57390@linux.ibm.com>
After all users of pci_root_buses external to PCI core have been
converted to using pci_find_next_bus(), move its declaration to the
PCI core code and stop exporting the symbol.
Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com>
---
drivers/pci/pci.h | 3 +++
drivers/pci/probe.c | 2 --
include/linux/pci.h | 4 ----
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 4a14f88e543a..1f36d400c9e0 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -366,6 +366,9 @@ static inline void pci_create_legacy_files(struct pci_bus *bus) { }
static inline void pci_remove_legacy_files(struct pci_bus *bus) { }
#endif
+/* List of all known PCI buses */
+extern struct list_head pci_root_buses;
+
/* Lock for read/write access to pci device and bus lists */
extern struct rw_semaphore pci_bus_sem;
extern struct mutex pci_slot_mutex;
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index b63cd0c310bc..2e97ab125ead 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -33,9 +33,7 @@ static struct resource busn_resource = {
.flags = IORESOURCE_BUS,
};
-/* Ugh. Need to stop exporting this to modules. */
LIST_HEAD(pci_root_buses);
-EXPORT_SYMBOL(pci_root_buses);
static LIST_HEAD(pci_domain_busn_res_list);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 2c4454583c11..1c4610848b5c 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1192,10 +1192,6 @@ extern enum pcie_bus_config_types pcie_bus_config;
extern const struct bus_type pci_bus_type;
-/* Do NOT directly access these two variables, unless you are arch-specific PCI
- * code, or PCI core code. */
-extern struct list_head pci_root_buses; /* List of all known PCI buses */
-
void pcibios_resource_survey_bus(struct pci_bus *bus);
void pcibios_bus_add_device(struct pci_dev *pdev);
void pcibios_add_bus(struct pci_bus *bus);
--
2.54.0
^ permalink raw reply related
* [PATCH 0/5] PCI: Finally make pci_root_buses private
From: Gerd Bayer @ 2026-05-15 14:22 UTC (permalink / raw)
To: Richard Henderson, Matt Turner, Magnus Lindholm, Russell King,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Bjorn Helgaas, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin
Cc: Yinghai Lu, linux-alpha, linux-kernel, linux-arm-kernel,
linuxppc-dev, linux-pci, Gerd Bayer
Hi all!
The ominous warning about pci_root_buses in drivers/pci/probe.c caught
my attention. Looking closer, I found that there are uses in four
arch-specific files left before we can stop exposing that symbol outside
of drivers/pci.
Finish off the job that Yinghai Lu started in 2013 - see
https://msgid.link/1359265003-16166-23-git-send-email-yinghai@kernel.org/
The entire series has been compile-tested only - with defconfigs on
alpha, arm, powerpc, and x86.
Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com>
---
Gerd Bayer (5):
alpha/pci: Use official API to iterate over PCI buses
arm/pci: Use official API to iterate over PCI buses
powerpc/pci: Use official API to iterate over PCI buses
x86/pci: Use official API to iterate over PCI buses
PCI: Make pci_root_buses private to PCI core
arch/alpha/kernel/pci.c | 4 ++--
arch/arm/kernel/bios32.c | 4 ++--
arch/powerpc/kernel/pci-common.c | 7 ++++---
arch/powerpc/kernel/pci_64.c | 4 ++--
arch/x86/pci/i386.c | 14 ++++++++------
drivers/pci/pci.h | 3 +++
drivers/pci/probe.c | 2 --
include/linux/pci.h | 4 ----
8 files changed, 21 insertions(+), 21 deletions(-)
---
base-commit: 5d6919055dec134de3c40167a490f33c74c12581
change-id: 20260508-priv_root_buses-0263ef2679ad
Best regards,
--
Gerd Bayer <gbayer@linux.ibm.com>
^ permalink raw reply
* [PATCH 1/5] alpha/pci: Use official API to iterate over PCI buses
From: Gerd Bayer @ 2026-05-15 14:22 UTC (permalink / raw)
To: Richard Henderson, Matt Turner, Magnus Lindholm, Russell King,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Bjorn Helgaas, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin
Cc: Yinghai Lu, linux-alpha, linux-kernel, linux-arm-kernel,
linuxppc-dev, linux-pci, Gerd Bayer
In-Reply-To: <20260515-priv_root_buses-v1-0-f8e393c57390@linux.ibm.com>
Replace iterating over pci_root_buses with the official
pci_find_next_bus() call provided by PCI core. This allows to make
pci_root_buses private to PCI core.
Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com>
---
arch/alpha/kernel/pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c
index 11df411b1d18..02ec4dbb3ac6 100644
--- a/arch/alpha/kernel/pci.c
+++ b/arch/alpha/kernel/pci.c
@@ -312,9 +312,9 @@ pcibios_claim_one_bus(struct pci_bus *b)
static void __init
pcibios_claim_console_setup(void)
{
- struct pci_bus *b;
+ struct pci_bus *b = NULL;
- list_for_each_entry(b, &pci_root_buses, node)
+ while ((b = pci_find_next_bus(b)) != NULL)
pcibios_claim_one_bus(b);
}
--
2.54.0
^ permalink raw reply related
* [PATCH 2/5] arm/pci: Use official API to iterate over PCI buses
From: Gerd Bayer @ 2026-05-15 14:22 UTC (permalink / raw)
To: Richard Henderson, Matt Turner, Magnus Lindholm, Russell King,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Bjorn Helgaas, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin
Cc: Yinghai Lu, linux-alpha, linux-kernel, linux-arm-kernel,
linuxppc-dev, linux-pci, Gerd Bayer
In-Reply-To: <20260515-priv_root_buses-v1-0-f8e393c57390@linux.ibm.com>
Replace iterating over pci_root_buses with the official
pci_find_next_bus() call provided by PCI core. This allows to make
pci_root_buses private to PCI core.
Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com>
---
arch/arm/kernel/bios32.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index ac0e890510da..35642c9ba054 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -59,9 +59,9 @@ static void pcibios_bus_report_status(struct pci_bus *bus, u_int status_mask, in
void pcibios_report_status(u_int status_mask, int warn)
{
- struct pci_bus *bus;
+ struct pci_bus *bus = NULL;
- list_for_each_entry(bus, &pci_root_buses, node)
+ while ((bus = pci_find_next_bus(bus)) != NULL)
pcibios_bus_report_status(bus, status_mask, warn);
}
--
2.54.0
^ permalink raw reply related
* [PATCH 4/5] x86/pci: Use official API to iterate over PCI buses
From: Gerd Bayer @ 2026-05-15 14:22 UTC (permalink / raw)
To: Richard Henderson, Matt Turner, Magnus Lindholm, Russell King,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Bjorn Helgaas, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin
Cc: Yinghai Lu, linux-alpha, linux-kernel, linux-arm-kernel,
linuxppc-dev, linux-pci, Gerd Bayer
In-Reply-To: <20260515-priv_root_buses-v1-0-f8e393c57390@linux.ibm.com>
Replace iterating over pci_root_buses with the official
pci_find_next_bus() call provided by PCI core. This allows to make
pci_root_buses private to PCI core.
Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com>
---
arch/x86/pci/i386.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
index e2de26b82940..194d0fa3cec8 100644
--- a/arch/x86/pci/i386.c
+++ b/arch/x86/pci/i386.c
@@ -357,10 +357,10 @@ static void pcibios_allocate_rom_resources(struct pci_bus *bus)
static int __init pcibios_assign_resources(void)
{
- struct pci_bus *bus;
+ struct pci_bus *bus = NULL;
if (!(pci_probe & PCI_ASSIGN_ROMS))
- list_for_each_entry(bus, &pci_root_buses, node)
+ while ((bus = pci_find_next_bus(bus)) != NULL)
pcibios_allocate_rom_resources(bus);
pci_assign_unassigned_resources();
@@ -390,16 +390,18 @@ void pcibios_resource_survey_bus(struct pci_bus *bus)
void __init pcibios_resource_survey(void)
{
- struct pci_bus *bus;
+ struct pci_bus *bus = NULL;
DBG("PCI: Allocating resources\n");
- list_for_each_entry(bus, &pci_root_buses, node)
+ while ((bus = pci_find_next_bus(bus)) != NULL)
pcibios_allocate_bus_resources(bus);
- list_for_each_entry(bus, &pci_root_buses, node)
+ bus = NULL; /* start all over */
+ while ((bus = pci_find_next_bus(bus)) != NULL)
pcibios_allocate_resources(bus, 0);
- list_for_each_entry(bus, &pci_root_buses, node)
+ bus = NULL; /* start all over */
+ while ((bus = pci_find_next_bus(bus)) != NULL)
pcibios_allocate_resources(bus, 1);
e820__reserve_resources_late();
--
2.54.0
^ permalink raw reply related
* [PATCH 3/5] powerpc/pci: Use official API to iterate over PCI buses
From: Gerd Bayer @ 2026-05-15 14:22 UTC (permalink / raw)
To: Richard Henderson, Matt Turner, Magnus Lindholm, Russell King,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Bjorn Helgaas, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin
Cc: Yinghai Lu, linux-alpha, linux-kernel, linux-arm-kernel,
linuxppc-dev, linux-pci, Gerd Bayer
In-Reply-To: <20260515-priv_root_buses-v1-0-f8e393c57390@linux.ibm.com>
Replace iterating over pci_root_buses with the official
pci_find_next_bus() call provided by PCI core. This allows to make
pci_root_buses private to PCI core.
Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com>
---
arch/powerpc/kernel/pci-common.c | 7 ++++---
arch/powerpc/kernel/pci_64.c | 4 ++--
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 8efe95a0c4ff..1e0be7bcaa56 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1417,10 +1417,10 @@ static void __init pcibios_reserve_legacy_regions(struct pci_bus *bus)
void __init pcibios_resource_survey(void)
{
- struct pci_bus *b;
+ struct pci_bus *b = NULL;
/* Allocate and assign resources */
- list_for_each_entry(b, &pci_root_buses, node)
+ while ((b = pci_find_next_bus(b)) != NULL)
pcibios_allocate_bus_resources(b);
if (!pci_has_flag(PCI_REASSIGN_ALL_RSRC)) {
pcibios_allocate_resources(0);
@@ -1432,7 +1432,8 @@ void __init pcibios_resource_survey(void)
* bus available resources to avoid allocating things on top of them
*/
if (!pci_has_flag(PCI_PROBE_ONLY)) {
- list_for_each_entry(b, &pci_root_buses, node)
+ b = NULL; /* Start all over */
+ while ((b = pci_find_next_bus(b)) != NULL)
pcibios_reserve_legacy_regions(b);
}
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index e27342ef128b..f816d063b984 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -227,7 +227,7 @@ SYSCALL_DEFINE3(pciconfig_iobase, long, which, unsigned long, in_bus,
unsigned long, in_devfn)
{
struct pci_controller* hose;
- struct pci_bus *tmp_bus, *bus = NULL;
+ struct pci_bus *tmp_bus = NULL, *bus = NULL;
struct device_node *hose_node;
/* Argh ! Please forgive me for that hack, but that's the
@@ -248,7 +248,7 @@ SYSCALL_DEFINE3(pciconfig_iobase, long, which, unsigned long, in_bus,
* used on pre-domains setup. We return the first match
*/
- list_for_each_entry(tmp_bus, &pci_root_buses, node) {
+ while ((tmp_bus = pci_find_next_bus(tmp_bus)) != NULL) {
if (in_bus >= tmp_bus->number &&
in_bus <= tmp_bus->busn_res.end) {
bus = tmp_bus;
--
2.54.0
^ permalink raw reply related
* [PATCH v3 3/3] fs/resctrl: Factor MBA parse-time conversion to be per-arch
From: Ben Horgan @ 2026-05-15 14:06 UTC (permalink / raw)
To: ben.horgan
Cc: james.morse, reinette.chatre, fenghuay, linux-kernel,
linux-arm-kernel, tglx, mingo, bp, dave.hansen, hpa, corbet, x86,
linux-doc, dave.martin, Dave Martin, Ben Horgan
In-Reply-To: <20260515140612.1205251-1-ben.horgan@arm.com>
From: Dave Martin <Dave.Martin@arm.com>
The control value parser for the MB resource currently coerces the
memory bandwidth percentage value from userspace to be an exact
multiple of the rdt_resource::resctrl_membw::bw_gran parameter.
On MPAM systems, this results in somewhat worse-than-worst-case
rounding, since the bandwidth granularity advertised to resctrl by the
MPAM driver is in general only an approximation to the actual hardware
granularity on these systems, and the hardware bandwidth allocation
control value is not natively a percentage -- necessitating a further
conversion in the resctrl_arch_update_domains() path, regardless of the
conversion done at parse time.
For MPAM and x86 use their custom pre-prepared parse-time conversion,
resctrl_arch_preconvert_bw(). This will avoid accumulated error
from rounding the value twice on MPAM systems. For x86 systems there
is no functional change.
Clarify the documentation, but avoid overly exact promises.
Clamping to bw_min and bw_max still feels generic: leave it in the core
code, for now.
[ BH: Split out x86 specific changes ]
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Ben Horgan <Ben.Horgan@arm.com>
Reviewed-by: Ben Horgan <ben.horgan@arm.com>
---
Documentation/filesystems/resctrl.rst | 17 +++++++++--------
fs/resctrl/ctrlmondata.c | 6 +++---
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/Documentation/filesystems/resctrl.rst b/Documentation/filesystems/resctrl.rst
index b003bed339fd..4322d8025453 100644
--- a/Documentation/filesystems/resctrl.rst
+++ b/Documentation/filesystems/resctrl.rst
@@ -236,12 +236,11 @@ with respect to allocation:
user can request.
"bandwidth_gran":
- The granularity in which the memory bandwidth
- percentage is allocated. The allocated
- b/w percentage is rounded off to the next
- control step available on the hardware. The
- available bandwidth control steps are:
- min_bandwidth + N * bandwidth_gran.
+ The approximate granularity in which the memory bandwidth
+ percentage is allocated. The allocated bandwidth percentage
+ is rounded up to the next control step available on the
+ hardware. The available hardware steps are no larger than
+ this value.
"delay_linear":
Indicates if the delay scale is linear or
@@ -871,8 +870,10 @@ The minimum bandwidth percentage value for each cpu model is predefined
and can be looked up through "info/MB/min_bandwidth". The bandwidth
granularity that is allocated is also dependent on the cpu model and can
be looked up at "info/MB/bandwidth_gran". The available bandwidth
-control steps are: min_bw + N * bw_gran. Intermediate values are rounded
-to the next control step available on the hardware.
+control steps are, approximately, min_bw + N * bw_gran. The steps may
+appear irregular due to rounding to an exact percentage: bw_gran is the
+maximum interval between the percentage values corresponding to any two
+adjacent steps in the hardware.
The bandwidth throttling is a core specific mechanism on some of Intel
SKUs. Using a high bandwidth and a low bandwidth setting on two threads
diff --git a/fs/resctrl/ctrlmondata.c b/fs/resctrl/ctrlmondata.c
index 9a7dfc48cb2e..934e12f5d145 100644
--- a/fs/resctrl/ctrlmondata.c
+++ b/fs/resctrl/ctrlmondata.c
@@ -37,8 +37,8 @@ typedef int (ctrlval_parser_t)(struct rdt_parse_data *data,
/*
* Check whether MBA bandwidth percentage value is correct. The value is
* checked against the minimum and max bandwidth values specified by the
- * hardware. The allocated bandwidth percentage is rounded to the next
- * control step available on the hardware.
+ * hardware. The allocated bandwidth percentage is converted as
+ * appropriate for consumption by the specific hardware driver.
*/
static bool bw_validate(char *buf, u32 *data, struct rdt_resource *r)
{
@@ -71,7 +71,7 @@ static bool bw_validate(char *buf, u32 *data, struct rdt_resource *r)
return false;
}
- *data = roundup(bw, (unsigned long)r->membw.bw_gran);
+ *data = resctrl_arch_preconvert_bw(bw, r);
return true;
}
--
2.43.0
^ permalink raw reply related
* [PATCH v3 2/3] arm_mpam: resctrl: Add pass-through resctrl_arch_preconvert_bw()
From: Ben Horgan @ 2026-05-15 14:06 UTC (permalink / raw)
To: ben.horgan
Cc: james.morse, reinette.chatre, fenghuay, linux-kernel,
linux-arm-kernel, tglx, mingo, bp, dave.hansen, hpa, corbet, x86,
linux-doc, dave.martin
In-Reply-To: <20260515140612.1205251-1-ben.horgan@arm.com>
resctrl rounds up the percentage value of the MBA based on the bw_gran. As
MPAM uses a binary fixed point fraction format for MBA rather than a
decimal percentage, this introduces rounding errors.
Without this additional rounding, if the user reads the value in an MB
schema and then writes it back to the schema, the value in hardware won't
change. However, with this additional rounding, this guarantee is broken
for systems with mbw_wd < 7.
resctrl is introducing resctrl_arch_preconvert_bw() to allow the arch code
to specify the conversion resctrl does to the user-provided bandwidth
value. Add the MPAM version of resctrl_arch_preconvert_bw(). This does no
conversion.
Signed-off-by: Ben Horgan <ben.horgan@arm.com>
---
drivers/resctrl/mpam_resctrl.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/mpam_resctrl.c
index 226ff6f532fa..5a2104af22cc 100644
--- a/drivers/resctrl/mpam_resctrl.c
+++ b/drivers/resctrl/mpam_resctrl.c
@@ -167,6 +167,11 @@ bool resctrl_arch_get_cdp_enabled(enum resctrl_res_level rid)
return mpam_resctrl_controls[rid].cdp_enabled;
}
+u32 resctrl_arch_preconvert_bw(u32 val, const struct rdt_resource *r)
+{
+ return val;
+}
+
/**
* resctrl_reset_task_closids() - Reset the PARTID/PMG values for all tasks.
*
--
2.43.0
^ permalink raw reply related
* [PATCH v3 1/3] x86/resctrl: Add resctrl_arch_preconvert_bw()
From: Ben Horgan @ 2026-05-15 14:06 UTC (permalink / raw)
To: ben.horgan
Cc: james.morse, reinette.chatre, fenghuay, linux-kernel,
linux-arm-kernel, tglx, mingo, bp, dave.hansen, hpa, corbet, x86,
linux-doc, dave.martin
In-Reply-To: <20260515140612.1205251-1-ben.horgan@arm.com>
On MPAM systems the rounding behaviour of the MBA control would be improved
if the rounding in the fs/resctrl code is removed but this is not the
case for x86. To allow any rounding or conversion of the bandwidth value
provided by the user to be specified by the arch code a new arch hook is
required.
Introduce resctrl_arch_preconvert_bw(), and add its x86 implementation.
This is currently unused in resctrl but when plumbed in it will replace the
call to roundup() in bw_validate().
Signed-off-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Ben Horgan <ben.horgan@arm.com>
---
Changes since Dave's v2:
Split from larger patch and add commit message
Update kernel-doc (Reinette)
---
arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 6 ++++++
include/linux/resctrl.h | 19 +++++++++++++++++++
2 files changed, 25 insertions(+)
diff --git a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
index b20e705606b8..19ae596f6b30 100644
--- a/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
+++ b/arch/x86/kernel/cpu/resctrl/ctrlmondata.c
@@ -16,9 +16,15 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/cpu.h>
+#include <linux/math.h>
#include "internal.h"
+u32 resctrl_arch_preconvert_bw(u32 val, const struct rdt_resource *r)
+{
+ return roundup(val, (unsigned long)r->membw.bw_gran);
+}
+
int resctrl_arch_update_one(struct rdt_resource *r, struct rdt_ctrl_domain *d,
u32 closid, enum resctrl_conf_type t, u32 cfg_val)
{
diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h
index 006e57fd7ca5..33a6742da4f9 100644
--- a/include/linux/resctrl.h
+++ b/include/linux/resctrl.h
@@ -500,6 +500,25 @@ bool resctrl_arch_mbm_cntr_assign_enabled(struct rdt_resource *r);
*/
int resctrl_arch_mbm_cntr_assign_set(struct rdt_resource *r, bool enable);
+/**
+ * resctrl_arch_preconvert_bw() - Prepare bandwidth control value for arch use.
+ * @val: Bandwidth control value written to the schemata file by userspace.
+ * @r: Resource whose schema was written.
+ *
+ * Convert the user provided bandwidth control value to an appropriate form for
+ * consumption by the hardware driver for resource @r. Converted value is stored
+ * in rdt_ctrl_domain::staged_config[] for later consumption by
+ * resctrl_arch_update_domains(). Is not called when MBA software controller is
+ * enabled.
+ *
+ * Architectures for which this pre-conversion hook is not useful should supply
+ * an implementation of this function that just returns val unmodified.
+ *
+ * Return:
+ * The converted value.
+ */
+u32 resctrl_arch_preconvert_bw(u32 val, const struct rdt_resource *r);
+
/*
* Update the ctrl_val and apply this config right now.
* Must be called on one of the domain's CPUs.
--
2.43.0
^ permalink raw reply related
* [PATCH v3 0/3] x86,fs/resctrl,arm_mpam: Factor MBA parse-time conversion to be per-arch
From: Ben Horgan @ 2026-05-15 14:06 UTC (permalink / raw)
To: ben.horgan
Cc: james.morse, reinette.chatre, fenghuay, linux-kernel,
linux-arm-kernel, tglx, mingo, bp, dave.hansen, hpa, corbet, x86,
linux-doc, dave.martin
This is a new version of Dave Martin's patch [1] to delegate rounding of
bandwidth control user values to the arch code. As there is now more than one
architecture using resctrl, I split the original patch into two, a core resctrl
patch and an x86 patch, and added an MPAM patch. Please let me know if the patch
break down and ordering is sensible and whether the pattern should be followed
for any future similar changes.
This does have a user visible effect on MB schema when using MPAM hardware
with 'bandwidth_gran' greater than 1. I'm not sure if MPAM hardware with such
coarse controls exists in the wild but it is spec compliant and I've tested it
on a model.
[1] https://lore.kernel.org/lkml/20251031154225.14799-1-Dave.Martin@arm.com/
Ben Horgan (2):
x86/resctrl: Add resctrl_arch_preconvert_bw()
arm_mpam: resctrl: Add pass-through resctrl_arch_preconvert_bw()
Dave Martin (1):
fs/resctrl: Factor MBA parse-time conversion to be per-arch
Documentation/filesystems/resctrl.rst | 17 +++++++++--------
arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 6 ++++++
drivers/resctrl/mpam_resctrl.c | 5 +++++
fs/resctrl/ctrlmondata.c | 6 +++---
include/linux/resctrl.h | 19 +++++++++++++++++++
5 files changed, 42 insertions(+), 11 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v2 1/1] arm64: dts: imx8mq-evk: Enable MIPI CSI and dual OV5640 cameras
From: Frank Li @ 2026-05-15 14:01 UTC (permalink / raw)
To: Robby Cai
Cc: robh, krzk+dt, conor+dt, s.hauer, festevam,
sebastian.krzyszkowiak, kernel, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260515111143.2980956-1-robby.cai@nxp.com>
On Fri, May 15, 2026 at 07:11:43PM +0800, Robby Cai wrote:
> Enable the MIPI CSI bridges and corresponding CSI-2 host interfaces
> on the i.MX8MQ EVK, and add two OV5640 camera sensors.
>
> The sensors are connected via I2C1 and I2C2, each with proper
> endpoint descriptions to form complete media pipelines.
>
> The resulting pipelines are:
>
> - OV5640 (I2C2) -> MIPI CSI1 -> CSI1 bridge
> - OV5640 (I2C1) -> MIPI CSI2 -> CSI2 bridge
>
> Both pipelines have been validated on the i.MX8MQ EVK using the
> upstream OV5640 driver.
>
> Both OV5640 sensors share a single reset GPIO on this board,
> which prevents independent hardware reset when both cameras
> are enabled. As a result, the reset line is kept deasserted
> via a GPIO hog, and sensor reset is performed via software.
Does reset_control_get_shared() resolve this problem?
Frank
^ permalink raw reply
* Re: [PATCH] arm64: mm: use u32 for FDT size in fixmap_remap_fdt()
From: Sang-Heon Jeon @ 2026-05-15 13:59 UTC (permalink / raw)
To: catalin.marinas, will; +Cc: linux-arm-kernel
In-Reply-To: <CABFDxMHngr+cyjZdiJTZATh2D5jC=qO+92B1VVrr0w9TNtx6nw@mail.gmail.com>
On Fri, May 15, 2026 at 10:55 PM Sang-Heon Jeon <ekffu200098@gmail.com> wrote:
>
> On Fri, May 15, 2026 at 2:13 AM Sang-Heon Jeon <ekffu200098@gmail.com> wrote:
> >
> > fixmap_remap_fdt() uses a signed int for the FDT size, so a malformed
> > totalsize bigger than INT_MAX wrongly passes the MAX_FDT_SIZE check.
> > Then create_mapping_noalloc() is called with a huge size and triggers
> > a BUG_ON() in the MMU code, with no diagnostic about the malformed FDT.
> >
> > Change the FDT size from int to u32, which is the return type of
> > fdt_totalsize(). So a malformed totalsize no longer wrongly passes the
> > MAX_FDT_SIZE check, and setup_machine_fdt() prints a pr_crit
> > diagnostic for it, not a BUG_ON in the MMU code.
> >
> > Fixes: 61bd93ce801b ("arm64: use fixmap region for permanent FDT mapping")
> > Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
> > ---
> > arch/arm64/include/asm/mmu.h | 2 +-
> > arch/arm64/kernel/setup.c | 4 ++--
> > arch/arm64/mm/fixmap.c | 4 ++--
> > 3 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
> > index 5e1211c540ab..a6b388ef4c3f 100644
> > --- a/arch/arm64/include/asm/mmu.h
> > +++ b/arch/arm64/include/asm/mmu.h
> > @@ -68,7 +68,7 @@ extern void create_mapping_noalloc(phys_addr_t phys, unsigned long virt,
> > extern void create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
> > unsigned long virt, phys_addr_t size,
> > pgprot_t prot, bool page_mappings_only);
> > -extern void *fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot);
> > +extern void *fixmap_remap_fdt(phys_addr_t dt_phys, u32 *size, pgprot_t prot);
> > extern void mark_linear_text_alias_ro(void);
> > extern int split_kernel_leaf_mapping(unsigned long start, unsigned long end);
> > extern void linear_map_maybe_split_to_ptes(void);
> > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > index 23c05dc7a8f2..7cabac0546dc 100644
> > --- a/arch/arm64/kernel/setup.c
> > +++ b/arch/arm64/kernel/setup.c
> > @@ -169,7 +169,7 @@ static void __init smp_build_mpidr_hash(void)
> >
> > static void __init setup_machine_fdt(phys_addr_t dt_phys)
> > {
> > - int size = 0;
> > + u32 size = 0;
> > void *dt_virt = fixmap_remap_fdt(dt_phys, &size, PAGE_KERNEL);
> > const char *name;
> >
> > @@ -182,7 +182,7 @@ static void __init setup_machine_fdt(phys_addr_t dt_phys)
> > */
> > if (!early_init_dt_scan(dt_virt, dt_phys)) {
> > pr_crit("\n"
> > - "Error: invalid device tree blob: PA=%pa, VA=%px, size=%d bytes\n"
> > + "Error: invalid device tree blob: PA=%pa, VA=%px, size=%u bytes\n"
> > "The dtb must be 8-byte aligned and must not exceed 2 MB in size.\n"
> > "\nPlease check your bootloader.\n",
> > &dt_phys, dt_virt, size);
> > diff --git a/arch/arm64/mm/fixmap.c b/arch/arm64/mm/fixmap.c
> > index c5c5425791da..c692e6ac2405 100644
> > --- a/arch/arm64/mm/fixmap.c
> > +++ b/arch/arm64/mm/fixmap.c
> > @@ -134,11 +134,11 @@ void __set_fixmap(enum fixed_addresses idx,
> > }
> > }
> >
> > -void *__init fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot)
> > +void *__init fixmap_remap_fdt(phys_addr_t dt_phys, u32 *size, pgprot_t prot)
> > {
> > const u64 dt_virt_base = __fix_to_virt(FIX_FDT);
> > phys_addr_t dt_phys_base;
> > - int offset;
> > + u32 offset;
>
> Also sashiko found another issue with malformed total size. And I
> think that can be resolved by the following changes.
Add missing sashiko review link :
https://sashiko.dev/#/patchset/20260514171304.2034930-1-ekffu200098%40gmail.com
> *size = fdt_totalsize(dt_virt);
> + if (*size < sizeof(struct fdt_header))
> + return NULL;
>
> Before sending a separate patch about malformed totalsize. First, I'd
> rather check reviewers' opinions.
>
> 1. Do we need to care about malformed totalsize? (including addressed
> by the current patch)
> 2. Does the above change need to be merged with the current patch or not?
>
> Looking forward to your feedback.
>
> Best Regards,
> Sang-Heon Jeon
>
> > void *dt_virt;
> >
> > /*
> > --
> > 2.43.0
> >
^ permalink raw reply
* Re: [PATCH] arm64: mm: use u32 for FDT size in fixmap_remap_fdt()
From: Sang-Heon Jeon @ 2026-05-15 13:55 UTC (permalink / raw)
To: catalin.marinas, will; +Cc: linux-arm-kernel
In-Reply-To: <20260514171304.2034930-1-ekffu200098@gmail.com>
On Fri, May 15, 2026 at 2:13 AM Sang-Heon Jeon <ekffu200098@gmail.com> wrote:
>
> fixmap_remap_fdt() uses a signed int for the FDT size, so a malformed
> totalsize bigger than INT_MAX wrongly passes the MAX_FDT_SIZE check.
> Then create_mapping_noalloc() is called with a huge size and triggers
> a BUG_ON() in the MMU code, with no diagnostic about the malformed FDT.
>
> Change the FDT size from int to u32, which is the return type of
> fdt_totalsize(). So a malformed totalsize no longer wrongly passes the
> MAX_FDT_SIZE check, and setup_machine_fdt() prints a pr_crit
> diagnostic for it, not a BUG_ON in the MMU code.
>
> Fixes: 61bd93ce801b ("arm64: use fixmap region for permanent FDT mapping")
> Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
> ---
> arch/arm64/include/asm/mmu.h | 2 +-
> arch/arm64/kernel/setup.c | 4 ++--
> arch/arm64/mm/fixmap.c | 4 ++--
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
> index 5e1211c540ab..a6b388ef4c3f 100644
> --- a/arch/arm64/include/asm/mmu.h
> +++ b/arch/arm64/include/asm/mmu.h
> @@ -68,7 +68,7 @@ extern void create_mapping_noalloc(phys_addr_t phys, unsigned long virt,
> extern void create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
> unsigned long virt, phys_addr_t size,
> pgprot_t prot, bool page_mappings_only);
> -extern void *fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot);
> +extern void *fixmap_remap_fdt(phys_addr_t dt_phys, u32 *size, pgprot_t prot);
> extern void mark_linear_text_alias_ro(void);
> extern int split_kernel_leaf_mapping(unsigned long start, unsigned long end);
> extern void linear_map_maybe_split_to_ptes(void);
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 23c05dc7a8f2..7cabac0546dc 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -169,7 +169,7 @@ static void __init smp_build_mpidr_hash(void)
>
> static void __init setup_machine_fdt(phys_addr_t dt_phys)
> {
> - int size = 0;
> + u32 size = 0;
> void *dt_virt = fixmap_remap_fdt(dt_phys, &size, PAGE_KERNEL);
> const char *name;
>
> @@ -182,7 +182,7 @@ static void __init setup_machine_fdt(phys_addr_t dt_phys)
> */
> if (!early_init_dt_scan(dt_virt, dt_phys)) {
> pr_crit("\n"
> - "Error: invalid device tree blob: PA=%pa, VA=%px, size=%d bytes\n"
> + "Error: invalid device tree blob: PA=%pa, VA=%px, size=%u bytes\n"
> "The dtb must be 8-byte aligned and must not exceed 2 MB in size.\n"
> "\nPlease check your bootloader.\n",
> &dt_phys, dt_virt, size);
> diff --git a/arch/arm64/mm/fixmap.c b/arch/arm64/mm/fixmap.c
> index c5c5425791da..c692e6ac2405 100644
> --- a/arch/arm64/mm/fixmap.c
> +++ b/arch/arm64/mm/fixmap.c
> @@ -134,11 +134,11 @@ void __set_fixmap(enum fixed_addresses idx,
> }
> }
>
> -void *__init fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot)
> +void *__init fixmap_remap_fdt(phys_addr_t dt_phys, u32 *size, pgprot_t prot)
> {
> const u64 dt_virt_base = __fix_to_virt(FIX_FDT);
> phys_addr_t dt_phys_base;
> - int offset;
> + u32 offset;
Also sashiko found another issue with malformed total size. And I
think that can be resolved by the following changes.
*size = fdt_totalsize(dt_virt);
+ if (*size < sizeof(struct fdt_header))
+ return NULL;
Before sending a separate patch about malformed totalsize. First, I'd
rather check reviewers' opinions.
1. Do we need to care about malformed totalsize? (including addressed
by the current patch)
2. Does the above change need to be merged with the current patch or not?
Looking forward to your feedback.
Best Regards,
Sang-Heon Jeon
> void *dt_virt;
>
> /*
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH 2/3] iommu/io-pgtable-arm: Rework to use the iommu-pages API
From: Jason Gunthorpe @ 2026-05-15 13:54 UTC (permalink / raw)
To: Mostafa Saleh
Cc: iommu, linux-arm-kernel, linux-kernel, robin.murphy, will, joro
In-Reply-To: <20260513215203.3852661-3-smostafa@google.com>
On Wed, May 13, 2026 at 09:52:02PM +0000, Mostafa Saleh wrote:
> Update the io-pgtable-arm allocator to use the iommu-pages API.
>
> Replace the DMA API usage from __arm_lpae_alloc_pages() with
> iommu_pages_start_incoherent() and from __arm_lpae_free_pages() with
> iommu_pages_free_incoherent().
>
> Since the iommu-pages API relies on metadata stored in the struct page
> during iommu_alloc_pages_node_sz(), it cannot be used safely with memory
> allocated via the custom cfg->alloc (which may not be backed by pages).
> So, isolate that logic and keep it as it.
>
> Suggested-by: Jason Gunthorpe <jgg@ziepe.ca>
> Signed-off-by: Mostafa Saleh <smostafa@google.com>
> ---
> drivers/iommu/io-pgtable-arm.c | 79 ++++++++++++++++++++++++----------
> 1 file changed, 56 insertions(+), 23 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
I feel the setup for incoherent walk for panthor is kind of sketchy,
if you select incoherent walk and pass in a random GPU driver struct
device there are alot of assumptions suddenly to know the dma API is
doing the right thing..
Jason
^ permalink raw reply
* Re: [PATCH v1] arm64: dts: ti: k3-am62-verdin: Add DSI to HDMI adapter overlay
From: Nishanth Menon @ 2026-05-15 13:49 UTC (permalink / raw)
To: Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Francesco Dolcini,
Vitor Soares
Cc: Nishanth Menon, Vitor Soares, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20260506143427.348806-2-ivitro@gmail.com>
Hi Vitor Soares,
On Wed, 06 May 2026 15:34:26 +0100, Vitor Soares wrote:
> Add a device-tree overlay for the Toradex DSI to HDMI Adapter, an
> accessory that connects to the Verdin DSI_1 interface and provides a
> full-size HDMI Type-A output. The adapter is based on the Lontium
> LT8912B DSI-to-HDMI bridge.
>
> The overlay is also combined with the Verdin AM62 carrier board device
> trees to provide ready-to-use DTBs for the Dahlia and Development Board
> carriers, in both WiFi and non-WiFi SoM variants.
>
> [...]
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/1] arm64: dts: ti: k3-am62-verdin: Add DSI to HDMI adapter overlay
commit: 48f1f6f480741f014f3774096236fff91cdcc297
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
https://ti.com/opensource
^ permalink raw reply
* Re: [PATCH v2] soc: ti: knav_qmss_queue: Implement resource cleanup in remove()
From: Nishanth Menon @ 2026-05-15 13:48 UTC (permalink / raw)
To: ssantosh, linux-arm-kernel, linux-kernel, Md Shofiqul Islam
Cc: Nishanth Menon
In-Reply-To: <20260506154114.2288-1-shofiqtest@gmail.com>
Hi Md Shofiqul Islam,
On Wed, 06 May 2026 18:41:14 +0300, Md Shofiqul Islam wrote:
> Implement the TODO in knav_queue_remove() by stopping PDSPs and
> freeing queue regions and queue ranges before disabling runtime PM,
> mirroring the cleanup performed in the probe error path.
>
> Set device_ready to false before cleanup to prevent any further
> use of the device during teardown.
>
> [...]
I have applied the following to branch ti-drivers-soc-next on [1].
Thank you!
[1/1] soc: ti: knav_qmss_queue: Implement resource cleanup in remove()
commit: 10a1969353b20caa50c320717e054601631c0d3e
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
https://ti.com/opensource
^ permalink raw reply
* Re: [PATCH v2] soc: ti: k3-ringacc: Fix access mode for k3_ringacc_ring_pop_tail_io/proxy
From: Nishanth Menon @ 2026-05-15 13:48 UTC (permalink / raw)
To: ssantosh, gehariprasath, Siddharth Vadapalli
Cc: Nishanth Menon, stable, linux-kernel, linux-arm-kernel, srk
In-Reply-To: <20260501124129.362192-1-s-vadapalli@ti.com>
Hi Siddharth Vadapalli,
On Fri, 01 May 2026 18:10:54 +0530, Siddharth Vadapalli wrote:
> k3_ringacc_ring_pop_tail_io() and k3_ringacc_ring_pop_tail_proxy()
> incorrectly use K3_RINGACC_ACCESS_MODE_POP_HEAD instead of
> K3_RINGACC_ACCESS_MODE_POP_TAIL. This will result in ring elements being
> popped in the reverse order of that which the caller expects. Fix this.
I have applied the following to branch ti-drivers-soc-next on [1].
I am queuing this up for the next window as things seem functional at
this point as well and was a bug that was present for a long time, so
I dont see this introduced in the current window.
Thank you!
[1/1] soc: ti: k3-ringacc: Fix access mode for k3_ringacc_ring_pop_tail_io/proxy
commit: b920352cfd2b0fcd1249ff006618c939b64fc8f7
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux.git
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
https://ti.com/opensource
^ permalink raw reply
* [PATCH] arm64: probes: Handle probes on hinted conditional branch instructions
From: Vladimir Murzin @ 2026-05-15 13:37 UTC (permalink / raw)
To: linux-arm-kernel
BC.cond instructions introduced by FEAT_HBC cannot be executed
out-of-line, like other branch instructions. However, they can be
simulated in the same way as B.cond instructions.
Extend the B.cond decoder mask to match BC.cond instructions as well,
and handle them using the existing B.cond simulation path.
Fixes: 7f86d128e437 ("arm64: add HWCAP for FEAT_HBC (hinted conditional branches)")
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
---
arch/arm64/include/asm/insn.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index f463a654a2bb..cc0702fa64a7 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -409,7 +409,7 @@ __AARCH64_INSN_FUNCS(cbz, 0x7F000000, 0x34000000)
__AARCH64_INSN_FUNCS(cbnz, 0x7F000000, 0x35000000)
__AARCH64_INSN_FUNCS(tbz, 0x7F000000, 0x36000000)
__AARCH64_INSN_FUNCS(tbnz, 0x7F000000, 0x37000000)
-__AARCH64_INSN_FUNCS(bcond, 0xFF000010, 0x54000000)
+__AARCH64_INSN_FUNCS(bcond, 0xFF000000, 0x54000000)
__AARCH64_INSN_FUNCS(svc, 0xFFE0001F, 0xD4000001)
__AARCH64_INSN_FUNCS(hvc, 0xFFE0001F, 0xD4000002)
__AARCH64_INSN_FUNCS(smc, 0xFFE0001F, 0xD4000003)
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v6 09/13] coresight: etm4x: missing cscfg_csdev_disable_active_config() in perf enable
From: Yeoreum Yun @ 2026-05-15 13:35 UTC (permalink / raw)
To: Leo Yan
Cc: coresight, linux-arm-kernel, linux-kernel, suzuki.poulose,
mike.leach, james.clark, alexander.shishkin, jie.gan
In-Reply-To: <20260515093923.GJ34802@e132581.arm.com>
Hi Leo,
> On Wed, Apr 22, 2026 at 02:21:59PM +0100, Yeoreum Yun wrote:
>
> [...]
>
> > @@ -895,6 +895,8 @@ static int etm4_parse_event_config(struct coresight_device *csdev,
> > * Missing BB support could cause silent decode errors
> > * so fail to open if it's not supported.
> > */
> > + if (cfg_hash)
> > + cscfg_csdev_disable_active_config(csdev);
>
> I prefer do a bit refactoring for this.
>
> we just save cfg_hash and cfg_preset into drvdata in
> etm4_parse_event_config():
>
> drvdata->cfg_hash = ATTR_CFG_GET_FLD(attr, configid);
> if (drvdata->cfg_hash)
> drvdata->preset = ATTR_CFG_GET_FLD(attr, preset);
>
> Then create two helpers:
>
> etm4_cscfg_enable(csdev) {
> struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>
> return cscfg_csdev_enable_active_config(csdev, drvdata->cfg_hash,
> drvdata->preset);
> }
>
> etm4_cscfg_disable(csdev) {
> cscfg_csdev_disable_active_config(csdev);
> }
>
> These helpers will be used by etm4_{enable|disable}_perf()
> and etm4_{enable|disable}_sysfs(). This might benefit the future cscfg
> refactoring.
I think this seems some over-engineering since the
etm4_cscfg_enable/disable() just an wrapper for
cscfg_csdev_enable/disable_active_config() but just increase size of drvdata.
It's not late to delay when we do refactoring the cscfg
and at that time, we can consider some place to save cfg_hash and
preset. If we do right now, personally, there seems no benefit for this.
Am I missing something?
Thanks.
[...]
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH 1/3] iommu/io-pgtable-arm: Use consistent sizes for page allocation and freeing
From: Jason Gunthorpe @ 2026-05-15 13:36 UTC (permalink / raw)
To: Mostafa Saleh
Cc: iommu, linux-arm-kernel, linux-kernel, robin.murphy, will, joro
In-Reply-To: <20260513215203.3852661-2-smostafa@google.com>
On Wed, May 13, 2026 at 09:52:01PM +0000, Mostafa Saleh wrote:
> At the moment we use alloc_size to allocate memory but then there
> is a logical error where we just size in the error and free path,
> which might be smaller.
> Also we size to do DMA-API operations, which is OK, but confusing.
>
> Instead of this error-prone handling, just set size to alloc_size
> and use it everywhere.
>
> Signed-off-by: Mostafa Saleh <smostafa@google.com>
> ---
> drivers/iommu/io-pgtable-arm.c | 11 ++++++-----
> 1 file changed, 6 insertions(+), 5 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
This is similar to how iommupt works, pt_top_memsize_lg2() rounds up
the top table size to the alignment minimum and we just dma map
flush/etc the larger size everwhere.
Jason
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: ti: k3-j784s4: Add GPU node
From: Nishanth Menon @ 2026-05-15 13:33 UTC (permalink / raw)
To: Antonios Christidis
Cc: Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, devicetree,
linux-kernel
In-Reply-To: <20260506-j784s4_gpu_node_upstream-v2-1-23d6a2565ac0@ti.com>
On 15:18-20260506, Antonios Christidis wrote:
> Add the Series BXS GPU node for j784s4 device tree.
>
Adding documentation why j721s2 compatible is correct for j784s4 is
needed.
[...]
> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> index 78fcd0c40abc..ddb9385cd942 100644
> --- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> @@ -137,6 +137,20 @@ serdes2: serdes@5020000 {
> };
> };
>
> + gpu: gpu@4e20000000 {
https://docs.kernel.org/devicetree/bindings/dts-coding-style.html
"Nodes on any bus, thus using unit addresses for children, shall be
ordered by unit address in ascending order. Alternatively for some
subarchitectures, nodes of the same type can be grouped together,
e.g. all I2C controllers one after another even if this breaks unit
address ordering."
Any specific reason to keep this patch ordering?
> + compatible = "ti,j721s2-gpu", "img,img-bxs-4-64", "img,img-rogue";
^^ j721s2-gpu: please clarify in commit message.
[...]
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
https://ti.com/opensource
^ permalink raw reply
* Re: [PATCH 3/3] iommu/io-pgtable-arm: Use address conversion consistently
From: Jason Gunthorpe @ 2026-05-15 13:33 UTC (permalink / raw)
To: Mostafa Saleh
Cc: iommu, linux-arm-kernel, linux-kernel, robin.murphy, will, joro
In-Reply-To: <20260513215203.3852661-4-smostafa@google.com>
On Wed, May 13, 2026 at 09:52:03PM +0000, Mostafa Saleh wrote:
> Use consistent address conversions in the driver:
> - virt_to_phys(): For all virtual to physical address conversion,
> convert __pa users as we don’t need to rely on it type casting.
> - phys_to_virt(): For all physical to virtual address conversion,
> similarly, convert __va users.
>
> That changes nothing at all. However, it will be useful when
> compiling this file for the KVM hypervisor as it can cleanly
> replace virt_to_phys/phys_to_virt
>
> Signed-off-by: Mostafa Saleh <smostafa@google.com>
> ---
> drivers/iommu/io-pgtable-arm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm-smmu: qcom: Add compatible for IPQ9650 SoC
From: Kathiravan Thirumoorthy @ 2026-05-15 13:30 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, iommu, devicetree, linux-kernel
In-Reply-To: <20260512-ipq9650_smmu_binding-v1-1-04defdaa140c@oss.qualcomm.com>
On 5/12/2026 12:17 PM, Kathiravan Thirumoorthy wrote:
> Qualcomm IPQ9650 SoC include APPS SMMU that implements arm,mmu-500.
> Document the compatible for the same.
Kindly ignore this patch. I will repost along with DTSI changes once it
is validated again!
>
> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> index 06fb5c8e7547..226f16711d67 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> @@ -37,6 +37,7 @@ properties:
> - enum:
> - qcom,eliza-smmu-500
> - qcom,glymur-smmu-500
> + - qcom,ipq9650-smmu-500
> - qcom,kaanapali-smmu-500
> - qcom,milos-smmu-500
> - qcom,qcm2290-smmu-500
>
> ---
> base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
> change-id: 20260512-ipq9650_smmu_binding-36dc05d39860
>
> Best regards,
> --
> Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
>
^ permalink raw reply
* Re: [PATCH v6 02/13] coresight: etm4x: fix underflow for nrseqstate
From: Leo Yan @ 2026-05-15 13:29 UTC (permalink / raw)
To: Yeoreum Yun
Cc: coresight, linux-arm-kernel, linux-kernel, suzuki.poulose,
mike.leach, james.clark, alexander.shishkin, jie.gan
In-Reply-To: <agb/NdYS/2jXdog0@e129823.arm.com>
On Fri, May 15, 2026 at 12:10:45PM +0100, Yeoreum Yun wrote:
[...]
> TBH, the number of transition is determinied by the MAX number of
> SEQ_STATE that's why I think define the ETM_MAX_SEQ_TRANSITIONS with
>
> #define ETM_MAX_SEQ_TRANSITIONS (ETM_MAX_SEQ_STATE - 1)
>
> and uses ETM_MAX_SEQ_TRANSITIONS for the TCRSEQEVR and seq_ctrl.
>
> Thought?
Looks good to me.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox