* [PATCH] raspberrypi: vchiq: free recycle buffer on thread exit
From: Yousef Alhouseen @ 2026-06-29 16:03 UTC (permalink / raw)
To: Florian Fainelli
Cc: Broadcom internal kernel review list, linux-rpi-kernel,
linux-arm-kernel, linux-kernel, Yousef Alhouseen
recycle_func() allocates a bitmap used while processing the free queue,
but returns directly when remote_event_wait() fails. The normal
kthread-stop path also exits without releasing the allocation.
Break out of the loop on wait errors, free the bitmap, and return the
saved status so both the error and stop paths release the per-thread
buffer.
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
---
drivers/platform/raspberrypi/vchiq-interface/vchiq_core.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/raspberrypi/vchiq-interface/vchiq_core.c b/drivers/platform/raspberrypi/vchiq-interface/vchiq_core.c
index 48d6b1d74329..f8b2d4b1a30e 100644
--- a/drivers/platform/raspberrypi/vchiq-interface/vchiq_core.c
+++ b/drivers/platform/raspberrypi/vchiq-interface/vchiq_core.c
@@ -2346,7 +2346,7 @@ recycle_func(void *v)
struct vchiq_shared_state *local = state->local;
u32 *found;
size_t length;
- int ret;
+ int ret = 0;
length = sizeof(*found) * BITSET_SIZE(VCHIQ_MAX_SERVICES);
@@ -2358,11 +2358,12 @@ recycle_func(void *v)
while (!kthread_should_stop()) {
ret = remote_event_wait(&state->recycle_event, &local->recycle);
if (ret)
- return ret;
+ break;
process_free_queue(state, found, length);
}
- return 0;
+ kfree(found);
+ return ret;
}
/* Called by the sync thread */
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 0/2] CPPC: reduce FFH feedback-counter sampling skew on arm64
From: Sumit Gupta @ 2026-06-29 15:54 UTC (permalink / raw)
To: Pengjie Zhang, catalin.marinas, will, rafael, lenb, robert.moore,
beata.michalska, zhenglifeng1, zhanjie9, cuiyunhui
Cc: linux-arm-kernel, linux-kernel, linux-acpi, acpica-devel,
linuxarm, jonathan.cameron, prime.zeng, wanghuiqiang, xuwei5,
lihuisong, yubowen8, wangzhi12, linux-tegra@vger.kernel.org
In-Reply-To: <20260410094145.4132082-1-zhangpengjie2@huawei.com>
On 10/04/26 15:11, Pengjie Zhang wrote:
> External email: Use caution opening links or attachments
>
>
> The legacy CPPC feedback-counter path reads the delivered and reference
> performance counters separately.
>
> On arm64 systems using AMU-backed CPPC FFH counters, each FFH read is
> served through a cross-CPU counter read helper. Reading the counters
> separately therefore widens the sampling window between them and can
> skew the delivered/reference ratio used by cpuinfo_cur_freq. Under heavy
> load, the skew is observable as transient values that may exceed the
> platform maximum, as discussed in [1] and [2].
>
> This series adds a small generic hook for architectures that can obtain
> both FFH feedback counters in one operation, while preserving the
> existing per-register read path as the fallback.
>
> Patch 1 adds the generic CPPC hook and uses it from cppc_get_perf_ctrs().
> Patch 2 implements the hook on arm64 by sampling both AMU counters in a
> single operation on the target CPU.
>
> [1] https://lore.kernel.org/all/20231025093847.3740104-4-zengheng4@huawei.com/
> [2] https://lore.kernel.org/all/20231212072617.14756-1-lihuisong@huawei.com/
>
> Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
>
> Pengjie Zhang (2):
> ACPI: CPPC: add paired FFH feedback-counter read hook
> arm64: topology: read CPPC FFH feedback counters in one operation
>
> arch/arm64/kernel/topology.c | 75 ++++++++++++++++++++++++++++++++----
> drivers/acpi/cppc_acpi.c | 58 +++++++++++++++++++++++++---
> include/acpi/cppc_acpi.h | 7 ++++
> 3 files changed, 127 insertions(+), 13 deletions(-)
>
> --
Hi Pengjie,
Thanks for the patches.
The series looks good to me, and it fixes the cpuinfo_cur_freq
spikes on an NVIDIA Vera (FFH) platform.
Just one nit on patch 2 (counter read order), noted there.
Tested-by: Sumit Gupta <sumitg@nvidia.com>
Reviewed-by: Sumit Gupta <sumitg@nvidia.com>
Thanks,
Sumit
^ permalink raw reply
* Re: [PATCH v4 0/4] arm64: cross-CPU NMI via SDEI
From: Catalin Marinas @ 2026-06-29 15:54 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: Will Deacon, James Morse, Mark Rutland, Marc Zyngier,
Doug Anderson, Petr Mladek, Thomas Gleixner, Andrew Morton,
Baoquan He, Puranjay Mohan, Usama Arif, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel
In-Reply-To: <akJsQK2iG2oZ3vYE@thinkstation>
On Mon, Jun 29, 2026 at 02:05:14PM +0100, Kiryl Shutsemau wrote:
> On Fri, Jun 26, 2026 at 08:40:57PM +0100, Kiryl Shutsemau wrote:
> > But I have not tried calling CPU_OFF directly, without completing the
> > event. I assumed it is required. Will give it a try when I have time.
>
> Tried it now, and it doesn't work either -- in a more interesting way.
>
> Calling PSCI CPU_OFF directly from the SDEI handler (event left
> uncompleted) reproducibly breaks the kdump capture kernel, and this
> reproduces under QEMU's TF-A, not just on Grace -- so it isn't a Grace
> firmware quirk.
I had a quick grep (with the help of claude) through the TF-A code and
it doesn't seem to be compliant with the spec. It should subscribe to
the PSCI CPU_OFF event and complete the SDEI but it doesn't. It seems to
handle CPU_ON but that may not be sufficient. It only EIOs the SGI once
the OS completed the event, which doesn't happen if you issue CPU_OFF.
> The test: a CPU wedged with interrupts masked is stopped via the SDEI
> rung; its handler calls __cpu_try_die() instead of parking. A/B in QEMU,
> changing only that wedged CPU's handling (everything else identical):
>
> - park it (current series): capture kernel boots fully to a shell.
> - CPU_OFF from the handler: capture kernel hangs in early boot, around
> SDEI re-init, never reaches a shell.
>
> Powering the PE off while its SDEI event is still active leaves EL3's
> dispatch state dangling, and the capture kernel trips over it. Completing
> the event first and then CPU_OFF -- what I tried originally -- silently
> wedges EL3 on Grace instead.
>
> So both routes off fail, and the CPU stays parked. The dump is complete
> either way; only re-onlining the stopped CPU in an SMP capture kernel is
> lost. It's a cheap QEMU repro now if anyone wants to dig into the EL3
> side.
Have you tried SDEI_EVENT_COMPLETE_AND_RESUME instead? Just COMPLETE
won't return to the kernel. We have sdei_handler_abort() to complete the
event and, hopefully, you can continue with the CPU_OFF. It's a work
around the TF-A non-compliance but I think this is useful even if you
don't issue the CPU_OFF (e.g. no CPU hotplug, just the park loop).
--
Catalin
^ permalink raw reply
* Re: (subset) [PATCH v5 0/6] Add support for Baijie Helper A133 board
From: Chen-Yu Tsai @ 2026-06-29 15:51 UTC (permalink / raw)
To: linux-arm-kernel, linux-sunxi, Alexander Sverdlin
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jernej Skrabec,
Samuel Holland, Hans de Goede, Dmitry Torokhov, Andre Przywara,
Jun Yan, Lukas Schmid, J. Neuschäfer, Eric Biggers,
Michal Simek, Luca Weiss, Sven Peter, Maxime Ripard, devicetree,
linux-kernel, linux-input
In-Reply-To: <20260623204824.691832-1-alexander.sverdlin@gmail.com>
On Tue, 23 Jun 2026 22:48:12 +0200, Alexander Sverdlin wrote:
> Baijie Helper A133 board is a development board around Baijie A133 Core
> SBC. Features:
>
> - 1/2/4GiB LPDDR4 DRAM
> - 8/16/32GiB eMMC
> - AXP707 PMIC
> - USB-C OTG port in peripheral mode (via onboard hub)
> - 2 USB 2.0 ports
> - MicroSD slot and on-board eMMC module
> - Gigabit Ethernet
> - Bluetooth
> - WiFi
>
> [...]
Applied to sunxi/config-for-7.3 in local tree, thanks!
[1/6] arm64: defconfig: Enable Allwinner LRADC input driver
commit: b4158103c45386ab30ba7624bee17ebf33940baa
Best regards,
--
Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* Re: [PATCH RFC v5 00/12] ZTE zx297520v3 clock bindings and driver
From: Conor Dooley @ 2026-06-29 15:49 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Brian Masney, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260628-zx29clk-v5-0-79ff044e4192@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1348 bytes --]
On Sun, Jun 28, 2026 at 10:58:55PM +0300, Stefan Dösinger wrote:
> Hi,
>
> I am sending version 5 of my zx297520v3 clock patch. The major change is
> using regmaps rather than raw mmio to access the clocks and moving reset
> handling into its own mfd/aux bus driver.
>
> I think the list of clocks in my driver is fairly complete; It is
> certainly a lot better than what the downstream ZTE drivers have. I
> deduced a lot of it by trial and error. I am sure there are some clocks
> missing that will need to be added to the binding later. Afaiu adding
> clocks is not an issue, but removing or reordering them is an ABI break.
Correct, you can add whatever you want as long as the existing defines
do not change.
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
> ---
> Changes in v5:
> *) Use MFD instead of aux bus for top and matrix clocks
> *) Move top and matrix bindings to soc/zte
> *) Give USB PHY its own resets
> *) Other localized changes are noted in the individual patches
> - Link to v4: https://lore.kernel.org/r/20260616-zx29clk-v4-0-ca994bd22e9d@gmail.com
Bindings seem fine to me, I'll be happy to give you some r-b tags when
you go non-RFC. To be frank, I think you should drop them as you've got
no significant questions here I think and you'll be taken a bt more
seriously.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: Arnd Bergmann @ 2026-06-29 15:48 UTC (permalink / raw)
To: Geert Uytterhoeven, Arnd Bergmann
Cc: Linus Walleij, Bartosz Golaszewski, Marcel Holtmann, MyungJoo Ham,
Chanwoo Choi, Geert Uytterhoeven, Andy Shevchenko,
Dmitry Torokhov, Ulf Hansson, linux-bluetooth, linux-kernel,
open list:GPIO SUBSYSTEM, dri-devel, linux-i2c, linux-iio,
linux-input, linux-mmc @ vger . kernel . org, linux-arm-kernel,
linux-pm, linux-usb
In-Reply-To: <CAMuHMdXhsM4JzArRuB=A46N-Ogbn2Fans+PVJVA-hEytFq=DeQ@mail.gmail.com>
On Mon, Jun 29, 2026, at 17:29, Geert Uytterhoeven wrote:
> On Mon, 29 Jun 2026 at 15:59, Arnd Bergmann <arnd@kernel.org> wrote:
>> From: Arnd Bergmann <arnd@arndb.de>
>>
>> Most remaining users of desc_to_gpio() only call it for printing debug
>> information.
>>
>> Replace this with a new gpiod_name() helper that returns the
>> gpio_desc->name string after checking the gpio_desc pointer.
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Thanks for your patch!
Thanks for testing!
>> --- a/drivers/gpio/gpio-aggregator.c
>> +++ b/drivers/gpio/gpio-aggregator.c
>> @@ -758,8 +758,8 @@ int gpiochip_fwd_desc_add(struct gpiochip_fwd *fwd, struct gpio_desc *desc,
>>
>> fwd->descs[offset] = desc;
>>
>> - dev_dbg(chip->parent, "%u => gpio %d irq %d\n", offset,
>> - desc_to_gpio(desc), gpiod_to_irq(desc));
>> + dev_dbg(chip->parent, "%u => gpio %s irq %d\n", offset,
>> + gpiod_name(desc), gpiod_to_irq(desc));
>>
>> return 0;
>> }
>
> Before, this printed:
>
> gpio-aggregator gpio-aggregator.1: 0 => gpio 589 irq 188
> gpio-aggregator gpio-aggregator.1: 1 => gpio 590 irq 189
>
> After, this prints:
>
> gpio-aggregator gpio-aggregator.1: 0 => gpio (null) irq 188
> gpio-aggregator gpio-aggregator.1: 1 => gpio (null) irq 189
>
> Same results for instantiation using sysfs or configfs[1], although
> the latter does have optional support for specifying the name.
I wonder how many of the other instances have the same problem
then. Would it be appropriate for gpiochip_fwd_desc_add() to set
a name itself to address this one?
Arnd
^ permalink raw reply
* Re: [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: Arnd Bergmann @ 2026-06-29 15:45 UTC (permalink / raw)
To: Andy Shevchenko, Arnd Bergmann
Cc: Linus Walleij, Bartosz Golaszewski, Marcel Holtmann, MyungJoo Ham,
Chanwoo Choi, Geert Uytterhoeven, Andy Shevchenko,
Dmitry Torokhov, Ulf Hansson, linux-bluetooth, linux-kernel,
open list:GPIO SUBSYSTEM, dri-devel, linux-i2c, linux-iio,
linux-input, linux-mmc @ vger . kernel . org, linux-arm-kernel,
linux-pm, linux-usb
In-Reply-To: <akKN59lv55CXS3HU@ashevche-desk.local>
On Mon, Jun 29, 2026, at 17:23, Andy Shevchenko wrote:
> On Mon, Jun 29, 2026 at 03:56:29PM +0200, Arnd Bergmann wrote:
>> +const char *gpiod_name(const struct gpio_desc *desc)
>> +{
>> + return desc ? desc->name : "(no gpio)";
>
> Can we get into here with wrong (error pointer descriptor)? Shouldn't you call
> one of validate_desc() / VALIDATE_DESC()?
Since all the callers previously call desc_to_gpio and that does
not even check desc at all, it would be a preexisting bug if
any caller passed an error pointer.
I added the NULL pointer check since many callers had that
part originally, like
tsdata->wake_gpio ? desc_to_gpio(tsdata->wake_gpio) : -1,
> Also not sure if "(no gpio)" is a good choice. "not requested"? "not provided"?
Any of those seem fine to me, not sure.
>> +static inline const char *gpiod_name(const struct gpio_desc *desc)
>> +{
>> + WARN_ON(desc);
>> + return "(no gpio)";
>
> Hmm... This will be a second copy with a slight potential of going apart from
> the other case. Perhaps a #define? (Yes, yes, I understand that there are pros
> and cons, in particular readability with define is questionable.)
I was mostly trying to optimize for consistency with the other
stub functions here. Since it should not actually be used at all
without gpiolib, returning NULL or an empty string here would
also work.
Arnd
^ permalink raw reply
* Re: [PATCH] remoteproc: xlnx: refactor start & stop ops
From: Mathieu Poirier @ 2026-06-29 15:44 UTC (permalink / raw)
To: Tanmay Shah
Cc: michal.simek, andersson, linux-arm-kernel, linux-kernel,
linux-remoteproc
In-Reply-To: <20260619163854.410392-1-tanmay.shah@amd.com>
On Fri, Jun 19, 2026 at 09:38:54AM -0700, Tanmay Shah wrote:
> Current _start and _stop ops are implemented using various APIs from the
> platform management firmware driver. Instead provide respective RPU
> start and stop API in the firmware driver and move the logic to interact
> with the PM firmware in the firmware driver. The remoteproc driver doesn't
> need to know actual logic, but only the final result i.e. RPU start/stop
> was success or not. This refactor keeps the remoteproc driver simple and
> moves firmware interaction logic to the firmware driver.
>
> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
> ---
> drivers/firmware/xilinx/zynqmp.c | 93 +++++++++++++++++++++++++
> drivers/remoteproc/xlnx_r5_remoteproc.c | 68 ++----------------
> include/linux/firmware/xlnx-zynqmp.h | 12 ++++
> 3 files changed, 110 insertions(+), 63 deletions(-)
>
Applied.
Thanks,
Mathieu
> diff --git a/drivers/firmware/xilinx/zynqmp.c b/drivers/firmware/xilinx/zynqmp.c
> index af838b2dc327..f9a3a95b0638 100644
> --- a/drivers/firmware/xilinx/zynqmp.c
> +++ b/drivers/firmware/xilinx/zynqmp.c
> @@ -1513,6 +1513,99 @@ int zynqmp_pm_request_wake(const u32 node,
> }
> EXPORT_SYMBOL_GPL(zynqmp_pm_request_wake);
>
> +/**
> + * zynqmp_pm_start_rpu - Boot Real-time Processing Unit (Cortex-R) on SoC
> + *
> + * @node: power-domains id of the core
> + * @bootaddr: Boot address of elf
> + *
> + * Return: status, either success or error+reason
> + */
> +int zynqmp_pm_start_rpu(const u32 node, const u64 bootaddr)
> +{
> + enum rpu_boot_mem bootmem;
> + int ret;
> +
> + /*
> + * The exception vector pointers (EVP) refer to the base-address of
> + * exception vectors (for reset, IRQ, FIQ, etc). The reset-vector
> + * starts at the base-address and subsequent vectors are on 4-byte
> + * boundaries.
> + *
> + * Exception vectors can start either from 0x0000_0000 (LOVEC) or
> + * from 0xFFFF_0000 (HIVEC) which is mapped in the OCM (On-Chip Memory)
> + *
> + * Usually firmware will put Exception vectors at LOVEC.
> + *
> + * It is not recommend that you change the exception vector.
> + * Changing the EVP to HIVEC will result in increased interrupt latency
> + * and jitter. Also, if the OCM is secured and the Cortex-R5F processor
> + * is non-secured, then the Cortex-R5F processor cannot access the
> + * HIVEC exception vectors in the OCM.
> + */
> + bootmem = (bootaddr >= 0xFFFC0000) ?
> + PM_RPU_BOOTMEM_HIVEC : PM_RPU_BOOTMEM_LOVEC;
> +
> + pr_debug("RPU boot addr 0x%llx from %s.", bootaddr,
> + bootmem == PM_RPU_BOOTMEM_HIVEC ? "OCM" : "TCM");
> +
> + /* Request node before starting RPU core if new version of API is supported */
> + if (zynqmp_pm_feature(PM_REQUEST_NODE) > PM_API_VERSION_1) {
> + ret = zynqmp_pm_request_node(node,
> + ZYNQMP_PM_CAPABILITY_ACCESS, 0,
> + ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> + if (ret < 0) {
> + pr_err("failed to request 0x%x", node);
> + return ret;
> + }
> + }
> +
> + ret = zynqmp_pm_request_wake(node, true,
> + bootmem, ZYNQMP_PM_REQUEST_ACK_NO);
> + if (ret)
> + pr_err("failed to start RPU = 0x%x\n", node);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(zynqmp_pm_start_rpu);
> +
> +/**
> + * zynqmp_pm_stop_rpu - Stop Real-time Processing Unit (Cortex-R) on SoC
> + *
> + * @node: power-domains id of the core
> + *
> + * Return: status, either success or error+reason
> + */
> +int zynqmp_pm_stop_rpu(const u32 node)
> +{
> + int ret;
> +
> + /* Use release node API to stop core if new version of API is supported */
> + if (zynqmp_pm_feature(PM_RELEASE_NODE) > PM_API_VERSION_1) {
> + ret = zynqmp_pm_release_node(node);
> + if (ret)
> + pr_err("failed to stop remoteproc RPU %d\n", ret);
> + return ret;
> + }
> +
> + /*
> + * Check expected version of EEMI call before calling it. This avoids
> + * any error or warning prints from firmware as it is expected that fw
> + * doesn't support it.
> + */
> + if (zynqmp_pm_feature(PM_FORCE_POWERDOWN) != PM_API_VERSION_1) {
> + pr_debug("EEMI interface %d ver 1 not supported\n",
> + PM_FORCE_POWERDOWN);
> + return -EOPNOTSUPP;
> + }
> +
> + /* maintain force pwr down for backward compatibility */
> + ret = zynqmp_pm_force_pwrdwn(node, ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> + if (ret)
> + pr_err("core force power down failed\n");
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(zynqmp_pm_stop_rpu);
> +
> /**
> * zynqmp_pm_set_requirement() - PM call to set requirement for PM slaves
> * @node: Node ID of the slave
> diff --git a/drivers/remoteproc/xlnx_r5_remoteproc.c b/drivers/remoteproc/xlnx_r5_remoteproc.c
> index 3349d1877751..dcd8a93f031c 100644
> --- a/drivers/remoteproc/xlnx_r5_remoteproc.c
> +++ b/drivers/remoteproc/xlnx_r5_remoteproc.c
> @@ -364,49 +364,12 @@ static void zynqmp_r5_rproc_kick(struct rproc *rproc, int vqid)
> static int zynqmp_r5_rproc_start(struct rproc *rproc)
> {
> struct zynqmp_r5_core *r5_core = rproc->priv;
> - enum rpu_boot_mem bootmem;
> int ret;
>
> - /*
> - * The exception vector pointers (EVP) refer to the base-address of
> - * exception vectors (for reset, IRQ, FIQ, etc). The reset-vector
> - * starts at the base-address and subsequent vectors are on 4-byte
> - * boundaries.
> - *
> - * Exception vectors can start either from 0x0000_0000 (LOVEC) or
> - * from 0xFFFF_0000 (HIVEC) which is mapped in the OCM (On-Chip Memory)
> - *
> - * Usually firmware will put Exception vectors at LOVEC.
> - *
> - * It is not recommend that you change the exception vector.
> - * Changing the EVP to HIVEC will result in increased interrupt latency
> - * and jitter. Also, if the OCM is secured and the Cortex-R5F processor
> - * is non-secured, then the Cortex-R5F processor cannot access the
> - * HIVEC exception vectors in the OCM.
> - */
> - bootmem = (rproc->bootaddr >= 0xFFFC0000) ?
> - PM_RPU_BOOTMEM_HIVEC : PM_RPU_BOOTMEM_LOVEC;
> -
> - dev_dbg(r5_core->dev, "RPU boot addr 0x%llx from %s.", rproc->bootaddr,
> - bootmem == PM_RPU_BOOTMEM_HIVEC ? "OCM" : "TCM");
> -
> - /* Request node before starting RPU core if new version of API is supported */
> - if (zynqmp_pm_feature(PM_REQUEST_NODE) > 1) {
> - ret = zynqmp_pm_request_node(r5_core->pm_domain_id,
> - ZYNQMP_PM_CAPABILITY_ACCESS, 0,
> - ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> - if (ret < 0) {
> - dev_err(r5_core->dev, "failed to request 0x%x",
> - r5_core->pm_domain_id);
> - return ret;
> - }
> - }
> -
> - ret = zynqmp_pm_request_wake(r5_core->pm_domain_id, 1,
> - bootmem, ZYNQMP_PM_REQUEST_ACK_NO);
> + ret = zynqmp_pm_start_rpu(r5_core->pm_domain_id, rproc->bootaddr);
> if (ret)
> - dev_err(r5_core->dev,
> - "failed to start RPU = 0x%x\n", r5_core->pm_domain_id);
> + dev_err(&rproc->dev, "failed to start RPU\n");
> +
> return ret;
> }
>
> @@ -423,30 +386,9 @@ static int zynqmp_r5_rproc_stop(struct rproc *rproc)
> struct zynqmp_r5_core *r5_core = rproc->priv;
> int ret;
>
> - /* Use release node API to stop core if new version of API is supported */
> - if (zynqmp_pm_feature(PM_RELEASE_NODE) > 1) {
> - ret = zynqmp_pm_release_node(r5_core->pm_domain_id);
> - if (ret)
> - dev_err(r5_core->dev, "failed to stop remoteproc RPU %d\n", ret);
> - return ret;
> - }
> -
> - /*
> - * Check expected version of EEMI call before calling it. This avoids
> - * any error or warning prints from firmware as it is expected that fw
> - * doesn't support it.
> - */
> - if (zynqmp_pm_feature(PM_FORCE_POWERDOWN) != 1) {
> - dev_dbg(r5_core->dev, "EEMI interface %d ver 1 not supported\n",
> - PM_FORCE_POWERDOWN);
> - return -EOPNOTSUPP;
> - }
> -
> - /* maintain force pwr down for backward compatibility */
> - ret = zynqmp_pm_force_pwrdwn(r5_core->pm_domain_id,
> - ZYNQMP_PM_REQUEST_ACK_BLOCKING);
> + ret = zynqmp_pm_stop_rpu(r5_core->pm_domain_id);
> if (ret)
> - dev_err(r5_core->dev, "core force power down failed\n");
> + dev_err(&rproc->dev, "failed to stop RPU\n");
>
> return ret;
> }
> diff --git a/include/linux/firmware/xlnx-zynqmp.h b/include/linux/firmware/xlnx-zynqmp.h
> index 7e27b0f7bf7e..347df66ee176 100644
> --- a/include/linux/firmware/xlnx-zynqmp.h
> +++ b/include/linux/firmware/xlnx-zynqmp.h
> @@ -644,6 +644,8 @@ int zynqmp_pm_get_node_status(const u32 node, u32 *const status,
> u32 *const requirements, u32 *const usage);
> int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const status,
> u32 *const requirements, u32 *const usage);
> +int zynqmp_pm_start_rpu(const u32 node, const u64 bootaddr);
> +int zynqmp_pm_stop_rpu(const u32 node);
> int zynqmp_pm_set_sd_config(u32 node, enum pm_sd_config_type config, u32 value);
> int zynqmp_pm_set_gem_config(u32 node, enum pm_gem_config_type config,
> u32 value);
> @@ -960,6 +962,16 @@ static inline int zynqmp_pm_get_rpu_node_status(const u32 node, u32 *const statu
> return -ENODEV;
> }
>
> +static inline int zynqmp_pm_start_rpu(const u32 node, const u64 bootaddr)
> +{
> + return -ENODEV;
> +}
> +
> +static inline int zynqmp_pm_stop_rpu(const u32 node)
> +{
> + return -ENODEV;
> +}
> +
> static inline int zynqmp_pm_set_sd_config(u32 node,
> enum pm_sd_config_type config,
> u32 value)
>
> base-commit: 721396afea31eac476d88f5db10ba111ba4b8382
> --
> 2.34.1
>
^ permalink raw reply
* Re: (subset) [PATCH v6 0/7] pinctrl: Add generic pinctrl for board-level mux chips
From: Frank.Li @ 2026-06-29 15:43 UTC (permalink / raw)
To: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafał Miłecki, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Peter Rosin, Frank Li
Cc: linux-kernel, linux-gpio, devicetree, imx, linux-arm-kernel,
Haibo Chen, Conor Dooley, Ahmad Fatoum
In-Reply-To: <20260504-pinctrl-mux-v6-0-8ea858ba3a5b@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
On Mon, 04 May 2026 19:54:34 -0400, Frank Li wrote:
> Add a generic pinctrl binding for board-level pinmux chips that are
> controlled through the multiplexer subsystem.
>
> On some boards, especially development boards, external mux chips are used
> to switch SoC signals between different peripherals (e.g. MMC and UART).
> The mux select lines are often driven by a GPIO expander over I2C,
> as illustrated below:
>
> [...]
Applied, thanks!
[6/7] arm64: dts: imx8mp-evk: add board-level mux for CAN2 and MICFIL
commit: ec5c75673cb9d4c9a2a55a70d54a6ccb254f4ba4
[7/7] arm64: dts: imx8mp-evk: add flexcan2 overlay file
commit: 368eb597c6ef0263931a3922648e8c7b83cd0536
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: RE: [PATCH v3 01/10] mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()
From: Sebastian Andrzej Siewior @ 2026-06-29 15:38 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: linux-remoteproc@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-rt-devel@lists.linux.dev, Bjorn Andersson, Clark Williams,
Fabio Estevam, Frank Li, Jassi Brar, Mathieu Poirier,
Pengutronix Kernel Team, Sascha Hauer, Steven Rostedt
In-Reply-To: <MRWPR04MB12330C5851B5421F8EE723F1A88EB2@MRWPR04MB12330.eurprd04.prod.outlook.com>
On 2026-06-26 09:00:04 [+0000], Peng Fan (OSS) wrote:
> > > If you would like to address the AI reported issue further, you may
> > > update readl_poll_timeout to readl_poll_timeout_atomic.
> >
> > What about the timeout value? Keep it as-is or reduce to?
>
> Let's keep it as-is.
The call is
readl_poll_timeout(, , , delay_us = 0, timeout_us = 10000);
so it will _not_ trigger the might_sleep() splat and will compare the
timeout value against ktime_get() so it will loop worst case for 10ms.
If I change it as-is to
readl_poll_timeout_atomic(, , , delay_us = 0, timeout_us = 10000);
then the result is slightly different: The clocksource is not used
(because it also works in suspend path where it is gone) and so the
timeout_us value is decremented based on the delay_us. If it is 0 then
it only subtracts 1ns per iteration. So the worst case delay becomes now
10.000.000 iterations.
I don't think this is an improvement: In the worst case the delay is
much longer and if there is a watch in that period, it will fire. So it
does not accomplish anything.
Having something like
readl_poll_timeout_atomic(, , , delay_us = 2, timeout_us = 100);
would lower the delay to 100us max (which is below the 1000HZ tick) and
would spin for 2us between register pools. But I have no idea what is
the expected delay and if it depends on the remote side.
Please be aware that this series except for the remoteproc/ imx_rproc)
has been merged as of v7.2-rc1. I can still send an update to the poll
in imx_mu_generic_tx() but I would prefer an improvement ;)
> Thanks,
> Peng.
Sebastian
^ permalink raw reply
* Re: [PATCH v2 2/6] clk: sunxi-ng: sun6i-rtc: clean up DT usage
From: Chen-Yu Tsai @ 2026-06-29 15:37 UTC (permalink / raw)
To: Jerome Brunet
Cc: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jernej Skrabec, Samuel Holland, Michael Turquette,
Stephen Boyd, Maxime Ripard, linux-rtc, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel, linux-clk
In-Reply-To: <20260629-a733-rtc-v2-2-7b72112784f8@baylibre.com>
On Mon, Jun 29, 2026 at 8:42 PM Jerome Brunet <jbrunet@baylibre.com> wrote:
>
> With sun6i-rtc compatible devices, the "ext-osc32k" clock input
> is optional for the devices that support this input (r329 and onward).
>
> Probably preparing for older SoC support, the driver does something funny
> when parsing DT. It check if "ext-osc32k" is present in the clock-names and
> if it is not, it uses the first clock as "ext-osc32k". This clock will
> actually be the rtc bus clock so what the driver does is wrong.
>
> At the moment, the driver does not support the older SoCs that would have
> an external 32k clock provided on index #0 so just remove this quirk.
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v6 0/4] Update the thermal support for imx93
From: Frank.Li @ 2026-06-29 15:36 UTC (permalink / raw)
To: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Fabio Estevam, Pengutronix Kernel Team, Jacky Bai
Cc: Frank Li, linux-pm, devicetree, imx, linux-arm-kernel,
Conor Dooley, Alice Guo
In-Reply-To: <20260430-imx93_tmu-v6-0-485459d7b54f@nxp.com>
From: Frank Li <Frank.Li@nxp.com>
On Thu, 30 Apr 2026 10:53:29 +0800, Jacky Bai wrote:
> The TMU (Thermal Monitoring Unit) on the i.MX93 requires specific
> configurations and workarounds that differ from previous implementations.
> So, using the 'fsl,qoriq-tmu' compatible string is not appropriate.
> To address this, a dedicated compatible string and corresponding driver
> changes need to be introduced to properly support the i.MX93 TMU.
>
>
> [...]
Applied, thanks!
[4/4] arm64: dts: imx93: update the tmu compatible string
commit: d911a33fa8e9fd4c691bc8429180fe1885bc3f2f
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: Geert Uytterhoeven @ 2026-06-29 15:29 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Walleij, Bartosz Golaszewski, Arnd Bergmann,
Marcel Holtmann, MyungJoo Ham, Chanwoo Choi, Geert Uytterhoeven,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, linux-bluetooth,
linux-kernel, linux-gpio, dri-devel, linux-i2c, linux-iio,
linux-input, linux-mmc, linux-arm-kernel, linux-pm, linux-usb
In-Reply-To: <20260629135917.1308621-1-arnd@kernel.org>
Hi Arnd,
On Mon, 29 Jun 2026 at 15:59, Arnd Bergmann <arnd@kernel.org> wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Most remaining users of desc_to_gpio() only call it for printing debug
> information.
>
> Replace this with a new gpiod_name() helper that returns the
> gpio_desc->name string after checking the gpio_desc pointer.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Thanks for your patch!
> Not sure if this the way we want to take this, or if the gpio name is
> an appropriate replacement in debug printk.
>
> Since most of the callers of desc_to_gpio() and gpio_to_desc() are
> otherwise in drivers that already depend on CONFIG_GPIOLIB_LEGACY and
> include linux/gpio/legacy.h, only a handful of instances remain that
> are otherwise in files that otherwise only use the descriptor interfaces:
> --- a/drivers/gpio/gpio-aggregator.c
> +++ b/drivers/gpio/gpio-aggregator.c
> @@ -758,8 +758,8 @@ int gpiochip_fwd_desc_add(struct gpiochip_fwd *fwd, struct gpio_desc *desc,
>
> fwd->descs[offset] = desc;
>
> - dev_dbg(chip->parent, "%u => gpio %d irq %d\n", offset,
> - desc_to_gpio(desc), gpiod_to_irq(desc));
> + dev_dbg(chip->parent, "%u => gpio %s irq %d\n", offset,
> + gpiod_name(desc), gpiod_to_irq(desc));
>
> return 0;
> }
Before, this printed:
gpio-aggregator gpio-aggregator.1: 0 => gpio 589 irq 188
gpio-aggregator gpio-aggregator.1: 1 => gpio 590 irq 189
After, this prints:
gpio-aggregator gpio-aggregator.1: 0 => gpio (null) irq 188
gpio-aggregator gpio-aggregator.1: 1 => gpio (null) irq 189
Same results for instantiation using sysfs or configfs[1], although
the latter does have optional support for specifying the name.
[1] Documentation/admin-guide/gpio/gpio-aggregator.rst
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 0/5] remoteproc: cleanup shared carveout and resource-table helpers
From: Mathieu Poirier @ 2026-06-29 15:36 UTC (permalink / raw)
To: Ben Levinsky
Cc: Bjorn Andersson, linux-remoteproc, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Geert Uytterhoeven,
Magnus Damm, Patrice Chotard, Maxime Coquelin, Alexandre Torgue,
Arnaud Pouliquen, Daniel Baluta, Tanmay Shah, imx,
linux-arm-kernel, linux-kernel, linux-renesas-soc, linux-stm32
In-Reply-To: <20260529021637.2077602-1-ben.levinsky@amd.com>
Applied.
Thanks,
Mathieu
On Thu, May 28, 2026 at 07:16:32PM -0700, Ben Levinsky wrote:
> This series is a preparatory remoteproc cleanup split out from review of
> the AMD BRAM-based remoteproc series.
>
> During review, there was a request to move the duplicated plain
> ioremap_wc()/iounmap() carveout callbacks into common code and to
> factor the "missing resource table is OK" ELF parsing path into a
> common helper as well. There was also a request to send that cleanup as
> its own patchset first, with the AMD BRAM series respun afterwards on
> top once this cleanup is merged.
>
> This version keeps the same overall cleanup goals as v2, but reworks
> the optional resource-table pieces based on follow-up review:
>
> - reshape the optional resource-table helper in patch 4 into the thin
> parse_fw() wrapper form suggested on the thread
> - switch the patch 5 clients over to that helper shape directly,
> without post-helper rproc->table_ptr checks
> - keep the driver-local parse_fw() wrappers and their existing log
> messages and severity choices
> - retain as much of the existing per-driver parse_fw() logic and code
> placement as possible while moving the missing-table handling
> through the shared helper
>
> This series now does that in five patches:
>
> 1. add common subsystem-private callbacks for the exact-match
> wc-ioremap carveout case
> 2. switch the in-tree exact-match users over to those callbacks
> 3. mark carveouts mapped through the shared wc-ioremap helper as
> iomem so the framework uses the proper I/O accessors
> 4. add a common helper for drivers that treat a missing ELF resource
> table as optional while keeping per-driver logging decisions local
> 5. switch the matching in-tree drivers over to that helper while
> keeping thin local parse_fw() wrappers
>
> For the carveout map/unmap cleanup, this series covers the exact-match
> users called out in review: xlnx_r5_remoteproc, rcar_rproc,
> st_remoteproc, stm32_rproc, imx_rproc, and imx_dsp_rproc. The zynqmp R5
> TCM mapping path is left alone because it also clears the mapped memory
> and is not an exact match.
>
> For the optional resource-table handling, this series converts
> xlnx_r5_remoteproc, rcar_rproc, stm32_rproc, imx_rproc, and
> imx_dsp_rproc. st_remoteproc is intentionally left unchanged because its
> parse_fw() callback also builds carveouts and is therefore not a direct
> match for the helper introduced here.
>
> Changes in v3:
> - rework patch 4 so the optional resource-table helper matches the
> thin-wrapper form suggested in review
> - note that patch 4 still triggers a checkpatch --strict warning for
> the flow-control macro form, but that implementation follows the
> maintainer's review suggestion for the thin parse_fw() wrapper shape
> - update patch 5 to use that helper shape directly in the client
> parse_fw() callbacks
> - drop the post-helper rproc->table_ptr checks from the converted
> drivers
> - keep the converted parse_fw() wrappers otherwise close to their
> existing structure and placement
> - test xlnx_r5_remoteproc on the latest tree with firmware images
> both with and without an ELF resource table
>
> Changes in v2:
> - split the mem->is_iomem change out into a separate patch
> - add a common error message on ioremap_wc() failure
> - drop logging from the optional resource-table helper
> - keep driver-local parse_fw() wrappers to preserve per-platform
> missing-resource-table logging policy
>
> Ben Levinsky (5):
> remoteproc: add common wc-ioremap carveout callbacks
> remoteproc: switch exact-match drivers to wc-ioremap callbacks
> remoteproc: mark wc-ioremap carveouts as iomem
> remoteproc: add helper for optional ELF resource tables
> remoteproc: switch drivers to optional resource-table helper
>
> drivers/remoteproc/imx_dsp_rproc.c | 41 +++-----------
> drivers/remoteproc/imx_rproc.c | 40 ++------------
> drivers/remoteproc/rcar_rproc.c | 41 ++------------
> drivers/remoteproc/remoteproc_internal.h | 38 +++++++++++++
> drivers/remoteproc/st_remoteproc.c | 31 +----------
> drivers/remoteproc/stm32_rproc.c | 39 ++-----------
> drivers/remoteproc/xlnx_r5_remoteproc.c | 70 +++++-------------------
> 7 files changed, 73 insertions(+), 227 deletions(-)
>
> --
> 2.34.1
^ permalink raw reply
* Re: [PATCH v12 2/2] arm64: dts: imx8ulp: Add MIPI CSI-2 and ISI nodes
From: Frank Li @ 2026-06-29 15:29 UTC (permalink / raw)
To: Guoniu Zhou
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Laurent Pinchart,
Fabio Estevam, Philipp Zabel, Mauro Carvalho Chehab, Hans Verkuil,
devicetree, imx, linux-arm-kernel, linux-kernel, linux-media
In-Reply-To: <20260424-csi2_imx8ulp-v12-2-da148eabc035@oss.nxp.com>
On Fri, Apr 24, 2026 at 02:49:51PM +0800, Guoniu Zhou wrote:
> The MIPI CSI-2 in the i.MX8ULP is almost identical to the version present
> in the i.MX8QXP/QM and is routed to the ISI. Add both the MIPI CSI-2 and
> ISI nodes, disabled by default, as they require an attached camera sensor
> to function.
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
This part of the previous version patch should be applied. If missed
something, please send new patch, which base on my dt64 branch.
Frank
> Changes in v12:
> - Swap ISI axi and apb clocks to align with dt-binding requirements
> - Update commit message
>
> Changes in v11:
> - Removed #include <dt-bindings/reset/imx8ulp-pcc-reset.h> which was
> deleted by Rob's dt-bindings cleanup series [2]
> - Replaced reset macros with numeric values and added comments to
> document the reset indices
>
> Changes in v1-v10:
> - See cover letter
> ---
> arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 66 ++++++++++++++++++++++++++++++
> 1 file changed, 66 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
> index 9b5d98766512..c5cae7675ce0 100644
> --- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
> @@ -859,6 +859,72 @@ spdif: spdif@2dab0000 {
> dma-names = "rx", "tx";
> status = "disabled";
> };
> +
> + isi: isi@2dac0000 {
> + compatible = "fsl,imx8ulp-isi";
> + reg = <0x2dac0000 0x10000>;
> + interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cgc2 IMX8ULP_CLK_LPAV_AXI_DIV>,
> + <&pcc5 IMX8ULP_CLK_ISI>;
> + clock-names = "axi", "apb";
> + power-domains = <&scmi_devpd IMX8ULP_PD_ISI>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + isi_in: endpoint {
> + remote-endpoint = <&mipi_csi_out>;
> + };
> + };
> + };
> + };
> +
> + mipi_csi: csi@2daf0000 {
> + compatible = "fsl,imx8ulp-mipi-csi2";
> + reg = <0x2daf0000 0x10000>,
> + <0x2dad0000 0x10000>;
> + clocks = <&pcc5 IMX8ULP_CLK_CSI>,
> + <&pcc5 IMX8ULP_CLK_CSI_CLK_ESC>,
> + <&pcc5 IMX8ULP_CLK_CSI_CLK_UI>,
> + <&pcc5 IMX8ULP_CLK_CSI_REGS>;
> + clock-names = "core", "esc", "ui", "pclk";
> + assigned-clocks = <&pcc5 IMX8ULP_CLK_CSI>,
> + <&pcc5 IMX8ULP_CLK_CSI_CLK_ESC>,
> + <&pcc5 IMX8ULP_CLK_CSI_CLK_UI>,
> + <&pcc5 IMX8ULP_CLK_CSI_REGS>;
> + assigned-clock-parents = <&cgc2 IMX8ULP_CLK_PLL4_PFD1_DIV1>,
> + <&cgc2 IMX8ULP_CLK_PLL4_PFD1_DIV2>,
> + <&cgc2 IMX8ULP_CLK_PLL4_PFD0_DIV1>;
> + assigned-clock-rates = <200000000>,
> + <80000000>,
> + <100000000>,
> + <79200000>;
> + power-domains = <&scmi_devpd IMX8ULP_PD_MIPI_CSI>;
> + resets = <&pcc5 5>, /* PCC5_CSI_REGS_SWRST */
> + <&pcc5 6>; /* PCC5_CSI_SWRST> */
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + mipi_csi_out: endpoint {
> + remote-endpoint = <&isi_in>;
> + };
> + };
> + };
> + };
> };
>
> gpiod: gpio@2e200000 {
>
> --
> 2.34.1
>
^ permalink raw reply
* [PATCH v2] misc: xilinx_sdfec: validate LDPC code register offsets
From: Yousef Alhouseen @ 2026-06-29 15:28 UTC (permalink / raw)
To: Derek Kiernan, Dragan Cvetic
Cc: Arnd Bergmann, Greg Kroah-Hartman, Michal Simek, linux-arm-kernel,
linux-kernel, Yousef Alhouseen
The LDPC code register helpers check the target MMIO address after
adding code_id * XSDFEC_LDPC_REG_JUMP to the register base. code_id is
supplied through the ioctl path, so the multiplication and addition can
wrap before the bounds check.
Validate the code_id against the register window size before computing
the final address, then write using the checked address.
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
---
Changes in v2:
- Guard against swapped high/base constants before subtracting.
- Preserve debug output and include offset/base/high in the message.
drivers/misc/xilinx_sdfec.c | 74 +++++++++++++++++--------------------
1 file changed, 34 insertions(+), 40 deletions(-)
diff --git a/drivers/misc/xilinx_sdfec.c b/drivers/misc/xilinx_sdfec.c
index 3135ba3a58ee..e73a139f3ffc 100644
--- a/drivers/misc/xilinx_sdfec.c
+++ b/drivers/misc/xilinx_sdfec.c
@@ -456,10 +456,25 @@ static int xsdfec_get_turbo(struct xsdfec_dev *xsdfec, void __user *arg)
return err;
}
+static int xsdfec_ldpc_reg_addr(struct xsdfec_dev *xsdfec, u32 base, u32 high,
+ u32 offset, u32 *addr)
+{
+ if (high < base || offset > (high - base) / XSDFEC_LDPC_REG_JUMP) {
+ dev_dbg(xsdfec->dev,
+ "LDPC register offset %u outside space 0x%x-0x%x",
+ offset, base, high);
+ return -EINVAL;
+ }
+
+ *addr = base + offset * XSDFEC_LDPC_REG_JUMP;
+ return 0;
+}
+
static int xsdfec_reg0_write(struct xsdfec_dev *xsdfec, u32 n, u32 k, u32 psize,
u32 offset)
{
u32 wdata;
+ u32 addr;
if (n < XSDFEC_REG0_N_MIN || n > XSDFEC_REG0_N_MAX || psize == 0 ||
(n > XSDFEC_REG0_N_MUL_P * psize) || n <= k || ((n % psize) != 0)) {
@@ -476,17 +491,11 @@ static int xsdfec_reg0_write(struct xsdfec_dev *xsdfec, u32 n, u32 k, u32 psize,
k = k << XSDFEC_REG0_K_LSB;
wdata = k | n;
- if (XSDFEC_LDPC_CODE_REG0_ADDR_BASE + (offset * XSDFEC_LDPC_REG_JUMP) >
- XSDFEC_LDPC_CODE_REG0_ADDR_HIGH) {
- dev_dbg(xsdfec->dev, "Writing outside of LDPC reg0 space 0x%x",
- XSDFEC_LDPC_CODE_REG0_ADDR_BASE +
- (offset * XSDFEC_LDPC_REG_JUMP));
+ if (xsdfec_ldpc_reg_addr(xsdfec, XSDFEC_LDPC_CODE_REG0_ADDR_BASE,
+ XSDFEC_LDPC_CODE_REG0_ADDR_HIGH, offset,
+ &addr))
return -EINVAL;
- }
- xsdfec_regwrite(xsdfec,
- XSDFEC_LDPC_CODE_REG0_ADDR_BASE +
- (offset * XSDFEC_LDPC_REG_JUMP),
- wdata);
+ xsdfec_regwrite(xsdfec, addr, wdata);
return 0;
}
@@ -494,6 +503,7 @@ static int xsdfec_reg1_write(struct xsdfec_dev *xsdfec, u32 psize,
u32 no_packing, u32 nm, u32 offset)
{
u32 wdata;
+ u32 addr;
if (psize < XSDFEC_REG1_PSIZE_MIN || psize > XSDFEC_REG1_PSIZE_MAX) {
dev_dbg(xsdfec->dev, "Psize is not in range");
@@ -510,17 +520,11 @@ static int xsdfec_reg1_write(struct xsdfec_dev *xsdfec, u32 psize,
nm = (nm << XSDFEC_REG1_NM_LSB) & XSDFEC_REG1_NM_MASK;
wdata = nm | no_packing | psize;
- if (XSDFEC_LDPC_CODE_REG1_ADDR_BASE + (offset * XSDFEC_LDPC_REG_JUMP) >
- XSDFEC_LDPC_CODE_REG1_ADDR_HIGH) {
- dev_dbg(xsdfec->dev, "Writing outside of LDPC reg1 space 0x%x",
- XSDFEC_LDPC_CODE_REG1_ADDR_BASE +
- (offset * XSDFEC_LDPC_REG_JUMP));
+ if (xsdfec_ldpc_reg_addr(xsdfec, XSDFEC_LDPC_CODE_REG1_ADDR_BASE,
+ XSDFEC_LDPC_CODE_REG1_ADDR_HIGH, offset,
+ &addr))
return -EINVAL;
- }
- xsdfec_regwrite(xsdfec,
- XSDFEC_LDPC_CODE_REG1_ADDR_BASE +
- (offset * XSDFEC_LDPC_REG_JUMP),
- wdata);
+ xsdfec_regwrite(xsdfec, addr, wdata);
return 0;
}
@@ -529,6 +533,7 @@ static int xsdfec_reg2_write(struct xsdfec_dev *xsdfec, u32 nlayers, u32 nmqc,
u32 max_schedule, u32 offset)
{
u32 wdata;
+ u32 addr;
if (nlayers < XSDFEC_REG2_NLAYERS_MIN ||
nlayers > XSDFEC_REG2_NLAYERS_MAX) {
@@ -563,17 +568,11 @@ static int xsdfec_reg2_write(struct xsdfec_dev *xsdfec, u32 nlayers, u32 nmqc,
wdata = (max_schedule | no_final_parity | special_qc | norm_type |
nmqc | nlayers);
- if (XSDFEC_LDPC_CODE_REG2_ADDR_BASE + (offset * XSDFEC_LDPC_REG_JUMP) >
- XSDFEC_LDPC_CODE_REG2_ADDR_HIGH) {
- dev_dbg(xsdfec->dev, "Writing outside of LDPC reg2 space 0x%x",
- XSDFEC_LDPC_CODE_REG2_ADDR_BASE +
- (offset * XSDFEC_LDPC_REG_JUMP));
+ if (xsdfec_ldpc_reg_addr(xsdfec, XSDFEC_LDPC_CODE_REG2_ADDR_BASE,
+ XSDFEC_LDPC_CODE_REG2_ADDR_HIGH, offset,
+ &addr))
return -EINVAL;
- }
- xsdfec_regwrite(xsdfec,
- XSDFEC_LDPC_CODE_REG2_ADDR_BASE +
- (offset * XSDFEC_LDPC_REG_JUMP),
- wdata);
+ xsdfec_regwrite(xsdfec, addr, wdata);
return 0;
}
@@ -581,20 +580,15 @@ static int xsdfec_reg3_write(struct xsdfec_dev *xsdfec, u8 sc_off, u8 la_off,
u16 qc_off, u32 offset)
{
u32 wdata;
+ u32 addr;
wdata = ((qc_off << XSDFEC_REG3_QC_OFF_LSB) |
(la_off << XSDFEC_REG3_LA_OFF_LSB) | sc_off);
- if (XSDFEC_LDPC_CODE_REG3_ADDR_BASE + (offset * XSDFEC_LDPC_REG_JUMP) >
- XSDFEC_LDPC_CODE_REG3_ADDR_HIGH) {
- dev_dbg(xsdfec->dev, "Writing outside of LDPC reg3 space 0x%x",
- XSDFEC_LDPC_CODE_REG3_ADDR_BASE +
- (offset * XSDFEC_LDPC_REG_JUMP));
+ if (xsdfec_ldpc_reg_addr(xsdfec, XSDFEC_LDPC_CODE_REG3_ADDR_BASE,
+ XSDFEC_LDPC_CODE_REG3_ADDR_HIGH, offset,
+ &addr))
return -EINVAL;
- }
- xsdfec_regwrite(xsdfec,
- XSDFEC_LDPC_CODE_REG3_ADDR_BASE +
- (offset * XSDFEC_LDPC_REG_JUMP),
- wdata);
+ xsdfec_regwrite(xsdfec, addr, wdata);
return 0;
}
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 3/5] media: nxp: imx8-isi: Add 16-bit raw Bayer format support
From: Frank Li @ 2026-06-29 14:57 UTC (permalink / raw)
To: guoniu.zhou
Cc: Laurent Pinchart, Mauro Carvalho Chehab, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Christian Hemp,
Stefan Riedmueller, Jacopo Mondi, Dong Aisheng, Guoniu Zhou,
linux-media, imx, linux-arm-kernel, linux-kernel, Laurentiu Palcu
In-Reply-To: <20260629-isi-v1-3-deebfdb1b07b@oss.nxp.com>
On Mon, Jun 29, 2026 at 03:44:57PM +0800, guoniu.zhou@oss.nxp.com wrote:
>
> Add support for 16-bit raw Bayer formats (SBGGR16, SGBRG16, SGRBG16,
> SRGGB16) to both the pipeline subdev and video capture interface.
>
> These formats are commonly used by high-end image sensors that output
> 16-bit raw data, enabling the ISI to process and capture full dynamic
> range from such sensors.
>
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> .../media/platform/nxp/imx8-isi/imx8-isi-pipe.c | 24 +++++++++++++++
> .../media/platform/nxp/imx8-isi/imx8-isi-video.c | 36 ++++++++++++++++++++++
> 2 files changed, 60 insertions(+)
>
> diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c b/drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c
> index 2d0843c86534..e58925d71164 100644
> --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c
> +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-pipe.c
> @@ -179,6 +179,30 @@ static const struct mxc_isi_bus_format_info mxc_isi_bus_formats[] = {
> .pads = BIT(MXC_ISI_PIPE_PAD_SINK)
> | BIT(MXC_ISI_PIPE_PAD_SOURCE),
> .encoding = MXC_ISI_ENC_RAW,
> + }, {
> + .mbus_code = MEDIA_BUS_FMT_SBGGR16_1X16,
> + .output = MEDIA_BUS_FMT_SBGGR16_1X16,
> + .pads = BIT(MXC_ISI_PIPE_PAD_SINK)
> + | BIT(MXC_ISI_PIPE_PAD_SOURCE),
> + .encoding = MXC_ISI_ENC_RAW,
> + }, {
> + .mbus_code = MEDIA_BUS_FMT_SGBRG16_1X16,
> + .output = MEDIA_BUS_FMT_SGBRG16_1X16,
> + .pads = BIT(MXC_ISI_PIPE_PAD_SINK)
> + | BIT(MXC_ISI_PIPE_PAD_SOURCE),
> + .encoding = MXC_ISI_ENC_RAW,
> + }, {
> + .mbus_code = MEDIA_BUS_FMT_SGRBG16_1X16,
> + .output = MEDIA_BUS_FMT_SGRBG16_1X16,
> + .pads = BIT(MXC_ISI_PIPE_PAD_SINK)
> + | BIT(MXC_ISI_PIPE_PAD_SOURCE),
> + .encoding = MXC_ISI_ENC_RAW,
> + }, {
> + .mbus_code = MEDIA_BUS_FMT_SRGGB16_1X16,
> + .output = MEDIA_BUS_FMT_SRGGB16_1X16,
> + .pads = BIT(MXC_ISI_PIPE_PAD_SINK)
> + | BIT(MXC_ISI_PIPE_PAD_SOURCE),
> + .encoding = MXC_ISI_ENC_RAW,
> },
> /* JPEG */
> {
> diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-video.c b/drivers/media/platform/nxp/imx8-isi/imx8-isi-video.c
> index fe4adfa3a1f0..5eb448f4c26f 100644
> --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-video.c
> +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-video.c
> @@ -356,6 +356,42 @@ static const struct mxc_isi_format_info mxc_isi_formats[] = {
> .color_planes = 1,
> .depth = { 16 },
> .encoding = MXC_ISI_ENC_RAW,
> + }, {
> + .mbus_code = MEDIA_BUS_FMT_SBGGR16_1X16,
> + .fourcc = V4L2_PIX_FMT_SBGGR16,
> + .type = MXC_ISI_VIDEO_CAP,
> + .isi_out_format = CHNL_IMG_CTRL_FORMAT_RAW16,
> + .mem_planes = 1,
> + .color_planes = 1,
> + .depth = { 16 },
> + .encoding = MXC_ISI_ENC_RAW,
> + }, {
> + .mbus_code = MEDIA_BUS_FMT_SGBRG16_1X16,
> + .fourcc = V4L2_PIX_FMT_SGBRG16,
> + .type = MXC_ISI_VIDEO_CAP,
> + .isi_out_format = CHNL_IMG_CTRL_FORMAT_RAW16,
> + .mem_planes = 1,
> + .color_planes = 1,
> + .depth = { 16 },
> + .encoding = MXC_ISI_ENC_RAW,
> + }, {
> + .mbus_code = MEDIA_BUS_FMT_SGRBG16_1X16,
> + .fourcc = V4L2_PIX_FMT_SGRBG16,
> + .type = MXC_ISI_VIDEO_CAP,
> + .isi_out_format = CHNL_IMG_CTRL_FORMAT_RAW16,
> + .mem_planes = 1,
> + .color_planes = 1,
> + .depth = { 16 },
> + .encoding = MXC_ISI_ENC_RAW,
> + }, {
> + .mbus_code = MEDIA_BUS_FMT_SRGGB16_1X16,
> + .fourcc = V4L2_PIX_FMT_SRGGB16,
> + .type = MXC_ISI_VIDEO_CAP,
> + .isi_out_format = CHNL_IMG_CTRL_FORMAT_RAW16,
> + .mem_planes = 1,
> + .color_planes = 1,
> + .depth = { 16 },
> + .encoding = MXC_ISI_ENC_RAW,
> },
> /* JPEG */
> {
>
> --
> 2.34.1
>
>
^ permalink raw reply
* [PATCH] Bluetooth: Properly disable remote wakeup for MT7922/MT7925 on Ryzen platform
From: Rong Zhang @ 2026-06-29 15:27 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Luiz Augusto von Dentz, Chris Lu (陸稚泓),
Will-CY Lee (李政穎),
SS Wu (巫憲欣), linux-bluetooth, linux-kernel,
linux-arm-kernel, linux-mediatek, Rong Zhang
It is reported that a remote wakeup could cause MT7922/MT7925's btusb
interface completely unresponsive. Resetting the xHCI root hub doesn't
help at all, and recovering from such a state needs a power cycle.
All reports seen to be relevant to Ryzen-based laptops. These NICs are
usually used as OEM components thanks to some sort of reference designs.
Their popularity on other platforms is unclear. While there is still a
chance that the quirk may exist on other platforms, be cautious and only
apply the quirk on AMD platforms for the time being.
Meanwhile, though device_set_wakeup_capable(false) is the correct fix
for other NICs with fake remote wakeup capabilities, doing so for
MT7922/MT7925 effectively prevents it from being used as wakeup
sources as per userspace requests. Hence, return -EBUSY on runtime
suspend to prevent the interface from being autosuspended while it's
still opened, which has the same effect as
device_set_wakeup_capable(false), since disabling remote wakeup simply
causes the USB core to gate runtime autosuspend as well due to
needs_remote_wakeup == 1. The interface can be safely autosuspended as
long as remote wakeup is disabled, i.e., after closing the HCI device.
Specifically, the interface may still take the advantage of remote
wakeup in order to wake up the system from sleep if userspace has
enabled it as a wakeup source.
Fixes: e31d761628ad ("Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925")
Signed-off-by: Rong Zhang <i@rong.moe>
---
drivers/bluetooth/btmtk.c | 10 ---------
drivers/bluetooth/btusb.c | 57 +++++++++++++++++++++++++++++++++++++++++++----
2 files changed, 53 insertions(+), 14 deletions(-)
diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index 02a96342e964..4614434dd57b 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -1381,16 +1381,6 @@ int btmtk_usb_setup(struct hci_dev *hdev)
break;
case 0x7922:
case 0x7925:
- /*
- * A remote wakeup could cause the device completely unresponsive, and
- * recovering from such a state needs a power cycle.
- *
- * Since the remote wakeup capability is super broken, just disable it
- * to get rid of the troubles. The device can still be autosuspended
- * when the bluetooth interface is closed.
- */
- device_set_wakeup_capable(&btmtk_data->udev->dev, false);
- fallthrough;
case 0x7961:
case 0x7902:
case 0x6639:
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 08c0a99a62c5..023ae782f41a 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -6,6 +6,7 @@
* Copyright (C) 2005-2008 Marcel Holtmann <marcel@holtmann.org>
*/
+#include <linux/cpufeature.h>
#include <linux/dmi.h>
#include <linux/module.h>
#include <linux/usb.h>
@@ -957,6 +958,7 @@ struct qca_dump_info {
#define BTUSB_USE_ALT3_FOR_WBS 15
#define BTUSB_ALT6_CONTINUOUS_TX 16
#define BTUSB_HW_SSR_ACTIVE 17
+#define BTUSB_WAKEUP_BROKEN 18
struct btusb_data {
struct hci_dev *hdev;
@@ -2936,10 +2938,20 @@ static int btusb_send_frame_mtk(struct hci_dev *hdev, struct sk_buff *skb)
}
}
+static inline bool platform_is_ryzen(void)
+{
+#ifdef CONFIG_X86
+ return boot_cpu_has(X86_FEATURE_ZEN);
+#else
+ return false;
+#endif
+}
+
static int btusb_mtk_setup(struct hci_dev *hdev)
{
struct btusb_data *data = hci_get_drvdata(hdev);
struct btmtk_data *btmtk_data = hci_get_priv(hdev);
+ int err;
/* MediaTek WMT vendor cmd requiring below USB resources to
* complete the handshake.
@@ -2956,7 +2968,29 @@ static int btusb_mtk_setup(struct hci_dev *hdev)
btusb_mtk_claim_iso_intf(data);
}
- return btmtk_usb_setup(hdev);
+ err = btmtk_usb_setup(hdev);
+ if (err)
+ return err;
+
+ switch (btmtk_data->dev_id) {
+ case 0x7922:
+ case 0x7925:
+ /*
+ * All reports seen to be relevant to Ryzen-based laptops. These
+ * NICs are usually used as OEM components thanks to some sort
+ * of reference designs.
+ *
+ * Their popularity on other platforms is unclear. While there
+ * is still a chance that the quirk may exist on other
+ * platforms, be cautious and only apply the quirk on AMD
+ * platforms for the time being.
+ */
+ if (platform_is_ryzen())
+ set_bit(BTUSB_WAKEUP_BROKEN, &data->flags);
+ break;
+ }
+
+ return 0;
}
static int btusb_mtk_shutdown(struct hci_dev *hdev)
@@ -4532,11 +4566,26 @@ static int btusb_suspend(struct usb_interface *intf, pm_message_t message)
BT_DBG("intf %p", intf);
- /* Don't auto-suspend if there are connections or discovery in
- * progress; external suspend calls shall never fail.
+ /*
+ * It is reported that remote wakeup events could sometimes cause some
+ * adapters completely unresponsive. Resetting the xHCI root hub doesn't
+ * help at all, and recovering from such a state needs a power cycle.
+ * Since disabling remote wakeup simply causes the USB core to gate
+ * runtime autosuspend as well due to needs_remote_wakeup == 1, let's do
+ * this ourselves to make our life easier. The interface can be safely
+ * autosuspended as long as remote wakeup is disabled, i.e., after
+ * closing the HCI device.
+ *
+ * Don't auto-suspend if there are connections or discovery in progress.
+ *
+ * External suspend calls shall never fail. Specifically, a device with
+ * broken remote wakeup may still take the advantage of remote wakeup in
+ * order to wake up the system from sleep if userspace has enabled it as
+ * a wakeup source.
*/
if (PMSG_IS_AUTO(message) &&
- (hci_conn_count(data->hdev) || hci_discovery_active(data->hdev)))
+ ((test_bit(BTUSB_WAKEUP_BROKEN, &data->flags) && data->intf->needs_remote_wakeup) ||
+ hci_conn_count(data->hdev) || hci_discovery_active(data->hdev)))
return -EBUSY;
if (data->suspend_count++)
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 230ba8c9-btmtk-ryzen-remote-wakeup-055a407682ef
Thanks,
Rong
^ permalink raw reply related
* Re: [PATCH 2/2] arm64: topology: read CPPC FFH feedback counters in one operation
From: Sumit Gupta @ 2026-06-29 15:27 UTC (permalink / raw)
To: Pengjie Zhang, catalin.marinas, will, rafael, lenb, robert.moore,
beata.michalska, zhenglifeng1, zhanjie9, cuiyunhui
Cc: linux-arm-kernel, linux-kernel, linux-acpi, acpica-devel,
linuxarm, jonathan.cameron, prime.zeng, wanghuiqiang, xuwei5,
lihuisong, yubowen8, wangzhi12, linux-tegra@vger.kernel.org
In-Reply-To: <20260410094145.4132082-3-zhangpengjie2@huawei.com>
On 10/04/26 15:11, Pengjie Zhang wrote:
> External email: Use caution opening links or attachments
>
>
> arm64 implements CPPC FFH feedback-counter reads using AMU counters.
> Because those counters must be sampled on the target CPU, reading the
> delivered and reference counters separately widens the observation window
> between them.
>
> Implement the paired FFH feedback-counter read hook on arm64 and sample
> both AMU counters together before decoding the requested CPC register
> values.
>
> Also factor the FFH bitfield extraction logic into a helper and reuse
> it from the existing single-counter FFH read path.
>
> Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
> ---
> arch/arm64/kernel/topology.c | 75 ++++++++++++++++++++++++++++++++----
> 1 file changed, 67 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> index b32f13358fbb..b90a767b2a1f 100644
> --- a/arch/arm64/kernel/topology.c
> +++ b/arch/arm64/kernel/topology.c
> @@ -50,6 +50,16 @@ struct amu_cntr_sample {
> unsigned long last_scale_update;
> };
>
> +struct amu_ffh_ctrs {
> + u64 corecnt;
> + u64 constcnt;
> +};
> +
> +enum cpc_ffh_ctr_id {
> + CPC_FFH_CTR_CORE = 0x0,
> + CPC_FFH_CTR_CONST = 0x1,
> +};
> +
> static DEFINE_PER_CPU_SHARED_ALIGNED(struct amu_cntr_sample, cpu_amu_samples);
>
> void update_freq_counters_refs(void)
> @@ -397,7 +407,7 @@ static void cpu_read_constcnt(void *val)
> }
>
> static inline
> -int counters_read_on_cpu(int cpu, smp_call_func_t func, u64 *val)
> +int counters_read_on_cpu(int cpu, smp_call_func_t func, void *val)
> {
> /*
> * Abort call on counterless CPU.
> @@ -447,24 +457,73 @@ bool cpc_ffh_supported(void)
> return true;
> }
>
> +static void amu_read_core_const_ctrs(void *val)
> +{
> + struct amu_ffh_ctrs *ctrs = val;
> +
> + cpu_read_constcnt(&ctrs->constcnt);
> + cpu_read_corecnt(&ctrs->corecnt);
> +}
Any reason to flip the order?
Harmless as they are read back to back, but better to add a comment
if it's intentional.
Thanks,
Sumit
....
^ permalink raw reply
* Re: [PATCH 3/4] dt-bindings: ipmi: Add optional LPC properties to ASPEED BT devices
From: Conor Dooley @ 2026-06-29 15:26 UTC (permalink / raw)
To: yc_hsieh
Cc: Corey Minyard, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, openipmi-developer, linux-kernel,
devicetree, linux-arm-kernel, linux-aspeed
In-Reply-To: <20260629-aspeed-bt-bmc-multichannel-v1-3-fc23ee337f7a@aspeedtech.com>
[-- Attachment #1: Type: text/plain, Size: 2563 bytes --]
On Mon, Jun 29, 2026 at 02:49:00PM +0800, Yu-Che Hsieh via B4 Relay wrote:
> From: Yu-Che Hsieh <yc_hsieh@aspeedtech.com>
>
> Allocating IO and IRQ resources to LPC devices is in-theory an operation
>
> for the host, however ASPEED systems describe these resources through
>
> BMC-internal configuration, as already supported by the ASPEED KCS BMC
>
> binding.
>
> Add aspeed,lpc-io-reg and aspeed,lpc-interrupts to the ASPEED BT BMC
>
> binding so firmware can describe the host LPC IO address and SerIRQ
>
> configuration using the same properties as KCS devices.
>
> Signed-off-by: Yu-Che Hsieh <yc_hsieh@aspeedtech.com>
> ---
> .../bindings/ipmi/aspeed,ast2400-ibt-bmc.yaml | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.yaml b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.yaml
> index c4f7cdbbe16b..1803c6bbae93 100644
> --- a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.yaml
> +++ b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.yaml
> @@ -25,6 +25,24 @@ properties:
> interrupts:
> maxItems: 1
>
> + aspeed,lpc-io-reg:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + maxItems: 1
> + description: |
> + The host CPU LPC IO address for the BT device.
> +
> + aspeed,lpc-interrupts:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + minItems: 2
> + maxItems: 2
> + description: |
> + A 2-cell property expressing the LPC SerIRQ number and the interrupt
> + level/sense encoding (specified in the standard fashion).
> +
> + Note that the generated interrupt is issued from the BMC to the host, and
> + thus the target interrupt controller is not captured by the BMC's
> + devicetree.
Why can these two properties not just be an additional reg and
interrupts entry?
Cheers,
Conor.
> +
> required:
> - compatible
> - reg
> @@ -35,10 +53,13 @@ additionalProperties: false
> examples:
> - |
> #include <dt-bindings/clock/aspeed-clock.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
>
> bt@1e789140 {
> compatible = "aspeed,ast2400-ibt-bmc";
> reg = <0x1e789140 0x18>;
> interrupts = <8>;
> clocks = <&syscon ASPEED_CLK_GATE_LCLK>;
> + aspeed,lpc-io-reg = <0xe4>;
> + aspeed,lpc-interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
> };
>
> --
> 2.34.1
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: (subset) [PATCH v12 0/2] Add i.MX8ULP ISI and CSI-2 support
From: Frank.Li @ 2026-06-29 15:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Laurent Pinchart, Fabio Estevam,
Philipp Zabel, Mauro Carvalho Chehab, Hans Verkuil, Guoniu Zhou
Cc: Frank Li, devicetree, imx, linux-arm-kernel, linux-kernel,
linux-media, stable
In-Reply-To: <20260424-csi2_imx8ulp-v12-0-da148eabc035@oss.nxp.com>
From: Frank Li <Frank.Li@nxp.com>
On Fri, 24 Apr 2026 14:49:49 +0800, Guoniu Zhou wrote:
> Add support for the Image Sensing Interface (ISI) and MIPI CSI-2 receiver
> on i.MX8ULP.
Applied, thanks!
[1/2] media: dt-bindings: nxp,imx8-isi: Drop fsl,blk-ctrl requirement for i.MX8ULP
commit: 2514a04c7455d0bbf41b3b1bfc3af2984ed6a7cc
Best regards,
--
Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH v2 3/6] clk: sunxi-ng: sun6i-rtc: Add feature bit for IOSC calibration
From: Chen-Yu Tsai @ 2026-06-29 15:25 UTC (permalink / raw)
To: Jerome Brunet
Cc: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jernej Skrabec, Samuel Holland, Michael Turquette,
Stephen Boyd, Maxime Ripard, linux-rtc, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel, linux-clk
In-Reply-To: <20260629-a733-rtc-v2-3-7b72112784f8@baylibre.com>
On Mon, Jun 29, 2026 at 8:42 PM Jerome Brunet <jbrunet@baylibre.com> wrote:
>
> From: Junhui Liu <junhui.liu@pigmoral.tech>
>
> The sun6i-rtc CCU driver currently uses a global static variable to
> denote whether calibration is supported, which makes IOSC operations
> tightly coupled to this file.
>
> Convert this into a feature bit to decouple the logic. This allows the
> IOSC clock code to be moved into a shared module for reuse by other SoCs.
>
> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
> Signed-off-by: Jerome Brunet<jbrunet@baylibre.com>
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* Re: [PATCH 05/37] drm/display: bridge-connector: split code creating the connector to a subfunction
From: Luca Ceresoli @ 2026-06-29 15:23 UTC (permalink / raw)
To: Laurent Pinchart, Luca Ceresoli
Cc: Maxime Ripard, Maarten Lankhorst, Thomas Zimmermann, David Airlie,
Simona Vetter, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260629144443.GA3106950@killaraus.ideasonboard.com>
On Mon Jun 29, 2026 at 4:44 PM CEST, Laurent Pinchart wrote:
> On Fri, Jun 26, 2026 at 06:51:14PM +0200, Luca Ceresoli wrote:
>> On Fri Jun 26, 2026 at 4:38 PM CEST, Maxime Ripard wrote:
>> > On Fri, Jun 26, 2026 at 04:16:39PM +0200, Luca Ceresoli wrote:
>> >> On Fri Jun 26, 2026 at 12:09 PM CEST, Maxime Ripard wrote:
>> >> > On Wed, Jun 24, 2026 at 05:47:10PM +0200, Luca Ceresoli wrote:
>> >> >> On Wed Jun 24, 2026 at 1:41 PM CEST, Maxime Ripard wrote:
>> >> >> > On Fri, Jun 12, 2026 at 02:56:24PM +0200, Luca Ceresoli wrote:
>> >> >> >> On Mon Jun 8, 2026 at 1:40 PM CEST, Maxime Ripard wrote:
>> >> >> >> > On Tue, May 19, 2026 at 12:37:22PM +0200, Luca Ceresoli wrote:
>> >> >> >> >> In preparation to introduce bridge hotplug, split out from
>> >> >> >> >> drm_bridge_connector_init() the code adding the drm_connector into a
>> >> >> >> >> dedicated function. This will be needed to be able to add (and re-add) the
>> >> >> >> >> connector from different code paths.
>> >> >> >> >
>> >> >> >> > Same story here, explaining what you need later on that calls for that
>> >> >> >> > change would be nice.
>> >> >> >>
>> >> >> >> Here's a more verbose version:
>> >> >> >>
>> >> >> >> Currently drm_bridge_connector_init() does two things:
>> >> >> >>
>> >> >> >> * allocate and initialize the drm_bridge_connector
>> >> >> >> (which embeds a drm_connector)
>> >> >> >> * initialize and register the embedded drm_connector
>> >> >> >>
>> >> >> >> For bridge hotplug we need to separate these two actions:
>> >> >> >>
>> >> >> >> * the drm_connector needs to be added and removed at any time based on
>> >> >> >> hotplug events
>> >> >> >> * the drm_bridge_connector is designated to create and remove the
>> >> >> >> drm_connector, so it must be persistent for the card lifetime
>> >> >> >>
>> >> >> >> As the lifetimes of drm_bridge_connector and drm_connector become
>> >> >> >> different, we need to create them in different moments.
>> >> >> >>
>> >> >> >> In preparation to support that, split out from
>> >> >> >> drm_bridge_connector_init() the code adding the drm_connector into a
>> >> >> >> dedicated function. No functional changes, just moving code around for
>> >> >> >> now. A future commit will make the drm_connector be created based on
>> >> >> >> hotplug events.
>> >> >> >>
>> >> >> >> Looks good?
>> >> >> >
>> >> >> > The message itself, yes, thanks.
>> >> >> >
>> >> >> > However, I have questions now :)
>> >> >> >
>> >> >> > Do we really expect drm_bridge_connector to stick around when a bridge
>> >> >> > gets unplugged? If so, how does it cope with having, say, an HDMI
>> >> >> > connector, and then swapping out the hotplugged part for an LVDS one?
>> >> >> > Does the HDMI connector sticks around indefinitely?
>> >> >>
>> >> >> In your example, the HDMI drm_connector would be unregistered and put on
>> >> >> hotunplug. Its allocation will stick around until the last put but that's
>> >> >> quite irrelevant. Then, on plugging the LVDS addon, a new LVDS
>> >> >> drm_connector will be created and registered.
>> >> >>
>> >> >> > *Especially* if we're using overlays for this, I'd expect everything
>> >> >> > after the first hotplugged bridge to be destroyed, no?
>> >> >>
>> >> >> As said, it would be unregistered immediately but might be freed later on
>> >> >> if still refcounted.
>> >> >>
>> >> >> This is visible in patches 36+15, the path to follow is:
>> >> >>
>> >> >> drm_bridge_connector_handle_event(event = DRM_BRIDGE_DETACHED) [patch 36]
>> >> >> -> drm_bridge_connector_dynconn_release() [patch 15]
>> >> >>
>> >> >> Does this solve your concern?
>> >> >
>> >> > Not really, I'm talking about drm_bridge_connector. The fact that
>> >> > bridges are destroyed make sense to me. The fact that
>> >> > drm_bridge_connector sticks around doesn't. It's supposed to be a
>> >> > connector for bridges. If you don't have bridges because they got
>> >> > destroyed, and connector, drm_bridge_connector doesn't have a reason to
>> >> > exist anymore, unless it's drm_bridge_hotplug in a trench coat :)
>> >>
>> >> It is not a hotplug-bridge in a trench coat, no :) The code is clear about
>> >> this.
>> >>
>> >> I'd say with this series a "drm_bridge_connector" is just becoming
>> >> something more (perhaps something else too). Somewhat as "a drm_bridge is
>> >> either a bridge or something else". :)
>> >>
>> >>
>> >> But let's leave names aside for a moment. If just looking at the current
>> >> code, the drm_bridge_connector is "a handler, owned by the card/encoder and
>> >> having the same lifetime, which takes care of drm_connector
>> >> creation/destruction at card probe/removal".
>> >>
>> >> What we need now is just the same plug " and on hotplug events" appended.
>> >>
>> >> So in both cases there needs to be "a handler persitent with the card".
>> >>
>> >> Do we agree so far?
>> >
>> > Ish. If we go for that, then we need to update the name.
>>
>> drm_connector_manager?
>> drm_bridge_connector_manager?
>
> I'm fine with a rename. When developing drm_bridge_connector I've always
> envisioned it as code that manages the creation of a connector for a
> chain of bridges. In particular, the drm_bridge_connector object is
> *not* and has never been a bridge.
That's my understanding of the drm_bridge_connector too.
> Ideally all this should move to the DRM core and be transparent to
> drivers. Drivers could set a flag somewhere to opt-in for connectors
> managed by the DRM core.
Not sure I got what you mean.
Currently drivers "opt-in" by:
1. passing DRM_BRIDGE_ATTACH_NO_CONNECTOR to drm_bridge_attach()
2. instantiating a drm_bridge_connector via drm_bridge_connector_init()
Do you suggest changing that, so 1 and 2 are done transparently if the
driver sets a new flag?
>> > drm_bridge_connector for something that is neither a bridge or a
>> > connector is not great.
>> >
>> > But even then, I'm not even sure why we need to have that "manager" in
>> > the first place. You want to make bridges be aware if they are the last
>> > in the chain or not.
>
> I don't think bridges should be aware of whether or not they're the last
> one in the chain.
I proposed that, not because I "want" that but because for hotplug we need
a way to know whether a DRM video pipeline is complete in the hardware or
not. This is used in patch 36:
/* Add the connector if the pipeline is now complete */
if (drm_bridge_connector_pipeline_is_complete(bridge_connector))
drm_bridge_connector_add_connector(bridge_connector);
In other words, on a hotplug event (some new hardware was added), check
whether the card is now complete _in the hardware_, and if it is create a
drm_connector.
In this series I proposed implementing it via a new .is_tail callback, that
has been rejected during Dispaly Next Hackfest [0].
The idea that popped up there was that bridge drivers could expose the
fwnode handler to the port@<N>/endpoint pointing to the next bridge. I
liked the idea but then I realized it would hardly fly in complex cases
like bridges with dual-LVDS-or-two-single-LVDS output, e.g. SN65DSI84.
So Maxime proposed [1]:
) Thanks for the notes, I think I largely agree with the discussion.
) Reading through it, I thought it would be nice for a new callback called
) get_next_bridge or something that would return either an error, NULL or a
) (refcounted) pointer to the next bridge in the chain. And have some kind
) of special error (ENODEV?) when the bridge should be there but isn't
) (and thus the chain isn't complete).
To me, "Making bridges aware if they are the last in the chain or not" is
not a goal. It is just a technique to implement
drm_bridge_connector_pipeline_is_complete(). I'm happy to implementing it
in a different way if you have better ideas, but I haven't.
[0] https://lore.kernel.org/lkml/DIXTUCXAU68V.1T7X89LMEUF2F@bootlin.com/
[1] https://lore.kernel.org/lkml/20260624-vagabond-neon-gorilla-cd6487@houat/
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 0/2] clocksource/drivers/arm_arch_timer_mmio: Restore support for early init
From: Stephan Gerhold @ 2026-06-29 15:23 UTC (permalink / raw)
To: Marc Zyngier
Cc: Mark Rutland, Daniel Lezcano, Thomas Gleixner, Sudeep Holla,
linux-arm-kernel, linux-kernel, linux-arm-msm, Jack Matthews,
Konrad Dybcio
In-Reply-To: <87qzmd89ih.wl-maz@kernel.org>
On Thu, Jun 11, 2026 at 02:57:42PM +0100, Marc Zyngier wrote:
> On Thu, 11 Jun 2026 09:47:58 +0100,
> Stephan Gerhold <stephan.gerhold@linaro.org> wrote:
> >
> > On Thu, Jun 11, 2026 at 08:59:19AM +0100, Marc Zyngier wrote:
> > > On Wed, 10 Jun 2026 18:53:09 +0100,
> > > Stephan Gerhold <stephan.gerhold@linaro.org> wrote:
> > > >
> > > > Jack reported a regression for some single-core Qualcomm platforms (e.g.
> > > > MDM9625, MDM9607) that no longer boot because no timers can be found during
> > > > early boot [1].
> > >
> > > Again, this is *not* a regression. These machines were *never*
> > > supported upstream.
> > >
> >
> > Sorry, I'll reword this next time. MDM9607 does have all required
> > drivers and compatibles upstream already and is just missing the actual
> > DT so it does feel somewhat supported to me, but I'm fine treating this
> > as a feature extension without stable backporting etc.
>
> "Supported" has a different definition for me. Cortex-A5 without the
> A9-style TWD was so far never seen in the wild. The Generic MMIO timer
> was introduced way after Cortex-A5 shipped, and was designed to work
> with the CPU timers, making this QCOM contraption a franken-hack.
>
> So calling this supported is very much pushing the boundaries of what
> was supposed to be put together.
>
Got it.
> >
> > > > These platforms rely on an obscure timer setup where the
> > > > global Arm MMIO timer (arm,armv7-timer-mem) is used as the only available
> > > > timer for the CPU. This setup used to work fine until commit 0f67b56d84b4
> > > > ("clocksource/drivers/arm_arch_timer_mmio: Switch over to standalone
> > > > driver") when the early timer initialization using TIMER_OF_DECLARE() was
> > > > removed when moving to the standalone MMIO driver.
> > > >
> > > > There doesn't seem to be any other usable CPU timer on those platforms, so
> > > > this series restores the early timer support using TIMER_OF_DECLARE()
> > > > inside the new standalone arm_arch_timer_mmio driver. This is pretty ugly,
> > > > but I could not think of a better solution so far. I tried to keep the
> > > > ugliness for the two probe paths as limited as possible. :-)
> > > >
> > > > If someone has a better idea how to solve this, I would be happy to try it.
> > >
> > > I would suggest finding out what is the latest point in the init
> > > sequence where the timer can be probed without preventing boot.
> > >
> >
> > It doesn't get far without having any timer:
> >
> > [ 0.000000] timer_probe: no matching timers found
> > [ 0.000000] entering initcall level: console
> > [ 0.000000] calling con_init+0x0/0x354 @ 0
> > [ 0.000000] Console: colour dummy device 80x30
> > [ 0.000000] initcall con_init+0x0/0x354 returned 0 after 0 usecs
> > [ 0.000000] sched_clock: 32 bits at 300 Hz, resolution 3333333ns, wraps every 7158278824300949ns
> > [ 0.000000] Calibrating delay loop...
> > <board hangs>
> >
>
> This is nothing that "lpj=[some value]" on the command line can't help
> getting past.
>
> > If you look at start_kernel() in init/main.c it's basically time_init()
> > that would normally probe the TIMER_OF_DECLARE() timers and
> > calibrate_delay() that needs some timer to finish. There is also
> > random_init() that comes directly after time_init(), which already wants
> > to have access to timestamp counters. I don't see any other suitable
> > place to hook into. :-/
>
> None of that should be a problem. I can boot a hacked arm64 kernel
> without any timer all the way to the point where it is waiting for a
> tick to enter the scheduler and run userspace. There's no reason why
> 32bit can't do something similar. Heck, 32bit doesn't even have a
> standard timer to rely on, so that's very much possible to do.
>
> Can you at least give it a try?
>
Thanks for the suggestion and sorry for the delay! I started testing
this, but then ran out of time before my vacation when trying to get the
CP15 timer working on the Cortex-A7.
With lpj=2658304, it proceeds until raid6_select_algo for me with my
current kernel config. I probably don't need the raid6 stuff on this
platform. Also, raid6_select_algo is subsys_initcall() so if I move
arm_arch_timer_mmio to core_initcall() instead of
builtin_platform_driver() (device_initcall()) it does indeed boot
successfully to the userspace login with the lpi= parameter. Nice!
> >
> > I also don't see any other timer we could use, at least for MDM9625.
> > It's a single-core Cortex-A5 and the downstream kernel defines only the
> > arm,armv7-timer-mem, which seems to be used for everything... (The
> > situation for MDM9607 is a bit different, but not any less messy,
> > unfortunately.)
>
> MDM9607 appears to be a Cortex-A7, so it *definitely* has all the
> bells and whistles that we need. The DT I found doesn't make describe
> the timer, but it is absolutely part of the CPU.
>
The CP15 timer is indeed *definitely* there for the Cortex-A7 in
MDM9607, but it's also *definitely* not working for me ... :(
As you saw, it's not documented anywhere for MDM9607. I tried to enable
it a few years ago already, but I couldn't get it working. I tried again
and it's still unusable. The CP15 timer is certainly there and it does
tick just fine. It also signals interrupts (ISTATUS gets set).
But I can't find the interrupts in the GIC:
- I tried some common options (PPI 13+14+11+10, 2+3+4+1), but it hangs
in raid6_select_algo like above (no timer interrupts).
- I created some brute force probing code that fires the timer and then
scans literally all GIC IRQs using GICD_ISPENDR. Nothing.
(It finds the correct PPIs on other platforms...)
- I asked Konrad if he can find something helpful in the chip
documentation, but apparently there is no clear mention of the CP15
interrupts there either ....
In other words, it looks like whoever designed this hardware didn't
think it would be useful to hook up the CPU interrupt lines to the GIC.
Or something like that ... Unfortunately, this means that we probably
need the MMIO timer even for the Cortex-A7 in MDM9607. :(
Since you mentioned that we don't need a timer early, I played a bit
with using the CP15 timer only as clocksource (without interrupt). That
seems works quite well actually to bypass the delay calibration problem.
In fact, then it skips the calibration entirely and uses (presumably
more accurate?) timer-based delay loops instead:
[ 0.000000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 6370867519511994 ns
[ 0.000000] arch_timer: No interrupt available, NOT giving up
[ 0.000000] arch_timer: cp15 timer running at 19.20MHz (virt).
[ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns
[ 0.000002] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns
[ 0.010688] Switching to timer-based delay loop, resolution 52ns
[ 0.019028] Console: colour dummy device 80x30
[ 0.024932] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.00 BogoMIPS (lpj=64000)
...
Still need the core_initcall() change, since it looks like that
raid6_select_algo code really wants to have some timer interrupts.
Aside from that it's just a couple of if conditions in the
arm_arch_timer driver to bypass the interrupt handling, but I imagine
you wouldn't be very happy about that kind of butchering either ...? :/
> As for the A5, if we can't get this machine to use the driver as is
> without butchering it and going 15 years back in time, then I'd rather
> hack together a minimal driver that only this contraption will make
> use of, and be done with it.
To be fair, if you look at PATCH 2/2 in this series, the actual MMIO
handling is completely unchanged. It's just some reshuffling of the
init/parsing code. The primary annoyance is probably use of pr_*()
rather than dev_*() logging and some minor manual resource management.
We could duplicate the parsing functions to avoid this reshuffling, but
the actual MMIO code would be still exactly the same. I'm not sure if
we should duplicate that.
Thanks,
Stephan
^ permalink raw reply
* Re: [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: Andy Shevchenko @ 2026-06-29 15:23 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Linus Walleij, Bartosz Golaszewski, Arnd Bergmann,
Marcel Holtmann, MyungJoo Ham, Chanwoo Choi, Geert Uytterhoeven,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, linux-bluetooth,
linux-kernel, linux-gpio, dri-devel, linux-i2c, linux-iio,
linux-input, linux-mmc, linux-arm-kernel, linux-pm, linux-usb
In-Reply-To: <20260629135917.1308621-1-arnd@kernel.org>
On Mon, Jun 29, 2026 at 03:56:29PM +0200, Arnd Bergmann wrote:
> Most remaining users of desc_to_gpio() only call it for printing debug
> information.
>
> Replace this with a new gpiod_name() helper that returns the
> gpio_desc->name string after checking the gpio_desc pointer.
Oh, that's nice!
...
> +/**
> + * gpiod_name() - get a name to print for a gpio descriptor
> + * @desc: gpio or NULL pointer to query
> + *
> + * Returns:
> + * The desc->name field or a dummy string for unknown GPIOs.
> + */
> +const char *gpiod_name(const struct gpio_desc *desc)
> +{
> + return desc ? desc->name : "(no gpio)";
Can we get into here with wrong (error pointer descriptor)? Shouldn't you call
one of validate_desc() / VALIDATE_DESC()?
Also not sure if "(no gpio)" is a good choice. "not requested"? "not provided"?
> +}
...
> +static inline const char *gpiod_name(const struct gpio_desc *desc)
> +{
> + WARN_ON(desc);
> + return "(no gpio)";
Hmm... This will be a second copy with a slight potential of going apart from
the other case. Perhaps a #define? (Yes, yes, I understand that there are pros
and cons, in particular readability with define is questionable.)
> +}
--
With Best Regards,
Andy Shevchenko
^ 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