* Re: [PATCH 5/5] pinctrl: pinctrl-scmi: Log number of pins, groups, functions
From: Linus Walleij @ 2026-05-23 9:18 UTC (permalink / raw)
To: Alex Tran
Cc: Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Sudeep Holla, Cristian Marussi,
Rafael J. Wysocki, Philipp Zabel, Viresh Kumar, Guenter Roeck,
linux-iio, linux-kernel, arm-scmi, linux-arm-kernel, linux-gpio,
linux-pm, linux-hwmon
In-Reply-To: <20260513-scmi-client-probe-log-v1-5-00b47b1be009@oss.qualcomm.com>
On Wed, May 13, 2026 at 6:44 PM Alex Tran <alex.tran@oss.qualcomm.com> wrote:
> The SCMI pinctrl driver does not currently log the number of pins,
> groups, and functions discovered from firmware. This information is
> useful for confirming the firmware exposed pinctrl resources during
> debugging.
>
> Log these counts after a successful probe to align with the existing
> SCMI client driver logging pattern.
>
> Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
Other kernel maintainers want a minimalist dmesg, but not me,
so I just applied this.
If someone is upset about the noise they can send a patch
changing it to dev_dbg().
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: gpio: add Axiado SGPIO controller
From: Linus Walleij @ 2026-05-23 9:13 UTC (permalink / raw)
To: Petar Stepanovic
Cc: Tzu-Hao Wei, Swark Yang, Prasad Bolisetty, Bartosz Golaszewski,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Harshit Shah,
SriNavmani A, linux-gpio, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <c20dc0cb-252b-4637-bb22-6078be62b21d@axiado.com>
On Wed, May 13, 2026 at 10:59 AM Petar Stepanovic
<pstepanovic@axiado.com> wrote:
> Some SGPIO outputs may control host-critical signals. For example, if the
> BMC reboots while the host/server remains powered on, changing SGPIO output
> values during driver initialization could potentially reset or shut down the
> running host.
>
> The purpose of `dout-init` is to provide a deterministic safe output state
> during SGPIO initialization, before any GPIO consumer has requested the line.
>
> That said, if the preferred approach is to preserve the existing hardware
> DOUT state during probe and only change the value when a GPIO consumer
> requests the line, I can rework the driver in that direction.
That is usually the best. The gpio framework scans the direction
of each line at probe(). While it does not know about the initial *value*
of each line, consumers can take this into account
when requesting a GPIO line like this:
gpio_vbus = devm_gpiod_get(dev, "vbus", GPIOD_ASIS);
This means the kernel does not put any initial value on the line.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v6 0/7] pinctrl: Add generic pinctrl for board-level mux chips
From: Linus Walleij @ 2026-05-23 9:02 UTC (permalink / raw)
To: Frank Li
Cc: Peter Rosin, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafał Miłecki, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-kernel, linux-gpio, devicetree, imx,
linux-arm-kernel, Haibo Chen, Conor Dooley, Ahmad Fatoum
In-Reply-To: <agNFaXbd_sMq5eAo@lizhi-Precision-Tower-5810>
On Tue, May 12, 2026 at 5:21 PM Frank Li <Frank.li@nxp.com> wrote:
> On Mon, May 11, 2026 at 10:34:35PM +0200, Linus Walleij wrote:
> > On Mon, May 11, 2026 at 9:38 PM Frank Li <Frank.li@nxp.com> wrote:
> >
> > > I fixed a build warning by missing doc 'np',
> > > https://lore.kernel.org/imx/20260507152117.240612-1-Frank.Li@nxp.com/
> > >
> > > Anything need me to do futher?
> >
> > Sorry was busy!
> >
> > Applied this fixup on top of the branch and merged it into my
> > devel branch for v7.2!
>
> Sorry, I missed picked up fix patch during rebase.
>
> https://lore.kernel.org/imx/20260512144806.22447-1-Frank.Li@nxp.com/T/#u
Ooops I should have seen it.
Applied it now!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v4 3/3] gpio: zynq: Add eio gpio support
From: Linus Walleij @ 2026-05-23 8:59 UTC (permalink / raw)
To: Shubhrajyoti Datta
Cc: linux-kernel, git, shubhrajyoti.datta, Srinivas Neeli,
Michal Simek, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-gpio, devicetree,
linux-arm-kernel
In-Reply-To: <20260512060917.2096456-4-shubhrajyoti.datta@amd.com>
On Tue, May 12, 2026 at 8:09 AM Shubhrajyoti Datta
<shubhrajyoti.datta@amd.com> wrote:
> Add support for the EIO GPIO controller found on
> xa2ve3288 silicon.
>
> The EIO GPIO block provides access to multiplexed I/O pins exposed
> through the EIO interface. Only bank 0 and bank 1 are connected to
> external MIO pins, with 26 GPIOs per bank (52 GPIOs total). This
> change extends the Zynq GPIO driver to support the EIO GPIO
> variant.
>
> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3 0/6] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
From: Wen Jiang @ 2026-05-23 8:26 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, urezki, baohua,
Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6
In-Reply-To: <20260522110727.fc7dccf90bc8513abd1fdbf1@linux-foundation.org>
On Sat, 23 May 2026 at 02:07, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Fri, 22 May 2026 13:31:40 +0800 Wen Jiang <jiangwenxiaomi@gmail.com> wrote:
>
> > This patchset accelerates ioremap, vmalloc, and vmap when the memory
> > is physically fully or partially contiguous.
>
> Thanks. AI review asked a few things and might have found an existing
> 32-bit bug in vmap():
>
> https://sashiko.dev/#/patchset/20260522053146.83209-1-jiangwenxiaomi@gmail.com
Hi Andrew,
I've gone through the Sashiko findings:
- Patch 5 (arch_vmap_pte_supported_shift on x86): Over-interpretation.
This targets ARM64 CONT_PTE. x86 falls through with PAGE_SHIFT
same as before.
- Patch 5 (1 << order overflow at order=31): Over-interpretation.
Reaching order=31 requires 8TB contiguous in a single vmap()
not a realistic usage pattern.
- Patch 6 (GFP_KERNEL triggering purge): The purge only triggers
when vmalloc space is already under pressure, and benefits the
subsequent PAGE_SIZE fallback as well, not wasted work.
- Patch 6 (32-bit count << PAGE_SHIFT overflow): Pre-existing.
Will send a separate fix.
- Patch 6 (unconditional alignment without checking contiguity):
The main vmap() users typically pass contiguous pages
(e.g. system_heap order 8 -> 4 -> 0).
Thanks,
Wen
^ permalink raw reply
* Re: [GIT PULL] KVM/arm64 fixes for 7.1, take #3
From: Paolo Bonzini @ 2026-05-23 8:03 UTC (permalink / raw)
To: Marc Zyngier
Cc: Michael Bommarito, Vincent Donnefort, Will Deacon, Yuan Yao,
Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, kvmarm, linux-arm-kernel, kvm
In-Reply-To: <20260520072518.504865-1-maz@kernel.org>
On Wed, May 20, 2026 at 9:25 AM Marc Zyngier <maz@kernel.org> wrote:
>
> Paolo,
>
> Here's the next set of KVM/arm64 fixes for 7.1. Continuing the trend,
> we have two AI-fuelled fixes, both of which are stable candidates.
> Additionally, a minor tidying-up of the hypervisor tracing descriptor
> validation.
>
> Please pull,
>
> M.
>
> The following changes since commit effc0a39b8e0f30670fe24f51e44329d4324e566:
>
> KVM: arm64: Pre-check vcpu memcache for host->guest donate (2026-05-07 14:12:42 +0100)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-7.1-3
>
> for you to fetch changes up to 1702da76e017ae0fbe1a92b07bc332972c293e89:
>
> KVM: arm64: Fix nVHE/pKVM hyp tracing error on invalid desc (2026-05-20 08:08:37 +0100)
Done, thanks.
Paolo
> ----------------------------------------------------------------
> KVM/arm64 fixes for 7.1, take #3
>
> - Fix ITS EventID sanitisation when restoring an interrupt translation
> table.
>
> - Fix PPI memory leak when failing to initialise a vcpu.
>
> - Correctly return an error when the validation of a hypervisor trace
> descriptor fails, and limit this validation to protected mode only.
>
> ----------------------------------------------------------------
> Michael Bommarito (2):
> KVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits
> KVM: arm64: vgic: Free private_irqs when init fails after allocation
>
> Vincent Donnefort (1):
> KVM: arm64: Fix nVHE/pKVM hyp tracing error on invalid desc
>
> arch/arm64/kvm/arm.c | 4 +++-
> arch/arm64/kvm/hyp/nvhe/trace.c | 9 +++++++--
> arch/arm64/kvm/vgic/vgic-its.c | 4 ++++
> 3 files changed, 14 insertions(+), 3 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v3 6/6] mm/vmalloc: align vm_area so vmap() can batch mappings
From: Uladzislau Rezki @ 2026-05-23 7:53 UTC (permalink / raw)
To: Wen Jiang
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, urezki,
baohua, Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6
In-Reply-To: <20260522053146.83209-7-jiangwenxiaomi@gmail.com>
On Fri, May 22, 2026 at 01:31:46PM +0800, Wen Jiang wrote:
> From: "Barry Song (Xiaomi)" <baohua@kernel.org>
>
> Try to align the vmap virtual address to PMD_SHIFT or a
> larger PTE mapping size hinted by the architecture, so
> contiguous pages can be batch-mapped when setting PMD or
> PTE entries.
>
> 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>
> ---
> mm/vmalloc.c | 33 ++++++++++++++++++++++++++++++++-
> 1 file changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 50642246f4d40..040d400928aab 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3620,6 +3620,37 @@ static int vmap_batched(unsigned long addr, unsigned long end,
> return err;
> }
>
> +static struct vm_struct *get_aligned_vm_area(unsigned long size,
> + unsigned long flags, const void *caller)
> +{
> + struct vm_struct *vm_area;
> + unsigned int shift;
> +
> + /* Try PMD alignment for large sizes */
> + if (size >= PMD_SIZE) {
> + vm_area = __get_vm_area_node(size, PMD_SIZE, PAGE_SHIFT, flags,
> + VMALLOC_START, VMALLOC_END,
> + NUMA_NO_NODE, GFP_KERNEL, caller);
> + if (vm_area)
> + return vm_area;
> + }
> +
> + /* Try CONT_PTE alignment */
> + shift = arch_vmap_pte_supported_shift(size);
> + if (shift > PAGE_SHIFT) {
> + vm_area = __get_vm_area_node(size, 1UL << shift, PAGE_SHIFT, flags,
> + VMALLOC_START, VMALLOC_END,
> + NUMA_NO_NODE, GFP_KERNEL, caller);
> + if (vm_area)
> + return vm_area;
> + }
> +
> + /* Fall back to page alignment */
> + return __get_vm_area_node(size, PAGE_SIZE, PAGE_SHIFT, flags,
> + VMALLOC_START, VMALLOC_END,
> + NUMA_NO_NODE, GFP_KERNEL, caller);
> +}
> +
> /**
> * vmap - map an array of pages into virtually contiguous space
> * @pages: array of page pointers
> @@ -3658,7 +3689,7 @@ void *vmap(struct page **pages, unsigned int count,
> return NULL;
>
> size = (unsigned long)count << PAGE_SHIFT;
> - area = get_vm_area_caller(size, flags, __builtin_return_address(0));
> + area = get_aligned_vm_area(size, flags, __builtin_return_address(0));
> if (!area)
> return NULL;
>
> --
> 2.34.1
>
This one LGTM:
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
--
Uladzislau Rezki
^ permalink raw reply
* Re: [PATCH 2/4] firmware: arm_ffa: Register core as a platform driver
From: Yeoreum Yun @ 2026-05-23 6:27 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Sudeep Holla, linux-security-module, linux-kernel,
linux-integrity, linux-arm-kernel, kvmarm
In-Reply-To: <20260523050555.GA1121518@ax162>
On Fri, May 22, 2026 at 10:05:55PM -0700, Nathan Chancellor wrote:
> On Sat, May 23, 2026 at 05:50:14AM +0100, Yeoreum Yun wrote:
> > Hi Nathan,
> >
> > > Hi Sudeep,
> > >
> > > On Fri, May 08, 2026 at 06:54:16PM +0100, Sudeep Holla wrote:
> > > > Move the FF-A core bring-up and teardown paths into platform driver
> > > > probe and remove callbacks, and register a synthetic arm-ffa platform
> > > > device to bind the driver.
> > > >
> > > > This makes the FF-A core lifetime follow the driver model while keeping
> > > > the device creation internal to the FF-A core. Use normal platform driver
> > > > registration so the probe path has standard driver-core semantics.
> > > >
> > > > The synthetic platform device is a temporary bridge until ACPI and
> > > > devicetree describe the FF-A core device or object. Once those firmware
> > > > description paths are defined, the internal platform device creation can
> > > > be dropped and the driver can bind to the firmware-described device
> > > > directly.
> > > >
> > > > Since the transport selection now happens from the platform probe path,
> > > > drop the __init annotation from ffa_transport_init().
> > > >
> > > > Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
> > >
> > > I am seeing
> > >
> > > arm-ffa arm-ffa: probe with driver arm-ffa failed with error -95
> > >
> > > on my two arm64 test machines after this change landed in -next as
> > > commit e659fc8e537c ("firmware: arm_ffa: Register core as a platform
> > > driver"), is this expected? If so, perhaps it should be silenced?
> >
> > Could you share the .config file you used for this?
>
> Sure thing! It is attached. If you need anything else, please let me
> know.
Thanks! unless there was other error log from ff-a driver,
I think this happens because your environment either doesn’t
support FF-A or is using an SMCCC version earlier than 1.2 from
ffa_version_check() or ffa_transport_init().
If that’s the case, You can ignore this log since this behavior is
expected, and the dd core should print an error log.
Before this patch, the error was not shown because all FF-A initialization
was done during the initcall phase, and nothing was printed
even when the initcall function returned an error from caller of initcall.
[...]
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* [PATCH v2 2/2] usb: dwc3: xilinx: use reset_control_reset() in versal init
From: Radhey Shyam Pandey @ 2026-05-23 7:08 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, michal.simek, p.zabel
Cc: linux-usb, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey
In-Reply-To: <cover.1779518171.git.radhey.shyam.pandey@amd.com>
Replace reset_control_assert()/deassert() with reset_control_reset().
For dwc3-xilinx, reset_control_reset() routes via the zynqmp reset
driver and uses PM_RESET_ACTION_PULSE, which performs assert and
deassert in firmware. This results in a single SMC call issuing a
reset pulse and taking the IP out of reset.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
Changes for v2:
- As suggested by Thinh rephrased commit description to explain
firmware driven reset sequence.
---
drivers/usb/dwc3/dwc3-xilinx.c | 16 ++++------------
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
index 02dc35e110b9..b832505e1b04 100644
--- a/drivers/usb/dwc3/dwc3-xilinx.c
+++ b/drivers/usb/dwc3/dwc3-xilinx.c
@@ -98,18 +98,10 @@ static int dwc3_xlnx_init_versal(struct dwc3_xlnx *priv_data)
dwc3_xlnx_mask_phy_rst(priv_data, false);
- /* Assert and De-assert reset */
- ret = reset_control_assert(crst);
- if (ret < 0) {
- dev_err_probe(dev, ret, "failed to assert Reset\n");
- return ret;
- }
-
- ret = reset_control_deassert(crst);
- if (ret < 0) {
- dev_err_probe(dev, ret, "failed to De-assert Reset\n");
- return ret;
- }
+ /* assert and deassert reset */
+ ret = reset_control_reset(crst);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to assert and deassert reset\n");
dwc3_xlnx_mask_phy_rst(priv_data, true);
dwc3_xlnx_set_coherency(priv_data, XLNX_USB2_TRAFFIC_ROUTE_CONFIG);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/2] minor cleanup for dwc3-xilinx glue driver
From: Radhey Shyam Pandey @ 2026-05-23 7:08 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, michal.simek, p.zabel
Cc: linux-usb, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey
Minor cleanups for the dwc3-xilinx glue driver:
- Fix a comment style violation (missing space before closing delimiter).
- Use reset_control_reset in versal init.
Changes for v2:
- Rephrased commit description for 2/2 patch.
- Drop functional fix (usb: dwc3: xilinx: fix error handling in zynqmp
init error paths) from this series.
Radhey Shyam Pandey (2):
usb: dwc3: xilinx: fix missing space before closing comment delimiter
usb: dwc3: xilinx: use reset_control_reset() in versal init
drivers/usb/dwc3/dwc3-xilinx.c | 18 +++++-------------
1 file changed, 5 insertions(+), 13 deletions(-)
base-commit: c1ecb239fa3456529a32255359fc78b69eb9d847
--
2.43.0
^ permalink raw reply
* [PATCH v2 1/2] usb: dwc3: xilinx: fix missing space before closing comment delimiter
From: Radhey Shyam Pandey @ 2026-05-23 7:08 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, michal.simek, p.zabel
Cc: linux-usb, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey
In-Reply-To: <cover.1779518171.git.radhey.shyam.pandey@amd.com>
Add missing space before '*/' in an inline comment to follow
the kernel coding style.
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
Changes for v2:
- Add Thinh Nguyen acked by tag.
---
drivers/usb/dwc3/dwc3-xilinx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
index 9b9525592a85..02dc35e110b9 100644
--- a/drivers/usb/dwc3/dwc3-xilinx.c
+++ b/drivers/usb/dwc3/dwc3-xilinx.c
@@ -194,7 +194,7 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
}
if (priv_data->usb3_phy) {
- /* Set PIPE Power Present signal in FPD Power Present Register*/
+ /* Set PIPE Power Present signal in FPD Power Present Register */
writel(FPD_POWER_PRSNT_OPTION, priv_data->regs + XLNX_USB_FPD_POWER_PRSNT);
/* Set the PIPE Clock Select bit in FPD PIPE Clock register */
writel(PIPE_CLK_SELECT, priv_data->regs + XLNX_USB_FPD_PIPE_CLK);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 2/4] firmware: arm_ffa: Register core as a platform driver
From: Yeoreum Yun @ 2026-05-23 4:50 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Sudeep Holla, yeoreum.yun, linux-security-module, linux-kernel,
linux-integrity, linux-arm-kernel, kvmarm
In-Reply-To: <20260523001148.GA1319283@ax162>
Hi Nathan,
> Hi Sudeep,
>
> On Fri, May 08, 2026 at 06:54:16PM +0100, Sudeep Holla wrote:
> > Move the FF-A core bring-up and teardown paths into platform driver
> > probe and remove callbacks, and register a synthetic arm-ffa platform
> > device to bind the driver.
> >
> > This makes the FF-A core lifetime follow the driver model while keeping
> > the device creation internal to the FF-A core. Use normal platform driver
> > registration so the probe path has standard driver-core semantics.
> >
> > The synthetic platform device is a temporary bridge until ACPI and
> > devicetree describe the FF-A core device or object. Once those firmware
> > description paths are defined, the internal platform device creation can
> > be dropped and the driver can bind to the firmware-described device
> > directly.
> >
> > Since the transport selection now happens from the platform probe path,
> > drop the __init annotation from ffa_transport_init().
> >
> > Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
>
> I am seeing
>
> arm-ffa arm-ffa: probe with driver arm-ffa failed with error -95
>
> on my two arm64 test machines after this change landed in -next as
> commit e659fc8e537c ("firmware: arm_ffa: Register core as a platform
> driver"), is this expected? If so, perhaps it should be silenced?
>
> Cheers,
> Nathan
>
Could you share the .config file you used for this?
Thanks!
[...]
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH 16/16] media: sun6i-isp: Add support for frame size enumeration
From: arash golgol @ 2026-05-23 4:34 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: linux-media, linux-arm-kernel, linux-sunxi, linux-kernel,
linux-staging, Mauro Carvalho Chehab, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Greg Kroah-Hartman,
Laurent Pinchart, Nicolas Dufresne
In-Reply-To: <20260518102451.417971-17-paulk@sys-base.io>
Hi Paul,
On Mon, May 18, 2026 at 2:02 PM Paul Kocialkowski <paulk@sys-base.io> wrote:
>
> This implements the enum_framesizes operation, which reports support for
> even sizes.
>
> Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
> ---
> .../media/sunxi/sun6i-isp/sun6i_isp_capture.c | 22 +++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/staging/media/sunxi/sun6i-isp/sun6i_isp_capture.c b/drivers/staging/media/sunxi/sun6i-isp/sun6i_isp_capture.c
> index 372b9331bd6d..e638ec32c7cd 100644
> --- a/drivers/staging/media/sunxi/sun6i-isp/sun6i_isp_capture.c
> +++ b/drivers/staging/media/sunxi/sun6i-isp/sun6i_isp_capture.c
> @@ -452,6 +452,26 @@ static int sun6i_isp_capture_enum_fmt(struct file *file, void *priv,
> return 0;
> }
>
> +static int sun6i_isp_capture_enum_framesizes(struct file *file, void *fh,
> + struct v4l2_frmsizeenum *frmsize)
> +{
> + if (frmsize->index)
> + return -EINVAL;
> +
> + if (!sun6i_isp_capture_format_find(frmsize->pixel_format))
> + return -EINVAL;
> +
> + frmsize->type = V4L2_FRMSIZE_TYPE_STEPWISE;
> + frmsize->stepwise.min_width = SUN6I_ISP_CAPTURE_WIDTH_MIN;
> + frmsize->stepwise.max_width = SUN6I_ISP_CAPTURE_WIDTH_MAX;
> + frmsize->stepwise.min_height = SUN6I_ISP_CAPTURE_HEIGHT_MIN;
> + frmsize->stepwise.max_height = SUN6I_ISP_CAPTURE_HEIGHT_MAX;
> + frmsize->stepwise.step_width = 2;
> + frmsize->stepwise.step_height = 2;
> +
> + return 0;
> +}
> +
> static int sun6i_isp_capture_g_fmt(struct file *file, void *priv,
> struct v4l2_format *format)
> {
> @@ -522,6 +542,8 @@ static const struct v4l2_ioctl_ops sun6i_isp_capture_ioctl_ops = {
> .vidioc_s_fmt_vid_cap = sun6i_isp_capture_s_fmt,
> .vidioc_try_fmt_vid_cap = sun6i_isp_capture_try_fmt,
>
> + .vidioc_enum_framesizes = sun6i_isp_capture_enum_framesizes,
> +
> .vidioc_enum_input = sun6i_isp_capture_enum_input,
> .vidioc_g_input = sun6i_isp_capture_g_input,
> .vidioc_s_input = sun6i_isp_capture_s_input,
> --
> 2.54.0
>
Tested on a LicheePi Zero Dock (V3s) with the ov5647 camera setup.
The enum_framesizes implementation behaves as expected and reports the
supported even frame sizes correctly.
Tested-by: Arash Golgol <arash.golgol@gmail.com>
Reviewed-by: Arash Golgol <arash.golgol@gmail.com>
--
Regards,
Arash Golgol
^ permalink raw reply
* Re: [PATCH v5 2/4] kernel: param: initialize module_kset in a pure_initcall
From: Shashank Balaji @ 2026-05-23 3:24 UTC (permalink / raw)
To: Petr Pavlu
Cc: Suzuki K Poulose, James Clark, Alexander Shishkin,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Jonathan Corbet, Shuah Khan, Luis Chamberlain, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Mike Leach, Leo Yan, Thierry Reding,
Jonathan Hunter, Rahul Bukte, linux-kernel, coresight,
linux-arm-kernel, driver-core, rust-for-linux, linux-doc,
Daniel Palmer, Tim Bird, linux-modules, linux-tegra, Sumit Gupta
In-Reply-To: <a0b17be8-f7dd-4d05-bc6f-28b32d0b0785@suse.com>
Hi Petr,
Thanks for the feedback!
On Fri, May 22, 2026 at 03:06:04PM +0200, Petr Pavlu wrote:
> On 5/18/26 12:19 PM, Shashank Balaji wrote:
> > Commit "driver core: platform: set mod_name in driver registration" will set
> > struct device_driver's mod_name member for platform driver registration. For a
> > driver to be registered with its mod_name set, module_kset needs to be
> > initialized, which currently happens in a subsys_initcall in param_sysfs_init().
> > The tegra cbb drivers register themselves before module_kset init, in a
> > core_initcall. This works currently because lookup_or_create_module_kobject(),
> > which dereferences module_kset via kset_find_obj(), is not called if mod_name
> > is not set, which is the case now.
> >
> > So in preparation for the commit "driver core: platform: set mod_name in driver registration",
> > move module_kset init to pure_initcall level, ensuring it happens before tegra
> > cbb driver registration.
> >
> > Suggested-by: Gary Guo <gary@garyguo.net>
> > Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
> > Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
> > Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
> > ---
> > Patch 4 depends on this patch
> > ---
> > kernel/params.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/params.c b/kernel/params.c
> > index 74d620bc2521..ac088d4b09a9 100644
> > --- a/kernel/params.c
> > +++ b/kernel/params.c
> > @@ -957,7 +957,7 @@ static int __init param_sysfs_init(void)
> >
> > return 0;
> > }
> > -subsys_initcall(param_sysfs_init);
> > +pure_initcall(param_sysfs_init);
> >
> > /*
> > * param_sysfs_builtin_init - add sysfs version and parameter
> >
>
> The change looks ok to me functionality-wise. Sysfs is initialized
> earlier in do_basic_setup() and other code, such as classes_init(),
> calls kset_create_and_add() similarly early.
>
> One minor issue is that pure_initcall() was originally intended for
> static variable initialization. The file include/linux/init.h says:
>
> | /*
> | * A "pure" initcall has no dependencies on anything else, and purely
> | * initializes variables that couldn't be statically initialized.
> | *
> | * This only exists for built-in code, not for modules.
> | * Keep main.c:initcall_level_names[] in sync.
> | */
> | #define pure_initcall(fn) __define_initcall(fn, 0)
>
> The patch stretches the intended use of pure_initcall() somewhat in this
> regard. However, other code already appears to do the same, so I guess
> this is ok.
Ah yeah, I thought of this too, but it seems like everyone else is doing
it. Linus introduced pure_initcall in b3438f8266cb
("Add "pure_initcall" for static variable initialization") with the
comment, and he introduced another user of it in 140d0b2108fa
("Do 'shm_init_ns()' in an early pure_initcall") which already stretches
the intended use as per the comment.
Given that it's just being used for "run me before core_initcall;
early_initcall is too early for me" without any "pureness" requirements, I
suppose the comment is due for a revision?
> Additionally, I think it would be good to update the comment preceding
> param_sysfs_init(). It currently says:
>
> | /*
> | * param_sysfs_init - create "module" kset
> | *
> | * This must be done before the initramfs is unpacked and
> | * request_module() thus becomes possible, because otherwise the
> | * module load would fail in mod_sysfs_init.
> | */
>
> I suggest changing it to something like follows:
>
> This must be done before any driver registration so that when a driver comes
> from a built-in module, the driver core can add the module under /sys/module
> and create the associated driver symlinks.
Thanks for catching this! I'll add it in the next revision.
Thanks,
Shashank
^ permalink raw reply
* Re: [PATCH 14/16] media: sun6i-isp: Use V4L2 subdev active state
From: arash golgol @ 2026-05-23 3:15 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: linux-media, linux-arm-kernel, linux-sunxi, linux-kernel,
linux-staging, Mauro Carvalho Chehab, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Greg Kroah-Hartman,
Laurent Pinchart, Nicolas Dufresne
In-Reply-To: <ahA61YIGM4Bqipu7@collins>
Hi Paul,
On Fri, May 22, 2026 at 2:45 PM Paul Kocialkowski <paulk@sys-base.io> wrote:
>
> Hi Arash,
>
> Le Thu 21 May 26, 12:53, arash golgol a écrit :
> > I used LicheePi Zero Dock (V3s) with the following pipeline as test setup.
> >
> > ov5647 -> sun6i-mipi-csi2 -> sun6i-csi-bridge -> sun6i-isp-proc ->
> > sun6i-isp-capture
> >
> > I verified TRY and ACTIVE state handling, including changing TRY
> > formats without affecting ACTIVE state. Format propagation from the
> > sink (csi) pad to the source pad was also tested.
> >
> > I also tested streaming with the sensor test pattern enabled and
> > verified the captured output was correct.
> >
> > Tested-by: Arash Golgol <arash.golgol@gmail.com>
>
> Thanks a lot for testing this! Did you test just this patch or the other
> ones (especially sun6i-csi format enumeration) as well?
>
Happy to help.
I only tested patch 14 for now, but I plan to test the other patches
as well when I get some more time, especially the sun6i-csi changes.
> Also if you have an opinion on the code itself feel free to drop a
> Reviewed-by tag, a lot of this work is very similar to what you did for
> sun6i-csi and other drivers.
>
From a code perspective, the changes look good to me.
Reviewed-by: Arash Golgol <arash.golgol@gmail.com>
--
Regards,
Arash Golgol
^ permalink raw reply
* [PATCH 2/2] ARM: dts: aspeed: sanmiguel: Fix the CPU_CHIPTHROT linename
From: Potin Lai @ 2026-05-23 2:28 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, Patrick Williams
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Cosmo Chou, Mike Hsieh, Potin Lai, Potin Lai
In-Reply-To: <20260523-potin-update-sanmiguel-dts-20260522-v1-0-169f5fceb5f9@quantatw.com>
Fix the GPIO linenames for CPU_CHIPTHROT signals.
The signals were incorrectly marked as output ("-O") while they are
actually input signals ("-I").
- B0_M0_CPU_CHIPTHROT_L-O -> B0_M0_CPU_CHIPTHROT_L-I
- B1_M0_CPU_CHIPTHROT_L-O -> B1_M0_CPU_CHIPTHROT_L-I
Signed-off-by: Potin Lai <potin.lai@quantatw.com>
---
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
index 61dbef45f8b0..d7ed497d7227 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
@@ -224,7 +224,7 @@ hpm0_ioexp_20: gpio@20 {
"B0_M0_LEAK_DETECT_ALERT_L-I",
"B0_M0_RUN_POWER_EN-O",
"B0_M0_RUN_POWER_PG-I",
- "B0_M0_CPU_CHIPTHROT_L-O",
+ "B0_M0_CPU_CHIPTHROT_L-I",
"B0_M0_SHDN_REQ_L-O",
"B0_M0_CPU_SHDN_OK_L-I",
"B0_M0_CPLD_READY-I",
@@ -398,7 +398,7 @@ hpm1_ioexp_20: gpio@20 {
"B1_M0_LEAK_DETECT_ALERT_L-I",
"B1_M0_RUN_POWER_EN-O",
"B1_M0_RUN_POWER_PG-I",
- "B1_M0_CPU_CHIPTHROT_L-O",
+ "B1_M0_CPU_CHIPTHROT_L-I",
"B1_M0_SHDN_REQ_L-O",
"B1_M0_CPU_SHDN_OK_L-I",
"B1_M0_CPLD_READY-I",
--
2.52.0
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: aspeed: sanmiguel: Add IOEXP interrupt pin settings
From: Potin Lai @ 2026-05-23 2:28 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, Patrick Williams
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Cosmo Chou, Mike Hsieh, Potin Lai, Potin Lai
In-Reply-To: <20260523-potin-update-sanmiguel-dts-20260522-v1-0-169f5fceb5f9@quantatw.com>
Kernel dmesg reports IRQ #44 being disabled due to unhandled
interrupts from multiple PCA953x IO expanders:
```
[ 447.047861] irq 44: nobody cared (try booting with the "irqpoll" option)
[ 447.063124] handlers:
[ 447.068176] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.087268] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.106344] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.125421] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.144513] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.163587] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.182663] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.201756] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.220837] Disabling IRQ #44
```
The affected IOEXP nodes are missing interrupt pin configuration in
the device tree, causing the interrupt line to remain asserted and
resulting in repeated unhandled IRQ events.
Add the required interrupt-related properties for the affected IOEXP
devices to ensure proper interrupt handling and prevent the IRQ from
being disabled.
Signed-off-by: Potin Lai <potin.lai@quantatw.com>
---
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
index 74c8c1772109..61dbef45f8b0 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
@@ -334,6 +334,8 @@ hmc_ioexp: gpio@20 {
reg = <0x20>;
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <ASPEED_GPIO(B, 6) IRQ_TYPE_LEVEL_LOW>;
gpio-line-names =
"", "", "HMC_EROT_FATAL_ERROR_L-I", "",
@@ -552,6 +554,8 @@ smm_ext_ioexp: gpio@38 {
reg = <0x38>;
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <ASPEED_GPIO(B, 6) IRQ_TYPE_LEVEL_LOW>;
gpio-line-names =
"SSD0_PRSNT_L-I", "E1S_PWR_EN-O",
--
2.52.0
^ permalink raw reply related
* [PATCH 0/2] ARM: dts: aspeed: sanmiguel: Update DTS file
From: Potin Lai @ 2026-05-23 2:28 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, Patrick Williams
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Cosmo Chou, Mike Hsieh, Potin Lai, Potin Lai
Update the SanMiguel DTS configuration to fix incorrect GPIO
linenames and resolve the IOEXP interrupt handling issue.
Signed-off-by: Potin Lai <potin.lai@quantatw.com>
---
Potin Lai (2):
ARM: dts: aspeed: sanmiguel: Add IOEXP interrupt pin settings
ARM: dts: aspeed: sanmiguel: Fix the CPU_CHIPTHROT linename
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
---
base-commit: 6e22b9e818d68d7b8ce6680aede0c80a9355929a
change-id: 20260522-potin-update-sanmiguel-dts-20260522-7b3d280e63f8
Best regards,
--
Potin Lai <potin.lai@quantatw.com>
^ permalink raw reply
* Re: [PATCH net-next v5 12/13] misc: lan966x-pci: dts: extend cpu reg to cover PCIE DBI space
From: Jakub Kicinski @ 2026-05-23 2:01 UTC (permalink / raw)
To: Daniel Machon
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Horatiu Vultur, Steen Hegelund, UNGLinuxDriver,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Herve Codina, Arnd Bergmann,
Greg Kroah-Hartman, Mohsin Bashir, netdev, linux-kernel, bpf,
linux-arm-kernel
In-Reply-To: <20260520-lan966x-pci-fdma-v5-12-ca56197ae05b@microchip.com>
On Wed, 20 May 2026 10:12:24 +0200 Daniel Machon wrote:
> The ATU outbound windows used by the FDMA engine are programmed through
> registers at offset 0x400000+, which falls outside the current cpu reg
> mapping. Extend the cpu reg size from 0x100000 (1MB) to 0x800000 (8MB)
> to cover the full PCIE DBI and iATU register space.
Are we supposed to take these to net-next ?
^ permalink raw reply
* Re: [PATCH net-next v5 11/13] net: lan966x: add PCIe FDMA XDP support
From: Jakub Kicinski @ 2026-05-23 2:01 UTC (permalink / raw)
To: Daniel Machon
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Horatiu Vultur, Steen Hegelund, UNGLinuxDriver,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Herve Codina, Arnd Bergmann,
Greg Kroah-Hartman, Mohsin Bashir, netdev, linux-kernel, bpf,
linux-arm-kernel
In-Reply-To: <20260520-lan966x-pci-fdma-v5-11-ca56197ae05b@microchip.com>
On Wed, 20 May 2026 10:12:23 +0200 Daniel Machon wrote:
> #if IS_ENABLED(CONFIG_MCHP_LAN966X_PCI)
> extern const struct lan966x_fdma_ops lan966x_fdma_pci_ops;
> +
> +static inline bool lan966x_is_pci(struct lan966x *lan966x)
> +{
> + return lan966x->ops == &lan966x_fdma_pci_ops;
return IS_ENABLED(CONFIG_MCHP_LAN966X_PCI) &&
lan966x->ops == &lan966x_fdma_pci_ops;
compiler will eliminate the reference to the ops as dead code
and linker will not complain that its object is missing.
> +}
> +#else
> +static inline bool lan966x_is_pci(struct lan966x *lan966x)
> +{
> + return false;
> +}
> #endif
>
> int lan966x_lag_port_join(struct lan966x_port *port,
> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_xdp.c b/drivers/net/ethernet/microchip/lan966x/lan966x_xdp.c
> index 9ee61db8690b..b470f731e25c 100644
> --- a/drivers/net/ethernet/microchip/lan966x/lan966x_xdp.c
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_xdp.c
> @@ -24,6 +24,16 @@ static int lan966x_xdp_setup(struct net_device *dev, struct netdev_bpf *xdp)
> old_prog = xchg(&port->xdp_prog, xdp->prog);
> new_xdp = lan966x_xdp_present(lan966x);
>
> + /* PCIe FDMA uses contiguous buffers, so no page_pool reload
> + * is needed. Drain NAPI before freeing the old program so
> + * no in-flight poll holds a stale pointer.
> + */
Not sure what this does. BPF programs are under RCU, they are not
immediately freed (if that's that you mean..)
> + if (lan966x_is_pci(lan966x)) {
> + if (old_prog)
> + napi_synchronize(&lan966x->napi);
> + goto out;
> + }
^ permalink raw reply
* Re: [PATCH net-next v5 09/13] net: lan966x: add PCIe FDMA support
From: Jakub Kicinski @ 2026-05-23 1:56 UTC (permalink / raw)
To: Daniel Machon
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Horatiu Vultur, Steen Hegelund, UNGLinuxDriver,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Herve Codina, Arnd Bergmann,
Greg Kroah-Hartman, Mohsin Bashir, netdev, linux-kernel, bpf,
linux-arm-kernel
In-Reply-To: <20260520-lan966x-pci-fdma-v5-9-ca56197ae05b@microchip.com>
On Wed, 20 May 2026 10:12:21 +0200 Daniel Machon wrote:
> Add PCIe FDMA support for lan966x. The PCIe FDMA path uses contiguous
> DMA buffers mapped through the endpoint's ATU, with memcpy-based frame
> transfer instead of per-page DMA mappings.
>
> With PCIe FDMA, throughput increases from ~33 Mbps (register-based I/O)
> to ~620 Mbps on an Intel x86 host with a lan966x PCIe card.
> diff --git a/drivers/net/ethernet/microchip/lan966x/Makefile b/drivers/net/ethernet/microchip/lan966x/Makefile
> index 4cdbe263502c..ac0beceb2a0d 100644
> --- a/drivers/net/ethernet/microchip/lan966x/Makefile
> +++ b/drivers/net/ethernet/microchip/lan966x/Makefile
> @@ -18,6 +18,10 @@ lan966x-switch-objs := lan966x_main.o lan966x_phylink.o lan966x_port.o \
> lan966x-switch-$(CONFIG_LAN966X_DCB) += lan966x_dcb.o
> lan966x-switch-$(CONFIG_DEBUG_FS) += lan966x_vcap_debugfs.o
>
> +ifdef CONFIG_MCHP_LAN966X_PCI
ifeq ()
would be more common in a Makefile?
> +lan966x-switch-y += lan966x_fdma_pci.o
> +endif
> +
> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
> index cc3c7b6c65ae..7036b1d937d5 100644
> --- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c
> @@ -7,6 +7,7 @@
> #include <linux/ip.h>
> #include <linux/of.h>
> #include <linux/of_net.h>
> +#include <linux/pci.h>
> #include <linux/phy/phy.h>
> #include <linux/platform_device.h>
> #include <linux/reset.h>
> @@ -49,6 +50,9 @@ struct lan966x_main_io_resource {
> static const struct lan966x_main_io_resource lan966x_main_iomap[] = {
> { TARGET_CPU, 0xc0000, 0 }, /* 0xe00c0000 */
> { TARGET_FDMA, 0xc0400, 0 }, /* 0xe00c0400 */
> +#if IS_ENABLED(CONFIG_MCHP_LAN966X_PCI)
why config option being enabled changes the targets?
Can someone with a non-PCI device enable that option too
(sure it would be useless but given that/if they can guarding
with an #if seems like a waste of LoC)
> + { TARGET_PCIE_DBI, 0x400000, 0 }, /* 0xe0400000 */
> +#endif
> { TARGET_ORG, 0, 1 }, /* 0xe2000000 */
> { TARGET_GCB, 0x4000, 1 }, /* 0xe2004000 */
> { TARGET_QS, 0x8000, 1 }, /* 0xe2008000 */
> @@ -1100,6 +1104,13 @@ static int lan966x_reset_switch(struct lan966x *lan966x)
>
> static const struct lan966x_fdma_ops *lan966x_get_fdma_ops(struct device *dev)
> {
> +#if IS_ENABLED(CONFIG_MCHP_LAN966X_PCI)
> + for (struct device *p = dev->parent; p; p = p->parent) {
> + if (dev_is_pci(p))
If the PCIe devices also use an intermediate platform device for
probing, can't they explicitly have some flag / state to indicate
they are PCIe? The device walk in such a constrained env seems
like an overkill
> + return &lan966x_fdma_pci_ops;
> + }
> +#endif
> +
> return &lan966x_fdma_ops;
> }
>
> diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.h b/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
> index 5f4dbeda17cd..e7fdd4447fb6 100644
> --- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
> +++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.h
> @@ -17,6 +17,9 @@
> #include <net/xdp.h>
>
> #include <fdma_api.h>
> +#if IS_ENABLED(CONFIG_MCHP_LAN966X_PCI)
> +#include <fdma_pci.h>
> +#endif
Conditional #includes make build testing harder, better to avoid them
> #include <vcap_api.h>
> #include <vcap_api_client.h>
>
> @@ -288,6 +291,10 @@ struct lan966x {
>
> void __iomem *regs[NUM_TARGETS];
>
> +#if IS_ENABLED(CONFIG_MCHP_LAN966X_PCI)
> + struct fdma_pci_atu atu;
> +#endif
> +
> int shared_queue_sz;
>
> u8 base_mac[ETH_ALEN];
> @@ -586,6 +593,10 @@ void lan966x_fdma_wakeup_netdev(struct lan966x *lan966x);
> int lan966x_fdma_get_max_frame(struct lan966x *lan966x);
> int lan966x_qsys_sw_status(struct lan966x *lan966x);
>
> +#if IS_ENABLED(CONFIG_MCHP_LAN966X_PCI)
> +extern const struct lan966x_fdma_ops lan966x_fdma_pci_ops;
> +#endif
There should be no need to wrap extern in an #if
^ permalink raw reply
* Re: [PATCH net-next v5 08/13] net: lan966x: add shutdown callback to stop FDMA on reboot
From: Jakub Kicinski @ 2026-05-23 1:45 UTC (permalink / raw)
To: Daniel Machon
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Horatiu Vultur, Steen Hegelund, UNGLinuxDriver,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Herve Codina, Arnd Bergmann,
Greg Kroah-Hartman, Mohsin Bashir, netdev, linux-kernel, bpf,
linux-arm-kernel
In-Reply-To: <20260520-lan966x-pci-fdma-v5-8-ca56197ae05b@microchip.com>
On Wed, 20 May 2026 10:12:20 +0200 Daniel Machon wrote:
> + napi_synchronize(&lan966x->napi);
> + napi_disable(&lan966x->napi);
Why the synchronize() before disable() ?
napi_synchronize() is a simplistic disable() + enable()
^ permalink raw reply
* Re: [PATCH v2] ARM: OMAP2+: Add CFI type for omap4_finish_suspend
From: Nathan Chancellor @ 2026-05-23 1:17 UTC (permalink / raw)
To: Mithil Bavishi
Cc: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Russell King, Sami Tolvanen, Kees Cook,
linux-arm-kernel, linux-omap, llvm, linux-kernel
In-Reply-To: <20260522233036.12277-1-bavishimithil@gmail.com>
On Fri, May 22, 2026 at 04:30:36PM -0700, Mithil Bavishi wrote:
> With CONFIG_CFI enabled, OMAP4 can trap in omap4_enter_lowpower()
> because omap_pm_ops.finish_suspend points directly to the assembly
> routine omap4_finish_suspend, which lacks the expected KCFI type
> metadata.
>
> Annotate omap4_finish_suspend with SYM_TYPED_FUNC_START so the assembly
> routine carries the KCFI type metadata.
>
> Signed-off-by: Mithil Bavishi <bavishimithil@gmail.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
> arch/arm/mach-omap2/sleep44xx.S | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S
> index f09c91978..0b48df6fc 100644
> --- a/arch/arm/mach-omap2/sleep44xx.S
> +++ b/arch/arm/mach-omap2/sleep44xx.S
> @@ -58,7 +58,7 @@
> * stack frame and it expects the caller to take care of it. Hence the entire
> * stack frame is saved to avoid possible stack corruption.
> */
> -ENTRY(omap4_finish_suspend)
> +SYM_TYPED_FUNC_START(omap4_finish_suspend)
> stmfd sp!, {r4-r12, lr}
> cmp r0, #0x0
> beq do_WFI @ No lowpower state, jump to WFI
> @@ -223,7 +223,7 @@ skip_scu_gp_clear:
> isb
> dsb
> ldmfd sp!, {r4-r12, pc}
> -ENDPROC(omap4_finish_suspend)
> +SYM_FUNC_END(omap4_finish_suspend)
>
> /*
> * ============================
> --
> 2.43.0
>
--
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH v2] net: stmmac: mmc: Remove duplicate mmc_rx crc
From: patchwork-bot+netdevbpf @ 2026-05-23 0:40 UTC (permalink / raw)
To: Abid Ali
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, mcoquelin.stm32,
alexandre.torgue, netdev, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260521-xgmac-mmc_rx_crc-cleanup-v2-1-7d9de09f5898@gmail.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 21 May 2026 16:32:46 +0000 you wrote:
> From: Abid Ali <dev.taqnialabs@gmail.com>
>
> MMC_XGMAC_RX_CRC_ERR is clear-on-read, and just a single read would
> update the mmc_rx_crc_error counter.
>
> [1] commit b6cdf09 ("net: stmmac: xgmac: Implement MMC counters").
> The duplicate read appears to have been unintentionally introduced in
> the intial MMC counter implementation. The databook does not mention
> MMC_XGMAC_RX_CRC_ERR needing the additional read.
>
> [...]
Here is the summary with links:
- [v2] net: stmmac: mmc: Remove duplicate mmc_rx crc
https://git.kernel.org/netdev/net-next/c/fd1cdeddd7bc
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 2/4] firmware: arm_ffa: Register core as a platform driver
From: Nathan Chancellor @ 2026-05-23 0:11 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-security-module, linux-kernel, linux-integrity,
linux-arm-kernel, kvmarm, Yeoreum Yun
In-Reply-To: <20260508-b4-ffa_plat_dev-v1-2-c5a30f8cf7b8@kernel.org>
Hi Sudeep,
On Fri, May 08, 2026 at 06:54:16PM +0100, Sudeep Holla wrote:
> Move the FF-A core bring-up and teardown paths into platform driver
> probe and remove callbacks, and register a synthetic arm-ffa platform
> device to bind the driver.
>
> This makes the FF-A core lifetime follow the driver model while keeping
> the device creation internal to the FF-A core. Use normal platform driver
> registration so the probe path has standard driver-core semantics.
>
> The synthetic platform device is a temporary bridge until ACPI and
> devicetree describe the FF-A core device or object. Once those firmware
> description paths are defined, the internal platform device creation can
> be dropped and the driver can bind to the firmware-described device
> directly.
>
> Since the transport selection now happens from the platform probe path,
> drop the __init annotation from ffa_transport_init().
>
> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
I am seeing
arm-ffa arm-ffa: probe with driver arm-ffa failed with error -95
on my two arm64 test machines after this change landed in -next as
commit e659fc8e537c ("firmware: arm_ffa: Register core as a platform
driver"), is this expected? If so, perhaps it should be silenced?
Cheers,
Nathan
# bad: [c1ecb239fa3456529a32255359fc78b69eb9d847] Add linux-next specific files for 20260522
# good: [6779b50faa562e6cca1aa6a4649a4d764c6c7e28] Merge tag 'pci-v7.1-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci
git bisect start 'c1ecb239fa3456529a32255359fc78b69eb9d847' '6779b50faa562e6cca1aa6a4649a4d764c6c7e28'
# bad: [c09bb0d7c56d56daed51e374409472c3fece9931] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/ath/ath.git
git bisect bad c09bb0d7c56d56daed51e374409472c3fece9931
# bad: [42b0664d6f7b3d04f961e0709811280e52d4d39c] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git
git bisect bad 42b0664d6f7b3d04f961e0709811280e52d4d39c
# good: [63775c4b77cf7ac5863ae0e76f8626b80d217562] Merge branch 'mm-nonmm-unstable' of https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
git bisect good 63775c4b77cf7ac5863ae0e76f8626b80d217562
# good: [f437936af5c74fddfdfcd2388a5f1eec2f9a105b] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap.git
git bisect good f437936af5c74fddfdfcd2388a5f1eec2f9a105b
# good: [01bf3f256f1ed15fa3884e4893e5a9d78fdfb2d6] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git
git bisect good 01bf3f256f1ed15fa3884e4893e5a9d78fdfb2d6
# bad: [bee649097c8de82d9dccd3660c41163a6507e3d4] Merge branch 'next' of https://git.kernel.org/pub/scm/linux/kernel/git/jenswi/linux-tee.git
git bisect bad bee649097c8de82d9dccd3660c41163a6507e3d4
# bad: [82ccfdd8dd1e29229a3ed7c95a76578706fc4a1d] Merge branch 'for-next' of https://github.com/sophgo/linux.git
git bisect bad 82ccfdd8dd1e29229a3ed7c95a76578706fc4a1d
# good: [32bc5496b48174dbca1f187f710955ee4d9527a1] firmware: arm_scmi: Validate SENSOR_UPDATE payload size
git bisect good 32bc5496b48174dbca1f187f710955ee4d9527a1
# bad: [64251369d33884b431a52b89c60fabf466f3913c] Merge branches 'for-next/scmi/updates' and 'for-next/ffa/updates' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into for-linux-next
git bisect bad 64251369d33884b431a52b89c60fabf466f3913c
# bad: [70492cfce2a4d41e87bf46989028a90f4bc6b38f] firmware: smccc: Fix Arm SMCCC SOC_ID name call
git bisect bad 70492cfce2a4d41e87bf46989028a90f4bc6b38f
# bad: [7fe2ec9fb8e9a78dad8d6b1e551cb4d126e36f1e] firmware: arm_ffa: Set the core device as FF-A device parent
git bisect bad 7fe2ec9fb8e9a78dad8d6b1e551cb4d126e36f1e
# bad: [e659fc8e537c7a21d5d693d6f30d8852f2fa8d91] firmware: arm_ffa: Register core as a platform driver
git bisect bad e659fc8e537c7a21d5d693d6f30d8852f2fa8d91
# good: [cc7e8f21b9f0c229d68cf19a837cba82b5ac2d87] Revert "firmware: arm_ffa: Change initcall level of ffa_init() to rootfs_initcall"
git bisect good cc7e8f21b9f0c229d68cf19a837cba82b5ac2d87
# first bad commit: [e659fc8e537c7a21d5d693d6f30d8852f2fa8d91] firmware: arm_ffa: Register core as a platform driver
^ 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