* Re: [PATCH v3 1/3] dt-bindings: net: add Realtek r8169 family PCIe Ethernet
From: Ricardo Pardini @ 2026-06-06 5:03 UTC (permalink / raw)
To: Heiner Kallweit, nic_swsd, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: Sebastian Reichel, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip
In-Reply-To: <b7cc8eba-ff6e-417d-8e74-b3bb24e08a26@gmail.com>
On 05/06/2026 17:48, Heiner Kallweit wrote:
> On 05.06.2026 13:49, Ricardo Pardini via B4 Relay wrote:
>> From: Ricardo Pardini <ricardo@pardini.net>
>>
>> Add a binding for fixed/soldered Realtek PCIe Ethernet controllers
>> driven by the r8169 driver (RTL8125/8126/8127/8168 and variants).
>>
>> The "pciVVVV,DDDD" compatibles are the Open Firmware PCI Bus Binding
>> spelling, auto-derived from PCI-SIG vendor/device IDs, but they still
>> need a binding when used in a board DT - analogous to "usbVVVV,PPPP"
>> compatibles documented in their own bindings (e.g. microchip,lan95xx)
>> so board DTs attaching properties (fixed MAC, nvmem cell, ...) to
>> these PCI function nodes can be validated.
>>
>
> The of node seems to be created by of_pci_make_dev_node(). But this
> function is called for bridges only in pci_bus_add_device().
> So where is the node created in your case? Did you test node creation?
>
Hi Heiner,
Seems to me of_pci_make_dev_node() is not at play here - that's the
DT-synthesis path. For nodes already present in DT, the of_node is bound
earlier, during pci_setup_device() -> pci_set_of_node() ->
of_pci_find_child_device() via the 5-cell reg.
Ref testing: yes; with this series on a NanoPC-T6 I get, for example:
/sys/bus/pci/devices/0004:41:00.0/of_node ->
/sys/firmware/devicetree/base/pcie@fe190000/pcie@0,0/ethernet@0,0 and
u-boot correctly adds local-mac-address property there which is
correctly picked up kernel-side:
=> setenv eth1addr 8e:b4:90:66:66:66
=> boot
...
# readlink -f /sys/bus/pci/devices/0004:41:00.0/of_node
/sys/firmware/devicetree/base/pcie@fe190000/pcie@0,0/ethernet@0,0
# xxd /sys/bus/pci/devices/0004:41:00.0/of_node/local-mac-address
00000000: 8eb4 9066 6666 ...fff
# ip link show dev end1 | grep ether
link/ether 8e:b4:90:66:66:66 brd ff:ff:ff:ff:ff:ff
>> +properties:
>> + compatible:
>> + enum:
>> + - pci10ec,8125 # RTL8125 2.5GbE
>> + - pci10ec,8126 # RTL8126 5GbE
>> + - pci10ec,8127 # RTL8127
>> + - pci10ec,8161 # RTL8168 variant
>> + - pci10ec,8162 # RTL8168 variant
>> + - pci10ec,8168 # RTL8168/8111 GbE
>
> This list reflects just some of the PCI id's handled by r8169.
> Any specific reason for this exact selection?
I went for "chips likely to be soldered down on an SBC", but that was
indeed speculative.
I guess I should trim to pci10ec,8125, which is all this series
describes? (further IDs can be added by the patches that introduce
boards using them)
--
Regards,
Ricardo
^ permalink raw reply
* Re: [PATCH bpf-next v2 8/8] selftests/bpf: add tests to validate KASAN on JIT programs
From: Yonghong Song @ 2026-06-06 4:09 UTC (permalink / raw)
To: Alexis Lothoré, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Eduard Zingerman,
Kumar Kartikeya Dwivedi, Song Liu, Jiri Olsa, John Fastabend,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Shuah Khan, Maxime Coquelin, Alexandre Torgue,
Ihor Solodrai
Cc: ebpf, Bastien Curutchet, Thomas Petazzoni, bpf, linux-kernel,
linux-kselftest, linux-stm32, linux-arm-kernel
In-Reply-To: <DJ1EYKOXV11H.25EJOUKFI81T4@bootlin.com>
On 6/5/26 1:55 PM, Alexis Lothoré wrote:
> On Fri Jun 5, 2026 at 7:20 PM CEST, Yonghong Song wrote:
>
> [...]
>
>>> Are you seeing any kasan report when you manually check your kernel
>>> logs, or not at all ? If not at all, are you using the "CI" defconfig ?
>> I do see one report:
>>
>> [ 79.503059] ==================================================================
>> [ 79.503715] BUG: KASAN: slab-use-after-free in bpf_prog_bb753b2ee1f69aa0_st_not_on_stack+0x115/0x160
>> [ 79.503715] Write of size 1 at addr ff11000117210a20 by task test_progs/2153
>>
>> [ 79.503715] CPU: 6 UID: 0 PID: 2153 Comm: test_progs Tainted: G OE 7.1.0-rc5-gd552a156c2fa #1926 PREEMPT(full)
>> [ 79.503715] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
>> [ 79.503715] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
>> [ 79.503715] Call Trace:
>> [ 79.503715] <TASK>
>> [ 79.503715] dump_stack_lvl+0x6d/0xa0
>> [ 79.503715] print_address_description+0x77/0x200
>> [ 79.503715] print_report+0x58/0x70
>> [ 79.503715] ? bpf_prog_bb753b2ee1f69aa0_st_not_on_stack+0x115/0x160
>> [ 79.503715] kasan_report+0xa2/0xe0
>> [ 79.503715] ? bpf_prog_bb753b2ee1f69aa0_st_not_on_stack+0x115/0x160
>> [ 79.503715] ? bpf_test_run+0x208/0x770
>> [ 79.503715] bpf_prog_bb753b2ee1f69aa0_st_not_on_stack+0x115/0x160
>> [ 79.503715] bpf_test_run+0x472/0x770
>> [ 79.503715] ? srso_alias_return_thunk+0x5/0xfbef5
>> [ 79.503715] ? __lock_acquire+0xe4a/0x2a10
>> [ 79.503715] ? __pfx___css_rstat_updated+0x10/0x10
>> [ 79.503715] ? __lock_acquire+0xe4a/0x2a10
>> [ 79.503715] ? __pfx_bpf_test_run+0x10/0x10
>> [ 79.503715] ? srso_alias_return_thunk+0x5/0xfbef5
>> [ 79.503715] ? lock_acquire+0xfd/0x2b0
>> [ 79.503715] ? srso_alias_return_thunk+0x5/0xfbef5
>> [ 79.503715] ? srso_alias_return_thunk+0x5/0xfbef5
>> [ 79.503715] ? rcu_is_watching+0x1f/0xa0
>> [ 79.503715] ? srso_alias_return_thunk+0x5/0xfbef5
>> [ 79.503715] ? __kasan_krealloc+0xe9/0x110
>> [ 79.503715] ? eth_type_trans+0x4b9/0x5f0
>> [ 79.503715] bpf_prog_test_run_skb+0xddf/0x22f0
>> [ 79.503715] ? __fget_files+0x29/0x350
>> [ 79.503715] ? srso_alias_return_thunk+0x5/0xfbef5
>> [ 79.503715] ? __fget_files+0x29/0x350
>> [ 79.503715] bpf_prog_test_run+0x1cc/0x2d0
>> [ 79.503715] __sys_bpf+0x740/0xa30
>> [ 79.503715] ? __pfx___sys_bpf+0x10/0x10
>> [ 79.503715] ? _prb_read_valid+0x334/0x770
>> [ 79.503715] ? handle_mm_fault+0x91b/0xc00
>> [ 79.503715] __x64_sys_bpf+0xba/0xd0
>> [ 79.503715] do_syscall_64+0xee/0x400
>> [ 79.503715] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
>> [ 79.503715] entry_SYSCALL_64_after_hwframe+0x76/0x7e
>> [ 79.503715] RIP: 0033:0x7f92d8cfe1ad
>> [ 79.503715] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 8
>> [ 79.503715] RSP: 002b:00007ffe4237fee8 EFLAGS: 00000206 ORIG_RAX: 0000000000000141
>> [ 79.503715] RAX: ffffffffffffffda RBX: 00007ffe423807b8 RCX: 00007f92d8cfe1ad
>> [ 79.503715] RDX: 0000000000000050 RSI: 00007ffe4237ff70 RDI: 000000000000000a
>> [ 79.503715] RBP: 00007ffe4237ff10 R08: 0000000000000000 R09: 0000000000000050
>> [ 79.503715] R10: 0000000000000064 R11: 0000000000000206 R12: 0000000000000000
>> [ 79.503715] R13: 00007ffe423807d8 R14: 00007f92d8eb9000 R15: 00005585778dd150
>> [ 79.503715] </TASK>
>>
>> [ 79.503715] Allocated by task 2153:
>> [ 79.503715] kasan_save_track+0x2f/0x70
>> [ 79.503715] __kasan_kmalloc+0x72/0x90
>> [ 79.503715] __kmalloc_node_noprof+0x34c/0x730
>> [ 79.503715] bpf_map_area_alloc+0x4a/0x110
>> [ 79.503715] array_map_alloc+0x19e/0x580
>> [ 79.503715] map_create+0x8b2/0x1500
>> [ 79.503715] __sys_bpf+0x7ea/0xa30
>> [ 79.503715] __x64_sys_bpf+0xba/0xd0
>> [ 79.503715] do_syscall_64+0xee/0x400
>> [ 79.503715] entry_SYSCALL_64_after_hwframe+0x76/0x7e
>>
>> [ 79.503715] The buggy address belongs to the object at ff11000117210800
>> which belongs to the cache kmalloc-cg-1k of size 1024
>> [ 79.503715] The buggy address is located 0 bytes to the right of
>> freed 544-byte region [ff11000117210800, ff11000117210a20)
>>
>> [ 79.503715] The buggy address belongs to the physical page:
>> [ 79.503715] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x117210
>> [ 79.503715] head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
>> [ 79.503715] memcg:ff11000117210411
>> [ 79.503715] flags: 0x200000000000040(head|node=0|zone=2)
>> [ 79.503715] page_type: f5(slab)
>> [ 79.503715] raw: 0200000000000040 ff11000100072000 dead000000000100 dead000000000122
>> [ 79.503715] raw: 0000000000000000 0000080000100010 00000000f5000000 ff11000117210411
>> [ 79.503715] head: 0200000000000040 ff11000100072000 dead000000000100 dead000000000122
>> [ 79.503715] head: 0000000000000000 0000080000100010 00000000f5000000 ff11000117210411
>> [ 79.503715] head: 0200000000000003 fffffffffffffe01 00000000ffffffff 00000000ffffffff
>> [ 79.503715] head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000008
>> [ 79.503715] page dumped because: kasan: bad access detected
>>
>> [ 79.503715] Memory state around the buggy address:
>> [ 79.503715] ff11000117210900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> [ 79.503715] ff11000117210980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> [ 79.503715] >ff11000117210a00: 00 00 00 00 fb fb fc fc fc fc fc fc fc fc fc fc
>> [ 79.503715] ^
>> [ 79.503715] ff11000117210a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> [ 79.503715] ff11000117210b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> [ 79.503715] ==================================================================
>>
>>
>> But when I am running another same test './test_progs -t kasan', there is no kasan reports.
> Ok, I guess you are missing kasan_multi_shot on your kernel command
> line: without this option, only the first report is generated, then
> KASAN does not emit additional report until you restart your kernel.
> Could you please try adding it and running the tests again ?
Thanks! Adding 'kasan_multi_shot' to the kernel command line indeed fixed the problem.
It would be great if you can mention 'kasan_multi_shot' is needed in kernel command
line in cover letter and in patch 8.
>
> Thanks,
>
> Alexis
>
>>> cat tools/testing/selftests/bpf/{config,config.vm,config.x86_64} > .config && make olddefconfig
>>>
>>> If not, would you mind sharing your defconfig ?
>> Attached.
>>
>>> Thanks,
>>>
>>> Alexis
>
>
>
^ permalink raw reply
* [PATCH] ASoC: mediatek: mt8365: check suspend backup allocation
From: Ruoyu Wang @ 2026-06-06 4:07 UTC (permalink / raw)
To: Liam Girdwood
Cc: Mark Brown, Jaroslav Kysela, Takashi Iwai, Matthias Brugger,
AngeloGioacchino Del Regno, linux-sound, linux-kernel,
linux-arm-kernel, linux-mediatek, Ruoyu Wang
mt8365_afe_suspend() lazily allocates the register backup array and then
stores register values into it. If devm_kcalloc() fails, the suspend path
dereferences afe->reg_back_up in the backup loop.
Check the allocation result before using the array. Disable the main
clock before returning so the error path balances the clock enable at the
start of suspend.
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
---
sound/soc/mediatek/mt8365/mt8365-afe-pcm.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/sound/soc/mediatek/mt8365/mt8365-afe-pcm.c b/sound/soc/mediatek/mt8365/mt8365-afe-pcm.c
index d01793394f225..74e4f53b31605 100644
--- a/sound/soc/mediatek/mt8365/mt8365-afe-pcm.c
+++ b/sound/soc/mediatek/mt8365/mt8365-afe-pcm.c
@@ -1978,6 +1978,10 @@ static int mt8365_afe_suspend(struct device *dev)
afe->reg_back_up =
devm_kcalloc(dev, afe->reg_back_up_list_num,
sizeof(unsigned int), GFP_KERNEL);
+ if (!afe->reg_back_up) {
+ mt8365_afe_disable_main_clk(afe);
+ return -ENOMEM;
+ }
for (i = 0; i < afe->reg_back_up_list_num; i++)
regmap_read(regmap, afe->reg_back_up_list[i],
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v4 18/24] iommu/arm-smmu-v3: Introduce master->ats_broken flag
From: Nicolin Chen @ 2026-06-06 4:04 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Bjorn Helgaas,
Rafael J . Wysocki, Len Brown, Pranjal Shrivastava, Mostafa Saleh,
Lu Baolu, Kevin Tian, linux-arm-kernel, iommu, linux-kernel,
linux-acpi, linux-pci, vsethi, Shuai Xue
In-Reply-To: <20260605230315.GF1962447@nvidia.com>
On Fri, Jun 05, 2026 at 08:03:15PM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 05, 2026 at 02:56:06PM -0700, Nicolin Chen wrote:
> > On Fri, Jun 05, 2026 at 04:42:59PM -0300, Jason Gunthorpe wrote:
> > > I don't see any of these options as appealing. We have to maintain a
> > > few key invariants, and I think it cannot be done without a way to
> > > find all the domains that are using the STE.
> > >
> > > One way or another you have to be using the invs list rw locks to
> > > synchronize the EATS state changes.
> > >
> > > It is okayish to be sloppy when turning EATS off, but when turning it
> > > back on we do need to cycle through every invs list and toggle its
> > > lock to ensure that the invalidations are synchronized before
> > > EATS=enable happens.
> >
> > I think the core guarantees that "cycle through every invs list"
> > happens: a PCI reset calls reset_prepare() blocking all the RID
> > and PASID domains and removing ATS entries from every invs list,
> > and then calls reset_done() that re-attach RID/PASID domains so
> > freshly new ATS entries will be installed before EATS=enable.
>
> I think this whole thing is so async and racy this is not something we
> can truely rely on. The driver is going to have to make sure it
> doesn't get turned on accidentally while the CD is still populated.
You mean the driver needs to ensure that the ATS entires in the
invs list would not be skipped when STE.EATS is enabled, right?
Otherwise, INV_TYPE_ATS_BROKEN + per-master domain list cannot
prevent a concurrent attach() from turning on STE.EATS either.
> > > Given you must have a way to go from STE -> master -> all invs lists
> > > I'm not sure either option really makes such a large difference.
> > >
> > > If so then adjusting the invs to disable the ATS is pretty simple, run
> > > over the xarray and set them all off. Yes you could find the master
> > > through a SID lookup with some locking adjustment.
> > > >
> > > > (1) Per-invs marker: INV_TYPE_ATS_BROKEN + master_domains
> > > > disable_ats() in the timeout path walks master->master_domains
> > > > and flips matching ATS invs entries to the BROKEN type.
> > > >
> > > > + invs walker is free (one case label in the existing type switch).
> > > > + No lock or pointer deref in the invs walker.
> > > > + No master pointer stored in invs; no lifetime concern.
> > > >
> > > > - disable_ats() walks every (master, domain) and marks each invs
> > > > set; the list needs locking usable from atomic.
> > >
> > > This doesn't seem so bad
> >
> > Yea, the only thing is that the disable path has to deal with a
> > complexity from going through a per-device domain list. Maybe it
> > can reuse iommu_group->pasid_array by taking xa_lock?
>
> Maybe the locking seems tricky as the locks might end up nesting in
> weird ways.
Oh, that's thoughtful.
> The streams rb tree and existing master domains linked list seems
> appealing if the locking can nest acceptably.
Yea, limiting the locking at the driver-level is more manageable.
> > > > (3) Per-master flag + inv->master pointer (v4)
> > > > invs entry carries a master pointer; the invs walker reads
> > > > cur->master->ats_broken directly.
> > > >
> > > > + invs walker is one READ_ONCE through a cached pointer.
> > > > + disable_ats is one WRITE_ONCE.
> > > > + atc_inv_master early-skip via one READ_ONCE.
> > > > + attach gate + post-attach re-check, same as (2).
> > > >
> > > > - invs holds a master ptr, so release_device must synchronize_rcu()
> > > > before freeing the master to drain walkers under rcu_read_lock().
> > > > We dropped this from v4 for that reason.
> > >
> > > synchronize_rcu is not right because you have to have gone through the
> > > rwlock so there can be no readers.
> >
> > Ah, I think you are right! When release_device() is invoked, the
> > device must be already in the release (blocked) domain. So there
> > should be no domain->invs in the system holding its ATS entries.
> > And the enable part would work as (2).
> >
> > In this case, (3) seems the best? It's fast on every aspect.
>
> I don't like it mainly because of the sketch enable side, and if we
> tighten that then you can just do 1 which doesn't have a perf impact..
I agree that per-master flag alone would be racy. So, for it to
work, it would need an extra spinlock. This v4 actually added a
pairing ats_broken_lock to fence arm_smmu_write_entry() in the
attach path, while the quarantine path is disabling STE.EATS and
setting the per-master flag. With that, the driver can ensure:
- no race in STE.EATS update
- consistency between STE.EATS and ATS entries in every invs
> But still, I'm not sure how all the asyncess and races will resolve in
> any of these cases.
Maybe we can try "INV_TYPE_ATS_BROKEN + per-master domain list"
first and see if Sashiko might identify some corner case.
Thanks
Nicolin
^ permalink raw reply
* Re: [PATCH v3 0/5] remoteproc: cleanup shared carveout and resource-table helpers
From: Peng Fan @ 2026-06-06 3:43 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Ben Levinsky, arnaud.pouliquen, daniel.baluta, Bjorn Andersson,
linux-remoteproc, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Geert Uytterhoeven, Magnus Damm, Patrice Chotard,
Maxime Coquelin, Alexandre Torgue, Tanmay Shah, imx,
linux-arm-kernel, linux-kernel, linux-renesas-soc, linux-stm32
In-Reply-To: <ah2aVdlsLqy9aeHP@p14s>
On Mon, Jun 01, 2026 at 08:42:29AM -0600, Mathieu Poirier wrote:
>Good morning,
>
>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 +++++-------------------
>
>This set looks good to me. I am fine with the checkpatch warning on the macro -
>given the redundancy it avoids, I think it can be tolerated.
>
>Wolfram has already indicated he wanted to test these changes - Arnaud, Daniel
>and Peng, please do the same for your platforms.
Tested-by: Peng Fan <peng.fan@nxp.com> #i.MX8MP-EVK
>
>Thanks,
>Mathieu
>
>> 7 files changed, 73 insertions(+), 227 deletions(-)
>>
>> --
>> 2.34.1
^ permalink raw reply
* [STATUS] arm64/for-kernelci - ffe7bef3786c1c2a725f80c2025010644452fd1c
From: KernelCI bot @ 2026-06-06 2:30 UTC (permalink / raw)
To: kernelci-results; +Cc: will, linux-arm-kernel
Hello,
Status summary for arm64/for-kernelci
Dashboard:
https://d.kernelci.org/c/arm64/for-kernelci/ffe7bef3786c1c2a725f80c2025010644452fd1c/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
branch: for-kernelci
commit hash: ffe7bef3786c1c2a725f80c2025010644452fd1c
origin: maestro
test start time: 2026-06-05 17:03:21.134000+00:00
Builds: 8 ✅ 0 ❌ 0 ⚠️
Boots: 12 ✅ 0 ❌ 1 ⚠️
Tests: 10548 ✅ 84 ❌ 93 ⚠️
### POSSIBLE REGRESSIONS
No possible regressions observed.
### FIXED REGRESSIONS
No fixed regressions observed.
### UNSTABLE TESTS
Hardware: bcm2711-rpi-4-b
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a230ad146e71b76f9f6eb2e
history: > ⚠️ > ✅ > ✅ > ✅ > ⚠️
Sent every day if there were changes in the past 24 hours.
Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci@lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
^ permalink raw reply
* Re: [PATCH] net: stmmac: xgmac: report L3/L4 filter match count in ethtool stats
From: patchwork-bot+netdevbpf @ 2026-06-06 2:20 UTC (permalink / raw)
To: Nazle, Asmade, Muhammad Nazim Amirul
Cc: netdev, andrew+netdev, davem, edumazet, kuba, pabeni,
mcoquelin.stm32, alexandre.torgue, rmk+kernel, maxime.chevallier,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260604083037.24407-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 4 Jun 2026 01:30:37 -0700 you wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>
> Read the L3FM and L4FM bits from the RX descriptor status word (RDES2)
> and increment the corresponding ethtool statistics counters. This allows
> users to observe L3/L4 filter hit rates via ethtool -S.
>
> Signed-off-by: Rohan G Thomas <rohan.g.thomas@altera.com>
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>
> [...]
Here is the summary with links:
- net: stmmac: xgmac: report L3/L4 filter match count in ethtool stats
https://git.kernel.org/netdev/net-next/c/903db046d557
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 net-next v3] net: microchip: sparx5: clean up PSFP resources on flower setup failure
From: patchwork-bot+netdevbpf @ 2026-06-06 2:10 UTC (permalink / raw)
To: Haoxiang Li
Cc: andrew+netdev, davem, kuba, pabeni, Steen.Hegelund, daniel.machon,
UNGLinuxDriver, kees, netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <20260603061716.747282-1-lihaoxiang@isrc.iscas.ac.cn>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 3 Jun 2026 14:17:16 +0800 you wrote:
> sparx5_tc_flower_psfp_setup() allocates PSFP stream gate, flow meter and
> stream filter resources before adding VCAP actions. If a later step
> fails, the resources allocated earlier in the function are not unwound.
>
> Add error paths to release the stream filter, flow meter and stream gate
> when setup fails after they have been acquired.
>
> [...]
Here is the summary with links:
- [net-next,v3] net: microchip: sparx5: clean up PSFP resources on flower setup failure
https://git.kernel.org/netdev/net-next/c/46e503673387
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 net-next v9 0/6] net: airoha: Support multiple net_devices connected to the same GDM port
From: patchwork-bot+netdevbpf @ 2026-06-06 2:10 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, ansuelsmth, benjamin.larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree, xuegang.lu, madhur.agrawal
In-Reply-To: <20260603-airoha-eth-multi-serdes-v9-0-5d476bc2f426@kernel.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 03 Jun 2026 08:00:14 +0200 you wrote:
> EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g.
> Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw arbiter that
> manages the traffic in a TDM manner. As a result multiple net_devices can
> connect to the same GDM{3,4} port and there is a theoretical "1:n"
> relation between GDM ports and net_devices.
>
> ┌─────────────────────────────────┐
> │ │ ┌──────┐
> │ P1 GDM1 ├────►MT7530│
> │ │ └──────┘
> │ │ ETH0 (DSA conduit)
> │ │
> │ PSE/FE │
> │ │
> │ │
> │ │ ┌─────┐
> │ P0 CDM1 ├────►QDMA0│
> │ P4 P9 GDM4 │ └─────┘
> └──┬─────────────────────────┬────┘
> │ │
> ┌──▼──┐ ┌────▼────┐
> │ PPE │ │ ARB │
> └─────┘ └─┬─────┬─┘
> │ │
> ┌──▼──┐┌─▼───┐
> │ ETH ││ USB │
> └─────┘└─────┘
> ETH1 ETH2
>
> [...]
Here is the summary with links:
- [net-next,v9,1/6] dt-bindings: net: airoha: Add GDM port ethernet child node
https://git.kernel.org/netdev/net-next/c/a4597204b681
- [net-next,v9,2/6] net: airoha: Remove private net_device pointer in airoha_gdm_dev struct
https://git.kernel.org/netdev/net-next/c/4408f5206809
- [net-next,v9,3/6] net: airoha: Support multiple net_devices for a single FE GDM port
https://git.kernel.org/netdev/net-next/c/a9c2ca61fec7
- [net-next,v9,4/6] net: airoha: Do not stop GDM port if it is shared
https://git.kernel.org/netdev/net-next/c/99b9d095d71e
- [net-next,v9,5/6] net: airoha: Introduce WAN device flag
https://git.kernel.org/netdev/net-next/c/7758cb462ff7
- [net-next,v9,6/6] net: airoha: Support multiple LAN/WAN interfaces for hw MAC address configuration
https://git.kernel.org/netdev/net-next/c/ef2aee987174
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH 11/11] pinctrl: airoha: an7583: remove undefined groups from pcm_spi pin function
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
pcm_spi_int, pcm_spi_cs2, pcm_spi_cs3, pcm_spi_cs4 pin groups are not
defined, so pcm_spi function can't be applied to these groups.
Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
---
drivers/pinctrl/mediatek/pinctrl-airoha.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-airoha.c b/drivers/pinctrl/mediatek/pinctrl-airoha.c
index b73ab60d0065..bf5ebb31e635 100644
--- a/drivers/pinctrl/mediatek/pinctrl-airoha.c
+++ b/drivers/pinctrl/mediatek/pinctrl-airoha.c
@@ -877,10 +877,8 @@ static const char *const pcm_spi_groups[] = { "pcm_spi", "pcm_spi_int",
"pcm_spi_cs2_p156",
"pcm_spi_cs2_p128",
"pcm_spi_cs3", "pcm_spi_cs4" };
-static const char *const an7583_pcm_spi_groups[] = { "pcm_spi", "pcm_spi_int",
- "pcm_spi_rst", "pcm_spi_cs1",
- "pcm_spi_cs2", "pcm_spi_cs3",
- "pcm_spi_cs4" };
+static const char *const an7583_pcm_spi_groups[] = { "pcm_spi",
+ "pcm_spi_rst", "pcm_spi_cs1" };
static const char *const i2s_groups[] = { "i2s" };
static const char *const emmc_groups[] = { "emmc" };
static const char *const pnand_groups[] = { "pnand" };
--
2.53.0
^ permalink raw reply related
* [PATCH 10/11] pinctrl: airoha: an7583: fix phy1_led1 pin function
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
phy1_led1 pin function wrongly refers to gpio1 instead of gpio11.
Fix it.
Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
---
drivers/pinctrl/mediatek/pinctrl-airoha.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-airoha.c b/drivers/pinctrl/mediatek/pinctrl-airoha.c
index e66b608c4803..b73ab60d0065 100644
--- a/drivers/pinctrl/mediatek/pinctrl-airoha.c
+++ b/drivers/pinctrl/mediatek/pinctrl-airoha.c
@@ -1754,7 +1754,7 @@ static const struct airoha_pinctrl_func_group an7583_phy1_led1_func_group[] = {
LAN1_LED_MAPPING_MASK, LAN1_PHY_LED_MAP(0)),
AIROHA_PINCTRL_PHY_LED1("gpio10", GPIO_LAN2_LED1_MODE_MASK,
LAN2_LED_MAPPING_MASK, LAN2_PHY_LED_MAP(0)),
- AIROHA_PINCTRL_PHY_LED1("gpio1", GPIO_LAN3_LED1_MODE_MASK,
+ AIROHA_PINCTRL_PHY_LED1("gpio11", GPIO_LAN3_LED1_MODE_MASK,
LAN3_LED_MAPPING_MASK, LAN3_PHY_LED_MAP(0)),
};
--
2.53.0
^ permalink raw reply related
* [PATCH 09/11] pinctrl: airoha: an7583: add missed gpio22 pin group
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
gpio22 pin group is missed, fix it.
Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
---
drivers/pinctrl/mediatek/pinctrl-airoha.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pinctrl/mediatek/pinctrl-airoha.c b/drivers/pinctrl/mediatek/pinctrl-airoha.c
index 9dce3ed6de17..e66b608c4803 100644
--- a/drivers/pinctrl/mediatek/pinctrl-airoha.c
+++ b/drivers/pinctrl/mediatek/pinctrl-airoha.c
@@ -749,6 +749,7 @@ static const int an7583_gpio18_pins[] = { 20 };
static const int an7583_gpio19_pins[] = { 21 };
static const int an7583_gpio20_pins[] = { 22 };
static const int an7583_gpio21_pins[] = { 23 };
+static const int an7583_gpio22_pins[] = { 24 };
static const int an7583_gpio23_pins[] = { 25 };
static const int an7583_gpio24_pins[] = { 26 };
static const int an7583_gpio25_pins[] = { 27 };
@@ -828,6 +829,7 @@ static const struct pingroup an7583_pinctrl_groups[] = {
PINCTRL_PIN_GROUP("gpio19", an7583_gpio19),
PINCTRL_PIN_GROUP("gpio20", an7583_gpio20),
PINCTRL_PIN_GROUP("gpio21", an7583_gpio21),
+ PINCTRL_PIN_GROUP("gpio22", an7583_gpio22),
PINCTRL_PIN_GROUP("gpio23", an7583_gpio23),
PINCTRL_PIN_GROUP("gpio24", an7583_gpio24),
PINCTRL_PIN_GROUP("gpio25", an7583_gpio25),
--
2.53.0
^ permalink raw reply related
* [PATCH 06/11] pinctrl: airoha: an7583: fix incorrect led mapping in phy4_led1 pin function
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
phy4_led1 pin function maps led incorrectly. It uses the same map as
phy3_led1. PHY{X} should map to LAN{N}_PHY_LED_MAP(X-1).
Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
---
drivers/pinctrl/mediatek/pinctrl-airoha.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-airoha.c b/drivers/pinctrl/mediatek/pinctrl-airoha.c
index 9497f5110f61..9be759f08b18 100644
--- a/drivers/pinctrl/mediatek/pinctrl-airoha.c
+++ b/drivers/pinctrl/mediatek/pinctrl-airoha.c
@@ -1710,13 +1710,13 @@ static const struct airoha_pinctrl_func_group an7583_phy3_led1_func_group[] = {
static const struct airoha_pinctrl_func_group an7583_phy4_led1_func_group[] = {
AIROHA_PINCTRL_PHY_LED1("gpio8", GPIO_LAN0_LED1_MODE_MASK,
- LAN0_LED_MAPPING_MASK, LAN0_PHY_LED_MAP(2)),
+ LAN0_LED_MAPPING_MASK, LAN0_PHY_LED_MAP(3)),
AIROHA_PINCTRL_PHY_LED1("gpio9", GPIO_LAN1_LED1_MODE_MASK,
- LAN1_LED_MAPPING_MASK, LAN1_PHY_LED_MAP(2)),
+ LAN1_LED_MAPPING_MASK, LAN1_PHY_LED_MAP(3)),
AIROHA_PINCTRL_PHY_LED1("gpio10", GPIO_LAN2_LED1_MODE_MASK,
- LAN2_LED_MAPPING_MASK, LAN2_PHY_LED_MAP(2)),
+ LAN2_LED_MAPPING_MASK, LAN2_PHY_LED_MAP(3)),
AIROHA_PINCTRL_PHY_LED1("gpio11", GPIO_LAN3_LED1_MODE_MASK,
- LAN3_LED_MAPPING_MASK, LAN3_PHY_LED_MAP(2)),
+ LAN3_LED_MAPPING_MASK, LAN3_PHY_LED_MAP(3)),
};
static const struct airoha_pinctrl_func en7581_pinctrl_funcs[] = {
--
2.53.0
^ permalink raw reply related
* [PATCH 08/11] pinctrl: airoha: an7583: fix gpio21 pin group
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
gpio21 pin group refers to gpio22 pin, this is wrong.
Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
---
drivers/pinctrl/mediatek/pinctrl-airoha.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-airoha.c b/drivers/pinctrl/mediatek/pinctrl-airoha.c
index 15a541724349..9dce3ed6de17 100644
--- a/drivers/pinctrl/mediatek/pinctrl-airoha.c
+++ b/drivers/pinctrl/mediatek/pinctrl-airoha.c
@@ -748,7 +748,7 @@ static const int an7583_gpio17_pins[] = { 19 };
static const int an7583_gpio18_pins[] = { 20 };
static const int an7583_gpio19_pins[] = { 21 };
static const int an7583_gpio20_pins[] = { 22 };
-static const int an7583_gpio21_pins[] = { 24 };
+static const int an7583_gpio21_pins[] = { 23 };
static const int an7583_gpio23_pins[] = { 25 };
static const int an7583_gpio24_pins[] = { 26 };
static const int an7583_gpio25_pins[] = { 27 };
--
2.53.0
^ permalink raw reply related
* [PATCH 07/11] pinctrl: airoha: fix pwm pin function for an7581 and an7583
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
AN7581 have 47 valid GPIOs only (gpio0-gpio46), so gpio47 is a fiction.
AN7583 have 49 valid GPIOs (gpio0-gpio48), so gpio48 is missed
To fix an issue
* create AN7583 specific pwm pin function,
* remove gpio47 from AN7581 pwm pin function.
Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
---
drivers/pinctrl/mediatek/pinctrl-airoha.c | 74 ++++++++++++++++++++++-
1 file changed, 72 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-airoha.c b/drivers/pinctrl/mediatek/pinctrl-airoha.c
index 9be759f08b18..15a541724349 100644
--- a/drivers/pinctrl/mediatek/pinctrl-airoha.c
+++ b/drivers/pinctrl/mediatek/pinctrl-airoha.c
@@ -906,7 +906,30 @@ static const char *const pwm_groups[] = { "gpio0", "gpio1",
"gpio40", "gpio41",
"gpio42", "gpio43",
"gpio44", "gpio45",
- "gpio46", "gpio47" };
+ "gpio46" };
+static const char *const an7583_pwm_groups[] = { "gpio0", "gpio1",
+ "gpio2", "gpio3",
+ "gpio4", "gpio5",
+ "gpio6", "gpio7",
+ "gpio8", "gpio9",
+ "gpio10", "gpio11",
+ "gpio12", "gpio13",
+ "gpio14", "gpio15",
+ "gpio16", "gpio17",
+ "gpio18", "gpio19",
+ "gpio20", "gpio21",
+ "gpio22", "gpio23",
+ "gpio24", "gpio25",
+ "gpio26", "gpio27",
+ "gpio28", "gpio29",
+ "gpio30", "gpio31",
+ "gpio36", "gpio37",
+ "gpio38", "gpio39",
+ "gpio40", "gpio41",
+ "gpio42", "gpio43",
+ "gpio44", "gpio45",
+ "gpio46", "gpio47",
+ "gpio48" };
static const char *const phy1_led0_groups[] = { "gpio33", "gpio34",
"gpio35", "gpio42" };
static const char *const phy2_led0_groups[] = { "gpio33", "gpio34",
@@ -1504,7 +1527,54 @@ static const struct airoha_pinctrl_func_group pwm_func_group[] = {
AIROHA_PINCTRL_PWM_EXT("gpio44", GPIO44_FLASH_MODE_CFG),
AIROHA_PINCTRL_PWM_EXT("gpio45", GPIO45_FLASH_MODE_CFG),
AIROHA_PINCTRL_PWM_EXT("gpio46", GPIO46_FLASH_MODE_CFG),
+};
+
+static const struct airoha_pinctrl_func_group an7583_pwm_func_group[] = {
+ AIROHA_PINCTRL_PWM("gpio0", GPIO0_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio1", GPIO1_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio2", GPIO2_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio3", GPIO3_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio4", GPIO4_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio5", GPIO5_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio6", GPIO6_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio7", GPIO7_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio8", GPIO8_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio9", GPIO9_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio10", GPIO10_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio11", GPIO11_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio12", GPIO12_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio13", GPIO13_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio14", GPIO14_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM("gpio15", GPIO15_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio16", GPIO16_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio17", GPIO17_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio18", GPIO18_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio19", GPIO19_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio20", GPIO20_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio21", GPIO21_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio22", GPIO22_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio23", GPIO23_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio24", GPIO24_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio25", GPIO25_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio26", GPIO26_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio27", GPIO27_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio28", GPIO28_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio29", GPIO29_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio30", GPIO30_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio31", GPIO31_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio36", GPIO36_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio37", GPIO37_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio38", GPIO38_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio39", GPIO39_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio40", GPIO40_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio41", GPIO41_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio42", GPIO42_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio43", GPIO43_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio44", GPIO44_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio45", GPIO45_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio46", GPIO46_FLASH_MODE_CFG),
AIROHA_PINCTRL_PWM_EXT("gpio47", GPIO47_FLASH_MODE_CFG),
+ AIROHA_PINCTRL_PWM_EXT("gpio48", GPIO48_FLASH_MODE_CFG),
};
#define AIROHA_PINCTRL_PHY_LED0(gpio, mux_val, map_mask, map_val) \
@@ -1759,7 +1829,7 @@ static const struct airoha_pinctrl_func an7583_pinctrl_funcs[] = {
PINCTRL_FUNC_DESC("emmc", emmc),
PINCTRL_FUNC_DESC("pnand", pnand),
PINCTRL_FUNC_DESC("pcie_reset", an7583_pcie_reset),
- PINCTRL_FUNC_DESC("pwm", pwm),
+ PINCTRL_FUNC_DESC("pwm", an7583_pwm),
PINCTRL_FUNC_DESC("phy1_led0", an7583_phy1_led0),
PINCTRL_FUNC_DESC("phy2_led0", an7583_phy2_led0),
PINCTRL_FUNC_DESC("phy3_led0", an7583_phy3_led0),
--
2.53.0
^ permalink raw reply related
* [PATCH 05/11] pinctrl: airoha: an7581: fix incorrect led mapping in phy4_led1 pin function
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
phy4_led1 pin function maps led incorrectly. It uses the same map as
phy3_led1. PHY{X} should map to LAN{N}_PHY_LED_MAP(X-1).
Fixes: 579839c9548c ("pinctrl: airoha: convert PHY LED GPIO to macro")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
---
drivers/pinctrl/mediatek/pinctrl-airoha.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-airoha.c b/drivers/pinctrl/mediatek/pinctrl-airoha.c
index 34eef79d058f..9497f5110f61 100644
--- a/drivers/pinctrl/mediatek/pinctrl-airoha.c
+++ b/drivers/pinctrl/mediatek/pinctrl-airoha.c
@@ -1622,13 +1622,13 @@ static const struct airoha_pinctrl_func_group phy3_led1_func_group[] = {
static const struct airoha_pinctrl_func_group phy4_led1_func_group[] = {
AIROHA_PINCTRL_PHY_LED1("gpio43", GPIO_LAN0_LED1_MODE_MASK,
- LAN0_LED_MAPPING_MASK, LAN0_PHY_LED_MAP(2)),
+ LAN0_LED_MAPPING_MASK, LAN0_PHY_LED_MAP(3)),
AIROHA_PINCTRL_PHY_LED1("gpio44", GPIO_LAN1_LED1_MODE_MASK,
- LAN1_LED_MAPPING_MASK, LAN1_PHY_LED_MAP(2)),
+ LAN1_LED_MAPPING_MASK, LAN1_PHY_LED_MAP(3)),
AIROHA_PINCTRL_PHY_LED1("gpio45", GPIO_LAN2_LED1_MODE_MASK,
- LAN2_LED_MAPPING_MASK, LAN2_PHY_LED_MAP(2)),
+ LAN2_LED_MAPPING_MASK, LAN2_PHY_LED_MAP(3)),
AIROHA_PINCTRL_PHY_LED1("gpio46", GPIO_LAN3_LED1_MODE_MASK,
- LAN3_LED_MAPPING_MASK, LAN3_PHY_LED_MAP(2)),
+ LAN3_LED_MAPPING_MASK, LAN3_PHY_LED_MAP(3)),
};
static const struct airoha_pinctrl_func_group an7583_phy1_led0_func_group[] = {
--
2.53.0
^ permalink raw reply related
* [PATCH 04/11] pinctrl: airoha: an7583: fix misprint in gpio19 pinconf
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
Pin 21 (gpio19) duplicate pinconf settings of pin 20. Fix it using
a proper bit number in the configuration register.
Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
---
drivers/pinctrl/mediatek/pinctrl-airoha.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-airoha.c b/drivers/pinctrl/mediatek/pinctrl-airoha.c
index 14b235727736..34eef79d058f 100644
--- a/drivers/pinctrl/mediatek/pinctrl-airoha.c
+++ b/drivers/pinctrl/mediatek/pinctrl-airoha.c
@@ -1851,7 +1851,7 @@ static const struct airoha_pinctrl_conf an7583_pinctrl_pullup_conf[] = {
PINCTRL_CONF_DESC(18, REG_GPIO_L_PU, BIT(16)),
PINCTRL_CONF_DESC(19, REG_GPIO_L_PU, BIT(17)),
PINCTRL_CONF_DESC(20, REG_GPIO_L_PU, BIT(18)),
- PINCTRL_CONF_DESC(21, REG_GPIO_L_PU, BIT(18)),
+ PINCTRL_CONF_DESC(21, REG_GPIO_L_PU, BIT(19)),
PINCTRL_CONF_DESC(22, REG_GPIO_L_PU, BIT(20)),
PINCTRL_CONF_DESC(23, REG_GPIO_L_PU, BIT(21)),
PINCTRL_CONF_DESC(24, REG_GPIO_L_PU, BIT(22)),
@@ -1968,7 +1968,7 @@ static const struct airoha_pinctrl_conf an7583_pinctrl_pulldown_conf[] = {
PINCTRL_CONF_DESC(18, REG_GPIO_L_PD, BIT(16)),
PINCTRL_CONF_DESC(19, REG_GPIO_L_PD, BIT(17)),
PINCTRL_CONF_DESC(20, REG_GPIO_L_PD, BIT(18)),
- PINCTRL_CONF_DESC(21, REG_GPIO_L_PD, BIT(18)),
+ PINCTRL_CONF_DESC(21, REG_GPIO_L_PD, BIT(19)),
PINCTRL_CONF_DESC(22, REG_GPIO_L_PD, BIT(20)),
PINCTRL_CONF_DESC(23, REG_GPIO_L_PD, BIT(21)),
PINCTRL_CONF_DESC(24, REG_GPIO_L_PD, BIT(22)),
@@ -2085,7 +2085,7 @@ static const struct airoha_pinctrl_conf an7583_pinctrl_drive_e2_conf[] = {
PINCTRL_CONF_DESC(18, REG_GPIO_L_E2, BIT(16)),
PINCTRL_CONF_DESC(19, REG_GPIO_L_E2, BIT(17)),
PINCTRL_CONF_DESC(20, REG_GPIO_L_E2, BIT(18)),
- PINCTRL_CONF_DESC(21, REG_GPIO_L_E2, BIT(18)),
+ PINCTRL_CONF_DESC(21, REG_GPIO_L_E2, BIT(19)),
PINCTRL_CONF_DESC(22, REG_GPIO_L_E2, BIT(20)),
PINCTRL_CONF_DESC(23, REG_GPIO_L_E2, BIT(21)),
PINCTRL_CONF_DESC(24, REG_GPIO_L_E2, BIT(22)),
@@ -2202,7 +2202,7 @@ static const struct airoha_pinctrl_conf an7583_pinctrl_drive_e4_conf[] = {
PINCTRL_CONF_DESC(18, REG_GPIO_L_E4, BIT(16)),
PINCTRL_CONF_DESC(19, REG_GPIO_L_E4, BIT(17)),
PINCTRL_CONF_DESC(20, REG_GPIO_L_E4, BIT(18)),
- PINCTRL_CONF_DESC(21, REG_GPIO_L_E4, BIT(18)),
+ PINCTRL_CONF_DESC(21, REG_GPIO_L_E4, BIT(19)),
PINCTRL_CONF_DESC(22, REG_GPIO_L_E4, BIT(20)),
PINCTRL_CONF_DESC(23, REG_GPIO_L_E4, BIT(21)),
PINCTRL_CONF_DESC(24, REG_GPIO_L_E4, BIT(22)),
--
2.53.0
^ permalink raw reply related
* [PATCH 03/11] pinctrl: airoha: an7581: fix misprint in gpio19 pinconf
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
Pin 32 (gpio19) duplicate pinconf settings of pin 31. Fix it using
a proper bit number in the configuration register.
Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
---
drivers/pinctrl/mediatek/pinctrl-airoha.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-airoha.c b/drivers/pinctrl/mediatek/pinctrl-airoha.c
index c0aed1b60792..14b235727736 100644
--- a/drivers/pinctrl/mediatek/pinctrl-airoha.c
+++ b/drivers/pinctrl/mediatek/pinctrl-airoha.c
@@ -1798,7 +1798,7 @@ static const struct airoha_pinctrl_conf en7581_pinctrl_pullup_conf[] = {
PINCTRL_CONF_DESC(29, REG_GPIO_L_PU, BIT(16)),
PINCTRL_CONF_DESC(30, REG_GPIO_L_PU, BIT(17)),
PINCTRL_CONF_DESC(31, REG_GPIO_L_PU, BIT(18)),
- PINCTRL_CONF_DESC(32, REG_GPIO_L_PU, BIT(18)),
+ PINCTRL_CONF_DESC(32, REG_GPIO_L_PU, BIT(19)),
PINCTRL_CONF_DESC(33, REG_GPIO_L_PU, BIT(20)),
PINCTRL_CONF_DESC(34, REG_GPIO_L_PU, BIT(21)),
PINCTRL_CONF_DESC(35, REG_GPIO_L_PU, BIT(22)),
@@ -1915,7 +1915,7 @@ static const struct airoha_pinctrl_conf en7581_pinctrl_pulldown_conf[] = {
PINCTRL_CONF_DESC(29, REG_GPIO_L_PD, BIT(16)),
PINCTRL_CONF_DESC(30, REG_GPIO_L_PD, BIT(17)),
PINCTRL_CONF_DESC(31, REG_GPIO_L_PD, BIT(18)),
- PINCTRL_CONF_DESC(32, REG_GPIO_L_PD, BIT(18)),
+ PINCTRL_CONF_DESC(32, REG_GPIO_L_PD, BIT(19)),
PINCTRL_CONF_DESC(33, REG_GPIO_L_PD, BIT(20)),
PINCTRL_CONF_DESC(34, REG_GPIO_L_PD, BIT(21)),
PINCTRL_CONF_DESC(35, REG_GPIO_L_PD, BIT(22)),
@@ -2032,7 +2032,7 @@ static const struct airoha_pinctrl_conf en7581_pinctrl_drive_e2_conf[] = {
PINCTRL_CONF_DESC(29, REG_GPIO_L_E2, BIT(16)),
PINCTRL_CONF_DESC(30, REG_GPIO_L_E2, BIT(17)),
PINCTRL_CONF_DESC(31, REG_GPIO_L_E2, BIT(18)),
- PINCTRL_CONF_DESC(32, REG_GPIO_L_E2, BIT(18)),
+ PINCTRL_CONF_DESC(32, REG_GPIO_L_E2, BIT(19)),
PINCTRL_CONF_DESC(33, REG_GPIO_L_E2, BIT(20)),
PINCTRL_CONF_DESC(34, REG_GPIO_L_E2, BIT(21)),
PINCTRL_CONF_DESC(35, REG_GPIO_L_E2, BIT(22)),
@@ -2149,7 +2149,7 @@ static const struct airoha_pinctrl_conf en7581_pinctrl_drive_e4_conf[] = {
PINCTRL_CONF_DESC(29, REG_GPIO_L_E4, BIT(16)),
PINCTRL_CONF_DESC(30, REG_GPIO_L_E4, BIT(17)),
PINCTRL_CONF_DESC(31, REG_GPIO_L_E4, BIT(18)),
- PINCTRL_CONF_DESC(32, REG_GPIO_L_E4, BIT(18)),
+ PINCTRL_CONF_DESC(32, REG_GPIO_L_E4, BIT(19)),
PINCTRL_CONF_DESC(33, REG_GPIO_L_E4, BIT(20)),
PINCTRL_CONF_DESC(34, REG_GPIO_L_E4, BIT(21)),
PINCTRL_CONF_DESC(35, REG_GPIO_L_E4, BIT(22)),
--
2.53.0
^ permalink raw reply related
* [PATCH 02/11] pinctrl: airoha: an7583: add missed gpio32 pin group
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
gpio32 pin group is missed for an7583 SoC. This patch add it.
Fixes: 3ffeb17a9a27 ("pinctrl: airoha: add support for Airoha AN7583 PINs")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
---
drivers/pinctrl/mediatek/pinctrl-airoha.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pinctrl/mediatek/pinctrl-airoha.c b/drivers/pinctrl/mediatek/pinctrl-airoha.c
index 805166223228..c0aed1b60792 100644
--- a/drivers/pinctrl/mediatek/pinctrl-airoha.c
+++ b/drivers/pinctrl/mediatek/pinctrl-airoha.c
@@ -758,6 +758,7 @@ static const int an7583_gpio28_pins[] = { 30 };
static const int an7583_gpio29_pins[] = { 31 };
static const int an7583_gpio30_pins[] = { 32 };
static const int an7583_gpio31_pins[] = { 33 };
+static const int an7583_gpio32_pins[] = { 34 };
static const int an7583_gpio33_pins[] = { 35 };
static const int an7583_gpio34_pins[] = { 36 };
static const int an7583_gpio35_pins[] = { 37 };
@@ -836,6 +837,7 @@ static const struct pingroup an7583_pinctrl_groups[] = {
PINCTRL_PIN_GROUP("gpio29", an7583_gpio29),
PINCTRL_PIN_GROUP("gpio30", an7583_gpio30),
PINCTRL_PIN_GROUP("gpio31", an7583_gpio31),
+ PINCTRL_PIN_GROUP("gpio32", an7583_gpio32),
PINCTRL_PIN_GROUP("gpio33", an7583_gpio33),
PINCTRL_PIN_GROUP("gpio34", an7583_gpio34),
PINCTRL_PIN_GROUP("gpio35", an7583_gpio35),
--
2.53.0
^ permalink raw reply related
* [PATCH 00/11] pinctrl: airoha: small fixes
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
This is a set of small fixes for Airoha pinctrl driver.
Mikhail Kshevetskiy (11):
pinctrl: airoha: an7581: add missed gpio32 pin group
pinctrl: airoha: an7583: add missed gpio32 pin group
pinctrl: airoha: an7581: fix misprint in gpio19 pinconf
pinctrl: airoha: an7583: fix misprint in gpio19 pinconf
pinctrl: airoha: an7581: fix incorrect led mapping in phy4_led1 pin
function
pinctrl: airoha: an7583: fix incorrect led mapping in phy4_led1 pin
function
pinctrl: airoha: fix pwm pin function for an7581 and an7583
pinctrl: airoha: an7583: fix gpio21 pin group
pinctrl: airoha: an7583: add missed gpio22 pin group
pinctrl: airoha: an7583: fix phy1_led1 pin function
pinctrl: airoha: an7583: remove undefined groups from pcm_spi pin
function
drivers/pinctrl/mediatek/pinctrl-airoha.c | 122 +++++++++++++++++-----
1 file changed, 98 insertions(+), 24 deletions(-)
--
2.53.0
^ permalink raw reply
* [PATCH 01/11] pinctrl: airoha: an7581: add missed gpio32 pin group
From: Mikhail Kshevetskiy @ 2026-06-06 2:03 UTC (permalink / raw)
To: Lorenzo Bianconi, Sean Wang, Linus Walleij, Matthias Brugger,
AngeloGioacchino Del Regno, Benjamin Larsson, Christian Marangi,
linux-mediatek, linux-gpio, linux-kernel, linux-arm-kernel,
Markus Gothe, Matheus Sampaio Queiroga
Cc: Mikhail Kshevetskiy
In-Reply-To: <20260606020342.1256509-1-mikhail.kshevetskiy@iopsys.eu>
gpio32 pin group is missed for an7581 SoC. This patch add it.
Fixes: 1c8ace2d0725 ("pinctrl: airoha: Add support for EN7581 SoC")
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
---
drivers/pinctrl/mediatek/pinctrl-airoha.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pinctrl/mediatek/pinctrl-airoha.c b/drivers/pinctrl/mediatek/pinctrl-airoha.c
index 995ba6175c95..805166223228 100644
--- a/drivers/pinctrl/mediatek/pinctrl-airoha.c
+++ b/drivers/pinctrl/mediatek/pinctrl-airoha.c
@@ -539,6 +539,7 @@ static const int en7581_gpio28_pins[] = { 41 };
static const int en7581_gpio29_pins[] = { 42 };
static const int en7581_gpio30_pins[] = { 43 };
static const int en7581_gpio31_pins[] = { 44 };
+static const int en7581_gpio32_pins[] = { 45 };
static const int en7581_gpio33_pins[] = { 46 };
static const int en7581_gpio34_pins[] = { 47 };
static const int en7581_gpio35_pins[] = { 48 };
@@ -623,6 +624,7 @@ static const struct pingroup en7581_pinctrl_groups[] = {
PINCTRL_PIN_GROUP("gpio29", en7581_gpio29),
PINCTRL_PIN_GROUP("gpio30", en7581_gpio30),
PINCTRL_PIN_GROUP("gpio31", en7581_gpio31),
+ PINCTRL_PIN_GROUP("gpio32", en7581_gpio32),
PINCTRL_PIN_GROUP("gpio33", en7581_gpio33),
PINCTRL_PIN_GROUP("gpio34", en7581_gpio34),
PINCTRL_PIN_GROUP("gpio35", en7581_gpio35),
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next] net: stmmac: dwmac4: Report DCB feature capability
From: patchwork-bot+netdevbpf @ 2026-06-06 1:40 UTC (permalink / raw)
To: Ovidiu Panait
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, mcoquelin.stm32,
alexandre.torgue, rmk+kernel, maxime.chevallier, o.rempel, netdev,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260603173644.24371-1-ovidiu.panait.rb@renesas.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 3 Jun 2026 17:36:43 +0000 you wrote:
> Bit 16 of the MAC HW Feature1 register reports the DCB (Data Centre
> Bridging) feature. Read it so that dma_cap.dcben and the debugfs
> report it accurately. Right now it is always reported as being disabled.
>
> Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 1 +
> drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c | 1 +
> 2 files changed, 2 insertions(+)
Here is the summary with links:
- [net-next] net: stmmac: dwmac4: Report DCB feature capability
https://git.kernel.org/netdev/net-next/c/3a58a1b8d505
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 net] net: airoha: Add NULL check for of_reserved_mem_lookup() in airoha_qdma_init_hfwd_queues()
From: patchwork-bot+netdevbpf @ 2026-06-06 1:30 UTC (permalink / raw)
To: ZhaoJinming
Cc: lorenzo, andrew+netdev, davem, edumazet, kuba, pabeni, horms,
linux-arm-kernel, linux-mediatek, netdev, linux-kernel, stable
In-Reply-To: <20260604070352.2603077-1-zhaojinming@uniontech.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 4 Jun 2026 15:03:52 +0800 you wrote:
> of_reserved_mem_lookup() may return NULL if the reserved memory region
> referenced by the "memory-region" phandle is not found in the reserved
> memory table (e.g. due to a misconfigured DTS or a removed
> memory-region node). The current code dereferences the returned
> pointer without checking for NULL, leading to a kernel NULL pointer
> dereference at the following lines:
>
> [...]
Here is the summary with links:
- [net] net: airoha: Add NULL check for of_reserved_mem_lookup() in airoha_qdma_init_hfwd_queues()
https://git.kernel.org/netdev/net/c/f9f25118faa4
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 v6 01/20] s390: Expose protected virtualization through cc_platform_has()
From: JAEHOON KIM @ 2026-06-06 0:34 UTC (permalink / raw)
To: Aneesh Kumar K.V (Arm), iommu, linux-arm-kernel, linux-kernel,
linux-coco
Cc: Robin Murphy, Marek Szyprowski, Will Deacon, Marc Zyngier,
Steven Price, Suzuki K Poulose, Catalin Marinas, Jiri Pirko,
Jason Gunthorpe, Mostafa Saleh, Petr Tesarik,
Alexey Kardashevskiy, Dan Williams, Xu Yilun, linuxppc-dev,
linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86, Halil Pasic,
Matthew Rosato
In-Reply-To: <20260604083959.1265923-2-aneesh.kumar@kernel.org>
On 6/4/2026 3:39 AM, Aneesh Kumar K.V (Arm) wrote:
> Protected virtualization guests use memory encryption, so advertise that to
> the rest of the kernel through cc_platform_has(CC_ATTR_MEM_ENCRYPT).
>
> s390 already forces DMA mappings to be unencrypted for protected
> virtualization guests through force_dma_unencrypted(). Add
> ARCH_HAS_CC_PLATFORM and provide the matching cc_platform_has()
> implementation
>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
Tested-by: Jaehoon Kim <jhkim@linux.ibm.com>
Tested on s390 PV guest with swiotlb_dynamic configuration. SWIOTLB
bounce buffer allocation and dynamic pool management work correctly.
Also concurrent I/O stress completed successfully.
Thanks,
Jaehoon.
> ---
> Cc: Halil Pasic <pasic@linux.ibm.com>
> Cc: Matthew Rosato <mjrosato@linux.ibm.com>
> Cc: Jaehoon Kim <jhkim@linux.ibm.com>
> ---
> arch/s390/Kconfig | 1 +
> arch/s390/mm/init.c | 14 ++++++++++++++
> 2 files changed, 15 insertions(+)
>
> diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
> index ecbcbb781e40..9b5e6029e043 100644
> --- a/arch/s390/Kconfig
> +++ b/arch/s390/Kconfig
> @@ -87,6 +87,7 @@ config S390
> select ARCH_ENABLE_SPLIT_PMD_PTLOCK if PGTABLE_LEVELS > 2
> select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE
> select ARCH_HAS_CC_CAN_LINK
> + select ARCH_HAS_CC_PLATFORM
> select ARCH_HAS_CPU_FINALIZE_INIT
> select ARCH_HAS_CURRENT_STACK_POINTER
> select ARCH_HAS_DEBUG_VIRTUAL
> diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
> index 1f72efc2a579..ad3c6d92b801 100644
> --- a/arch/s390/mm/init.c
> +++ b/arch/s390/mm/init.c
> @@ -50,6 +50,7 @@
> #include <linux/virtio_anchor.h>
> #include <linux/virtio_config.h>
> #include <linux/execmem.h>
> +#include <linux/cc_platform.h>
>
> pgd_t swapper_pg_dir[PTRS_PER_PGD] __section(".bss..swapper_pg_dir");
> pgd_t invalid_pg_dir[PTRS_PER_PGD] __section(".bss..invalid_pg_dir");
> @@ -140,6 +141,19 @@ bool force_dma_unencrypted(struct device *dev)
> return is_prot_virt_guest();
> }
>
> +
> +bool cc_platform_has(enum cc_attr attr)
> +{
> + switch (attr) {
> + case CC_ATTR_MEM_ENCRYPT:
> + return is_prot_virt_guest();
> +
> + default:
> + return false;
> + }
> +}
> +EXPORT_SYMBOL_GPL(cc_platform_has);
> +
> /* protected virtualization */
> static void __init pv_init(void)
> {
^ permalink raw reply
* Re: [PATCH bpf-next v2 4/8] bpf, x86: refactor BPF_ST management in do_jit
From: Alexei Starovoitov @ 2026-06-05 23:22 UTC (permalink / raw)
To: Alexis Lothoré (eBPF Foundation), Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Martin KaFai Lau,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Song Liu,
Yonghong Song, Jiri Olsa, John Fastabend, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Shuah Khan, Maxime Coquelin, Alexandre Torgue, Ihor Solodrai
Cc: ebpf, Bastien Curutchet, Thomas Petazzoni, bpf, linux-kernel,
linux-kselftest, linux-stm32, linux-arm-kernel
In-Reply-To: <20260604-kasan-v2-4-c066e627fda8@bootlin.com>
On Thu Jun 4, 2026 at 1:22 PM PDT, Alexis Lothoré (eBPF Foundation) wrote:
> In order to prepare for KASAN checks insertion before every
> memory-related load or store, group all BPF_ST instructions that indeed
> access memory in a single block of fall-through cases to allow
> instrumenting those in one call, rather than having to instrument all
> cases individually.
>
> Signed-off-by: Alexis Lothoré (eBPF Foundation) <alexis.lothore@bootlin.com>
> ---
> arch/x86/net/bpf_jit_comp.c | 53 ++++++++++++++++++++++++++-------------------
> 1 file changed, 31 insertions(+), 22 deletions(-)
>
> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> index 0981791014eb..943a0f315cf2 100644
> --- a/arch/x86/net/bpf_jit_comp.c
> +++ b/arch/x86/net/bpf_jit_comp.c
> @@ -2300,41 +2300,50 @@ static int do_jit(struct bpf_verifier_env *env, struct bpf_prog *bpf_prog, int *
> EMIT_LFENCE();
> break;
>
> - /* ST: *(u8*)(dst_reg + off) = imm */
> case BPF_ST | BPF_MEM | BPF_B:
> - if (is_ereg(dst_reg))
> - EMIT2(0x41, 0xC6);
> - else
> - EMIT1(0xC6);
> - goto st;
> case BPF_ST | BPF_MEM | BPF_H:
> - if (is_ereg(dst_reg))
> - EMIT3(0x66, 0x41, 0xC7);
> - else
> - EMIT2(0x66, 0xC7);
> - goto st;
> case BPF_ST | BPF_MEM | BPF_W:
> - if (is_ereg(dst_reg))
> - EMIT2(0x41, 0xC7);
> - else
> - EMIT1(0xC7);
> - goto st;
> case BPF_ST | BPF_MEM | BPF_DW:
> - if (dst_reg == BPF_REG_PARAMS && insn->off == -8) {
> - /* Arg 6: store immediate in r9 register */
> - emit_mov_imm64(&prog, X86_REG_R9, imm32 >> 31, (u32)imm32);
> + switch (BPF_SIZE(insn->code)) {
> + case BPF_B:
> + if (is_ereg(dst_reg))
> + EMIT2(0x41, 0xC6);
> + else
> + EMIT1(0xC6);
> + break;
> + case BPF_H:
> + if (is_ereg(dst_reg))
> + EMIT3(0x66, 0x41, 0xC7);
> + else
> + EMIT2(0x66, 0xC7);
> + break;
> + case BPF_W:
> + if (is_ereg(dst_reg))
> + EMIT2(0x41, 0xC7);
> + else
> + EMIT1(0xC7);
> + break;
> + case BPF_DW:
> + if (dst_reg == BPF_REG_PARAMS &&
> + insn->off == -8) {
> + /* Arg 6: store immediate in r9 register */
> + emit_mov_imm64(&prog, X86_REG_R9,
> + imm32 >> 31, (u32)imm32);
> + break;
> + }
> + EMIT2(add_1mod(0x48, dst_reg), 0xC7);
maybe it's an opportunity to cover this into separate helper function?
When indent reaches 4 tabs it's about time.
^ 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