* Re: [PATCH v3 2/8] dt-bindings: gpio: cdns: add Axiado AX3005 GPIO variant
From: Swark Yang @ 2026-07-21 3:35 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Harshit Shah,
Linus Walleij, Bartosz Golaszewski, Jan Kotas, Michal Simek,
Andi Shyti, Przemysław Gaj, Alexandre Belloni, Frank Li,
Boris Brezillon, Greg Kroah-Hartman, Jiri Slaby, Mark Brown,
Mathias Nyman, devicetree, linux-arm-kernel, linux-kernel,
linux-gpio, linux-i2c, linux-i3c, linux-serial, linux-spi,
linux-usb
In-Reply-To: <20260717-prudent-indefinable-labradoodle-fcaa9e@quoll>
On 7/17/2026 4:33 PM, Krzysztof Kozlowski wrote:
>
> This should stay enum which would also make your diff easier to read.
>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> Best regards,
> Krzysztof
>
Hi Krzysztof,
Agreed on the enum, and thanks for the tags.
Since Bartosz already applied this to the GPIO tree, should I send an
incremental patch to fix the formatting, or is it fine as-is?
Thanks,
Swark
^ permalink raw reply
* Re: [PATCH v1] driver: fpga: xilinx-selectmap: add csi and rdwr support
From: Heiko Schocher @ 2026-07-21 4:48 UTC (permalink / raw)
To: Michal Simek, linux-kernel
Cc: linux-fpga, linux-arm-kernel, Moritz Fischer, Tom Rix, Xu Yilun
In-Reply-To: <dad54c5f-34d1-4aab-bf7c-590ed5f638e6@amd.com>
Hello Michal,
On 20.07.26 14:40, Michal Simek wrote:
>
>
> On 7/16/26 09:00, Heiko Schocher wrote:
>> Add csi_b and rdwr pin support for the xilinx,selectmap driver.
>>
>> In current driver the pins are configured from DTS and set to
>> GPIOD_OUT_HIGH. This works in case you have one FPGA.
>>
>> Extend this to really implement csi_b and rdwr pin function in
>> driver, so it works with more than one FPGA.
>>
>> Tested on AM625 based board with 2 FPGAs connected to GPMC.
>>
>> Signed-off-by: Heiko Schocher <hs@nabladev.com>
>> ---
>>
>> drivers/fpga/xilinx-selectmap.c | 20 ++++++++++++++++++--
>> 1 file changed, 18 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/fpga/xilinx-selectmap.c b/drivers/fpga/xilinx-selectmap.c
>> index d0cbb5fdfe3a..b5fbdedf8aec 100644
>> --- a/drivers/fpga/xilinx-selectmap.c
>> +++ b/drivers/fpga/xilinx-selectmap.c
>> @@ -19,6 +19,8 @@
>> struct xilinx_selectmap_conf {
>> struct xilinx_fpga_core core;
>> void __iomem *base;
>> + struct gpio_desc *csi_b;
>> + struct gpio_desc *rdwr_b;
>> };
>> #define to_xilinx_selectmap_conf(obj) \
>> @@ -30,9 +32,21 @@ static int xilinx_selectmap_write(struct xilinx_fpga_core *core,
>> struct xilinx_selectmap_conf *conf = to_xilinx_selectmap_conf(core);
>> size_t i;
>> + if (conf->csi_b)
>
> Is this really needed?
>
> 4023 int gpiod_set_value(struct gpio_desc *desc, int value)
> 4024 {
> 4025 VALIDATE_DESC(desc);
> 4026 /* Should be using gpiod_set_value_cansleep() */
> 4027 WARN_ON(desc->gdev->can_sleep);
> 4028 return gpiod_set_value_nocheck(desc, value);
> 4029 }
> 4030 EXPORT_SYMBOL_GPL(gpiod_set_value);
>
> 398 #define VALIDATE_DESC(desc) do { \
> 399 int __valid = validate_desc(desc, __func__); \
> 400 if (__valid <= 0) \
> 401 return __valid; \
> 402 } while (0)
>
> 385 static int validate_desc(const struct gpio_desc *desc, const char *func)
> 386 {
> 387 if (!desc)
> 388 return 0;
> 389
> 390 if (IS_ERR(desc)) {
> 391 pr_warn("%s: invalid GPIO (errorpointer: %pe)\n", func, desc);
> 392 return PTR_ERR(desc);
> 393 }
> 394
> 395 return 1;
> 396 }
> 397
>
> You should be able to just skip it because validate_desc is checking it for you.
It seems this is possible yes, so I drop it!
>> + gpiod_set_value(conf->csi_b, GPIOD_OUT_HIGH);
>> +
>> + if (conf->rdwr_b)
>> + gpiod_set_value(conf->rdwr_b, GPIOD_OUT_HIGH);
>> +
>> for (i = 0; i < count; ++i)
>> writeb(buf[i], conf->base);
>> + if (conf->rdwr_b)
>> + gpiod_set_value(conf->rdwr_b, GPIOD_OUT_LOW);
>> +
>> + if (conf->csi_b)
>> + gpiod_set_value(conf->csi_b, GPIOD_OUT_LOW);
>> +
>> return 0;
>> }
>> @@ -56,16 +70,18 @@ static int xilinx_selectmap_probe(struct platform_device *pdev)
>> conf->base = base;
>> /* CSI_B is active low */
>> - gpio = devm_gpiod_get_optional(&pdev->dev, "csi", GPIOD_OUT_HIGH);
>> + gpio = devm_gpiod_get_optional(&pdev->dev, "csi", GPIOD_OUT_LOW);
>> if (IS_ERR(gpio))
>> return dev_err_probe(&pdev->dev, PTR_ERR(gpio),
>> "Failed to get CSI_B gpio\n");
>> + conf->csi_b = gpio;
>
> Isn't it easier to simply call to avoid it?
>
> conf->csi_b = devm_gpiod_get_optional(&pdev->dev, "csi", GPIOD_OUT_LOW);
Of course, will send a v2 and drop the local gpio variable as not
longer needed.
Thanks for the review!
bye,
Heiko
>
> Thanks,
> Michal
--
Nabla Software Engineering
HRB 40522 Augsburg
Phone: +49 821 45592596
E-Mail: office@nabladev.com
Geschäftsführer : Stefano Babic
^ permalink raw reply
* Re: [PATCH v2 1/2] arm64: dts: ti: k3-am642-tqma64xxl: add ospi0 vcc-supply
From: Vignesh Raghavendra @ 2026-07-21 4:56 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Nora Schiffer
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel,
devicetree, linux-kernel, linux, Alexander Feilke
In-Reply-To: <aaec2ddf7cecb58ca0af37d4f03afec571804757.1783348781.git.nora.schiffer@ew.tq-group.com>
Hi Nora Schiffer,
On Mon, 06 Jul 2026 16:43:58 +0200, Nora Schiffer wrote:
> arm64: dts: ti: k3-am642-tqma64xxl: add ospi0 vcc-supply
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/2] arm64: dts: ti: k3-am642-tqma64xxl: add ospi0 vcc-supply
commit: 4266c6f3122ac388e1be7e71e09afc94dfc10379
[2/2] arm64: dts: ti: k3-am642-tqma64xxl-mbax4xxl: add icssg1 ti,pa-stats
commit: aec2bf3585ec0aacbea04c3d11077b2981bc6966
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
--
Vignesh
^ permalink raw reply
* Re: [PATCH] arm64: dts: ti: k3-am62l: Add bootph to usb0
From: Vignesh Raghavendra @ 2026-07-21 4:57 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bryan Brattlof
Cc: linux-arm-kernel, devicetree, linux-kernel, Anshul Dalal
In-Reply-To: <20260714-am62lx-evm-dfu-v1-1-62b025bea71a@ti.com>
Hi Bryan Brattlof,
On Tue, 14 Jul 2026 18:05:48 -0500, Bryan Brattlof wrote:
> arm64: dts: ti: k3-am62l: Add bootph to usb0
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/1] arm64: dts: ti: k3-am62l: Add bootph to usb0
commit: 43aa380f66fb97a5a8233019b62e79183c4ae48a
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
--
Vignesh
^ permalink raw reply
* Re: [PATCH v2] cpufreq: apple-soc: Calculate frequency as a 64-bit value
From: Viresh Kumar @ 2026-07-21 4:58 UTC (permalink / raw)
To: Sasha Finkelstein
Cc: Sven Peter, Janne Grunau, Neal Gompa, Rafael J. Wysocki, asahi,
linux-arm-kernel, linux-pm, linux-kernel
In-Reply-To: <20260720-cpufreq-64-v2-1-72bd9b4e5ca0@chaosmail.tech>
On 20-07-26, 09:25, Sasha Finkelstein wrote:
> The current frequency calculation is done in 32 bit, causing problems
> if run on a future SoC that can boost higher than 4.2GHz. Ideally, we
> should use a true u64 instead of unsigned long and "knowning" that this
> only runs on 64 bit machines, but the core code uses ulong everywhere,
> so this should be good enough.
>
> Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
> ---
> Changes in v2:
> - Minor style fixes
> - Link to v1: https://patch.msgid.link/20260703-cpufreq-64-v1-1-c406c705319a@chaosmail.tech
> ---
> drivers/cpufreq/apple-soc-cpufreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied. Thanks.
--
viresh
^ permalink raw reply
* Re: (subset) [PATCH v6 0/3] arm64: dts/bindings: Add support for BeagleBadge
From: Vignesh Raghavendra @ 2026-07-21 4:58 UTC (permalink / raw)
To: Nishanth Menon, Judith Mendez
Cc: Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, devicetree, linux-kernel, Andrew Davis,
Bryan Brattlof, Jason Kridner, Robert Nelson, Conor Dooley
In-Reply-To: <20260603192305.1347908-1-jm@ti.com>
Hi Judith Mendez,
On Wed, 03 Jun 2026 14:23:02 -0500, Judith Mendez wrote:
> arm64: dts/bindings: Add support for BeagleBadge
>
> Hi,
>
> BeagleBoard.org BeagleBadge[1] is a compact, affordable open source
> hardware [2] single board computer based on the Texas Instruments AM62L3
> SoC designed for IoT and embedded applications. Add base support for
> the same.
>
> [...]
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/3] dt-bindings: arm: ti: Add am62l3-beaglebadge
commit: e2393ed6275732036d8f7c2b05de1319c5c691d6
[2/3] arm64: dts: ti: Add k3-am62l3-beaglebadge
commit: 0c78b72362f4bd90f8a46ea7be385fe05137e06d
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
--
Vignesh
^ permalink raw reply
* Re: (subset) [PATCH v2] arm64: dts: ti: k3-am62-verdin: Add RPi Touch Display 2 7-inch
From: Vignesh Raghavendra @ 2026-07-21 4:59 UTC (permalink / raw)
To: Nishanth Menon, Tero Kristo, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Francesco Dolcini
Cc: Francesco Dolcini, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260715055446.31139-1-francesco@dolcini.it>
Hi Francesco Dolcini,
On Wed, 15 Jul 2026 07:54:45 +0200, Francesco Dolcini wrote:
> arm64: dts: ti: k3-am62-verdin: Add RPi Touch Display 2 7-inch
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/1] arm64: dts: ti: k3-am62-verdin: Add RPi Touch Display 2 7-inch
commit: d55f26485cd17f34bb4d5c0acb32a199e235628e
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
--
Vignesh
^ permalink raw reply
* Re: [PATCH 0/5] arm64: dts: ti: k3-am62-verdin: Add Toradex Capacitive Touch Display 10.1" LVDS
From: Vignesh Raghavendra @ 2026-07-21 5:09 UTC (permalink / raw)
To: laurent.pinchart, neil.armstrong, jesszhan0024, maarten.lankhorst,
mripard, tzimmermann, airlied, simona, robh, krzk+dt, conor+dt,
nm, kristo, prabhakar.mahadev-lad.rj, thierry.reding, sam,
Leonardo Costa
Cc: leonardo.costa, dri-devel, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260623195741.495734-1-leoreis.costa@gmail.com>
Hi Leonardo Costa,
On Tue, 23 Jun 2026 16:57:36 -0300, Leonardo Costa wrote:
> arm64: dts: ti: k3-am62-verdin: Add Toradex Capacitive Touch Display 10.1" LVDS
>
> From: Leonardo Costa <leonardo.costa@toradex.com>
>
> This series adds device tree overlays for Toradex Capacitive
> Touch Display 10.1" LVDS V2 on Verdin AM62.
>
> [...]
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/5] dt-bindings: vendor-prefixes: Add Opto Logic
commit: d980b7b9263e43bcf876be2f36355d23d58b24bb
[2/5] dt-bindings: display: panel-lvds: Add compatible for Opto Logic SCX1001511GGC49
commit: 854310180235e4c1df953eea3c97e9a1fca5b53c
[3/5] arm64: dts: ti: k3-am62-verdin: Add Toradex Capacitive Touch Display 10.1" LVDS V2
commit: f19e38321d061fcbc695f9a7aa609e4ef9eff1a2
[4/5] arm64: dts: ti: k3-am62-verdin: Add Toradex DSI to LVDS adapter with the 10.1" V2 display
commit: fea4b900f4e8afb518def13b487b44472d3974c1
[5/5] arm64: dts: ti: k3-am62-verdin: Add Mezzanine with Toradex Display 10.1" LVDS
commit: 46d70de6c0afc95252330ef08c70704aa47a6a95
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
--
Vignesh
^ permalink raw reply
* Re: [PATCH v3] ARM: imx: Fix suspend/resume crash with Clang CFI
From: Yo'av Moshe @ 2026-07-21 5:20 UTC (permalink / raw)
To: Nick Desaulniers, Yo'av Moshe
Cc: Frank Li, Sascha Hauer, Russell King, Pengutronix Kernel Team,
Fabio Estevam, Nathan Chancellor, Bill Wendling, Justin Stitt,
imx, linux-arm-kernel, llvm, stable, linux-kernel
In-Reply-To: <CAKwvOd=eAC-Mz0kZhbHQMFOY=ba=WXDH6X_Zzh6KGfuq5PmJ4A@mail.gmail.com>
On 2026-07-20 6:53 PM, Nick Desaulniers wrote:
>
> Are we able to just put __nocfi on the declaration of
> `imx6_suspend_in_ocram_fn`, rather than bother with a wrapper
> (imx6_suspend_in_ocram)? I don't know if that works, but surely you
> can test that quickly?
Thanks for the suggestion! I tested placing __nocfi directly on the
imx6_suspend_in_ocram_fn variable declaration:
static void (* __nocfi imx6_suspend_in_ocram_fn)(void __iomem *ocram_vbase);
Unfortunately, Clang ignores no_sanitize("cfi") on variable declarations and
emits a compiler warning:
warning: 'no_sanitize' attribute argument 'cfi' not supported on a
global variable [-Wignored-attributes]
Because Clang ignores it, it still injects the CFI check at the call site.
I tested this on physical hardware (Kobo Clara HD), and it crashes on suspend.
Best regards,
Yo'av
^ permalink raw reply
* [PATCH v5 0/7] Read MAC address from SST vendor specific SFDP region
From: Manikandan Muralidharan @ 2026-07-21 5:28 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
Some Microchip/SST QSPI flashes (e.g. the SST26VF064BEUI) are factory
programmed with globally unique, write-protected EUI-48 and EUI-64
identifiers stored in a vendor-specific SFDP parameter table. On boards
that have no on-board EEPROM (sama5d27_wlsom1, sama5d29 curiosity,
sam9x75 curiosity) this is a reliable source for an Ethernet MAC address,
instead of relying on a U-Boot-provided or random address.
This v5 reworks the approach into a generic NVMEM framework with no vendor
code in the SPI NOR core:
- The SPI NOR core now exposes the entire SFDP as a generic read-only
NVMEM device, rooted at a new "sfdp" child node of the flash.
- A new NVMEM layout driver (drivers/nvmem/layouts/) locates the
Microchip vendor parameter table at runtime and presents the EUI-48 as
a "mac-address" cell.
- Arbitrary parameters can be read with a standard fixed-layout
(known offset) or with an nvmem-layout parser (location discovered at runtime).
Changes in v5:
- 1/7 and 5/7 - Add R-b tags
- 3/7- Rework the comments, function name and commit message.Check all the nodes
(for_each_available_child) for the right compatible "jedec,sfdp" instead
of node name.
Changes in v4:
- Rework per v3 review: remove the vendor-specific SFDP handling from the
SPI NOR core; expose the whole SFDP as a generic read-only NVMEM device
and move the EUI extraction into an nvmem-layout driver.
- Introduce a new nvmem-layout driver to discover the vendor-table location
at runtime; no offset hardcoded in the device tree.
- Describe the SFDP via a dedicated "sfdp" subnode (compatible
"jedec,sfdp"), which also resolves the v3 dtbs_check "Unevaluated
properties ('nvmem-layout')" warning.
- Reverse the stored EUI bytes into canonical MAC order.
- Enable the layout in sama5_defconfig.
Changes in v3:
- 2/3 - add support to update the QSPI partition into 'fixed-partition'
binding in sama5d27_wlsom1
- 3/3 - add nvmem-layout in qspi node for EUI48 MAC Address and nvmem cell
properties for macb node in sama5d27_wlsom1
Changes in v2:
- 1/3 - parse the SST vendor table, read and store the addresses
into a resource - managed space. Register the addresses
into NVMEM framework
- 2/3 - add support to update the QSPI partition into 'fixed-partition'
binding
v4: https://lore.kernel.org/linux-devicetree/20260630092406.150587-1-manikandan.m@microchip.com/
Manikandan Muralidharan (7):
dt-bindings: mtd: jedec,spi-nor: allow the SFDP to be exposed via
NVMEM
dt-bindings: nvmem: layouts: add Microchip/SST SFDP EUI layout
mtd: spi-nor: sfdp: expose the SFDP as a read-only NVMEM device
nvmem: layouts: add Microchip/SST SFDP EUI layout driver
ARM: dts: microchip: sama5d27_wlsom1: use fixed-partitions for QSPI
flash
ARM: dts: microchip: sama5d27_wlsom1: read MAC address from QSPI SFDP
ARM: configs: sama5: enable Microchip/SST SFDP EUI NVMEM layout
.../bindings/mtd/jedec,spi-nor.yaml | 18 ++
.../layouts/microchip,sst26vf-sfdp-eui.yaml | 60 ++++++
.../bindings/nvmem/layouts/nvmem-layout.yaml | 1 +
MAINTAINERS | 6 +
.../dts/microchip/at91-sama5d27_wlsom1.dtsi | 61 +++---
.../dts/microchip/at91-sama5d27_wlsom1_ek.dts | 2 +
arch/arm/configs/sama5_defconfig | 1 +
drivers/mtd/spi-nor/core.c | 8 +
drivers/mtd/spi-nor/core.h | 1 +
drivers/mtd/spi-nor/sfdp.c | 86 +++++++++
drivers/nvmem/layouts/Kconfig | 10 +
drivers/nvmem/layouts/Makefile | 1 +
drivers/nvmem/layouts/sst26vf-sfdp-eui.c | 182 ++++++++++++++++++
13 files changed, 415 insertions(+), 22 deletions(-)
create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/microchip,sst26vf-sfdp-eui.yaml
create mode 100644 drivers/nvmem/layouts/sst26vf-sfdp-eui.c
base-commit: b95f03f04d475aa6719d15a636ddf32222d55657
--
2.43.0
^ permalink raw reply
* [PATCH v5 1/7] dt-bindings: mtd: jedec,spi-nor: allow the SFDP to be exposed via NVMEM
From: Manikandan Muralidharan @ 2026-07-21 5:28 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
In-Reply-To: <20260721052859.171341-1-manikandan.m@microchip.com>
Add an optional "sfdp" child node (compatible "jedec,sfdp") that
describes the SFDP as a read-only NVMEM provider via nvmem.yaml, so its
contents (e.g. a vendor EUI-48/EUI-64) can be read through NVMEM cells.
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
---
.../devicetree/bindings/mtd/jedec,spi-nor.yaml | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
index 587af4968255..98fd954598ab 100644
--- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
+++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
@@ -103,6 +103,20 @@ properties:
spi-cpol: true
spi-cpha: true
+ sfdp:
+ $ref: /schemas/nvmem/nvmem.yaml#
+ unevaluatedProperties: false
+ description:
+ The Serial Flash Discoverable Parameters (SFDP) tables exposed as a
+ read-only NVMEM device. This allows standard or vendor-specific SFDP
+ data (for example a factory-programmed EUI-48/EUI-64 identifier) to be
+ consumed through NVMEM cells.
+ properties:
+ compatible:
+ const: jedec,sfdp
+ required:
+ - compatible
+
dependencies:
spi-cpol: [ spi-cpha ]
spi-cpha: [ spi-cpol ]
@@ -122,6 +136,10 @@ examples:
spi-max-frequency = <40000000>;
m25p,fast-read;
reset-gpios = <&gpio 12 GPIO_ACTIVE_LOW>;
+
+ sfdp {
+ compatible = "jedec,sfdp";
+ };
};
};
...
--
2.43.0
^ permalink raw reply related
* [PATCH v5 2/7] dt-bindings: nvmem: layouts: add Microchip/SST SFDP EUI layout
From: Manikandan Muralidharan @ 2026-07-21 5:28 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
In-Reply-To: <20260721052859.171341-1-manikandan.m@microchip.com>
Add a binding for the NVMEM layout that exposes the factory-programmed
EUI-48 identifier from the Microchip/SST vendor-specific SFDP parameter
table (e.g. SST26VF064BEUI) as a "mac-address" NVMEM cell, and reference
it from nvmem-layout.yaml.
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
.../layouts/microchip,sst26vf-sfdp-eui.yaml | 60 +++++++++++++++++++
.../bindings/nvmem/layouts/nvmem-layout.yaml | 1 +
2 files changed, 61 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/layouts/microchip,sst26vf-sfdp-eui.yaml
diff --git a/Documentation/devicetree/bindings/nvmem/layouts/microchip,sst26vf-sfdp-eui.yaml b/Documentation/devicetree/bindings/nvmem/layouts/microchip,sst26vf-sfdp-eui.yaml
new file mode 100644
index 000000000000..37357efb7840
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/layouts/microchip,sst26vf-sfdp-eui.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/layouts/microchip,sst26vf-sfdp-eui.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVMEM layout of the Microchip/SST SFDP EUI-48 identifier
+
+maintainers:
+ - Manikandan Muralidharan <manikandan.m@microchip.com>
+
+description:
+ Some Microchip/SST serial flashes (for example the SST26VF064BEUI) are
+ factory programmed with a globally unique EUI-48 identifier stored in a
+ vendor-specific SFDP parameter table and permanently write-protected. This
+ layout locates that table and exposes the EUI-48 as an NVMEM cell so that,
+ for example, a network driver can use it as a MAC address. The location of
+ the data is discovered at runtime from the SFDP; no offset is encoded in the
+ device tree.
+
+select: false
+
+properties:
+ compatible:
+ const: microchip,sst26vf-sfdp-eui
+
+ mac-address:
+ type: object
+ description:
+ The factory-programmed EUI-48 identifier, usable as a MAC address.
+ additionalProperties: false
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+
+ sfdp {
+ compatible = "jedec,sfdp";
+
+ nvmem-layout {
+ compatible = "microchip,sst26vf-sfdp-eui";
+
+ mac-address {
+ };
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
index 382507060651..e63b93083821 100644
--- a/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
+++ b/Documentation/devicetree/bindings/nvmem/layouts/nvmem-layout.yaml
@@ -20,6 +20,7 @@ description: |
oneOf:
- $ref: fixed-layout.yaml
- $ref: kontron,sl28-vpd.yaml
+ - $ref: microchip,sst26vf-sfdp-eui.yaml
- $ref: onie,tlv-layout.yaml
- $ref: u-boot,env.yaml
--
2.43.0
^ permalink raw reply related
* [PATCH v5 3/7] mtd: spi-nor: sfdp: expose the SFDP as a read-only NVMEM device
From: Manikandan Muralidharan @ 2026-07-21 5:28 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
In-Reply-To: <20260721052859.171341-1-manikandan.m@microchip.com>
The SPI NOR core already reads the SFDP tables during enumeration and
caches them in nor->sfdp->dwords (see spi_nor_parse_sfdp()). Re-expose
that cached data as a read-only NVMEM device, in on-flash byte order,
rooted at the flash's SFDP child node (compatible "jedec,sfdp").
This lets NVMEM cells reference any SFDP data: a fixed-layout for
parameters at a known offset, or an nvmem-layout parser for vendor data
whose location must be discovered at runtime.The device is only registered
when an "sfdp" node is present in the device tree.
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
drivers/mtd/spi-nor/core.c | 8 ++++
drivers/mtd/spi-nor/core.h | 1 +
drivers/mtd/spi-nor/sfdp.c | 86 ++++++++++++++++++++++++++++++++++++++
3 files changed, 95 insertions(+)
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index ccf4396cdcd0..b833d8ec2d65 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -3204,6 +3204,14 @@ static int spi_nor_init_params(struct spi_nor *nor)
spi_nor_init_params_deprecated(nor);
}
+ /*
+ * Expose the SFDP table as an NVMEM device only when
+ * the flash actually provides one
+ */
+ ret = spi_nor_register_sfdp_nvmem(nor);
+ if (ret)
+ return ret;
+
ret = spi_nor_late_init_params(nor);
if (ret)
return ret;
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index ba2d1a862c9d..0a6484298c5c 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -698,6 +698,7 @@ int spi_nor_controller_ops_write_reg(struct spi_nor *nor, u8 opcode,
int spi_nor_check_sfdp_signature(struct spi_nor *nor);
int spi_nor_parse_sfdp(struct spi_nor *nor);
+int spi_nor_register_sfdp_nvmem(struct spi_nor *nor);
static inline struct spi_nor *mtd_to_spi_nor(struct mtd_info *mtd)
{
diff --git a/drivers/mtd/spi-nor/sfdp.c b/drivers/mtd/spi-nor/sfdp.c
index 4600983cb579..704799fe92ae 100644
--- a/drivers/mtd/spi-nor/sfdp.c
+++ b/drivers/mtd/spi-nor/sfdp.c
@@ -6,6 +6,8 @@
#include <linux/bitfield.h>
#include <linux/mtd/spi-nor.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of.h>
#include <linux/slab.h>
#include <linux/sort.h>
@@ -1612,3 +1614,87 @@ int spi_nor_parse_sfdp(struct spi_nor *nor)
kfree(param_headers);
return err;
}
+
+static int spi_nor_sfdp_reg_read(void *priv, unsigned int offset,
+ void *val, size_t bytes)
+{
+ struct spi_nor *nor = priv;
+ struct sfdp *sfdp = nor->sfdp;
+ size_t sfdp_size = sfdp->num_dwords * sizeof(*sfdp->dwords);
+
+ if (offset >= sfdp_size || bytes > sfdp_size - offset)
+ return -EINVAL;
+
+ /* The cached SFDP is kept in on-flash (little-endian) byte order. */
+ memcpy(val, (u8 *)sfdp->dwords + offset, bytes);
+
+ return 0;
+}
+
+static void spi_nor_sfdp_nvmem_put_np(void *data)
+{
+ of_node_put(data);
+}
+
+/**
+ * spi_nor_register_sfdp_nvmem() - expose the SFDP as a read-only NVMEM device
+ * @nor: pointer to a 'struct spi_nor'
+ *
+ * Expose the whole SFDP, in on-flash byte order, as a read-only NVMEM device
+ * rooted at the flash's SFDP child node (compatible "jedec,sfdp"). This lets
+ * generic (fixed-layout) or vendor (nvmem-layout) cells reference any SFDP
+ * data. The device is only registered when a child node with the "jedec,sfdp"
+ * compatible is described in the device tree.
+ *
+ * Return: 0 on success or if there is nothing to do, -errno otherwise.
+ */
+int spi_nor_register_sfdp_nvmem(struct spi_nor *nor)
+{
+ struct device *dev = nor->dev;
+ struct nvmem_config config = { };
+ struct nvmem_device *nvmem;
+ struct device_node *np;
+ int ret;
+
+ if (!nor->sfdp)
+ return 0;
+
+ for_each_available_child_of_node(dev_of_node(dev), np)
+ if (of_device_is_compatible(np, "jedec,sfdp"))
+ break;
+ if (!np)
+ return 0;
+
+ /*
+ * Register the put before devm_nvmem_register() so it runs last on
+ * detach, after the NVMEM device that uses the node is gone.
+ */
+ ret = devm_add_action_or_reset(dev, spi_nor_sfdp_nvmem_put_np, np);
+ if (ret)
+ return ret;
+
+ config.dev = dev;
+ config.of_node = np;
+ config.name = "sfdp";
+ config.id = NVMEM_DEVID_AUTO;
+ config.owner = THIS_MODULE;
+ config.read_only = true;
+ config.word_size = 1;
+ config.stride = 1;
+ config.size = (int)(nor->sfdp->num_dwords * sizeof(*nor->sfdp->dwords));
+ config.reg_read = spi_nor_sfdp_reg_read;
+ config.priv = nor;
+
+ nvmem = devm_nvmem_register(dev, &config);
+ if (IS_ERR(nvmem)) {
+ /* NVMEM support is optional. */
+ if (PTR_ERR(nvmem) == -EOPNOTSUPP)
+ return 0;
+ return dev_err_probe(dev, PTR_ERR(nvmem),
+ "failed to register SFDP NVMEM device\n");
+ }
+
+ dev_dbg(dev, "exposed %d-byte SFDP as an NVMEM device\n", config.size);
+
+ return 0;
+}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3] ARM: imx: Fix suspend/resume crash with Clang CFI
From: Yo'av Moshe @ 2026-07-21 5:29 UTC (permalink / raw)
To: Sami Tolvanen, Yo'av Moshe
Cc: Frank Li, Sascha Hauer, Russell King, Pengutronix Kernel Team,
Fabio Estevam, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, imx, linux-arm-kernel, llvm, stable, linux-kernel
In-Reply-To: <CABCJKudqGL+BFFcz3qsuoJB6S_OAt-vs2yqePC_=oy+JzmPpVw@mail.gmail.com>
On 2026-07-20 9:29 PM, Sami Tolvanen wrote:
> Would it be possible to just copy the 4-byte CFI hash prefix to OCRAM
> when relocating the function? If not, the __nocfi approach seems
> reasonable to me.
>
> Sami
I gave this a try - I tried copying 4 bytes from before imx6_suspend
into OCRAM, but when I tested it on physical hardware (Kobo Clara HD),
it still crashed on suspend.
I suspect it's because imx6_suspend is written in assembly
(suspend-imx6.S) rather than C, so Clang doesn't emit a CFI hash prefix
before it in the first place.
Best regards,
Yo'av
^ permalink raw reply
* [PATCH v5 4/7] nvmem: layouts: add Microchip/SST SFDP EUI layout driver
From: Manikandan Muralidharan @ 2026-07-21 5:28 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
In-Reply-To: <20260721052859.171341-1-manikandan.m@microchip.com>
Add an NVMEM layout that exposes the factory-programmed EUI-48 identifier
from the Microchip/SST vendor SFDP parameter table (e.g. SST26VF064BEUI)
as a "mac-address" cell, for use as a network MAC address. The vendor
table is located at runtime via the SFDP NVMEM device (no offset in DT),
and a read_post_process callback reverses the LSB-first bytes into
canonical MAC order. Binds to an "nvmem-layout" node with compatible
"microchip,sst26vf-sfdp-eui".
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
MAINTAINERS | 6 +
drivers/nvmem/layouts/Kconfig | 10 ++
drivers/nvmem/layouts/Makefile | 1 +
drivers/nvmem/layouts/sst26vf-sfdp-eui.c | 182 +++++++++++++++++++++++
4 files changed, 199 insertions(+)
create mode 100644 drivers/nvmem/layouts/sst26vf-sfdp-eui.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 1ab8736850ea..9fac8c5203a5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17815,6 +17815,12 @@ F: Documentation/devicetree/bindings/sound/atmel,at91-ssc.yaml
F: drivers/misc/atmel-ssc.c
F: include/linux/atmel-ssc.h
+MICROCHIP SST SFDP EUI NVMEM LAYOUT DRIVER
+M: Manikandan Muralidharan <manikandan.m@microchip.com>
+S: Maintained
+F: Documentation/devicetree/bindings/nvmem/layouts/microchip,sst26vf-sfdp-eui.yaml
+F: drivers/nvmem/layouts/sst26vf-sfdp-eui.c
+
Microchip Timer Counter Block (TCB) Capture Driver
M: Kamel Bouhara <kamel.bouhara@bootlin.com>
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
diff --git a/drivers/nvmem/layouts/Kconfig b/drivers/nvmem/layouts/Kconfig
index 5e586dfebe47..855c7db530da 100644
--- a/drivers/nvmem/layouts/Kconfig
+++ b/drivers/nvmem/layouts/Kconfig
@@ -26,6 +26,16 @@ config NVMEM_LAYOUT_ONIE_TLV
If unsure, say N.
+config NVMEM_LAYOUT_SST26VF_SFDP_EUI
+ tristate "Microchip/SST SFDP EUI-48 layout support"
+ help
+ Say Y here if you want to expose the factory-programmed EUI-48
+ identifier stored in the Microchip/SST vendor-specific SFDP parameter
+ table (e.g. SST26VF064BEUI) as NVMEM cells, so that network drivers
+ can use them as a MAC address.
+
+ If unsure, say N.
+
config NVMEM_LAYOUT_U_BOOT_ENV
tristate "U-Boot environment variables layout"
select CRC32
diff --git a/drivers/nvmem/layouts/Makefile b/drivers/nvmem/layouts/Makefile
index 4940c9db0665..b99eac1f63f2 100644
--- a/drivers/nvmem/layouts/Makefile
+++ b/drivers/nvmem/layouts/Makefile
@@ -5,4 +5,5 @@
obj-$(CONFIG_NVMEM_LAYOUT_SL28_VPD) += sl28vpd.o
obj-$(CONFIG_NVMEM_LAYOUT_ONIE_TLV) += onie-tlv.o
+obj-$(CONFIG_NVMEM_LAYOUT_SST26VF_SFDP_EUI) += sst26vf-sfdp-eui.o
obj-$(CONFIG_NVMEM_LAYOUT_U_BOOT_ENV) += u-boot-env.o
diff --git a/drivers/nvmem/layouts/sst26vf-sfdp-eui.c b/drivers/nvmem/layouts/sst26vf-sfdp-eui.c
new file mode 100644
index 000000000000..641318d6f0af
--- /dev/null
+++ b/drivers/nvmem/layouts/sst26vf-sfdp-eui.c
@@ -0,0 +1,182 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * NVMEM layout for the factory-programmed EUI-48 identifier stored in the
+ * Microchip/SST vendor-specific SFDP parameter table (e.g. SST26VF064BEUI).
+ *
+ * The whole SFDP is exposed as a read-only NVMEM device by the SPI NOR core.
+ * This layout locates the Microchip vendor parameter table at runtime and
+ * registers the EUI-48 address as an NVMEM cell, so that a network driver can
+ * consume it as a MAC address. No offset is hardcoded in the device tree.
+ *
+ * Copyright (C) 2026 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Manikandan Muralidharan <manikandan.m@microchip.com>
+ */
+
+#include <linux/etherdevice.h>
+#include <linux/minmax.h>
+#include <linux/nvmem-consumer.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of.h>
+#include <linux/unaligned.h>
+#include <uapi/linux/if_ether.h>
+
+/* SFDP header and parameter header, as laid out on the flash. */
+struct sfdp_header {
+ u8 signature[4];
+ u8 minor;
+ u8 major;
+ u8 nph;
+ u8 unused;
+};
+
+struct sfdp_parameter_header {
+ u8 id_lsb;
+ u8 minor;
+ u8 major;
+ u8 length;
+ u8 parameter_table_pointer[3];
+ u8 id_msb;
+};
+
+#define SFDP_SIGNATURE 0x50444653U
+
+#define SFDP_PARAM_HEADER_ID(h) (((h)->id_msb << 8) | (h)->id_lsb)
+#define SFDP_PARAM_HEADER_PTP(h) get_unaligned_le24((h)->parameter_table_pointer)
+
+/* Microchip (vendor) parameter table identifier: id_msb << 8 | id_lsb. */
+#define SFDP_MCHP_VENDOR_ID 0x01bf
+
+#define SFDP_MCHP_EUI48_MARKER_OFFSET 0x60
+#define SFDP_MCHP_EUI48_MARKER 0x30
+#define SFDP_MCHP_EUI48_OFFSET 0x61
+
+static int sfdp_eui_read_post_process(void *priv, const char *id, int index,
+ unsigned int offset, void *buf,
+ size_t bytes)
+{
+ u8 *data = buf;
+ int i;
+
+ /* SFDP stores the address least-significant octet first; reverse it. */
+ for (i = 0; i < bytes / 2; i++)
+ swap(data[i], data[bytes - 1 - i]);
+
+ if (bytes == ETH_ALEN && !is_valid_ether_addr(buf))
+ return -EINVAL;
+
+ return 0;
+}
+
+static int sfdp_eui_find_vendor_table(struct nvmem_device *nvmem, u32 *ptp)
+{
+ struct sfdp_parameter_header ph;
+ struct sfdp_header hdr;
+ int nph, i, ret;
+
+ ret = nvmem_device_read(nvmem, 0, sizeof(hdr), &hdr);
+ if (ret < 0)
+ return ret;
+
+ if (get_unaligned_le32(hdr.signature) != SFDP_SIGNATURE)
+ return -EINVAL;
+
+ /* The number of parameter headers (NPH) field is zero-based. */
+ nph = hdr.nph;
+
+ for (i = 0; i <= nph; i++) {
+ ret = nvmem_device_read(nvmem, sizeof(hdr) + i * sizeof(ph),
+ sizeof(ph), &ph);
+ if (ret < 0)
+ return ret;
+
+ if (SFDP_PARAM_HEADER_ID(&ph) != SFDP_MCHP_VENDOR_ID)
+ continue;
+
+ *ptp = SFDP_PARAM_HEADER_PTP(&ph);
+ return 0;
+ }
+
+ return -ENOENT;
+}
+
+static int sfdp_eui_add_cells(struct nvmem_layout *layout)
+{
+ struct nvmem_device *nvmem = layout->nvmem;
+ struct device *dev = &layout->dev;
+ struct nvmem_cell_info info = { };
+ struct device_node *layout_np;
+ u32 base = 0;
+ u8 marker;
+ int ret;
+
+ ret = sfdp_eui_find_vendor_table(nvmem, &base);
+ if (ret == -ENOENT) {
+ dev_dbg(dev, "no Microchip SFDP vendor table found\n");
+ return 0;
+ }
+ if (ret)
+ return ret;
+
+ /* The EUI-48 is present only if its marker byte is programmed. */
+ ret = nvmem_device_read(nvmem, base + SFDP_MCHP_EUI48_MARKER_OFFSET,
+ 1, &marker);
+ if (ret < 0)
+ return ret;
+ if (marker != SFDP_MCHP_EUI48_MARKER) {
+ dev_dbg(dev, "EUI-48 not programmed (marker 0x%02x)\n", marker);
+ return 0;
+ }
+
+ layout_np = of_nvmem_layout_get_container(nvmem);
+ if (!layout_np)
+ return -ENOENT;
+
+ info.name = "mac-address";
+ info.offset = base + SFDP_MCHP_EUI48_OFFSET;
+ info.bytes = ETH_ALEN;
+ info.np = of_get_child_by_name(layout_np, "mac-address");
+ info.read_post_process = sfdp_eui_read_post_process;
+
+ ret = nvmem_add_one_cell(nvmem, &info);
+ if (ret)
+ of_node_put(info.np);
+ else
+ dev_dbg(dev, "exposed EUI-48 at SFDP offset 0x%x\n", info.offset);
+
+ of_node_put(layout_np);
+
+ return ret;
+}
+
+static int sfdp_eui_probe(struct nvmem_layout *layout)
+{
+ layout->add_cells = sfdp_eui_add_cells;
+
+ return nvmem_layout_register(layout);
+}
+
+static void sfdp_eui_remove(struct nvmem_layout *layout)
+{
+ nvmem_layout_unregister(layout);
+}
+
+static const struct of_device_id sfdp_eui_of_match_table[] = {
+ { .compatible = "microchip,sst26vf-sfdp-eui" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, sfdp_eui_of_match_table);
+
+static struct nvmem_layout_driver sfdp_eui_layout = {
+ .driver = {
+ .name = "microchip-sst26vf-sfdp-eui-layout",
+ .of_match_table = sfdp_eui_of_match_table,
+ },
+ .probe = sfdp_eui_probe,
+ .remove = sfdp_eui_remove,
+};
+module_nvmem_layout_driver(sfdp_eui_layout);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Manikandan Muralidharan <manikandan.m@microchip.com>");
+MODULE_DESCRIPTION("NVMEM layout for the EUI-48 in the Microchip/SST SFDP vendor table");
--
2.43.0
^ permalink raw reply related
* [PATCH v5 5/7] ARM: dts: microchip: sama5d27_wlsom1: use fixed-partitions for QSPI flash
From: Manikandan Muralidharan @ 2026-07-21 5:28 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
In-Reply-To: <20260721052859.171341-1-manikandan.m@microchip.com>
Move the QSPI flash partitions under a "partitions" node with the
"fixed-partitions" compatible, as required by the current MTD partition
binding, instead of declaring them as direct children of the flash node.
No functional change.
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
---
.../dts/microchip/at91-sama5d27_wlsom1.dtsi | 52 +++++++++++--------
1 file changed, 29 insertions(+), 23 deletions(-)
diff --git a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
index 0417f53b3e96..062aa02a98ed 100644
--- a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
+++ b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
@@ -240,34 +240,40 @@ qspi1_flash: flash@0 {
m25p,fast-read;
status = "disabled";
- at91bootstrap@0 {
- label = "at91bootstrap";
- reg = <0x0 0x40000>;
- };
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ at91bootstrap@0 {
+ label = "at91bootstrap";
+ reg = <0x0 0x40000>;
+ };
- bootloader@40000 {
- label = "bootloader";
- reg = <0x40000 0xc0000>;
- };
+ bootloader@40000 {
+ label = "bootloader";
+ reg = <0x40000 0xc0000>;
+ };
- bootloaderenvred@100000 {
- label = "bootloader env redundant";
- reg = <0x100000 0x40000>;
- };
+ bootloaderenvred@100000 {
+ label = "bootloader env redundant";
+ reg = <0x100000 0x40000>;
+ };
- bootloaderenv@140000 {
- label = "bootloader env";
- reg = <0x140000 0x40000>;
- };
+ bootloaderenv@140000 {
+ label = "bootloader env";
+ reg = <0x140000 0x40000>;
+ };
- dtb@180000 {
- label = "device tree";
- reg = <0x180000 0x80000>;
- };
+ dtb@180000 {
+ label = "device tree";
+ reg = <0x180000 0x80000>;
+ };
- kernel@200000 {
- label = "kernel";
- reg = <0x200000 0x600000>;
+ kernel@200000 {
+ label = "kernel";
+ reg = <0x200000 0x600000>;
+ };
};
};
};
--
2.43.0
^ permalink raw reply related
* [PATCH v5 6/7] ARM: dts: microchip: sama5d27_wlsom1: read MAC address from QSPI SFDP
From: Manikandan Muralidharan @ 2026-07-21 5:28 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
In-Reply-To: <20260721052859.171341-1-manikandan.m@microchip.com>
Describe the QSPI flash SFDP as an NVMEM provider with the
microchip,sst26vf-sfdp-eui layout, which exposes the factory-programmed
EUI-48 as a "mac-address" cell, and point macb0 at it through
nvmem-cells. This yields a stable MAC address on boards where U-Boot does
not program one, instead of falling back to a random address.
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi | 11 +++++++++++
.../boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts | 2 ++
2 files changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
index 062aa02a98ed..6016d7f2a39c 100644
--- a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
+++ b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
@@ -240,6 +240,17 @@ qspi1_flash: flash@0 {
m25p,fast-read;
status = "disabled";
+ sfdp {
+ compatible = "jedec,sfdp";
+
+ nvmem-layout {
+ compatible = "microchip,sst26vf-sfdp-eui";
+
+ mac_address_eui48: mac-address {
+ };
+ };
+ };
+
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts
index 35a933eec573..5e87bf04bc47 100644
--- a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts
+++ b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1_ek.dts
@@ -97,6 +97,8 @@ uart6: serial@200 {
&macb0 {
status = "okay";
+ nvmem-cells = <&mac_address_eui48>;
+ nvmem-cell-names = "mac-address";
};
&pioA {
--
2.43.0
^ permalink raw reply related
* [PATCH v5 7/7] ARM: configs: sama5: enable Microchip/SST SFDP EUI NVMEM layout
From: Manikandan Muralidharan @ 2026-07-21 5:28 UTC (permalink / raw)
To: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
Cc: Manikandan Muralidharan
In-Reply-To: <20260721052859.171341-1-manikandan.m@microchip.com>
Enable CONFIG_NVMEM_LAYOUT_SST26VF_SFDP_EUI so the factory EUI-48 stored
in the SST26VF QSPI flash SFDP can be used as a MAC address on boards
such as the sama5d27_wlsom1.
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
---
arch/arm/configs/sama5_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/sama5_defconfig b/arch/arm/configs/sama5_defconfig
index bd7f0b5f7d66..14dda4b0cfd0 100644
--- a/arch/arm/configs/sama5_defconfig
+++ b/arch/arm/configs/sama5_defconfig
@@ -220,6 +220,7 @@ CONFIG_PWM=y
CONFIG_PWM_ATMEL=y
CONFIG_PWM_ATMEL_HLCDC_PWM=y
CONFIG_PWM_ATMEL_TCB=y
+CONFIG_NVMEM_LAYOUT_SST26VF_SFDP_EUI=y
CONFIG_EXT4_FS=y
CONFIG_FANOTIFY=y
CONFIG_AUTOFS_FS=m
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 2/4] media: synopsys: hdmirx: add HDMI audio capture support
From: Igor Paunovic @ 2026-07-21 5:31 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Mauro Carvalho Chehab, Sebastian Reichel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, linux-media,
linux-rockchip, linux-arm-kernel, kernel, devicetree,
linux-kernel
In-Reply-To: <b8d63f61-b73e-412e-8119-ced1afdd4551@collabora.com>
Hi Dmitry,
> Re-arming will be best option if it works properly.
Went back to it and made it work properly -- with one honest caveat
at the end.
Plain cancel/re-arm could not have been enough as previously
written: hdmirx_resume() fully resets the controller via
reset_control_bulk_assert/deassert in hdmirx_enable(), wiping the
audio configuration (I2S_EN, AUDIO_ENABLE, FIFO thresholds), and
the worker's error path never re-programs those -- it only resyncs
the clock rate and reinits the FIFO. So v4 does:
- suspend: cancel_delayed_work_sync() on the audio worker before
the clocks are gated (audio_streaming stays set);
- resume: if a capture stream is active, re-program the whole
audio path (clock from the last known sample rate, FIFO
thresholds, I2S_EN, AUDIO_ENABLE) and re-arm the worker.
The programming is factored out of hw_params() into a shared
hdmirx_audio_setup() helper so resume and hw_params cannot drift.
I also checked that nothing in the post-resume hotplug re-init path
(plugout/plugin/submodule_init/controller_init) touches the audio
bits, so the restore survives the replug dance resume triggers.
Measured on the Orange Pi 5 Plus (pm_test=devices, i.e. full device
suspend/resume callbacks, active capture stream with live audio
through the whole cycle): on resume the capture simply continues --
audio was flowing again the moment the display came back, no
userspace intervention, clean dmesg, no oops in any of the ~6
cycles exercised tonight.
The caveat: a *second* suspend/resume cycle in the same boot leaves
the audio datapath silent (the I2S slave sees no bit clock, so
capture reads time out) even though the resume restore re-programs
everything, and a fresh stream open does not recover it -- only a
reboot does. Notably this happens with plain no-stream suspend
cycles as well, so it is not caused by (and would not be prevented
by) either the re-arm or the -EBUSY approach -- it looks like more
controller state lost on repeated reset that neither hw_params nor
resume currently covers, likely the same warm-up state machine I
described in the v3 testing note (audio needing a video STREAMON
after a replug). I am instrumenting the register state next to
root-cause it; I'd treat it as a follow-up rather than a v4
blocker, but happy to hear if you see it differently -- and curious
whether the 5B shows the same second-cycle behavior.
v4 follows with the re-arm plus the dts and binding changes already
mentioned.
One more small thing the audio bit exposes, for a possible
follow-up: hdmirx_cec_update_bits() is a non-atomic RMW (the read
and the write each take rst_lock separately), and with audio added
there are now two writers of GLOBAL_SWENABLE, so a CEC adapter
enable racing an audio enable/disable could in theory lose the
other side's bit. Mainline today has a single writer, so it is not
a bug there. Can send a small patch making it atomic if you think
it is worth it.
Best regards,
Igor
On Mon, Jul 20, 2026 at 4:37 PM Dmitry Osipenko
<dmitry.osipenko@collabora.com> wrote:
>
> On 7/20/26 15:30, Igor Paunovic wrote:
> > Hi Dmitry,
> >
> > Great to hear it works on the 5B -- thanks for testing!
> >
> > Agreed on the -EBUSY guard, done in my tree exactly as you wrote it.
> > It also supersedes the suspend cancel/re-arm I had queued from the
> > bot review: with suspend refused while audio_streaming is set, the
> > worker can never be armed at suspend time, so those hunks are
> > dropped.
> >
> > v4 follows shortly with this plus Sebastian's dts restructuring
> > (shared disabled-by-default card in rk3588-extra.dtsi, renamed to
> > "RK3588 HDMI-IN") and Krzysztof's binding comments (dai-common.yaml
> > reference + unevaluatedProperties).
>
> Re-arming will be best option if it works properly.
>
> --
> Best regards,
> Dmitry
^ permalink raw reply
* Re: [PATCH v7 1/7] arm64/hugetlb: Extend batching of multiple CONT_PTE in a single PTE setup
From: Barry Song @ 2026-07-21 5:31 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Wen Jiang, akpm, catalin.marinas, linux-mm, urezki, will,
Xueyuan.chen21, ajd, anshuman.khandual, linux-arm-kernel,
linux-kernel, rppt, ryan.roberts, dev.jain, Wen Jiang, Leo Yan
In-Reply-To: <6adafb9c-b966-473b-90ba-3432b5574039@kernel.org>
On Mon, Jul 20, 2026 at 4:16 PM David Hildenbrand (Arm)
<david@kernel.org> wrote:
>
> On 7/15/26 13:08, Wen Jiang wrote:
> > From: "Barry Song (Xiaomi)" <baohua@kernel.org>
> >
> > For sizes aligned to CONT_PTE_SIZE and smaller than PMD_SIZE,
> > we can handle CONT_PTE_SIZE groups together.
> >
> > These additional sizes are mapping spans used by non-hugetlbfs(vmalloc)
> > mm code, not new HugeTLB hstate sizes.
> >
> > Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> > Signed-off-by: Wen Jiang <jiangwen6@xiaomi.com>
> > Tested-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> > Tested-by: Leo Yan <leo.yan@arm.com>
> > Reviewed-by: Dev Jain <dev.jain@arm.com>
> > ---
> > arch/arm64/mm/hugetlbpage.c | 15 +++++++++++++++
>
> Huh, why are we touching hugetlbpage.c, which is HUGETLB-only material:
>
> $ cat arch/arm64/mm/Makefile | grep hugetlbpage
> obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
>
> Something is off here, if vmalloc ends up reusing some of these helpers, they
> should probably get moved out here into common arm64 code.
This has been an issue since the original commit f7ee1f13d606c1
("mm/vmalloc: enable mapping of huge pages at pte level in vmap").
I agree that this likely needs some code reorganization. However, that would
probably be better handled as a separate follow-up series rather than as part
of this one, since it is not a small or trivial change.
The main problem is that the kernel lacks a set_ptes() helper for kernel
space. As a result, hugetlb has been repurposed for this across multiple
architectures since 2021 [1].
[1] https://lore.kernel.org/all/cover.1620795204.git.christophe.leroy@csgroup.eu/
Best Regards
Barry
^ permalink raw reply
* Re: [PATCH 1/2] phy: zynqmp: fix clock error handling in xpsgtr_phy_init()
From: Michal Simek @ 2026-07-21 5:39 UTC (permalink / raw)
To: Radhey Shyam Pandey, tomi.valkeinen, vkoul, neil.armstrong
Cc: linux-kernel, linux-phy, linux-arm-kernel, git
In-Reply-To: <20260720153832.1130006-2-radhey.shyam.pandey@amd.com>
On 7/20/26 17:38, Radhey Shyam Pandey wrote:
> Propagate clk_prepare_enable() failures to the caller instead of
> returning success, and disable the reference clock on initialization
> error paths to avoid leaking clock references when phy_exit() is not
> called.
>
> Fixes: 25d700833513 ("phy: xilinx: phy-zynqmp: dynamic clock support for power-save")
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
> ---
> drivers/phy/xilinx/phy-zynqmp.c | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/phy/xilinx/phy-zynqmp.c b/drivers/phy/xilinx/phy-zynqmp.c
> index fe6b4925d166..c8230f2bda62 100644
> --- a/drivers/phy/xilinx/phy-zynqmp.c
> +++ b/drivers/phy/xilinx/phy-zynqmp.c
> @@ -658,12 +658,13 @@ static int xpsgtr_phy_init(struct phy *phy)
> {
> struct xpsgtr_phy *gtr_phy = phy_get_drvdata(phy);
> struct xpsgtr_dev *gtr_dev = gtr_phy->dev;
> - int ret = 0;
> + int ret;
>
> mutex_lock(>r_dev->gtr_mutex);
>
> /* Configure and enable the clock when peripheral phy_init call */
> - if (clk_prepare_enable(gtr_dev->clk[gtr_phy->refclk]))
> + ret = clk_prepare_enable(gtr_dev->clk[gtr_phy->refclk]);
> + if (ret)
> goto out;
>
> /* Skip initialization if not required. */
> @@ -673,7 +674,7 @@ static int xpsgtr_phy_init(struct phy *phy)
> if (gtr_dev->tx_term_fix) {
> ret = xpsgtr_phy_tx_term_fix(gtr_phy);
> if (ret < 0)
> - goto out;
> + goto out_disable_clk;
>
> gtr_dev->tx_term_fix = false;
> }
> @@ -687,7 +688,7 @@ static int xpsgtr_phy_init(struct phy *phy)
> */
> ret = xpsgtr_configure_pll(gtr_phy);
> if (ret)
> - goto out;
> + goto out_disable_clk;
>
> xpsgtr_lane_set_protocol(gtr_phy);
>
> @@ -705,6 +706,10 @@ static int xpsgtr_phy_init(struct phy *phy)
> break;
> }
>
> + goto out;
> +
> +out_disable_clk:
> + clk_disable_unprepare(gtr_dev->clk[gtr_phy->refclk]);
> out:
> mutex_unlock(>r_dev->gtr_mutex);
> return ret;
Reviewed-by: Michal Simek <michal.simek@amd.com>
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH 2/2] phy: zynqmp: fix runtime PM leak on probe allocation failure
From: Michal Simek @ 2026-07-21 5:39 UTC (permalink / raw)
To: Radhey Shyam Pandey, tomi.valkeinen, vkoul, neil.armstrong
Cc: linux-kernel, linux-phy, linux-arm-kernel, git
In-Reply-To: <20260720153832.1130006-3-radhey.shyam.pandey@amd.com>
On 7/20/26 17:38, Radhey Shyam Pandey wrote:
> Allocate saved_regs before pm_runtime_resume_and_get() so a
> devm_kmalloc() failure does not leave an unreleased runtime PM usage
> counter.
>
> Fixes: 5af9b304bc60 ("phy: xilinx: phy-zynqmp: Fix SGMII linkup failure on resume")
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
> ---
> drivers/phy/xilinx/phy-zynqmp.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/phy/xilinx/phy-zynqmp.c b/drivers/phy/xilinx/phy-zynqmp.c
> index c8230f2bda62..2138f5399821 100644
> --- a/drivers/phy/xilinx/phy-zynqmp.c
> +++ b/drivers/phy/xilinx/phy-zynqmp.c
> @@ -1044,6 +1044,12 @@ static int xpsgtr_probe(struct platform_device *pdev)
> return PTR_ERR(provider);
> }
>
> + gtr_dev->saved_regs = devm_kmalloc(gtr_dev->dev,
> + sizeof(save_reg_address),
> + GFP_KERNEL);
> + if (!gtr_dev->saved_regs)
> + return -ENOMEM;
> +
> pm_runtime_set_active(gtr_dev->dev);
> pm_runtime_enable(gtr_dev->dev);
>
> @@ -1053,12 +1059,6 @@ static int xpsgtr_probe(struct platform_device *pdev)
> return ret;
> }
>
> - gtr_dev->saved_regs = devm_kmalloc(gtr_dev->dev,
> - sizeof(save_reg_address),
> - GFP_KERNEL);
> - if (!gtr_dev->saved_regs)
> - return -ENOMEM;
> -
> return 0;
> }
>
Reviewed-by: Michal Simek <michal.simek@amd.com>
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v4 0/3] Add support for Variscite VAR-SOM-AM62 and Symphony board
From: Vignesh Raghavendra @ 2026-07-21 5:47 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-arm-kernel, Stefano Radaelli
Cc: pierluigi.p, matthias.p, Stefano Radaelli, Nishanth Menon,
Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kees Cook, Tony Luck, Guilherme G. Piccoli
In-Reply-To: <cover.1783864932.git.stefano.r@variscite.com>
Hi Stefano Radaelli,
On Sun, 12 Jul 2026 16:04:47 +0200, Stefano Radaelli wrote:
> Add support for Variscite VAR-SOM-AM62 and Symphony board
>
> The series includes:
> - Device tree bindings documentation
> - SOM device tree with common peripherals
> - Symphony carrier board device tree with board-specific features
>
> [...]
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/3] dt-bindings: arm: ti: Add bindings for Variscite VAR-SOM-AM62
commit: 8571d1e223a5d220aba7e323b4de36d7341ee37e
[2/3] arm64: dts: ti: Add support for Variscite VAR-SOM-AM62
commit: 5f865bbef8e5a91780064b847365d755845bc974
[3/3] arm64: dts: ti: var-som-am62: Add support for Variscite Symphony Board
commit: 5fde9c21c671ff501523d55138b4f5eeb577b97e
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
--
Vignesh
^ permalink raw reply
* Re: [PATCH v2 0/4] arm64: dts: am62p5-var-som-symphony: align DTS with hardware revision
From: Vignesh Raghavendra @ 2026-07-21 5:47 UTC (permalink / raw)
To: linux-kernel, devicetree, linux-arm-kernel, Stefano Radaelli
Cc: pierluigi.p, matthias.p, Stefano Radaelli, Nishanth Menon,
Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <cover.1782680023.git.stefano.r@variscite.com>
Hi Stefano Radaelli,
On Sun, 28 Jun 2026 22:56:04 +0200, Stefano Radaelli wrote:
> arm64: dts: am62p5-var-som-symphony: align DTS with hardware revision
>
> This series updates the device tree description for the Variscite
> VAR-SOM-AM62P and Symphony carrier board to better reflect the current
> board configuration.
>
> It aligns the Ethernet PHY description, updates the audio codec
> configuration, and adds the touchscreen and TPM devices together with
> their required board-level resources.
>
> [...]
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/4] arm64: dts: ti: var-som-am62p: fix Ethernet PHY configuration
commit: 1c97b48546ad266090d66528314f7da399ce6ecf
[2/4] arm64: dts: ti: var-som-am62p: update audio codec configuration
commit: c026c728573b42718759ce425b075b9b25e194bf
[3/4] arm64: dts: am62p5-var-som-symphony: add touchscreen support
commit: b29d6c7d2030f084e3b4911579bce1fb038b24fb
[4/4] arm64: dts: am62p5-var-som-symphony: add TPM support
commit: cb364ce1df8902d8f26c05e1091e24f337efade7
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
--
Vignesh
^ permalink raw reply
* Re: [PATCH 7/7] soc: xilinx: Remove redundant dev_err()
From: Michal Simek @ 2026-07-21 5:49 UTC (permalink / raw)
To: Pandey, Radhey Shyam, Pan Chuang, Prasanna Kumar T S M,
Marco Crivellari, Jay Buddhabhatti,
moderated list:ARM/ZYNQ ARCHITECTURE, open list, Arnd Bergmann
In-Reply-To: <8ca27e7b-d122-48c1-bf1c-0f104c4a7eec@amd.com>
On 7/20/26 17:50, Pandey, Radhey Shyam wrote:
> On 7/20/2026 3:29 PM, Pan Chuang wrote:
>> Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in
>> devm_request_*_irq()"), devm_request_threaded_irq() automatically logs
>> detailed error messages on failure. Remove the now-redundant
>> driver-specific dev_err() calls.
>>
>> Signed-off-by: Pan Chuang <panchuang@vivo.com>
>> ---
>
> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
> Thanks!
>> drivers/soc/xilinx/zynqmp_power.c | 5 +----
>> 1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/drivers/soc/xilinx/zynqmp_power.c b/drivers/soc/xilinx/
>> zynqmp_power.c
>> index 370e61ac47d8..54c796afb89e 100644
>> --- a/drivers/soc/xilinx/zynqmp_power.c
>> +++ b/drivers/soc/xilinx/zynqmp_power.c
>> @@ -368,11 +368,8 @@ static int zynqmp_pm_probe(struct platform_device *pdev)
>> IRQF_NO_SUSPEND | IRQF_ONESHOT,
>> dev_name(&pdev->dev),
>> &pdev->dev);
>> - if (ret) {
>> - dev_err(&pdev->dev, "devm_request_threaded_irq '%d' failed with
>> %d\n",
>> - irq, ret);
>> + if (ret)
>> return ret;
>> - }
>> } else {
>> dev_err(&pdev->dev, "Required property not found in DT node\n");
>> return -ENOENT;
>
No issue with this patch but how do you want this to be merged?
It should go via soc specific trees and then to Arnd. I don't think Arnd will
take this directly to soc tree.
My suggestion would be to split it and get that patches merged separately.
Just in case
Acked-by: Michal Simek <michal.simek@amd.com>
Thanks,
Michal
^ 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