* [PATCH net V2 1/2] net: xilinx: axienet: Correct BD length masks to match AXIDMA IP spec
From: Suraj Gupta @ 2026-03-26 18:55 UTC (permalink / raw)
To: andrew+netdev, davem, edumazet, kuba, pabeni, michal.simek,
sean.anderson, radhey.shyam.pandey, horms
Cc: netdev, linux-arm-kernel, linux-kernel, harini.katakam
In-Reply-To: <20260326185510.3840084-1-suraj.gupta2@amd.com>
The XAXIDMA_BD_CTRL_LENGTH_MASK and XAXIDMA_BD_STS_ACTUAL_LEN_MASK
macros were defined as 0x007FFFFF (23 bits), but the AXI DMA IP
product guide (PG021) specifies the buffer length field as bits 25:0
(26 bits). Update both masks to match the IP documentation.
In practice this had no functional impact, since Ethernet frames are
far smaller than 2^23 bytes and the extra bits were always zero, but
the masks should still reflect the hardware specification.
Fixes: 8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver")
Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
---
drivers/net/ethernet/xilinx/xilinx_axienet.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet.h b/drivers/net/ethernet/xilinx/xilinx_axienet.h
index 5ff742103beb..602389843342 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet.h
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet.h
@@ -105,7 +105,7 @@
#define XAXIDMA_BD_HAS_DRE_MASK 0xF00 /* Whether has DRE mask */
#define XAXIDMA_BD_WORDLEN_MASK 0xFF /* Whether has DRE mask */
-#define XAXIDMA_BD_CTRL_LENGTH_MASK 0x007FFFFF /* Requested len */
+#define XAXIDMA_BD_CTRL_LENGTH_MASK GENMASK(25, 0) /* Requested len */
#define XAXIDMA_BD_CTRL_TXSOF_MASK 0x08000000 /* First tx packet */
#define XAXIDMA_BD_CTRL_TXEOF_MASK 0x04000000 /* Last tx packet */
#define XAXIDMA_BD_CTRL_ALL_MASK 0x0C000000 /* All control bits */
@@ -130,7 +130,7 @@
#define XAXIDMA_BD_CTRL_TXEOF_MASK 0x04000000 /* Last tx packet */
#define XAXIDMA_BD_CTRL_ALL_MASK 0x0C000000 /* All control bits */
-#define XAXIDMA_BD_STS_ACTUAL_LEN_MASK 0x007FFFFF /* Actual len */
+#define XAXIDMA_BD_STS_ACTUAL_LEN_MASK GENMASK(25, 0) /* Actual len */
#define XAXIDMA_BD_STS_COMPLETE_MASK 0x80000000 /* Completed */
#define XAXIDMA_BD_STS_DEC_ERR_MASK 0x40000000 /* Decode error */
#define XAXIDMA_BD_STS_SLV_ERR_MASK 0x20000000 /* Slave error */
--
2.49.1
^ permalink raw reply related
* [PATCH net V2 0/2] Correct BD length masks and BQL accounting for multi-BD TX packets
From: Suraj Gupta @ 2026-03-26 18:55 UTC (permalink / raw)
To: andrew+netdev, davem, edumazet, kuba, pabeni, michal.simek,
sean.anderson, radhey.shyam.pandey, horms
Cc: netdev, linux-arm-kernel, linux-kernel, harini.katakam
This patch series fixes two issues in the Xilinx AXI Ethernet driver:
1. Corrects the BD length masks to match the AXIDMA IP spec.
2. Fixes BQL accounting for multi-BD TX packets.
---
Changes in V2:
Use GENMASK() to define the BD length masks.
---
Suraj Gupta (2):
net: xilinx: axienet: Correct BD length masks to match AXIDMA IP spec
net: xilinx: axienet: Fix BQL accounting for multi-BD TX packets
drivers/net/ethernet/xilinx/xilinx_axienet.h | 7 +++++--
.../net/ethernet/xilinx/xilinx_axienet_main.c | 20 +++++++++----------
2 files changed, 15 insertions(+), 12 deletions(-)
--
2.49.1
^ permalink raw reply
* Re: [PATCH v4 3/7] pinctrl: extract pinctrl_generic_to_map() from pinctrl_generic_pins_function_dt_node_to_map()
From: Conor Dooley @ 2026-03-26 18:55 UTC (permalink / raw)
To: Frank Li
Cc: Peter Rosin, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rafał Miłecki, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-kernel, linux-gpio,
devicetree, imx, linux-arm-kernel, Haibo Chen
In-Reply-To: <20260326-concur-eel-3e0b3d91e00a@spud>
[-- Attachment #1: Type: text/plain, Size: 4792 bytes --]
On Thu, Mar 26, 2026 at 06:52:12PM +0000, Conor Dooley wrote:
> On Wed, Mar 25, 2026 at 07:04:12PM -0400, Frank Li wrote:
>
> > diff --git a/drivers/pinctrl/pinctrl-generic.c b/drivers/pinctrl/pinctrl-generic.c
> > index efb39c6a670331775855efdc8566102b5c6202ef..20a216ae63e91b69985ea4cfcd0b57103c6ca950 100644
> > --- a/drivers/pinctrl/pinctrl-generic.c
> > +++ b/drivers/pinctrl/pinctrl-generic.c
> > @@ -17,29 +17,18 @@
> > #include "pinctrl-utils.h"
> > #include "pinmux.h"
> >
> > -static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *pctldev,
>
> > +int
> > +pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent,
>
> Can you drop this stylistic change please? The
Whoops, cut myself off. To be clear, what I am asking for is to keep the
"int" etc on the same line as the function name. This function is new,
but you did it for the existing function too and the comparison is here.
>
> > + struct device_node *np, struct pinctrl_map **maps,
> > + unsigned int *num_maps, unsigned int *num_reserved_maps,
> > + const char **group_names, unsigned int ngroups,
> > + const char **functions, unsigned int *pins)
> > {
> > struct device *dev = pctldev->dev;
> > - const char **functions;
> > + int npins, ret, reserve = 1;
> > + unsigned int num_configs;
> > const char *group_name;
> > unsigned long *configs;
> > - unsigned int num_configs, pin, *pins;
> > - int npins, ret, reserve = 1;
> > -
> > - npins = of_property_count_u32_elems(np, "pins");
> > -
> > - if (npins < 1) {
> > - dev_err(dev, "invalid pinctrl group %pOFn.%pOFn %d\n",
> > - parent, np, npins);
> > - return npins;
> > - }
> >
> > group_name = devm_kasprintf(dev, GFP_KERNEL, "%pOFn.%pOFn", parent, np);
> > if (!group_name)
> > @@ -51,22 +40,6 @@ static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *p
> > if (!pins)
> > return -ENOMEM;
>
> This looks suspect. You've left the pins allocation behind:
> pins = devm_kcalloc(dev, npins, sizeof(*pins), GFP_KERNEL);
> if (!pins)
> return -ENOMEM;
> but pinctrl_generic_pins_function_dt_subnode_to_map() has already
> populated this array before calling the function.
>
> Also, this should probably be
> Suggested-by: Conor Dooley <conor.dooley@microchip.com>
>
> Cheers,
> Conor.
>
> >
> > - functions = devm_kcalloc(dev, npins, sizeof(*functions), GFP_KERNEL);
> > - if (!functions)
> > - return -ENOMEM;
> > -
> > - for (int i = 0; i < npins; i++) {
> > - ret = of_property_read_u32_index(np, "pins", i, &pin);
> > - if (ret)
> > - return ret;
> > -
> > - pins[i] = pin;
> > -
> > - ret = of_property_read_string(np, "function", &functions[i]);
> > - if (ret)
> > - return ret;
> > - }
> > -
> > ret = pinctrl_utils_reserve_map(pctldev, maps, num_reserved_maps, num_maps, reserve);
> > if (ret)
> > return ret;
> > @@ -103,6 +76,54 @@ static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *p
> > return 0;
> > };
> >
> > +static int
> > +pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *pctldev,
> > + struct device_node *parent,
> > + struct device_node *np,
> > + struct pinctrl_map **maps,
> > + unsigned int *num_maps,
> > + unsigned int *num_reserved_maps,
> > + const char **group_names,
> > + unsigned int ngroups)
> > +{
> > + struct device *dev = pctldev->dev;
> > + unsigned int pin, *pins;
> > + const char **functions;
> > + int npins, ret;
> > +
> > + npins = of_property_count_u32_elems(np, "pins");
> > +
> > + if (npins < 1) {
> > + dev_err(dev, "invalid pinctrl group %pOFn.%pOFn %d\n",
> > + parent, np, npins);
> > + return npins;
> > + }
> > +
> > + pins = devm_kcalloc(dev, npins, sizeof(*pins), GFP_KERNEL);
> > + if (!pins)
> > + return -ENOMEM;
> > +
> > + functions = devm_kcalloc(dev, npins, sizeof(*functions), GFP_KERNEL);
> > + if (!functions)
> > + return -ENOMEM;
> > +
> > + for (int i = 0; i < npins; i++) {
> > + ret = of_property_read_u32_index(np, "pins", i, &pin);
> > + if (ret)
> > + return ret;
> > +
> > + pins[i] = pin;
> > +
> > + ret = of_property_read_string(np, "function", &functions[i]);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + return pinctrl_generic_to_map(pctldev, parent, np, maps, num_maps,
> > + num_reserved_maps, group_names, ngroups,
> > + functions, pins);
> > +}
> > +
> > /*
> > * For platforms that do not define groups or functions in the driver, but
> > * instead use the devicetree to describe them. This function will, unlike
> >
> > --
> > 2.43.0
> >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 3/7] pinctrl: extract pinctrl_generic_to_map() from pinctrl_generic_pins_function_dt_node_to_map()
From: Conor Dooley @ 2026-03-26 18:52 UTC (permalink / raw)
To: Frank Li
Cc: Peter Rosin, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rafał Miłecki, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-kernel, linux-gpio,
devicetree, imx, linux-arm-kernel, Haibo Chen
In-Reply-To: <20260325-pinctrl-mux-v4-3-043c2c82e623@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 4227 bytes --]
On Wed, Mar 25, 2026 at 07:04:12PM -0400, Frank Li wrote:
> diff --git a/drivers/pinctrl/pinctrl-generic.c b/drivers/pinctrl/pinctrl-generic.c
> index efb39c6a670331775855efdc8566102b5c6202ef..20a216ae63e91b69985ea4cfcd0b57103c6ca950 100644
> --- a/drivers/pinctrl/pinctrl-generic.c
> +++ b/drivers/pinctrl/pinctrl-generic.c
> @@ -17,29 +17,18 @@
> #include "pinctrl-utils.h"
> #include "pinmux.h"
>
> -static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *pctldev,
> +int
> +pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent,
Can you drop this stylistic change please? The
> + struct device_node *np, struct pinctrl_map **maps,
> + unsigned int *num_maps, unsigned int *num_reserved_maps,
> + const char **group_names, unsigned int ngroups,
> + const char **functions, unsigned int *pins)
> {
> struct device *dev = pctldev->dev;
> - const char **functions;
> + int npins, ret, reserve = 1;
> + unsigned int num_configs;
> const char *group_name;
> unsigned long *configs;
> - unsigned int num_configs, pin, *pins;
> - int npins, ret, reserve = 1;
> -
> - npins = of_property_count_u32_elems(np, "pins");
> -
> - if (npins < 1) {
> - dev_err(dev, "invalid pinctrl group %pOFn.%pOFn %d\n",
> - parent, np, npins);
> - return npins;
> - }
>
> group_name = devm_kasprintf(dev, GFP_KERNEL, "%pOFn.%pOFn", parent, np);
> if (!group_name)
> @@ -51,22 +40,6 @@ static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *p
> if (!pins)
> return -ENOMEM;
This looks suspect. You've left the pins allocation behind:
pins = devm_kcalloc(dev, npins, sizeof(*pins), GFP_KERNEL);
if (!pins)
return -ENOMEM;
but pinctrl_generic_pins_function_dt_subnode_to_map() has already
populated this array before calling the function.
Also, this should probably be
Suggested-by: Conor Dooley <conor.dooley@microchip.com>
Cheers,
Conor.
>
> - functions = devm_kcalloc(dev, npins, sizeof(*functions), GFP_KERNEL);
> - if (!functions)
> - return -ENOMEM;
> -
> - for (int i = 0; i < npins; i++) {
> - ret = of_property_read_u32_index(np, "pins", i, &pin);
> - if (ret)
> - return ret;
> -
> - pins[i] = pin;
> -
> - ret = of_property_read_string(np, "function", &functions[i]);
> - if (ret)
> - return ret;
> - }
> -
> ret = pinctrl_utils_reserve_map(pctldev, maps, num_reserved_maps, num_maps, reserve);
> if (ret)
> return ret;
> @@ -103,6 +76,54 @@ static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *p
> return 0;
> };
>
> +static int
> +pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *pctldev,
> + struct device_node *parent,
> + struct device_node *np,
> + struct pinctrl_map **maps,
> + unsigned int *num_maps,
> + unsigned int *num_reserved_maps,
> + const char **group_names,
> + unsigned int ngroups)
> +{
> + struct device *dev = pctldev->dev;
> + unsigned int pin, *pins;
> + const char **functions;
> + int npins, ret;
> +
> + npins = of_property_count_u32_elems(np, "pins");
> +
> + if (npins < 1) {
> + dev_err(dev, "invalid pinctrl group %pOFn.%pOFn %d\n",
> + parent, np, npins);
> + return npins;
> + }
> +
> + pins = devm_kcalloc(dev, npins, sizeof(*pins), GFP_KERNEL);
> + if (!pins)
> + return -ENOMEM;
> +
> + functions = devm_kcalloc(dev, npins, sizeof(*functions), GFP_KERNEL);
> + if (!functions)
> + return -ENOMEM;
> +
> + for (int i = 0; i < npins; i++) {
> + ret = of_property_read_u32_index(np, "pins", i, &pin);
> + if (ret)
> + return ret;
> +
> + pins[i] = pin;
> +
> + ret = of_property_read_string(np, "function", &functions[i]);
> + if (ret)
> + return ret;
> + }
> +
> + return pinctrl_generic_to_map(pctldev, parent, np, maps, num_maps,
> + num_reserved_maps, group_names, ngroups,
> + functions, pins);
> +}
> +
> /*
> * For platforms that do not define groups or functions in the driver, but
> * instead use the devicetree to describe them. This function will, unlike
>
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] regulator: dt-bindings: mt6315: Add regulator supplies
From: Conor Dooley @ 2026-03-26 18:35 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Mark Brown, Liam Girdwood, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
linux-kernel, linux-arm-kernel, linux-mediatek, devicetree
In-Reply-To: <20260326081050.1115201-2-wenst@chromium.org>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] arm64/entry: Fix involuntary preemption exception masking
From: Thomas Gleixner @ 2026-03-26 18:32 UTC (permalink / raw)
To: Mark Rutland
Cc: vladimir.murzin, peterz, catalin.marinas, ruanjinjie,
linux-kernel, luto, will, linux-arm-kernel
In-Reply-To: <acV2552t5X4OlNYi@J2N7QTR9R3>
Mark!
On Thu, Mar 26 2026 at 18:11, Mark Rutland wrote:
>
> I've pushed a (very early, WIP) draft to
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/entry/rework
>
> ... which is missing commit messages, comments, etc, but seems to work.
>
> I'll see about getting that tested, cleaned up, and on-list.
I've pulled it and looked at the v7.0-rc3.. diff.
That looks really good! Thanks for taking care of that.
As a related side note. Seeing that even more of the generic entry code
is moving to include/linux/, I'm pondering to move the content back into
kernel/entry and include those "local" headers from the
include/linux/... so that everything is to find in one place, but that's
a purely cosmetic problem :)
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v9 1/5] PCI: Add pcie_get_link_speed() helper for safe array access
From: Manivannan Sadhasivam @ 2026-03-26 18:32 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Hans Zhang, lpieralisi, jingoohan1, kwilczynski, bhelgaas,
florian.fainelli, jim2101024, robh, ilpo.jarvinen, linux-arm-msm,
linux-arm-kernel, linux-renesas-soc, claudiu.beznea.uj,
linux-mediatek, linux-tegra, linux-omap, bcm-kernel-feedback-list,
linux-pci, linux-kernel, shawn.lin
In-Reply-To: <20260326181624.GA1331242@bhelgaas>
On Thu, Mar 26, 2026 at 01:16:24PM -0500, Bjorn Helgaas wrote:
> On Sat, Mar 14, 2026 at 12:55:18AM +0800, Hans Zhang wrote:
> > The pcie_link_speed[] array is indexed by PCIe generation numbers
> > (1 = 2.5 GT/s, 2 = 5 GT/s, ...). Several drivers use it directly,
> > which can lead to out-of-bounds accesses if an invalid generation
> > number is used.
> >
> > Introduce a helper function pcie_get_link_speed() that returns the
> > corresponding enum pci_bus_speed value for a given generation number,
> > or PCI_SPEED_UNKNOWN if the generation is out of range. This will
> > allow us to safely handle invalid values after the range check is
> > removed from of_pci_get_max_link_speed().
> >
> > Signed-off-by: Hans Zhang <18255117159@163.com>
> > ---
> > drivers/pci/pci.h | 2 ++
> > drivers/pci/probe.c | 16 ++++++++++++++++
> > 2 files changed, 18 insertions(+)
> >
> > diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> > index 13d998fbacce..409aca7d737a 100644
> > --- a/drivers/pci/pci.h
> > +++ b/drivers/pci/pci.h
> > @@ -108,6 +108,8 @@ struct pcie_tlp_log;
> > PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE)
> >
> > extern const unsigned char pcie_link_speed[];
> > +unsigned char pcie_get_link_speed(unsigned int speed);
> > +
> > extern bool pci_early_dump;
> >
> > extern struct mutex pci_rescan_remove_lock;
> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > index bccc7a4bdd79..d6592898330c 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -783,6 +783,22 @@ const unsigned char pcie_link_speed[] = {
> > };
> > EXPORT_SYMBOL_GPL(pcie_link_speed);
> >
> > +/**
> > + * pcie_link_speed_value - Get speed value from PCIe generation number
>
> Wrong name here (pcie_link_speed_value vs pcie_get_link_speed)
> (pointed out by Sashiko).
>
Noticed this one while applying.
> > + * @speed: PCIe speed (1-based: 1 = 2.5GT, 2 = 5GT, ...)
> > + *
> > + * Returns the speed value (e.g., PCIE_SPEED_2_5GT) if @speed is valid,
> > + * otherwise returns PCI_SPEED_UNKNOWN.
> > + */
> > +unsigned char pcie_get_link_speed(unsigned int speed)
>
> Sashiko also pointed out that the commit log says this returns "enum
> pci_bus_speed", while here we return unsigned char (which is also the
> type of pcie_link_speed[x]).
>
> https://sashiko.dev/#/patchset/20260313165522.123518-1-18255117159%40163.com
>
This one I didn't, but fixed now, thanks!
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v9 0/5] PCI: of: Remove max-link-speed generation validation
From: Manivannan Sadhasivam @ 2026-03-26 18:29 UTC (permalink / raw)
To: lpieralisi, jingoohan1, kwilczynski, bhelgaas, helgaas,
florian.fainelli, jim2101024, Hans Zhang
Cc: robh, ilpo.jarvinen, linux-arm-msm, linux-arm-kernel,
linux-renesas-soc, claudiu.beznea.uj, linux-mediatek, linux-tegra,
linux-omap, bcm-kernel-feedback-list, linux-pci, linux-kernel,
shawn.lin
In-Reply-To: <20260313165522.123518-1-18255117159@163.com>
On Sat, 14 Mar 2026 00:55:17 +0800, Hans Zhang wrote:
> This series moves the validation from the common OF function to the
> individual PCIe controller drivers. To protect against out-of-bounds
> accesses to the pcie_link_speed[] array, we first introduce a helper
> function pcie_get_link_speed() that safely returns the speed value
> (or PCI_SPEED_UNKNOWN) for a given generation number.
>
> Then all direct uses of pcie_link_speed[] as an array are converted to
> use the new helper, ensuring that even if an invalid generation number
> reaches those code paths, no out-of-bounds access occurs.
>
> [...]
Applied, thanks!
[1/5] PCI: Add pcie_get_link_speed() helper for safe array access
commit: df61f4732adf9de5ad1f5e71b7670710c1597d18
[2/5] PCI: dwc: Use pcie_get_link_speed() helper for safe array access
commit: d884b0e51459175f17ddc52759ea4533bb752130
[3/5] PCI: j721e: Validate max-link-speed from DT
commit: 1542ac6d83d0b5706f45e2937de7b4f7b8c4831d
[4/5] PCI: controller: Validate max-link-speed
commit: d0cc5918a1d539344190cbb19fa3ae0e7b0dca1e
[5/5] PCI: of: Remove max-link-speed generation validation
commit: 15217c7015c0e1804925693c55d721aad8987e32
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 3/3] KVM: arm64: Don't pass host_debug_state to BRBE world-switch routines
From: Will Deacon @ 2026-03-26 18:21 UTC (permalink / raw)
To: kvmarm
Cc: mark.rutland, linux-arm-kernel, Marc Zyngier, Oliver Upton,
James Clark, Leo Yan, Suzuki K Poulose, Fuad Tabba,
Alexandru Elisei, Yabin Cui
In-Reply-To: <20260326141214.18990-4-will@kernel.org>
On Thu, Mar 26, 2026 at 02:12:13PM +0000, Will Deacon wrote:
> Now that the SPE and BRBE nVHE world-switch routines operate on the
> host_debug_state directly, tweak the BRBE code to do the same for
> consistency.
>
> This is purely cosmetic.
>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Oliver Upton <oupton@kernel.org>
> Cc: James Clark <james.clark@linaro.org>
> Cc: Leo Yan <leo.yan@arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Cc: Fuad Tabba <tabba@google.com>
> Cc: Alexandru Elisei <alexandru.elisei@arm.com>
> Tested-by: Fuad Tabba <tabba@google.com>
> Reviewed-by: Fuad Tabba <tabba@google.com>
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
> arch/arm64/kvm/hyp/nvhe/debug-sr.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/debug-sr.c b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> index 84bc80f4e36b..50413171bd1a 100644
> --- a/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> +++ b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> @@ -156,9 +156,9 @@ static void __trace_switch_to_host(void)
> *host_data_ptr(host_debug_state.trfcr_el1));
> }
>
> -static void __debug_save_brbe(u64 *brbcr_el1)
> +static void __debug_save_brbe(void)
> {
> - *brbcr_el1 = 0;
> + u64 *brbcr_el1 = host_data_ptr(host_debug_state.brbcr_el1);
Oh no, I've been sashiko'd!
The above is definitely not "purely cosmetic" and I should retain the
'*brbcr_el1 = 0; ' line.
Will
^ permalink raw reply
* Re: [PATCH v9 1/5] PCI: Add pcie_get_link_speed() helper for safe array access
From: Bjorn Helgaas @ 2026-03-26 18:16 UTC (permalink / raw)
To: Hans Zhang
Cc: lpieralisi, jingoohan1, mani, kwilczynski, bhelgaas,
florian.fainelli, jim2101024, robh, ilpo.jarvinen, linux-arm-msm,
linux-arm-kernel, linux-renesas-soc, claudiu.beznea.uj,
linux-mediatek, linux-tegra, linux-omap, bcm-kernel-feedback-list,
linux-pci, linux-kernel, shawn.lin
In-Reply-To: <20260313165522.123518-2-18255117159@163.com>
On Sat, Mar 14, 2026 at 12:55:18AM +0800, Hans Zhang wrote:
> The pcie_link_speed[] array is indexed by PCIe generation numbers
> (1 = 2.5 GT/s, 2 = 5 GT/s, ...). Several drivers use it directly,
> which can lead to out-of-bounds accesses if an invalid generation
> number is used.
>
> Introduce a helper function pcie_get_link_speed() that returns the
> corresponding enum pci_bus_speed value for a given generation number,
> or PCI_SPEED_UNKNOWN if the generation is out of range. This will
> allow us to safely handle invalid values after the range check is
> removed from of_pci_get_max_link_speed().
>
> Signed-off-by: Hans Zhang <18255117159@163.com>
> ---
> drivers/pci/pci.h | 2 ++
> drivers/pci/probe.c | 16 ++++++++++++++++
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index 13d998fbacce..409aca7d737a 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -108,6 +108,8 @@ struct pcie_tlp_log;
> PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE)
>
> extern const unsigned char pcie_link_speed[];
> +unsigned char pcie_get_link_speed(unsigned int speed);
> +
> extern bool pci_early_dump;
>
> extern struct mutex pci_rescan_remove_lock;
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index bccc7a4bdd79..d6592898330c 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -783,6 +783,22 @@ const unsigned char pcie_link_speed[] = {
> };
> EXPORT_SYMBOL_GPL(pcie_link_speed);
>
> +/**
> + * pcie_link_speed_value - Get speed value from PCIe generation number
Wrong name here (pcie_link_speed_value vs pcie_get_link_speed)
(pointed out by Sashiko).
> + * @speed: PCIe speed (1-based: 1 = 2.5GT, 2 = 5GT, ...)
> + *
> + * Returns the speed value (e.g., PCIE_SPEED_2_5GT) if @speed is valid,
> + * otherwise returns PCI_SPEED_UNKNOWN.
> + */
> +unsigned char pcie_get_link_speed(unsigned int speed)
Sashiko also pointed out that the commit log says this returns "enum
pci_bus_speed", while here we return unsigned char (which is also the
type of pcie_link_speed[x]).
https://sashiko.dev/#/patchset/20260313165522.123518-1-18255117159%40163.com
> +{
> + if (speed >= ARRAY_SIZE(pcie_link_speed))
> + return PCI_SPEED_UNKNOWN;
> +
> + return pcie_link_speed[speed];
> +}
> +EXPORT_SYMBOL_GPL(pcie_get_link_speed);
> +
> const char *pci_speed_string(enum pci_bus_speed speed)
> {
> /* Indexed by the pci_bus_speed enum */
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: stmmac: remove axi_kbbe, axi_mb and axi_rb members
From: Russell King (Oracle) @ 2026-03-26 18:15 UTC (permalink / raw)
To: Simon Horman
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, Conor Dooley,
David S. Miller, devicetree, Eric Dumazet, Giuseppe Cavallaro,
Jakub Kicinski, Jose Abreu, Krzysztof Kozlowski, linux-arm-kernel,
linux-stm32, netdev, Paolo Abeni, Rob Herring, Yao Zi
In-Reply-To: <acVxNBLE8Ck2qfjc@shell.armlinux.org.uk>
On Thu, Mar 26, 2026 at 05:47:32PM +0000, Russell King (Oracle) wrote:
> On Thu, Mar 26, 2026 at 05:29:43PM +0000, Simon Horman wrote:
> > On Tue, Mar 24, 2026 at 10:05:40AM +0000, Russell King (Oracle) wrote:
> > > axi_kbbe, axi_mb and axi_rb are all written, but nothing ever reads
> > > their values. Remove the code that sets these and the struct members.
> > >
> > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> >
> > Hi Russell,
> >
> > FYI, AI review suggests that these fields should also be removed from
> > Documentation/networking/device_drivers/ethernet/stmicro/stmmac.rst
>
> I noticed. I've prepared an update if netdev folk want that to happen
> as I've noticed that that documentation is fairly out of date now.
There's another reason I haven't submitted an update, and that's
because netdev is fairly backlogged at the moment - currently there's
381 patches in patchwork - four pages of patchwork, with the oldest
"new" patch dated 21st March. I don't think netdev patchwork needs
more patches at the moment!
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v1 1/3] dt-bindings: arm: fsl: add Variscite DART-MX93 Boards
From: Conor Dooley @ 2026-03-26 18:12 UTC (permalink / raw)
To: Stefano Radaelli
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Shawn Guo, Dario Binacchi, Alexander Stein, Maud Spierings,
Josua Mayer, Markus Niebel, Francesco Dolcini, Primoz Fiser
In-Reply-To: <b7b243c9c3931e8d7ddd984b654e7ef493e84690.1774539301.git.stefano.r@variscite.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 03/15] net: stmmac: qcom-ethqos: eliminate configure_func
From: Russell King (Oracle) @ 2026-03-26 18:12 UTC (permalink / raw)
To: Simon Horman
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-arm-msm,
linux-stm32, Mohd Ayaan Anwar, netdev, Paolo Abeni
In-Reply-To: <20260326180453.GU111839@horms.kernel.org>
On Thu, Mar 26, 2026 at 06:04:53PM +0000, Simon Horman wrote:
> On Tue, Mar 24, 2026 at 01:11:44PM +0000, Russell King (Oracle) wrote:
> > Since ethqos_fix_mac_speed() is called via a function pointer, and only
> > indirects via the configure_func function pointer, eliminate this
> > unnecessary indirection.
> >
> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
>
> ...
>
> > @@ -623,14 +627,6 @@ static void ethqos_configure_sgmii(struct qcom_ethqos *ethqos,
> > ethqos_pcs_set_inband(ethqos, interface == PHY_INTERFACE_MODE_SGMII);
> > }
> >
> > -static void ethqos_fix_mac_speed(void *priv, phy_interface_t interface,
> > - int speed, unsigned int mode)
> > -{
> > - struct qcom_ethqos *ethqos = priv;
> > -
> > - ethqos->configure_func(ethqos, interface, speed);
> > -}
> > -
> > static int qcom_ethqos_serdes_powerup(struct net_device *ndev, void *priv)
> > {
> > struct qcom_ethqos *ethqos = priv;
>
> Hi Russell,
>
> FYI, AI generated review reports that the comment in ethqos_clks_config()
> that references ethqos_fix_mac_speed() should also be updated.
Also already noted (yesterday).
I do keep an eye on patchwork for my own patches - I have a firefox tab
permanently open for my patches in patchwork:
https://patchwork.kernel.org/project/netdevbpf/list/?submitter=165511
Thanks anyway.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH 1/2] arm64/entry: Fix involuntary preemption exception masking
From: Mark Rutland @ 2026-03-26 18:11 UTC (permalink / raw)
To: Thomas Gleixner
Cc: vladimir.murzin, peterz, catalin.marinas, ruanjinjie,
linux-kernel, luto, will, linux-arm-kernel
In-Reply-To: <87ecl7gbeu.ffs@tglx>
On Wed, Mar 25, 2026 at 04:46:01PM +0100, Thomas Gleixner wrote:
> On Wed, Mar 25 2026 at 11:03, Mark Rutland wrote:
> > On Sun, Mar 22, 2026 at 12:25:06AM +0100, Thomas Gleixner wrote:
> > I *think* what would work for us is we could split some of the exit
> > handling (including involuntary preemption) into a "prepare" step, as we
> > have for return to userspace. That way, arm64 could handle exiting
> > something like:
> >
> > local_irq_disable();
> > irqentry_exit_prepare(); // new, all generic logic
> > local_daif_mask();
> > arm64_exit_to_kernel_mode() {
> > ...
> > irqentry_exit(); // ideally irqentry_exit_to_kernel_mode().
> > ...
> > }
> >
> > ... and other architectures can use a combined exit_to_kernel_mode() (or
> > whatever we call that), which does both, e.g.
> >
> > // either noinstr, __always_inline, or a macro
> > void irqentry_prepare_and_exit(void)
>
> That's a bad idea as that would require to do a full kernel rename of
> all existing irqentry_exit() users.
>
> > {
> > irqentry_exit_prepare();
> > irqentry_exit();
> > }
>
> Aside of the naming that should work.
Thanks for confirming!
I've pushed a (very early, WIP) draft to
https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/entry/rework
... which is missing commit messages, comments, etc, but seems to work.
I'll see about getting that tested, cleaned up, and on-list.
Mark.
^ permalink raw reply
* Re: [PATCH net-next v4 1/2] net: stmmac: provide flag to disable EEE
From: Russell King (Oracle) @ 2026-03-26 18:10 UTC (permalink / raw)
To: Kieran Bingham
Cc: Laurent Pinchart, imx, netdev, Andrew Lunn, David S. Miller,
Eric Dumazet, Fabio Estevam, Francesco Dolcini, Frank Li,
Jakub Kicinski, Joy Zou, Marco Felsch, Paolo Abeni,
Pengutronix Kernel Team, Stefan Klug, linux-arm-kernel
In-Reply-To: <177454628933.1078312.13488207016388509694@ping.linuxembedded.co.uk>
On Thu, Mar 26, 2026 at 05:31:29PM +0000, Kieran Bingham wrote:
> This one has been a roller coaster, but I'm glad we got to the bottom of
> it.
>
> I hope someone from synopsis takes note and and documents this for
> future silicon integrations.
I would say that it _is_ clearly documented in the databook. v3.74a
4.3.4. LPI Interrupt already states that this signal is generated in
the receive clock domain, and is not cleared immediately after the LPI
control and status register is read.
It goes on to state that this is because the signal to clear it has to
cross from the CSR clock domain to the receive clock domain to clear
the signal - and states that it is at least _four_ receive clock
cycles.
So, if the dwmac core is operating at 10Mbps, that means its receive
clock is running at 2.5MHz which has a period of 400ns. In this case,
the four receive clock cycles to clear this interrupt is 1.6us,
assuming that the receive clock is running.
However, if EEE is enabled, the receive clock comes from the PHY,
which may gate off when the link re-enters LPI - and this event is
under the control of the remote end, not the local end. So, what this
means is that even though it states four receive clocks to clear the
lpi_intr_o signal, that doesn't necessarily mean it will clear in
1.6us as the receive clock may be stopped.
So, I think it is clearly stated in the databook already, but as it's
just two paragraphs buried in around 1500 pages, that may explain why
it has been missed on iMX.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v9 1/5] PCI: Add pcie_get_link_speed() helper for safe array access
From: Bjorn Helgaas @ 2026-03-26 18:09 UTC (permalink / raw)
To: Hans Zhang
Cc: lpieralisi, jingoohan1, mani, kwilczynski, bhelgaas,
florian.fainelli, jim2101024, robh, ilpo.jarvinen, linux-arm-msm,
linux-arm-kernel, linux-renesas-soc, claudiu.beznea.uj,
linux-mediatek, linux-tegra, linux-omap, bcm-kernel-feedback-list,
linux-pci, linux-kernel, shawn.lin
In-Reply-To: <20260313165522.123518-2-18255117159@163.com>
On Sat, Mar 14, 2026 at 12:55:18AM +0800, Hans Zhang wrote:
> The pcie_link_speed[] array is indexed by PCIe generation numbers
> (1 = 2.5 GT/s, 2 = 5 GT/s, ...). Several drivers use it directly,
> which can lead to out-of-bounds accesses if an invalid generation
> number is used.
>
> Introduce a helper function pcie_get_link_speed() that returns the
> corresponding enum pci_bus_speed value for a given generation number,
> or PCI_SPEED_UNKNOWN if the generation is out of range. This will
> allow us to safely handle invalid values after the range check is
> removed from of_pci_get_max_link_speed().
>
> Signed-off-by: Hans Zhang <18255117159@163.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> drivers/pci/pci.h | 2 ++
> drivers/pci/probe.c | 16 ++++++++++++++++
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index 13d998fbacce..409aca7d737a 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -108,6 +108,8 @@ struct pcie_tlp_log;
> PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE)
>
> extern const unsigned char pcie_link_speed[];
> +unsigned char pcie_get_link_speed(unsigned int speed);
> +
> extern bool pci_early_dump;
>
> extern struct mutex pci_rescan_remove_lock;
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index bccc7a4bdd79..d6592898330c 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -783,6 +783,22 @@ const unsigned char pcie_link_speed[] = {
> };
> EXPORT_SYMBOL_GPL(pcie_link_speed);
>
> +/**
> + * pcie_link_speed_value - Get speed value from PCIe generation number
> + * @speed: PCIe speed (1-based: 1 = 2.5GT, 2 = 5GT, ...)
> + *
> + * Returns the speed value (e.g., PCIE_SPEED_2_5GT) if @speed is valid,
> + * otherwise returns PCI_SPEED_UNKNOWN.
> + */
> +unsigned char pcie_get_link_speed(unsigned int speed)
> +{
> + if (speed >= ARRAY_SIZE(pcie_link_speed))
> + return PCI_SPEED_UNKNOWN;
> +
> + return pcie_link_speed[speed];
> +}
> +EXPORT_SYMBOL_GPL(pcie_get_link_speed);
> +
> const char *pci_speed_string(enum pci_bus_speed speed)
> {
> /* Indexed by the pci_bus_speed enum */
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH net-next 03/15] net: stmmac: qcom-ethqos: eliminate configure_func
From: Simon Horman @ 2026-03-26 18:04 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-arm-msm,
linux-stm32, Mohd Ayaan Anwar, netdev, Paolo Abeni
In-Reply-To: <E1w51Xs-0000000DwVV-2bnh@rmk-PC.armlinux.org.uk>
On Tue, Mar 24, 2026 at 01:11:44PM +0000, Russell King (Oracle) wrote:
> Since ethqos_fix_mac_speed() is called via a function pointer, and only
> indirects via the configure_func function pointer, eliminate this
> unnecessary indirection.
>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
...
> @@ -623,14 +627,6 @@ static void ethqos_configure_sgmii(struct qcom_ethqos *ethqos,
> ethqos_pcs_set_inband(ethqos, interface == PHY_INTERFACE_MODE_SGMII);
> }
>
> -static void ethqos_fix_mac_speed(void *priv, phy_interface_t interface,
> - int speed, unsigned int mode)
> -{
> - struct qcom_ethqos *ethqos = priv;
> -
> - ethqos->configure_func(ethqos, interface, speed);
> -}
> -
> static int qcom_ethqos_serdes_powerup(struct net_device *ndev, void *priv)
> {
> struct qcom_ethqos *ethqos = priv;
Hi Russell,
FYI, AI generated review reports that the comment in ethqos_clks_config()
that references ethqos_fix_mac_speed() should also be updated.
...
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Ville Syrjälä @ 2026-03-26 17:58 UTC (permalink / raw)
To: Maxime Ripard
Cc: Nicolas Frattaroli, Harry Wentland, Leo Li, Rodrigo Siqueira,
Alex Deucher, Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Thomas Zimmermann, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Sandy Huang, Heiko Stübner, Andy Yan,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, kernel, amd-gfx, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, intel-gfx, intel-xe, linux-doc,
Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <20260326-pumpkin-goshawk-of-stamina-0ccb84@houat>
On Thu, Mar 26, 2026 at 06:02:47PM +0100, Maxime Ripard wrote:
> On Wed, Mar 25, 2026 at 08:43:15PM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote:
> > > On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> > > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > +enum drm_connector_color_format {
> > > > > > > > > + /**
> > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > > > > > > + * helpers should pick a suitable color format. All implementations of a
> > > > > > > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > > > > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > > > > > > + * semantics.
> > > > > > > > > + *
> > > > > > > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > > > > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > > > > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > > > > > > + * YCbCr 4:2:0.
> > > > > > > > > + *
> > > > > > > > > + * For display protocols other than HDMI, the recursive bridge chain
> > > > > > > > > + * format selection picks the first chain of bridge formats that works,
> > > > > > > > > + * as has already been the case before the introduction of the "color
> > > > > > > > > + * format" property. Non-HDMI bridges should therefore either sort their
> > > > > > > > > + * bus output formats by preference, or agree on a unified auto format
> > > > > > > > > + * selection logic that's implemented in a common state helper (like
> > > > > > > > > + * how HDMI does it).
> > > > > > > > > + */
> > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > > > > > > > > +
> > > > > > > > > + /**
> > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > > > > > > > > + */
> > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > > > +
> > > > > > > > > + /**
> > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > > > + * not subsampled)
> > > > > > > > > + */
> > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > > > +
> > > > > > > > > + /**
> > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > > > + * with horizontal subsampling)
> > > > > > > > > + */
> > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > > > +
> > > > > > > > > + /**
> > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > > > + */
> > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > > > >
> > > > > > > > Seems like this should document what the quantization range
> > > > > > > > should be for each format.
> > > > > > > >
> > > > > > >
> > > > > > > I don't think so? If you want per-component bit depth values,
> > > > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > > > enum is more abstract than that, and is there to communicate
> > > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > > > by other properties.
> > > > > > >
> > > > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > > > be added; no digital display protocol standard supports it to my
> > > > > > > knowledge, and hopefully none ever will.
> > > > > >
> > > > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > > > >
> > > > > > The i915 behaviour is that YCbCr is always limited range,
> > > > > > RGB can either be full or limited range depending on the
> > > > > > "Broadcast RGB" property and other related factors.
> > > > >
> > > > > So far the HDMI state has both the format and quantization range as
> > > > > different fields. I'm not sure we need to document the range in the
> > > > > format field, maybe only mention it's not part of the format but has a
> > > > > field of its own?
> > > >
> > > > I think we only have it for RGB (on some drivers only?). For YCbCr
> > > > I think the assumption is limited range everywhere.
> > > >
> > > > But I'm not really concerned about documenting struct members.
> > > > What I'm talking about is the *uapi* docs. Surely userspace
> > > > will want to know what the new property actually does so the
> > > > uapi needs to be documented properly. And down the line some
> > > > new driver might also implement the wrong behaviour if there
> > > > is no clear specification.
> > >
> > > Ack
> > >
> > > > So I'm thinking (or perhaps hoping) the rule might be something like:
> > > > - YCbCr limited range
> > > > - RGB full range if "Broadcast RGB" property is not present
> > >
> > > Isn't it much more complicated than that for HDMI though? My
> > > recollection was that any VIC but VIC1 would be limited range, and
> > > anything else full range?
> >
> > Do we have some driver that implements the CTA-861 CE vs. IT mode
> > logic but doesn't expose the "Broadcast RGB" property? I was hoping
> > those would always go hand in hand now.
>
> I'm not sure. i915 and the HDMI state helpers handle it properly (I
> think?) but it looks like only vc4 registers the Broadcast RGB property
> and uses the HDMI state helpers.
>
> And it looks like amdgpu registers Broadcast RGB but doesn't use
> drm_default_rgb_quant_range() which seems suspicious?
If they want just manual full vs. limited then they should
limit the property to not expose the "auto" option at all.
amdgpu also ties this in with the "colorspace" property, which
originally in i915 only controlled the infoframes/etc. But on
amdgpu it now controls various aspects of output color
transformation. The end result is that the property is a complete
mess with most of the values making no sense. And for whatever
reason everyone involved refused to remove/deprecate the
nonsensical values :/
Looks like this series should make sure the documentation for
the "colorspace" property is in sync with the new property
as well. Currently now it's giving conflicting information.
--
Ville Syrjälä
Intel
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: stmmac: remove axi_kbbe, axi_mb and axi_rb members
From: Russell King (Oracle) @ 2026-03-26 17:47 UTC (permalink / raw)
To: Simon Horman
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, Conor Dooley,
David S. Miller, devicetree, Eric Dumazet, Giuseppe Cavallaro,
Jakub Kicinski, Jose Abreu, Krzysztof Kozlowski, linux-arm-kernel,
linux-stm32, netdev, Paolo Abeni, Rob Herring, Yao Zi
In-Reply-To: <20260326172943.GR111839@horms.kernel.org>
On Thu, Mar 26, 2026 at 05:29:43PM +0000, Simon Horman wrote:
> On Tue, Mar 24, 2026 at 10:05:40AM +0000, Russell King (Oracle) wrote:
> > axi_kbbe, axi_mb and axi_rb are all written, but nothing ever reads
> > their values. Remove the code that sets these and the struct members.
> >
> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
>
> Hi Russell,
>
> FYI, AI review suggests that these fields should also be removed from
> Documentation/networking/device_drivers/ethernet/stmicro/stmmac.rst
I noticed. I've prepared an update if netdev folk want that to happen
as I've noticed that that documentation is fairly out of date now.
Do we think it's still useful, or should we consider deleting or
trimming it down? Would it be better to move the struct definitions
into the header file and making the header file part of the docs so
that the documentation is local to the structs?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] net: phy: Introduce Airoha AN8801/R Gigabit Ethernet PHY driver
From: Russell King (Oracle) @ 2026-03-26 17:44 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Andrew Lunn, Andrew Lunn, Louis-Alexis Eyraud, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, AngeloGioacchino Del Regno,
Heiner Kallweit, kevin-kw.huang, macpaul.lin, matthias.bgg,
kernel, netdev, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel
In-Reply-To: <385d2137-0d15-4dc0-8994-9cd48e4150b4@bootlin.com>
On Thu, Mar 26, 2026 at 06:25:20PM +0100, Maxime Chevallier wrote:
> On 26/03/2026 17:56, Andrew Lunn wrote:
> >> What is the timing requirements for a system going into suspend vs a WoL
> >> packet being sent? Should a WoL packet abort entry into suspend? If yes,
> >> then we need to program the MAC before the PHY is suspended, because
> >> suspend could already be in progress.
> >
> > We would then need to hook into the NETDEV_CHANGEADDR notifier, and
> > call into the PHY driver to let it reprogram the MAC address.
>
> We would also probably have to re-do that MAC addr programming at phy
> attach time ? If the PHY isn't attached (e.g. link admin-down on some
> boards), we can't use that notifier as we don't know what netdev to
> listen to. Or I'm missing something ?
Another point to consider in this area:
Should a detached PHY remain with WoL enabled?
If e.g. the network driver is unbound from its device, which certainly
disconnects the PHY from the network interface, should that PHY still
be able to wake up the system when there is no way to configure,
check its status, or handle its interrupts?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v9 1/5] PCI: Add pcie_get_link_speed() helper for safe array access
From: Manivannan Sadhasivam @ 2026-03-26 17:40 UTC (permalink / raw)
To: Hans Zhang, bhelgaas, helgaas
Cc: lpieralisi, jingoohan1, kwilczynski, florian.fainelli, jim2101024,
robh, ilpo.jarvinen, linux-arm-msm, linux-arm-kernel,
linux-renesas-soc, claudiu.beznea.uj, linux-mediatek, linux-tegra,
linux-omap, bcm-kernel-feedback-list, linux-pci, linux-kernel,
shawn.lin
In-Reply-To: <20260313165522.123518-2-18255117159@163.com>
On Sat, Mar 14, 2026 at 12:55:18AM +0800, Hans Zhang wrote:
> The pcie_link_speed[] array is indexed by PCIe generation numbers
> (1 = 2.5 GT/s, 2 = 5 GT/s, ...). Several drivers use it directly,
> which can lead to out-of-bounds accesses if an invalid generation
> number is used.
>
> Introduce a helper function pcie_get_link_speed() that returns the
> corresponding enum pci_bus_speed value for a given generation number,
> or PCI_SPEED_UNKNOWN if the generation is out of range. This will
> allow us to safely handle invalid values after the range check is
> removed from of_pci_get_max_link_speed().
>
Bjorn: Could you please take a look at this patch and ack if looks good? Rest of
the patches look good to me (I might squash patch 5 with 4 while applying).
- Mani
> Signed-off-by: Hans Zhang <18255117159@163.com>
> ---
> drivers/pci/pci.h | 2 ++
> drivers/pci/probe.c | 16 ++++++++++++++++
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index 13d998fbacce..409aca7d737a 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -108,6 +108,8 @@ struct pcie_tlp_log;
> PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE)
>
> extern const unsigned char pcie_link_speed[];
> +unsigned char pcie_get_link_speed(unsigned int speed);
> +
> extern bool pci_early_dump;
>
> extern struct mutex pci_rescan_remove_lock;
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index bccc7a4bdd79..d6592898330c 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -783,6 +783,22 @@ const unsigned char pcie_link_speed[] = {
> };
> EXPORT_SYMBOL_GPL(pcie_link_speed);
>
> +/**
> + * pcie_link_speed_value - Get speed value from PCIe generation number
> + * @speed: PCIe speed (1-based: 1 = 2.5GT, 2 = 5GT, ...)
> + *
> + * Returns the speed value (e.g., PCIE_SPEED_2_5GT) if @speed is valid,
> + * otherwise returns PCI_SPEED_UNKNOWN.
> + */
> +unsigned char pcie_get_link_speed(unsigned int speed)
> +{
> + if (speed >= ARRAY_SIZE(pcie_link_speed))
> + return PCI_SPEED_UNKNOWN;
> +
> + return pcie_link_speed[speed];
> +}
> +EXPORT_SYMBOL_GPL(pcie_get_link_speed);
> +
> const char *pci_speed_string(enum pci_bus_speed speed)
> {
> /* Indexed by the pci_bus_speed enum */
> --
> 2.34.1
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH 00/12] treewide: Convert buses to use generic driver_override
From: Danilo Krummrich @ 2026-03-26 17:38 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Russell King, Greg Kroah-Hartman, Rafael J. Wysocki,
Ioana Ciornei, Nipun Gupta, Nikhil Agarwal, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li, Bjorn Helgaas,
Armin Wolf, Bjorn Andersson, Mathieu Poirier, Vineeth Vijayan,
Peter Oberparleiter, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Harald Freudenberger, Holger Dengler, Mark Brown, Jason Wang,
Xuan Zhuo, Eugenio Pérez, Alex Williamson, Juergen Gross,
Stefano Stabellini, Oleksandr Tyshchenko,
Christophe Leroy (CS GROUP), linux-kernel, driver-core,
linuxppc-dev, linux-hyperv, linux-pci, platform-driver-x86,
linux-arm-msm, linux-remoteproc, linux-s390, linux-spi,
virtualization, kvm, xen-devel, linux-arm-kernel
In-Reply-To: <20260325052919-mutt-send-email-mst@kernel.org>
On Wed Mar 25, 2026 at 10:29 AM CET, Michael S. Tsirkin wrote:
> vdpa bits:
>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
>
> I assume it'll all be merged together?
I can take it through the driver-core tree if you prefer, but you can also pick
it up yourself.
^ permalink raw reply
* Re: [PATCH net-next v4 1/2] net: stmmac: provide flag to disable EEE
From: Kieran Bingham @ 2026-03-26 17:31 UTC (permalink / raw)
To: Laurent Pinchart, imx, netdev
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Fabio Estevam,
Francesco Dolcini, Frank Li, Jakub Kicinski, Joy Zou,
Marco Felsch, Paolo Abeni, Pengutronix Kernel Team,
Russell King (Oracle), Stefan Klug, linux-arm-kernel
In-Reply-To: <20260325210003.2752013-2-laurent.pinchart@ideasonboard.com>
Quoting Laurent Pinchart (2026-03-25 21:00:02)
> From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
>
> Some platforms have problems when EEE is enabled, and thus need a way
> to disable stmmac EEE support. Add a flag before the other LPI related
> flags which tells stmmac to avoid populating the phylink LPI
> capabilities, which causes phylink to call phy_disable_eee() for any
> PHY that is attached to the affected phylink instance.
>
> iMX8MP is an example - the lpi_intr_o signal is wired to an OR gate
> along with the main dwmac interrupts. Since lpi_intr_o is synchronous
> to the receive clock domain, and takes four clock cycles to clear, this
> leads to interrupt storms as the interrupt remains asserted for some
> time after the LPI control and status register is read.
>
> This problem becomes worse when the receive clock from the PHY stops
> when the receive path enters LPI state - which means that lpi_intr_o
> can not deassert until the clock restarts. Since the LPI state of the
> receive path depends on the link partner, this is out of our control.
> We could disable RX clock stop at the PHY, but that doesn't get around
> the slow-to-deassert lpi_intr_o mentioned in the above paragraph.
>
> Previously, iMX8MP worked around this by disabling gigabit EEE, but
> this is insufficient - the problem is also visible at 100M speeds,
> where the receive clock is slower.
>
> There is extensive discussion and investigation in the thread linked
> below, the result of which is summarised in this commit message.
This one has been a roller coaster, but I'm glad we got to the bottom of
it.
I hope someone from synopsis takes note and and documents this for
future silicon integrations.
Can't wait to see where else this pops up.
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
>
> Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Closes: https://lore.kernel.org/r/20251026122905.29028-1-laurent.pinchart@ideasonboard.com
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> Tested-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 ++++++-
> include/linux/stmmac.h | 13 +++++++------
> 2 files changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 9b6b49331639..ce51b9c22129 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -1438,7 +1438,12 @@ static int stmmac_phylink_setup(struct stmmac_priv *priv)
> config->supported_interfaces,
> pcs->supported_interfaces);
>
> - if (priv->dma_cap.eee) {
> + /* Some platforms, e.g. iMX8MP, wire lpi_intr_o to the same interrupt
> + * used for stmmac's main interrupts, which leads to interrupt storms.
> + * STMMAC_FLAG_EEE_DISABLE allows EEE to be disabled on such platforms.
> + */
> + if (priv->dma_cap.eee &&
> + !(priv->plat->flags & STMMAC_FLAG_EEE_DISABLE)) {
> /* The GMAC 3.74a databook states that EEE is only supported
> * in MII, GMII, and RGMII interfaces.
> */
> diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
> index 5b2bece81448..e62d21afd56d 100644
> --- a/include/linux/stmmac.h
> +++ b/include/linux/stmmac.h
> @@ -207,12 +207,13 @@ enum dwmac_core_type {
> #define STMMAC_FLAG_MULTI_MSI_EN BIT(7)
> #define STMMAC_FLAG_EXT_SNAPSHOT_EN BIT(8)
> #define STMMAC_FLAG_INT_SNAPSHOT_EN BIT(9)
> -#define STMMAC_FLAG_RX_CLK_RUNS_IN_LPI BIT(10)
> -#define STMMAC_FLAG_EN_TX_LPI_CLOCKGATING BIT(11)
> -#define STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP BIT(12)
> -#define STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY BIT(13)
> -#define STMMAC_FLAG_KEEP_PREAMBLE_BEFORE_SFD BIT(14)
> -#define STMMAC_FLAG_SERDES_SUPPORTS_2500M BIT(15)
> +#define STMMAC_FLAG_EEE_DISABLE BIT(10)
> +#define STMMAC_FLAG_RX_CLK_RUNS_IN_LPI BIT(11)
> +#define STMMAC_FLAG_EN_TX_LPI_CLOCKGATING BIT(12)
> +#define STMMAC_FLAG_EN_TX_LPI_CLK_PHY_CAP BIT(13)
> +#define STMMAC_FLAG_HWTSTAMP_CORRECT_LATENCY BIT(14)
> +#define STMMAC_FLAG_KEEP_PREAMBLE_BEFORE_SFD BIT(15)
> +#define STMMAC_FLAG_SERDES_SUPPORTS_2500M BIT(16)
>
> struct mac_device_info;
>
> --
> Regards,
>
> Laurent Pinchart
>
^ permalink raw reply
* Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
From: Miguel Ojeda @ 2026-03-26 17:31 UTC (permalink / raw)
To: Christian Schrefl
Cc: Alice Ryhl, Ard Biesheuvel, Jamie Cunliffe, Will Deacon,
Catalin Marinas, Russell King (Oracle), Miguel Ojeda, a.hindborg,
acourbot, akpm, anton.ivanov, bjorn3_gh, boqun.feng, dakr, david,
gary, johannes, justinstitt, linux-arm-kernel, linux-kbuild,
linux-kernel, linux-mm, linux-um, llvm, lossin, mark.rutland,
mmaurer, morbo, nathan, nick.desaulniers+lkml, nicolas.schier,
nsc, peterz, richard, rust-for-linux, tmgross, urezki
In-Reply-To: <9cf5a94c-0f37-446c-b63d-ddac5674d220@gmail.com>
On Thu, Mar 26, 2026 at 3:31 PM Christian Schrefl
<chrisi.schrefl@gmail.com> wrote:
>
> It should probably be fine to use armv7a-none-eabi. I've mostly used
> arm-unknown-linux-gnueabi since I though it needed to match the
> bindgen-target (which is -linux-gnu for all architectures) and
> because from what I understand clang also uses arm-linux-gnueabi [1].
> Also when I selected the target I thought that we would also support
> armv6, but since I had no v6 hardware to test on I disabled it.
I see, thanks for the quick reply!
My current thinking is to enable this only for x86_64 and arm64, so if
you/arm decide to switch the target (and/or enable this experimental
feature), then that can be done without a rush, independently.
(Please take a look at Russell's reply as well about the short enums thing.)
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v2 0/3] Inline helpers into Rust without full LTO
From: Miguel Ojeda @ 2026-03-26 17:30 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Christian Schrefl, Alice Ryhl, Ard Biesheuvel, Jamie Cunliffe,
Will Deacon, Catalin Marinas, Miguel Ojeda, a.hindborg, acourbot,
akpm, anton.ivanov, bjorn3_gh, boqun.feng, dakr, david, gary,
johannes, justinstitt, linux-arm-kernel, linux-kbuild,
linux-kernel, linux-mm, linux-um, llvm, lossin, mark.rutland,
mmaurer, morbo, nathan, nick.desaulniers+lkml, nicolas.schier,
nsc, peterz, richard, rust-for-linux, tmgross, urezki
In-Reply-To: <acVOL5Psz6kHlhq2@shell.armlinux.org.uk>
On Thu, Mar 26, 2026 at 4:18 PM Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
>
> I'm not sure if this is still true, but I believe it used to be the case
> that the -linux-gnueabi target has one behaviour for enums (fixed size)
> whereas -none-eabi, the size of the type depends on the range of values
> included in the enum.
>
> Certianly, when Arm Ltd were proposing EABI, EABI had the latter
> behaviour, and I think there were cases where Linux used "enum" in
> its UAPI.
Short enums? I see `c-enum-min-bits` in the armv7a-none-eabi built-in
`rustc` target, and indeed:
#![no_std]
#[repr(C)]
enum T {
A,
B,
}
pub static S: usize = core::mem::size_of::<T>();
is 1 for that one, and 4 for the other.
Thanks!
Cheers,
Miguel
^ 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