* [PATCH 2/2] coresight: tnoc: Fix clock refcount imbalance on platform remove
From: Jie Gan @ 2026-07-01 6:05 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Anshuman Khandual, Yeoreum Yun,
Yuanfang Zhang, Maxime Coquelin, Alexandre Torgue, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel, linux-stm32, Jie Gan
In-Reply-To: <20260701-fix-clock-refcount-unbalance-v1-0-321dc63c1f90@oss.qualcomm.com>
coresight_get_enable_clocks() enables the programming clock through
devm_clk_get_optional_enabled(), which also registers a devm action to
call clk_disable_unprepare() when the driver detaches.
After probe, pm_runtime_put() allows the device to suspend and the
runtime suspend callback disables the same clock. During remove the
device is left runtime suspended, so pm_runtime_disable() freezes it
with the clock already disabled. The devm cleanup that runs afterwards
calls clk_disable_unprepare() a second time, underflowing the clock
enable refcount.
Resume the device with pm_runtime_get_sync() before pm_runtime_disable()
so the clock is enabled again and balances the devm-managed disable.
Fixes: 5799dee92dc2 ("coresight-tnoc: add platform driver to support Interconnect TNOC")
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
drivers/hwtracing/coresight/coresight-tnoc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hwtracing/coresight/coresight-tnoc.c b/drivers/hwtracing/coresight/coresight-tnoc.c
index 9e8de4323d28..a4ac0eb02248 100644
--- a/drivers/hwtracing/coresight/coresight-tnoc.c
+++ b/drivers/hwtracing/coresight/coresight-tnoc.c
@@ -300,6 +300,7 @@ static void itnoc_remove(struct platform_device *pdev)
struct trace_noc_drvdata *drvdata = platform_get_drvdata(pdev);
coresight_unregister(drvdata->csdev);
+ pm_runtime_get_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v14 0/7] Provide support for Trigger Generation Unit
From: Songwei.Chai @ 2026-07-01 6:04 UTC (permalink / raw)
To: Suzuki K Poulose, Greg KH
Cc: andersson, alexander.shishkin, mike.leach, konrad.dybcio,
james.clark, krzk+dt, conor+dt, linux-kernel, linux-arm-kernel,
linux-arm-msm, coresight, devicetree
In-Reply-To: <e7d83356-c9cc-4324-a65e-fda3bd27af76@oss.qualcomm.com>
On 6/30/2026 3:59 PM, Songwei.Chai wrote:
>
>
> On 6/29/2026 6:44 PM, Suzuki K Poulose wrote:
>> Hello,
>>
>> On 29/06/2026 11:17, Songwei.Chai wrote:
>>>
>>> On 6/29/2026 12:22 PM, Greg KH wrote:
>>>> On Mon, Jun 29, 2026 at 11:03:33AM +0800, Songwei.Chai wrote:
>>>>> Hi Greg & Alexander,
>>>>>
>>>>> Apologies for interrupting again.
>>>>>
>>>>> As the TGU hardware plays an important role in Qualcomm tracing
>>>>> design, I
>>>>> would greatly appreciate it if you could kindly take some time to
>>>>> review
>>>>> this at your earliest convenience.
>>>> The merge window _just_ closed, please give us a chance to catch up.
>>>>
>>>> Also, why us? Surely you have other reviewers for this code, right?
>>>
>>> Hi Greg,
>>>
>>> Understood, thanks for letting us know.
>>>
>>> Regarding your question: since this introduces a new
>>> drivers/hwtracing/ qcom directory, there is no existing maintainer
>>> for it.
>>> Given your scope (and Alexander's), we believe you are the most
>>> relevant reviewers.
>>>
>>> The reason for creating the qcom directory is as follows:
>>>
>>> /We previously tried to upstream this driver under
>>> drivers/hwtracing/ coresight,/
>>> /but it was not accepted as it is considered Qualcomm-specific and
>>> not tightly/
>>> /coupled with the CoreSight subsystem. Based on this feedback, we are
>>
>> Some clarification here: This device is not CoreSight so we denied
>> keeping this under drivers/hwtracing/coresight/ - Not because it is
>> Qualcomm specific. We have TPDM, TPDA, TnoC devices under the coresight
>> subsystem, which are all Qualcomm specific for e.g.
>>
>> That said, there are other drivers in drivers/hwtracing/ which I usually
>> merge and push to Greg, after some reviews/acks from the respective
>> people (e.g., PTT HiSilicon PCIe Tune and Trace).
>>
>> But, your proposal was that there were other maintainers for your new
>> subtree and you were going to push this via ,linux-arm-msm ? to which I
>> didn't have any objections.
>>
>> That said, I am fine with pushing this to Greg via the CoreSight pull
>> requests (similar to Hisilicon PTT driver), but would need someone to
>> Maintain/Review the driver (with entries in MAINTAINERS, similar to
>> PTT).
>>
>>
>> Thoughts ?
>
> Hi Suzuki,
>
> Thank you for your constructive feedback in helping us move this patch
> forward.
> As the owner of this driver, together with Jie Gan (who has extensive
> review experience), we will be responsible for the maintenance and
> review going forward.
> I will also include the MAINTAINERS update in the next TGU release.
>
> Please feel free to share any further comments or suggestions.
>
> Thanks,
> Songwei
>
Hi Suzuki,
In the latest TGU Patch series (V15), I have also added you as a
maintainer so that you will be notified of any new drivers under
drivers/hwtracing/qcom.
The review responsibilities will be handled by Jie and myself.
Thanks,
Songwei
>>
>> Kind regards
>> Suzuki
>>
>>
>>
>>> exploring/
>>> /a dedicated drivers/hwtracing/qcom directory, similar to intel_th,
>>> to better/
>>> /support this and future Qualcomm hwtracing drivers./
>>>
>>> More details can be found in “[PATCH v14 0/7] -- Why we are
>>> proposing this”.
>>>
>>> Thanks,
>>> Songwei
>>>
>>>>
>>>> thanks,
>>>>
>>>> greg k-h
>>
^ permalink raw reply
* Re: [PATCH v2 0/5] netfilter: nf_flow_table_path: L2 bridge offload
From: Daniel Pawlik @ 2026-07-01 6:11 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netfilter-devel, netdev, bridge, coreteam, linux-mediatek,
linux-arm-kernel
In-Reply-To: <akOCJI-2kAAwOQzz@chamomile>
Hi Florian, Pablo,
I'll leave it up to you - if `br_netfilter` isn't the right approach
in this case, then we can drop that series.
Before your reply, I wasn't familiar with Eric Woudstra's
"bridge-fastpath" series - thanks for the tip.
I'll take a look at it and try to build on those patches.
Thanks, and best regards,
Dan
wt., 30 cze 2026 o 10:45 Pablo Neira Ayuso <pablo@netfilter.org> napisał(a):
>
> Hi,
>
> On Tue, Jun 30, 2026 at 08:57:30AM +0200, Daniel Pawlik wrote:
> > This series adds L2 bridge offload support to nft_flow_offload, allowing
> > bridged IPv4/IPv6 flows to be accelerated by the flowtable fast path
> > without requiring L3 routing.
> >
> > Background
> > ----------
> > Hardware flow offload engines (e.g. MediaTek PPE) can accelerate bridged
> > traffic but require that nft_flow_offload detect and handle bridged flows
> > differently from routed ones: no routing table lookup, MAC addresses from
> > the Ethernet header, and VLAN context pre-populated from the bridge port.
> >
> > v2: Fix missing Returns: tags in kernel-doc comments for the three new
> > bridge helpers (br_fdb_has_forwarding_entry_rcu,
> > br_vlan_get_offload_info_rcu, br_vlan_is_enabled_rcu).
> >
> > Patches
> > -------
> > 1/5 net: export __dev_fill_forward_path
> > Refactors dev_fill_forward_path() to expose __dev_fill_forward_path()
> > which accepts a caller-supplied net_device_path_ctx, needed to
> > pre-populate VLAN state before the forward path walk.
> >
> > 2/5 net: bridge: add flow offload helpers
> > Adds br_fdb_has_forwarding_entry_rcu(), br_vlan_get_offload_info_rcu()
> > and br_vlan_is_enabled_rcu() to expose bridge state to nft_flow_offload
> > without requiring inclusion of net/bridge/br_private.h.
> >
> > 3/5 netfilter: nf_flow_table_path: add L2 bridge offload
> > Core of the series. Adds nft_flow_offload_is_bridging() detection,
> > nft_flow_route_bridging() which avoids nf_route() (fails for
> > bridged-only subnets), MAC/VLAN pre-population for bridged flows,
> > and a dst leak fix. nft_flow_route() becomes a thin dispatcher.
> >
> > 4/5 netfilter: nf_flow_table_path: handle DEV_PATH_MTK_WDMA in path info
> > Fixes zero-source-MAC in PPE entries when a bridged flow traverses
> > MT7996/MT7915 WiFi WDMA hardware.
> >
> > 5/5 netfilter: nf_flow_table_path: add VLAN passthrough support
> > Records VLAN encap info for passthrough-mode bridge ports so hardware
> > offload entries include the correct VLAN tag.
> >
> > Rebase note
> > -----------
> > Originally developed against OpenWrt pending-6.18 patches by Ryan Chen
> > <rchen14b@gmail.com> and Bo-Cun Chen <bc-bocun.chen@mediatek.com>.
> > Rebased to current upstream: path discovery infrastructure moved to
> > nf_flow_table_path.c in commit 93d7a7ed0734 ("netfilter: flowtable: move
> > path discovery infrastructure to its own file"), so all netfilter changes
> > now land in that file rather than nft_flow_offload.c.
> >
> > How to enable bridge offload
> > -----------------------------
> > 1. Load kmod-br-netfilter so that bridged IP traffic traverses the
> > netfilter forward chain.
> >
> > 2. Enable netfilter hooks on the bridge:
> > echo 1 > /sys/class/net/<br>/bridge/nf_call_iptables
> > echo 1 > /sys/class/net/<br>/bridge/nf_call_ip6tables
>
> This requires br_netfilter which is a no go.
>
> Sorry, but we should really target at the native nf_conntrack_bridge
> support.
>
> > 3. Register bridge member interfaces in the nft flowtable:
> > table inet filter {
> > flowtable f {
> > hook ingress priority filter
> > devices = { eth0, wlan0 }
> > }
> > chain forward {
> > type filter hook forward priority filter
> > meta l4proto { tcp, udp } flow add @f
> > }
> > }
>
> Yes, but br_netfilter makes no sense for nftables.
>
> br_netfilter was made to fill gap at the time ebtables was lagging a
> lot behind iptables in terms of features. And getting ebtables on pair
> with iptables in functionality was not feasible either, because it
> required many new extensions that were specific of the bridge family,
> which probably was not a big deal, but it also required to get
> the ebtables command line tool on pair with iptables userspace, which
> has received more development attention/effort that the bridge tool.
>
> All of this does not stand true anymore with nftables, where the
> bridge family capabilities are at pair with the inet families.
>
> I am looking now at the native flowtable bridge support, I will get
> back to you with updates.
^ permalink raw reply
* [PATCH] ASoC: mediatek: mt8173-rt5650: tidyup error message
From: Kuninori Morimoto @ 2026-07-01 6:17 UTC (permalink / raw)
To: AngeloGioacchino Del Regno, Jaroslav Kysela, Liam Girdwood,
linux-arm-kernel, linux-sound, Mark Brown, Matthias Brugger,
Takashi Iwai
mt8173_rt5650_dev_probe() has strange error message
=> ret = device_property_read_u32(...);
^^^^^^^^^^^^^^^^^^^^^^^^
if (ret)
=> dev_err(... "%s snd_soc_register_card fail %d\n", ...);
^^^^^^^^^^^^^^^^^^^^^
It should be "device_property_read_u32() fail". Fix it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
sound/soc/mediatek/mt8173/mt8173-rt5650.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/mediatek/mt8173/mt8173-rt5650.c b/sound/soc/mediatek/mt8173/mt8173-rt5650.c
index 3d6d7bc05b872..8c5096482520a 100644
--- a/sound/soc/mediatek/mt8173/mt8173-rt5650.c
+++ b/sound/soc/mediatek/mt8173/mt8173-rt5650.c
@@ -315,7 +315,7 @@ static int mt8173_rt5650_dev_probe(struct platform_device *pdev)
&mt8173_rt5650_priv.pll_from);
if (ret) {
dev_err(&pdev->dev,
- "%s snd_soc_register_card fail %d\n",
+ "%s device_property_read_u32() fail %d\n",
__func__, ret);
}
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 0/8] treewide: remove unnecessary invalid range checks in memblock iteration loops
From: Mike Rapoport @ 2026-07-01 6:22 UTC (permalink / raw)
To: Albert Ou, Andrew Morton, Andrey Ryabinin, Catalin Marinas,
Huacai Chen, Madhavan Srinivasan, Michael Ellerman, Muchun Song,
Oscar Salvador, Palmer Dabbelt, Paul Walmsley, Russell King,
Will Deacon, Sang-Heon Jeon
Cc: linux-mm, Alexander Potapenko, Alexandre Ghiti, Andrey Konovalov,
Christophe Leroy (CS GROUP), David Hildenbrand, Dmitry Vyukov,
kasan-dev, linux-arm-kernel, linux-kernel, linuxppc-dev,
linux-riscv, loongarch, Nicholas Piggin, Vincenzo Frascino,
WANG Xuerui
In-Reply-To: <20260630150413.1718632-1-ekffu200098@gmail.com>
On Wed, 01 Jul 2026 00:04:05 +0900, Sang-Heon Jeon wrote:
> treewide: remove unnecessary invalid range checks in memblock iteration loops
>
> The memblock API guarantees that for_each_mem_range() and
> for_each_mem_pfn_range() never return an invalid range, meaning start is
> always less than end.
>
> Several memblock callers still have unnecessary invalid range checks in
> their loop bodies, so remove them.
>
> [...]
Applied to range-checks branch of memblock.git tree, thanks!
[1/8] arm64: mm: remove unreachable invalid range check in kasan_init_shadow()
commit: f6e6c57f2e100813be6d5882060fef81cb6f32de
[2/8] LoongArch: remove unreachable invalid range check in kasan_init()
commit: 68d3b7d58237b8794d9343210d4c90b8381cfa96
[3/8] riscv: remove unreachable invalid range check in create_linear_mapping_page_table()
commit: 99e60ebe108817fd48791f2cb81f1e672ad8285b
[4/8] riscv: remove unreachable invalid range check in kasan_init()
commit: 8008f6995d0c0cf22e7b4d60e95fe14085c10f35
[5/8] ARM: remove unreachable invalid range check in kasan_init()
commit: 3db1a9ccf9290ea3fe01aadf3bd743ef7032b24a
[6/8] powerpc64/kasan: Remove unreachable invalid range check in kasan_init_phys_region()
commit: 21e95a4b6f34770571eeeaa6adb535efba1b7281
[7/8] mm: remove unnecessary empty range check in early_calculate_totalpages()
commit: c6af91e48594191f62ad3c1fcc8269b1eb539ef8
[8/8] mm/hugetlb: remove unnecessary empty range check in hugetlb_bootmem_set_nodes()
commit: 2db44dc8bdd3cfc933a3193724f4d38b03e35b80
tree: https://git.kernel.org/pub/scm/linux/kernel/git/rppt/memblock
branch: range-checks
--
Sincerely yours,
Mike.
^ permalink raw reply
* [RFC PATCH 0/2] Add NPAC driver to accel subsystem
From: Jaspinder Budhal @ 2026-07-01 6:25 UTC (permalink / raw)
To: ogabbay, corbet, skhan
Cc: dri-devel, linux-doc, linux-kernel, linux-arm-kernel, j-budhal,
srk, s-vadapalli
This series adds support for the Network Packet ACcelerator (NPAC)
client driver. NPAC is a hardware accelerator for offloading
packet processing tasks from the various hosts on TI's TDA5 family
of SoCs.
This is a minimal reference implementation to establish the framework
for NPAC acceleration support in the Linux kernel. Further details
are in patch 1 which adds documentation for the driver and describes
the system architecture, driver interface, and execution flows.
This RFC is submitted for getting feedback on the initial implementation.
Jaspinder Budhal (2):
Documentation: accel: Add NPAC client driver documentation
accel/npac: Add NPAC client driver
Documentation/accel/npac.rst | 142 ++++++++++++++++++++++
drivers/accel/Kconfig | 1 +
drivers/accel/Makefile | 1 +
drivers/accel/npac/Kconfig | 13 ++
drivers/accel/npac/Makefile | 3 +
drivers/accel/npac/npac_drv.c | 218 ++++++++++++++++++++++++++++++++++
6 files changed, 378 insertions(+)
create mode 100644 Documentation/accel/npac.rst
create mode 100644 drivers/accel/npac/Kconfig
create mode 100644 drivers/accel/npac/Makefile
create mode 100644 drivers/accel/npac/npac_drv.c
--
2.34.1
^ permalink raw reply
* [RFC PATCH 1/2] Documentation: accel: Add NPAC client driver documentation
From: Jaspinder Budhal @ 2026-07-01 6:25 UTC (permalink / raw)
To: ogabbay, corbet, skhan
Cc: dri-devel, linux-doc, linux-kernel, linux-arm-kernel, j-budhal,
srk, s-vadapalli
In-Reply-To: <20260701062505.1091840-1-j-budhal@ti.com>
NPAC (Network Packet ACcelerator) is a hardware accelerator present on
TI's TDA5 family of SoCs, designed to offload network packet processing
tasks from various hosts. It can be used to implement various packet
processing use cases such as ACL (Access Control List) rule enforcement,
reducing host CPU load.
This is an RFC patch for getting feedback on the initial implementation.
See the TDA54 SoC datasheet for hardware details:
https://www.ti.com/lit/ds/symlink/tda54-q1.pdf
Signed-off-by: Jaspinder Budhal <j-budhal@ti.com>
---
Documentation/accel/npac.rst | 142 +++++++++++++++++++++++++++++++++++
1 file changed, 142 insertions(+)
create mode 100644 Documentation/accel/npac.rst
diff --git a/Documentation/accel/npac.rst b/Documentation/accel/npac.rst
new file mode 100644
index 000000000000..fba6ddd0cfd2
--- /dev/null
+++ b/Documentation/accel/npac.rst
@@ -0,0 +1,142 @@
+.. SPDX-License-Identifier: GPL-2.0-only OR MIT
+
+====================================================
+Texas Instruments NPAC (Network Packet ACcelerator)
+====================================================
+
+Overview
+========
+
+NPAC (Network Packet ACcelerator) is a hardware accelerator available
+on Texas Instruments SoCs in the TDA5 family that provides network packet
+processing acceleration [0]_.
+
+The NPAC Host Driver runs on a dedicated remote processor and manages
+NPAC hardware.
+
+The NPAC client driver provides offloading support for ethernet-related tasks
+and communicates with the NPAC Host Driver over RPMsg (Remote Processor
+Messaging).
+
+The driver exposes /dev/accel/accel* as the userspace interface for accelerator
+configuration and management operations.
+
+The NPAC Host Driver supports ACL (Access Control
+List) [1]_ rule offload. ACL configuration requests are sent by the client
+driver to the NPAC Host Driver.
+
+Communication Model
+-------------------
+
+The NPAC client driver registers with the RPMsg subsystem during driver
+initialization.
+
+When the NPAC host driver announces the NPAC RPMsg service endpoint, the
+RPMsg core matches the announced service against the registered NPAC client
+driver and invokes the driver probe callback.
+
+Offload command received from userspace are formatted into RPMsgs and sent
+to the NPAC Host Driver.
+
+NPAC Host Driver responses are received through RPMsg callbacks.
+
+ACL Rule Offload
+----------------
+
+ACL (Access Control List) rules are packet filtering policies that define how
+network traffic should be handled — for example, dropping packets from a
+blacklisted source IP or allowing traffic only from trusted MAC addresses.
+
+In the standard Linux networking stack, ACL enforcement is handled in software
+by the netfilter subsystem. Each packet is inspected against the configured
+ruleset on the host CPU. On embedded SoCs in the TDA5 family such as TDA54,
+the per-packet overhead of software-based ACL enforcement accumulates under
+high traffic rates, increasing CPU utilization and reducing the processing
+capacity available for other system functions.
+
+The NPAC client driver offloads rules from Linux to NPAC hardware.
+Once a rule is programmed, matching packets are handled entirely by NPAC,
+reducing CPU load.
+
+For example, a rule to drop all packets from a specific source IP or to
+allow packets from a trusted source is offloaded to NPAC. Instead of the
+host parsing each packet and applying the ACL rules, NPAC enforces the
+rule directly in hardware.
+
+Userspace Interface
+-------------------
+
+The driver exposes /dev/accel/accel* as the userspace control interface for ACL
+rule management operations.
+
+The interface uses IOCTL-based request handling for accelerator configuration
+and rule management operations.
+
+IOCTL Commands
+~~~~~~~~~~~~~~
+
+DRM_IOCTL_NPAC_ACL_ADD_RULE
+
+ This IOCTL allows userspace to add an ACL rule to the accelerator. The
+ call will forward the rule to the NPAC host driver for hardware programming.
+ The NPAC Host Driver is responsible for validating the rule and applying it to
+ the NPAC hardware.
+
+DRM_IOCTL_NPAC_ACL_DELETE_RULE
+
+ This IOCTL allows userspace to remove an ACL rule from the accelerator.
+ The call will forward the deletion request to the NPAC host driver, which
+ will remove the rule from the NPAC hardware.
+
+Driver Lifecycle
+----------------
+
+The driver lifecycle is coordinated through the RPMsg framework.
+
+Probe Flow
+~~~~~~~~~~
+
+1. The NPAC client driver registers with the RPMsg subsystem
+
+2. NPAC host driver initializes on the remote processor
+
+3. NPAC Host Driver announces its RPMsg service endpoint
+
+4. The RPMsg subsystem in Linux matches the announced service against
+ the registered NPAC client driver
+
+5. The RPMsg subsystem invokes the driver probe callback
+
+6. Driver communication resources are initialized
+
+7. /dev/accel/accel* becomes available to userspace
+
+Request Flow
+~~~~~~~~~~~~
+
+1. Userspace submits an ACL configuration request through /dev/accel/accel*
+
+2. The request is forwarded to the NPAC host driver using RPMsg
+
+3. The NPAC Host Driver validates the request and performs the required hardware
+ programming operations
+
+4. NPAC Host Driver responses are received by the Linux driver through the RPMsg
+ callback.
+
+RPMsg Integration
+-----------------
+
+The driver integrates with the Linux RPMsg subsystem for communication with
+the NPAC host driver processor.
+
+RPMsg is used as the transport mechanism for:
+
+- Accelerator configuration requests
+- NPAC Host Driver responses
+
+References
+----------
+
+.. [0] https://www.ti.com/lit/ds/symlink/tda54-q1.pdf
+.. [1] https://en.wikipedia.org/wiki/Access-control_list#Networking_ACLs
--
2.34.1
^ permalink raw reply related
* [RFC PATCH 2/2] accel/npac: Add NPAC client driver
From: Jaspinder Budhal @ 2026-07-01 6:25 UTC (permalink / raw)
To: ogabbay, corbet, skhan
Cc: dri-devel, linux-doc, linux-kernel, linux-arm-kernel, j-budhal,
srk, s-vadapalli
In-Reply-To: <20260701062505.1091840-1-j-budhal@ti.com>
Add the Linux client driver for the Network Packet ACcelerator (NPAC).
The driver communicates with the NPAC host driver via RPMsg,
allowing offloading of ethernet-related packet processing tasks.
The driver provides the basic framework for receiving offload commands
via IOCTL and communicating with the NPAC hardware accelerator.
Signed-off-by: Jaspinder Budhal <j-budhal@ti.com>
---
drivers/accel/Kconfig | 1 +
drivers/accel/Makefile | 1 +
drivers/accel/npac/Kconfig | 13 ++
drivers/accel/npac/Makefile | 3 +
drivers/accel/npac/npac_drv.c | 218 ++++++++++++++++++++++++++++++++++
5 files changed, 236 insertions(+)
create mode 100644 drivers/accel/npac/Kconfig
create mode 100644 drivers/accel/npac/Makefile
create mode 100644 drivers/accel/npac/npac_drv.c
diff --git a/drivers/accel/Kconfig b/drivers/accel/Kconfig
index bdf48ccafcf2..a6d8c1ebfcf1 100644
--- a/drivers/accel/Kconfig
+++ b/drivers/accel/Kconfig
@@ -28,6 +28,7 @@ source "drivers/accel/amdxdna/Kconfig"
source "drivers/accel/ethosu/Kconfig"
source "drivers/accel/habanalabs/Kconfig"
source "drivers/accel/ivpu/Kconfig"
+source "drivers/accel/npac/Kconfig"
source "drivers/accel/qaic/Kconfig"
source "drivers/accel/rocket/Kconfig"
diff --git a/drivers/accel/Makefile b/drivers/accel/Makefile
index 1d3a7251b950..0df7b9f2ae18 100644
--- a/drivers/accel/Makefile
+++ b/drivers/accel/Makefile
@@ -4,5 +4,6 @@ obj-$(CONFIG_DRM_ACCEL_AMDXDNA) += amdxdna/
obj-$(CONFIG_DRM_ACCEL_ARM_ETHOSU) += ethosu/
obj-$(CONFIG_DRM_ACCEL_HABANALABS) += habanalabs/
obj-$(CONFIG_DRM_ACCEL_IVPU) += ivpu/
+obj-$(CONFIG_DRM_ACCEL_NPAC_CLIENT) += npac/
obj-$(CONFIG_DRM_ACCEL_QAIC) += qaic/
obj-$(CONFIG_DRM_ACCEL_ROCKET) += rocket/
\ No newline at end of file
diff --git a/drivers/accel/npac/Kconfig b/drivers/accel/npac/Kconfig
new file mode 100644
index 000000000000..a9543ac2c7aa
--- /dev/null
+++ b/drivers/accel/npac/Kconfig
@@ -0,0 +1,13 @@
+config DRM_ACCEL_NPAC_CLIENT
+ tristate "NPAC Client Driver"
+ depends on DRM_ACCEL
+ depends on RPMSG
+ help
+ This driver is the NPAC (Network Packet ACcelerator) client,
+ communicating with the NPAC host driver running on a remote
+ processor over RPMsg. The driver registers with the DRM accelerator
+ framework and exposes /dev/accel/accel* as the userspace interface
+ for ACL rule offload operations.
+ If you have a device with NPAC and wish to use it with this
+ driver, say M to compile this driver as a module, or Y to
+ compile it into the kernel.
diff --git a/drivers/accel/npac/Makefile b/drivers/accel/npac/Makefile
new file mode 100644
index 000000000000..89f4773d7041
--- /dev/null
+++ b/drivers/accel/npac/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+obj-$(CONFIG_DRM_ACCEL_NPAC_CLIENT) += npac_drv.o
diff --git a/drivers/accel/npac/npac_drv.c b/drivers/accel/npac/npac_drv.c
new file mode 100644
index 000000000000..7516382ba74b
--- /dev/null
+++ b/drivers/accel/npac/npac_drv.c
@@ -0,0 +1,218 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * Copyright (C) 2026 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include <drm/drm_accel.h>
+#include <drm/drm_drv.h>
+#include <drm/drm_file.h>
+#include <drm/drm_gem.h>
+#include <drm/drm_ioctl.h>
+#include <linux/completion.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/rpmsg.h>
+
+#define NPAC_RPMSG_SERVICE_NAME "ti.npac"
+#define NPAC_ACK_TIMEOUT_MS 1000
+
+/**
+ * enum npac_acl_cmd - IOCTL command numbers for NPAC ACL operations.
+ */
+enum npac_acl_cmd {
+ /** @NPAC_ACL_ADD_RULE: Add an ACL rule. */
+ NPAC_ACL_ADD_RULE,
+
+ /** @NPAC_ACL_DELETE_RULE: Delete an ACL rule. */
+ NPAC_ACL_DELETE_RULE,
+};
+
+/**
+ * enum npac_acl_match_type - Match field selector for an ACL rule.
+ */
+enum npac_acl_match_type {
+ /** @NPAC_ACL_MATCH_SRC_IPV4: Match on source IPv4 address. */
+ NPAC_ACL_MATCH_SRC_IPV4 = 1,
+
+ /** @NPAC_ACL_MATCH_DST_IPV4: Match on destination IPv4 address. */
+ NPAC_ACL_MATCH_DST_IPV4,
+
+ /** @NPAC_ACL_MATCH_SRC_MAC: Match on source MAC address. */
+ NPAC_ACL_MATCH_SRC_MAC,
+
+ /** @NPAC_ACL_MATCH_DST_MAC: Match on destination MAC address. */
+ NPAC_ACL_MATCH_DST_MAC,
+};
+
+/**
+ * enum npac_acl_verdict - Action to apply when an ACL rule matches.
+ */
+enum npac_acl_verdict {
+ /** @NPAC_ACL_VERDICT_ALLOW: Accept the matched packet. */
+ NPAC_ACL_VERDICT_ALLOW = 1,
+
+ /** @NPAC_ACL_VERDICT_DROP: Drop the matched packet. */
+ NPAC_ACL_VERDICT_DROP,
+};
+
+/* Sized for the largest match field: a 6-byte MAC address. */
+#define NPAC_ACL_MATCH_VALUE_MAX 6
+
+struct npac_acl_offload_rule {
+ __u32 match_type;
+ __u32 verdict;
+ __u8 match_value[NPAC_ACL_MATCH_VALUE_MAX];
+};
+
+#define DRM_IOCTL_NPAC_ACL_ADD_RULE \
+ DRM_IOWR(DRM_COMMAND_BASE + NPAC_ACL_ADD_RULE, struct npac_acl_offload_rule)
+
+#define DRM_IOCTL_NPAC_ACL_DELETE_RULE \
+ DRM_IOWR(DRM_COMMAND_BASE + NPAC_ACL_DELETE_RULE, struct npac_acl_offload_rule)
+
+struct npac_device {
+ struct drm_device drm;
+ struct rpmsg_device *rpdev;
+ struct mutex req_lock; /* lock for request */
+ struct completion ack;
+};
+
+static inline struct npac_device *drm_to_npac_device(struct drm_device *dev)
+{
+ return container_of(dev, struct npac_device, drm);
+}
+
+static int npac_add_rule_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file)
+{
+ struct npac_device *npac = drm_to_npac_device(dev);
+ struct npac_acl_offload_rule *rule = data;
+ int ret;
+
+ dev_dbg(dev->dev, "add rule ioctl received\n");
+
+ mutex_lock(&npac->req_lock);
+ reinit_completion(&npac->ack);
+ ret = rpmsg_send(npac->rpdev->ept, rule, sizeof(*rule));
+ if (ret) {
+ dev_err(dev->dev, "rpmsg_send failed: %d\n", ret);
+ mutex_unlock(&npac->req_lock);
+ return ret;
+ }
+ if (!wait_for_completion_timeout(&npac->ack,
+ msecs_to_jiffies(NPAC_ACK_TIMEOUT_MS))) {
+ dev_err(dev->dev, "ack timed out\n");
+ mutex_unlock(&npac->req_lock);
+ return -ETIMEDOUT;
+ }
+ mutex_unlock(&npac->req_lock);
+ return 0;
+}
+
+static int npac_delete_rule_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file)
+{
+ struct npac_device *npac = drm_to_npac_device(dev);
+ struct npac_acl_offload_rule *rule = data;
+ int ret;
+
+ dev_dbg(dev->dev, "delete rule ioctl received\n");
+
+ mutex_lock(&npac->req_lock);
+ reinit_completion(&npac->ack);
+ ret = rpmsg_send(npac->rpdev->ept, rule, sizeof(*rule));
+ if (ret) {
+ dev_err(dev->dev, "rpmsg_send failed: %d\n", ret);
+ mutex_unlock(&npac->req_lock);
+ return ret;
+ }
+ if (!wait_for_completion_timeout(&npac->ack,
+ msecs_to_jiffies(NPAC_ACK_TIMEOUT_MS))) {
+ dev_err(dev->dev, "ack timed out\n");
+ mutex_unlock(&npac->req_lock);
+ return -ETIMEDOUT;
+ }
+ mutex_unlock(&npac->req_lock);
+ return 0;
+}
+
+static const struct drm_ioctl_desc npac_drm_ioctls[] = {
+ DRM_IOCTL_DEF_DRV(NPAC_ACL_ADD_RULE, npac_add_rule_ioctl, DRM_ROOT_ONLY),
+ DRM_IOCTL_DEF_DRV(NPAC_ACL_DELETE_RULE, npac_delete_rule_ioctl, DRM_ROOT_ONLY),
+};
+
+DEFINE_DRM_ACCEL_FOPS(npac_fops);
+
+static const struct drm_driver npac_drm_driver = {
+ .driver_features = DRIVER_COMPUTE_ACCEL,
+ .ioctls = npac_drm_ioctls,
+ .num_ioctls = ARRAY_SIZE(npac_drm_ioctls),
+ .fops = &npac_fops,
+ .name = "npac",
+ .desc = "NPAC Client Driver",
+};
+
+static int npac_cb(struct rpmsg_device *rpdev, void *data, int len,
+ void *priv, u32 src)
+{
+ struct npac_device *npac = dev_get_drvdata(&rpdev->dev);
+
+ dev_dbg(&rpdev->dev, "ack received\n");
+ complete(&npac->ack);
+ return 0;
+}
+
+static int npac_probe(struct rpmsg_device *rpdev)
+{
+ struct npac_device *npac;
+ int ret;
+
+ npac = devm_drm_dev_alloc(&rpdev->dev, &npac_drm_driver,
+ struct npac_device, drm);
+ if (IS_ERR(npac))
+ return PTR_ERR(npac);
+
+ npac->rpdev = rpdev;
+ mutex_init(&npac->req_lock);
+ init_completion(&npac->ack);
+ dev_set_drvdata(&rpdev->dev, npac);
+
+ ret = drm_dev_register(&npac->drm, 0);
+ if (ret) {
+ dev_err(&rpdev->dev, "Failed to register DRM accel device: %d\n", ret);
+ return ret;
+ }
+
+ dev_info(&rpdev->dev, "NPAC Client driver probed\n");
+ return 0;
+}
+
+static void npac_remove(struct rpmsg_device *rpdev)
+{
+ struct npac_device *npac = dev_get_drvdata(&rpdev->dev);
+
+ drm_dev_unplug(&npac->drm);
+
+ dev_info(&rpdev->dev, "NPAC Client Driver removed\n");
+}
+
+static struct rpmsg_device_id npac_id_table[] = {
+ { .name = NPAC_RPMSG_SERVICE_NAME },
+ {},
+};
+MODULE_DEVICE_TABLE(rpmsg, npac_id_table);
+
+static struct rpmsg_driver npac_driver = {
+ .drv.name = KBUILD_MODNAME,
+ .id_table = npac_id_table,
+ .probe = npac_probe,
+ .callback = npac_cb,
+ .remove = npac_remove,
+};
+
+module_rpmsg_driver(npac_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("NPAC Client Driver");
+MODULE_AUTHOR("Jaspinder Budhal <j-budhal@ti.com>");
--
2.34.1
^ permalink raw reply related
* Re: [PULL] PCI: meson: Fix PERST# timing by asserting reset before LTSSM enable
From: Manivannan Sadhasivam @ 2026-07-01 6:31 UTC (permalink / raw)
To: gowtham
Cc: yue.wang, lpieralisi, kwilczynski, robh, bhelgaas, neil.armstrong,
khilman, jbrunet, martin.blumenstingl, linux-pci, linux-amlogic,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260614095626.7afb7c04@slick.ferryfair.com>
On Sun, Jun 14, 2026 at 09:56:26AM +0530, gowtham wrote:
> The following changes since commit
> bb532bfaf7919c7c98caab81864e9ce2646e11e3:
>
> Linux 7.0.11 (2026-06-01 17:54:55 +0200)
>
> are available in the Git repository at:
>
> https://github.com/GowthamKudupudi/linux.git
> tags/meson-pcie-warm-reset-linux-7.0.y
>
> for you to fetch changes up to 852811b11795ee389ea6a953ed0db69b76722469:
>
> PCI: meson: Fix PERST# timing by asserting reset before LTSSM enable
> (2026-06-14 09:41:01 +0530)
>
Sorry, we don't pull patches from random trees. Please submit the patches to
linux-pci for review.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH] net: airoha: fix MIB stats collection to be lossless
From: Aniket Negi @ 2026-07-01 6:38 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-arm-kernel, linux-mediatek, netdev,
linux-kernel, aniket.negi
In-Reply-To: <akPQ7P1Dqb00oWa3@lore-desk>
Hi Lorenzo,
Thank you for the detailed review and suggestions!
> > + /* TX - 64-bit H+L registers: hw accumulates the total, read directly. =
> */
> > val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_H(port->id));
> > - dev->stats.tx_ok_pkts += ((u64)val << 32);
> > - val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_L(port->id));
> > - dev->stats.tx_ok_pkts += val;
> > + dev->stats.tx_ok_pkts = (u64)val << 32;
>
> I guess it is more readable to store REG_FE_GDM_TX_OK_PKT_CNT_L() read in v=
> al
> here. Something like:
>
> val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_L(port->id));
> dev->stats.tx_ok_pkts += val;
>
> This apply even to occurrence below
Agreed. I'll store CNT_L read in val first to improve readability.
> > + dev->stats.tx_ok_pkts += airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_L=
> (port->id));
> > =20
> > val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_BYTE_CNT_H(port->id));
> > - dev->stats.tx_ok_bytes += ((u64)val << 32);
> > - val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_BYTE_CNT_L(port->id));
> > - dev->stats.tx_ok_bytes += val;
> > + dev->stats.tx_ok_bytes = (u64)val << 32;
> > + dev->stats.tx_ok_bytes += airoha_fe_rr(eth, REG_FE_GDM_TX_OK_BYTE_CNT=
> _L(port->id));
> > =20
> > + /* TX - 32-bit registers: accumulate delta to handle wrap-around. */
> > val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_DROP_CNT(port->id));
> > - dev->stats.tx_drops += val;
> > + dev->stats.tx_drops += (u32)(val - dev->stats.hw_prev_stats.tx_drops);
> > + dev->stats.hw_prev_stats.tx_drops = val;
> > =20
> > val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_BC_CNT(port->id));
> > - dev->stats.tx_broadcast += val;
> > + dev->stats.tx_broadcast += (u32)(val - dev->stats.hw_prev_stats.tx_br=
> oadcast);
> > + dev->stats.hw_prev_stats.tx_broadcast = val;
> > =20
> > val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_MC_CNT(port->id));
> > - dev->stats.tx_multicast += val;
> > + dev->stats.tx_multicast += (u32)(val - dev->stats.hw_prev_stats.tx_mu=
> lticast);
> > + dev->stats.hw_prev_stats.tx_multicast = val;
> > =20
> > val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_RUNT_CNT(port->id));
> > - dev->stats.tx_len[i] += val;
> > + dev->stats.tx_len[i] += (u32)(val - dev->stats.hw_prev_stats.tx_len[i=
> ]);
> > + dev->stats.hw_prev_stats.tx_len[i] = val;
> > =20
> > val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_E64_CNT_H(port->id));
> > - dev->stats.tx_len[i] += ((u64)val << 32);
> > - val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_E64_CNT_L(port->id));
> > - dev->stats.tx_len[i++] += val;
> > + dev->stats.tx_len[i] += (u64)val << 32;
>
> Since now we do not reset MIB counters, this is wrong, you can't use "+="
You are absolutely right, since MIB counters are no longer cleared, using "+=" for E64 counter would cause double counting each iteration. This was missed in the patch, specifically for the case where runt count(32 bit) and E64 counter (64 bit) need to be combined in the same counter.
I'll fix this by using separate accumulator fields to "tx_runt_accum/rx_runt_accum" to track the runt deltas, then compute tx_len[i] as tx_len[i]= tx_runt_accum + E64_CNT (H+L).
> > val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_RUNT_CNT(port->id));
> > - dev->stats.rx_len[i] += val;
> > + dev->stats.rx_len[i] += (u32)(val - dev->stats.hw_prev_stats.rx_len[i=
> ]);
> > + dev->stats.hw_prev_stats.rx_len[i] = val;
> > =20
> > val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_E64_CNT_H(port->id));
> > - dev->stats.rx_len[i] += ((u64)val << 32);
> > - val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_E64_CNT_L(port->id));
> > - dev->stats.rx_len[i++] += val;
> > + dev->stats.rx_len[i] += (u64)val << 32;
>
> same here.
Acked. The same approach above will be applied to rx_len[i].
> > +
> > + struct {
> > + /* Previous HW register values for 32-bit counter delta tracking.
> > + * Storing the last seen value and accumulating (u32)(curr - prev)
> > + * in 64-bit software counter & handles wrap-around transparently
> > + * via unsigned arithmetic. These fields are never reported to
> > + * userspace.
> > + */
>
> can you please align the comment here?
Will fix the comment alignment.
>
> > + u32 tx_drops;
> > + u32 tx_broadcast;
> > + u32 tx_multicast;
> > + u32 tx_len[7];
> > + u32 rx_drops;
> > + u32 rx_broadcast;
> > + u32 rx_multicast;
> > + u32 rx_errors;
> > + u32 rx_crc_error;
> > + u32 rx_over_errors;
> > + u32 rx_fragment;
> > + u32 rx_jabber;
> > + u32 rx_len[7];
> > + } hw_prev_stats;
>
> Maybe something like "prev_val32" ?
>
> Will update the name of struct to hold prev counter from hw_pre_stats to prev_val32.
Good suggestion. However, since the struct hw_prev_stats now contains both u32 (previous register value) and u64 (runt accumulators) fields. I'll rename it to "prev_mib_state" to better reflect its dual purpose of storing previous register values for delta calculation and accumulators for combined counters.
Regards,
Aniket Negi
^ permalink raw reply
* Re: [PATCH 3/3] net: stmmac: dwmac-socfpga: Add mac-mode DT property support
From: Maxime Chevallier @ 2026-07-01 6:49 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade, dinguyen
Cc: rmk+kernel, krzk+dt, conor+dt, robh, davem, edumazet, kuba,
pabeni, andrew+netdev, devicetree, linux-arm-kernel, netdev,
linux-kernel
In-Reply-To: <20260630133108.27244-4-muhammad.nazim.amirul.nazle.asmade@altera.com>
Hi,
On 6/30/26 15:31, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>
> Russell King's commit de696c63c1dc ("net: stmmac: socfpga: convert to
> use phy_interface") replaced mac_interface with phy_interface in
> socfpga_get_plat_phymode(), noting that no upstream DTS files set the
> "mac-mode" property, making the two values identical.
>
> The Agilex5 SoCDK TSN Config2 board is an exception: its gmac1 TSN
> port uses GMII internally in the MAC while the PHY-side interface is
> RGMII, so mac-mode and phy-mode differ. Without restoring mac_interface
> support, the MAC is configured with RGMII instead of GMII, causing
> connectivity failures on this board.
>
> Add socfpga_of_get_mac_mode() to read the optional "mac-mode" DT
> property and store it in a new mac_interface field. When the property
> is absent, mac_interface falls back to phy_interface, preserving
> the existing behaviour for all other boards.
After our discussions, indeed mac-mode seems to be the way to go, however
I have some remarks on how it's handled right now.
>
> Fixes: de696c63c1dc ("net: stmmac: socfpga: convert to use phy_interface")
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> ---
> .../ethernet/stmicro/stmmac/dwmac-socfpga.c | 23 ++++++++++++++++++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> index 1d7f0a57d288..6a6837c4a414 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
> @@ -69,12 +69,30 @@ struct socfpga_dwmac {
> void __iomem *tse_pcs_base;
> void __iomem *sgmii_adapter_base;
> bool f2h_ptp_ref_clk;
> + phy_interface_t mac_interface;
> const struct socfpga_dwmac_ops *ops;
> };
>
> +static int socfpga_of_get_mac_mode(struct device_node *np)
> +{
> + const char *pm;
> + int err, i;
> +
> + err = of_property_read_string(np, "mac-mode", &pm);
> + if (err < 0)
> + return err;
> +
> + for (i = 0; i < PHY_INTERFACE_MODE_MAX; i++) {
> + if (!strcasecmp(pm, phy_modes(i)))
> + return i;
> + }
> +
> + return -ENODEV;
> +}
> +
> static phy_interface_t socfpga_get_plat_phymode(struct socfpga_dwmac *dwmac)
> {
> - return dwmac->plat_dat->phy_interface;
> + return dwmac->mac_interface;
> }
Taking a look at the logic in socfpga_gen{5|10}_set_phy_mode(), we have :
phy_interface_t phymode = socfpga_get_plat_phymode(dwmac);
u32 val;
socfpga_set_phy_mode_common(phymode, &val)
if (dwmac->splitter_base)
val = SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_GMII_MII;
[...]
if (phymode == PHY_INTERFACE_MODE_SGMII)
socfpga_sgmii_config(dwmac, true);
With this new patch, we now have 2 different ways of handling this
converter block (splitter presence, and mac-mode presence in DT)
Can you unify this a bit ?
One thing could be adding a helper to get the macmode such as
socfpga_get_plat_macmode()
I think we should move the splitter handling before calling
socfpga_get_plat_macmode() :
if (dwmac->splitter_base)
dwmav->mac_interface = PHY_INTERFACE_MODE_GMII
We'd get the intf_sel value based on the macmode, and also calls to
helpers such as socfpga_sgmii_config(phymode, xxx) need the actual
phymode as a parameter, not the macmode.
Thanks :)
Maxime
^ permalink raw reply
* Re: [PATCH] net: airoha: fix MIB stats collection to be lossless
From: Lorenzo Bianconi @ 2026-07-01 6:51 UTC (permalink / raw)
To: Aniket Negi
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-arm-kernel, linux-mediatek, netdev,
linux-kernel, aniket.negi
In-Reply-To: <20260701063823.239783-1-aniket.negi03@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5633 bytes --]
> Hi Lorenzo,
>
> Thank you for the detailed review and suggestions!
>
> > > + /* TX - 64-bit H+L registers: hw accumulates the total, read directly. =
> > */
> > > val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_H(port->id));
> > > - dev->stats.tx_ok_pkts += ((u64)val << 32);
> > > - val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_L(port->id));
> > > - dev->stats.tx_ok_pkts += val;
> > > + dev->stats.tx_ok_pkts = (u64)val << 32;
> >
> > I guess it is more readable to store REG_FE_GDM_TX_OK_PKT_CNT_L() read in v=
> > al
> > here. Something like:
> >
> > val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_L(port->id));
> > dev->stats.tx_ok_pkts += val;
> >
> > This apply even to occurrence below
> Agreed. I'll store CNT_L read in val first to improve readability.
>
> > > + dev->stats.tx_ok_pkts += airoha_fe_rr(eth, REG_FE_GDM_TX_OK_PKT_CNT_L=
> > (port->id));
> > > =20
> > > val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_BYTE_CNT_H(port->id));
> > > - dev->stats.tx_ok_bytes += ((u64)val << 32);
> > > - val = airoha_fe_rr(eth, REG_FE_GDM_TX_OK_BYTE_CNT_L(port->id));
> > > - dev->stats.tx_ok_bytes += val;
> > > + dev->stats.tx_ok_bytes = (u64)val << 32;
> > > + dev->stats.tx_ok_bytes += airoha_fe_rr(eth, REG_FE_GDM_TX_OK_BYTE_CNT=
> > _L(port->id));
> > > =20
> > > + /* TX - 32-bit registers: accumulate delta to handle wrap-around. */
> > > val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_DROP_CNT(port->id));
> > > - dev->stats.tx_drops += val;
> > > + dev->stats.tx_drops += (u32)(val - dev->stats.hw_prev_stats.tx_drops);
> > > + dev->stats.hw_prev_stats.tx_drops = val;
> > > =20
> > > val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_BC_CNT(port->id));
> > > - dev->stats.tx_broadcast += val;
> > > + dev->stats.tx_broadcast += (u32)(val - dev->stats.hw_prev_stats.tx_br=
> > oadcast);
> > > + dev->stats.hw_prev_stats.tx_broadcast = val;
> > > =20
> > > val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_MC_CNT(port->id));
> > > - dev->stats.tx_multicast += val;
> > > + dev->stats.tx_multicast += (u32)(val - dev->stats.hw_prev_stats.tx_mu=
> > lticast);
> > > + dev->stats.hw_prev_stats.tx_multicast = val;
> > > =20
> > > val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_RUNT_CNT(port->id));
> > > - dev->stats.tx_len[i] += val;
> > > + dev->stats.tx_len[i] += (u32)(val - dev->stats.hw_prev_stats.tx_len[i=
> > ]);
> > > + dev->stats.hw_prev_stats.tx_len[i] = val;
> > > =20
> > > val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_E64_CNT_H(port->id));
> > > - dev->stats.tx_len[i] += ((u64)val << 32);
> > > - val = airoha_fe_rr(eth, REG_FE_GDM_TX_ETH_E64_CNT_L(port->id));
> > > - dev->stats.tx_len[i++] += val;
> > > + dev->stats.tx_len[i] += (u64)val << 32;
> >
> > Since now we do not reset MIB counters, this is wrong, you can't use "+="
>
> You are absolutely right, since MIB counters are no longer cleared, using "+=" for E64 counter would cause double counting each iteration. This was missed in the patch, specifically for the case where runt count(32 bit) and E64 counter (64 bit) need to be combined in the same counter.
>
> I'll fix this by using separate accumulator fields to "tx_runt_accum/rx_runt_accum" to track the runt deltas, then compute tx_len[i] as tx_len[i]= tx_runt_accum + E64_CNT (H+L).
>
> > > val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_RUNT_CNT(port->id));
> > > - dev->stats.rx_len[i] += val;
> > > + dev->stats.rx_len[i] += (u32)(val - dev->stats.hw_prev_stats.rx_len[i=
> > ]);
> > > + dev->stats.hw_prev_stats.rx_len[i] = val;
> > > =20
> > > val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_E64_CNT_H(port->id));
> > > - dev->stats.rx_len[i] += ((u64)val << 32);
> > > - val = airoha_fe_rr(eth, REG_FE_GDM_RX_ETH_E64_CNT_L(port->id));
> > > - dev->stats.rx_len[i++] += val;
> > > + dev->stats.rx_len[i] += (u64)val << 32;
> >
> > same here.
>
> Acked. The same approach above will be applied to rx_len[i].
>
> > > +
> > > + struct {
> > > + /* Previous HW register values for 32-bit counter delta tracking.
> > > + * Storing the last seen value and accumulating (u32)(curr - prev)
> > > + * in 64-bit software counter & handles wrap-around transparently
> > > + * via unsigned arithmetic. These fields are never reported to
> > > + * userspace.
> > > + */
> >
> > can you please align the comment here?
>
> Will fix the comment alignment.
>
> >
> > > + u32 tx_drops;
> > > + u32 tx_broadcast;
> > > + u32 tx_multicast;
> > > + u32 tx_len[7];
> > > + u32 rx_drops;
> > > + u32 rx_broadcast;
> > > + u32 rx_multicast;
> > > + u32 rx_errors;
> > > + u32 rx_crc_error;
> > > + u32 rx_over_errors;
> > > + u32 rx_fragment;
> > > + u32 rx_jabber;
> > > + u32 rx_len[7];
> > > + } hw_prev_stats;
> >
> > Maybe something like "prev_val32" ?
> >
> > Will update the name of struct to hold prev counter from hw_pre_stats to prev_val32.
>
> Good suggestion. However, since the struct hw_prev_stats now contains both u32 (previous register value) and u64 (runt accumulators) fields. I'll rename it to "prev_mib_state" to better reflect its dual purpose of storing previous register values for delta calculation and accumulators for combined counters.
Maybe better mib_prev?
Since now we do not reset the MIB counters in airoha_update_hw_stats(), we can
get rid of the for loop there and just call airoha_dev_get_hw_stats() with the
provided dev pointer. Even better, just rename airoha_dev_get_hw_stats() in
airoha_update_hw_stats() and move the spinlock there. What do you think?
Regards,
Lorenzo
>
> Regards,
> Aniket Negi
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 1/5] dt-bindings: arm: coresight-tnoc: Add standalone qcom,coresight-agtnoc compatible
From: Krzysztof Kozlowski @ 2026-07-01 6:57 UTC (permalink / raw)
To: Jie Gan
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang, Abel Vesa, Alexander Shishkin, Konrad Dybcio,
linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260701-fix-tracenoc-probe-issue-v4-1-aefab449a470@oss.qualcomm.com>
On Wed, Jul 01, 2026 at 09:53:41AM +0800, Jie Gan wrote:
> The TNOC compatible previously only allowed the two-string AMBA form
> "qcom,coresight-tnoc", "arm,primecell", which forces the device onto the
> AMBA bus.
>
> Convert the compatible to a oneOf and add a standalone
> "qcom,coresight-agtnoc" compatible alongside the existing AMBA form. The
> standalone string carries no "arm,primecell" entry, so the device is
> created on the platform bus instead of the AMBA bus.
That's a Linux driver specific reason, so not a valid one.
Describe the hardware instead.
Also, you do not get other compatible for the same device.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 2/5] coresight: tnoc: add AG tnoc standalone compatible to the platform driver
From: Krzysztof Kozlowski @ 2026-07-01 6:58 UTC (permalink / raw)
To: Jie Gan
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Abel Vesa,
Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang, Abel Vesa, Alexander Shishkin, Konrad Dybcio,
linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260701-fix-tracenoc-probe-issue-v4-2-aefab449a470@oss.qualcomm.com>
On Wed, Jul 01, 2026 at 09:53:42AM +0800, Jie Gan wrote:
> The Aggregator TNOC can be described either as an AMBA device using the
> "qcom,coresight-tnoc", "arm,primecell" compatible or as a standalone
> platform device using the new "qcom,coresight-agtnoc" compatible. The
> latter avoids the AMBA bus and the associated peripheral-ID probing.
So here it is: you added a fake hardware description so the driver can
avoid some action.
No, instead fix the drivers. Hardware did not change, thus you should
not change the bindings.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 0/3] Add AST2700 USB3.2 PHY driver
From: Ryan Chen @ 2026-07-01 6:58 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, Andrew Jeffery, Philipp Zabel
Cc: linux-phy, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Ryan Chen, Krzysztof Kozlowski
Add AST2700 USB3.2 PHY support.
- Supports Super Speed Plus Gen2x1 (10 Gbps), Super Speed (5 Gbps),
High Speed (480 Mbps), Full Speed (12Mbps), and Low Speed (1.5 Mbps).
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
Changes in v3:
- Wire drivers/phy/aspeed/ into drivers/phy/Kconfig and
drivers/phy/Makefile so the driver is actually built.
- Fix the Makefile config symbol to CONFIG_PHY_ASPEED_USB3 to match
the Kconfig symbol.
- Expand the Kconfig help text.
- Link to v2: https://lore.kernel.org/r/20260116-upstream_usb3phy-v2-0-0b0c9f3eb6f4@aspeedtech.com
Changes in v2:
- aspeed,ast2700-usb3-phy.yaml
- Drop clocks, resets descripton.
- Kconfig
- add COMPILE_TEST, remove default n
- Link to v1: https://lore.kernel.org/r/20260114-upstream_usb3phy-v1-0-2e59590be2d7@aspeedtech.com
---
Ryan Chen (3):
dt-bindings: phy: aspeed: Document AST2700 USB3.2 PHY
phy: aspeed: Add AST2700 USB3.2 PHY driver
MAINTAINERS: Add ASPEED USB3 PHY driver
.../bindings/phy/aspeed,ast2700-usb3-phy.yaml | 48 +++++
MAINTAINERS | 8 +
drivers/phy/Kconfig | 1 +
drivers/phy/Makefile | 1 +
drivers/phy/aspeed/Kconfig | 15 ++
drivers/phy/aspeed/Makefile | 2 +
drivers/phy/aspeed/phy-aspeed-usb3.c | 236 +++++++++++++++++++++
7 files changed, 311 insertions(+)
---
base-commit: 948efecf22e49aa4bf55bb73ec79a0ddcfd38571
change-id: 20260112-upstream_usb3phy-7116f8dfe779
Best regards,
--
Ryan Chen <ryan_chen@aspeedtech.com>
^ permalink raw reply
* [PATCH v3 1/3] dt-bindings: phy: aspeed: Document AST2700 USB3.2 PHY
From: Ryan Chen @ 2026-07-01 6:58 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, Andrew Jeffery, Philipp Zabel
Cc: linux-phy, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Ryan Chen, Krzysztof Kozlowski
In-Reply-To: <20260701-upstream_usb3phy-v3-0-00e12315b6f9@aspeedtech.com>
Document AST2700 USB3.2 PHY. This IP is connected between
USB3 controller and PHY module.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
.../bindings/phy/aspeed,ast2700-usb3-phy.yaml | 48 ++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/aspeed,ast2700-usb3-phy.yaml b/Documentation/devicetree/bindings/phy/aspeed,ast2700-usb3-phy.yaml
new file mode 100644
index 000000000000..b83037aa0438
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/aspeed,ast2700-usb3-phy.yaml
@@ -0,0 +1,48 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/aspeed,ast2700-usb3-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED AST2700 USB 3.2 PHY
+
+maintainers:
+ - Ryan Chen <ryan_chen@aspeedtech.com>
+
+properties:
+ compatible:
+ const: aspeed,ast2700-usb3-phy
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ '#phy-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - resets
+ - '#phy-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/aspeed,ast2700-scu.h>
+ #include <dt-bindings/reset/aspeed,ast2700-scu.h>
+
+ usb-phy@12010000 {
+ compatible = "aspeed,ast2700-usb3-phy";
+ reg = <0x12010000 0xc0>;
+ clocks = <&syscon0 SCU0_CLK_GATE_PORTAUSB2CLK>;
+ resets = <&syscon0 SCU0_RESET_PORTA_PHY3>;
+ #phy-cells = <0>;
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH v3 3/3] MAINTAINERS: Add ASPEED USB3 PHY driver
From: Ryan Chen @ 2026-07-01 6:58 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, Andrew Jeffery, Philipp Zabel
Cc: linux-phy, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Ryan Chen
In-Reply-To: <20260701-upstream_usb3phy-v3-0-00e12315b6f9@aspeedtech.com>
Add maintainer entry for ASPEED USB3 PHY driver.
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 895a87b571c3..10c08f322618 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4062,6 +4062,14 @@ S: Maintained
F: Documentation/devicetree/bindings/usb/aspeed,ast2600-udc.yaml
F: drivers/usb/gadget/udc/aspeed_udc.c
+ASPEED USB3 PHY DRIVER
+M: Ryan Chen <ryan_chen@aspeedtech.com>
+L: linux-aspeed@lists.ozlabs.org (moderated for non-subscribers)
+L: linux-phy@lists.infradead.org
+S: Maintained
+F: Documentation/devicetree/bindings/phy/aspeed,ast2700-usb3-phy.yaml
+F: drivers/phy/aspeed/phy-aspeed-usb3.c
+
ASPEED VIDEO ENGINE DRIVER
M: Eddie James <eajames@linux.ibm.com>
L: linux-media@vger.kernel.org
--
2.34.1
^ permalink raw reply related
* [PATCH v3 2/3] phy: aspeed: Add AST2700 USB3.2 PHY driver
From: Ryan Chen @ 2026-07-01 6:58 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, Andrew Jeffery, Philipp Zabel
Cc: linux-phy, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Ryan Chen
In-Reply-To: <20260701-upstream_usb3phy-v3-0-00e12315b6f9@aspeedtech.com>
Add AST2700 USB3.2 PHY driver support.
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
drivers/phy/Kconfig | 1 +
drivers/phy/Makefile | 1 +
drivers/phy/aspeed/Kconfig | 15 +++
drivers/phy/aspeed/Makefile | 2 +
drivers/phy/aspeed/phy-aspeed-usb3.c | 236 +++++++++++++++++++++++++++++++++++
5 files changed, 255 insertions(+)
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 19f3b7d12b7d..85fa381978f8 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -171,6 +171,7 @@ config PHY_XGENE
source "drivers/phy/allwinner/Kconfig"
source "drivers/phy/amlogic/Kconfig"
source "drivers/phy/apple/Kconfig"
+source "drivers/phy/aspeed/Kconfig"
source "drivers/phy/axiado/Kconfig"
source "drivers/phy/broadcom/Kconfig"
source "drivers/phy/cadence/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index d7aa516bcc49..c6dd02003bbe 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_PHY_XGENE) += phy-xgene.o
obj-$(CONFIG_GENERIC_PHY) += allwinner/ \
amlogic/ \
apple/ \
+ aspeed/ \
axiado/ \
broadcom/ \
cadence/ \
diff --git a/drivers/phy/aspeed/Kconfig b/drivers/phy/aspeed/Kconfig
new file mode 100644
index 000000000000..7b5f48db2be8
--- /dev/null
+++ b/drivers/phy/aspeed/Kconfig
@@ -0,0 +1,15 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+#
+# PHY drivers for ASPEED
+#
+
+config PHY_ASPEED_USB3
+ tristate "ASPEED USB3 PHY driver"
+ select GENERIC_PHY
+ depends on (ARCH_ASPEED || COMPILE_TEST)
+ help
+ Enable this to support the USB 3.2 PHY on the Aspeed AST2700 SoC.
+ It supports SuperSpeedPlus Gen2x1 (10 Gbps), SuperSpeed (5 Gbps),
+ High Speed (480 Mbps), Full Speed (12 Mbps) and Low Speed
+ (1.5 Mbps), and is paired with the DWC3 USB controller.
diff --git a/drivers/phy/aspeed/Makefile b/drivers/phy/aspeed/Makefile
new file mode 100644
index 000000000000..d96d9d73a009
--- /dev/null
+++ b/drivers/phy/aspeed/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_PHY_ASPEED_USB3) += phy-aspeed-usb3.o
diff --git a/drivers/phy/aspeed/phy-aspeed-usb3.c b/drivers/phy/aspeed/phy-aspeed-usb3.c
new file mode 100644
index 000000000000..eff148faa14c
--- /dev/null
+++ b/drivers/phy/aspeed/phy-aspeed-usb3.c
@@ -0,0 +1,236 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2026 Aspeed Technology Inc.
+ */
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+#include <linux/reset.h>
+
+#define PHY3S00 0x00
+#define PHY3S00_INIT_DONE BIT(15)
+#define PHY3S00_SRAM_BYPASS BIT(7)
+#define PHY3S00_SRAM_EXT_LOAD BIT(6)
+#define PHY3S04 0x04
+#define PHY3C00 0x08
+#define PHY3C04 0x0C
+#define PHY3P00 0x10
+#define PHY3P00_RX_ADAPT_AFE_EN_G1 BIT(0)
+#define PHY3P00_RX_ADAPT_AFE_EN_G2 BIT(1)
+#define PHY3P00_RX_ADAPT_DFE_EN_G1 BIT(2)
+#define PHY3P00_RX_ADAPT_DFE_EN_G2 BIT(3)
+#define PHY3P00_RX_CDR_VCO_LOWFREQ_G1 BIT(4)
+#define PHY3P00_RX_CDR_VCO_LOWFREQ_G2 BIT(5)
+#define PHY3P00_RX_EQ_AFE_GAIN_G1 GENMASK(9, 6)
+#define PHY3P00_RX_EQ_AFE_GAIN_G2 GENMASK(13, 10)
+#define PHY3P00_RX_EQ_ATT_LVL_G1 GENMASK(16, 14)
+#define PHY3P00_RX_EQ_ATT_LVL_G2 GENMASK(19, 17)
+#define PHY3P00_RX_EQ_CTLE_BOOST_G1 GENMASK(24, 20)
+#define PHY3P00_RX_EQ_CTLE_BOOST_G2 GENMASK(29, 25)
+#define PHY3P00_RX_EQ_DELTA_IQ_G1_LO GENMASK(31, 30)
+
+#define PHY3P04 0x14
+#define PHY3P04_RX_EQ_DELTA_IQ_G1_HI GENMASK(1, 0)
+#define PHY3P04_RX_EQ_DELTA_IQ_G2 GENMASK(5, 2)
+#define PHY3P04_RX_EQ_DFE_TAP1_G1 GENMASK(13, 6)
+#define PHY3P04_RX_EQ_DFE_TAP1_G2 GENMASK(21, 14)
+#define PHY3P04_RX_LOS_LFPS_EN BIT(22)
+#define PHY3P04_RX_LOS_THRESHOLD GENMASK(25, 23)
+#define PHY3P04_RX_TERM_CTRL GENMASK(28, 26)
+#define PHY3P04_TX_EQ_MAIN_G1_LO GENMASK(31, 29)
+
+#define PHY3P08 0x18
+#define PHY3P08_TX_EQ_MAIN_G1_HI GENMASK(1, 0)
+#define PHY3P08_TX_EQ_MAIN_G2 GENMASK(6, 2)
+#define PHY3P08_TX_EQ_OVRD BIT(7)
+#define PHY3P08_TX_EQ_POST_G1 GENMASK(12, 9)
+#define PHY3P08_TX_EQ_POST_G2 GENMASK(16, 13)
+#define PHY3P08_TX_EQ_PRE_G1 GENMASK(20, 17)
+#define PHY3P08_TX_EQ_PRE_G2 GENMASK(24, 21)
+#define PHY3P08_TX_IBOOST_LVL GENMASK(28, 25)
+#define PHY3P08_TX_TERM_CTRL GENMASK(31, 29)
+
+#define PHY3P0C 0x1C
+#define PHY3P0C_TX_VBOOST_EN BIT(0)
+
+#define PHY3CMD 0x40
+
+#define PHY3P_RX_EQ_CTLE_BOOST_G1_DEFAULT 0x7
+#define PHY3P_RX_EQ_CTLE_BOOST_G2_DEFAULT 0x7
+#define PHY3P_RX_EQ_DELTA_IQ_G1_DEFAULT 0x3
+#define PHY3P_RX_EQ_DELTA_IQ_G2_DEFAULT 0x5
+#define PHY3P_RX_LOS_THRESHOLD_DEFAULT 0x3
+#define PHY3P_RX_TERM_CTRL_DEFAULT 0x2
+#define PHY3P_TX_EQ_MAIN_G1_DEFAULT 0xa
+#define PHY3P_TX_EQ_MAIN_G2_DEFAULT 0x9
+#define PHY3P_TX_EQ_POST_G1_DEFAULT 0x4
+#define PHY3P_TX_EQ_POST_G2_DEFAULT 0x3
+#define PHY3P_TX_EQ_PRE_G2_DEFAULT 0x2
+#define PHY3P_TX_IBOOST_LVL_DEFAULT 0xf
+#define PHY3P_TX_TERM_CTRL_DEFAULT 0x2
+
+#define PHY3P00_DEFAULT ( \
+ PHY3P00_RX_ADAPT_AFE_EN_G1 | \
+ PHY3P00_RX_ADAPT_AFE_EN_G2 | \
+ PHY3P00_RX_ADAPT_DFE_EN_G1 | \
+ PHY3P00_RX_ADAPT_DFE_EN_G2 | \
+ FIELD_PREP(PHY3P00_RX_EQ_CTLE_BOOST_G1, PHY3P_RX_EQ_CTLE_BOOST_G1_DEFAULT) | \
+ FIELD_PREP(PHY3P00_RX_EQ_CTLE_BOOST_G2, PHY3P_RX_EQ_CTLE_BOOST_G2_DEFAULT) | \
+ FIELD_PREP(PHY3P00_RX_EQ_DELTA_IQ_G1_LO, \
+ PHY3P_RX_EQ_DELTA_IQ_G1_DEFAULT & 0x3) \
+)
+
+#define PHY3P04_DEFAULT ( \
+ FIELD_PREP(PHY3P04_RX_EQ_DELTA_IQ_G1_HI, \
+ PHY3P_RX_EQ_DELTA_IQ_G1_DEFAULT >> 2) | \
+ FIELD_PREP(PHY3P04_RX_EQ_DELTA_IQ_G2, PHY3P_RX_EQ_DELTA_IQ_G2_DEFAULT) | \
+ PHY3P04_RX_LOS_LFPS_EN | \
+ FIELD_PREP(PHY3P04_RX_LOS_THRESHOLD, PHY3P_RX_LOS_THRESHOLD_DEFAULT) | \
+ FIELD_PREP(PHY3P04_RX_TERM_CTRL, PHY3P_RX_TERM_CTRL_DEFAULT) | \
+ FIELD_PREP(PHY3P04_TX_EQ_MAIN_G1_LO, \
+ PHY3P_TX_EQ_MAIN_G1_DEFAULT & 0x7) \
+)
+
+#define PHY3P08_DEFAULT ( \
+ FIELD_PREP(PHY3P08_TX_EQ_MAIN_G1_HI, PHY3P_TX_EQ_MAIN_G1_DEFAULT >> 3) | \
+ FIELD_PREP(PHY3P08_TX_EQ_MAIN_G2, PHY3P_TX_EQ_MAIN_G2_DEFAULT) | \
+ FIELD_PREP(PHY3P08_TX_EQ_POST_G1, PHY3P_TX_EQ_POST_G1_DEFAULT) | \
+ FIELD_PREP(PHY3P08_TX_EQ_POST_G2, PHY3P_TX_EQ_POST_G2_DEFAULT) | \
+ FIELD_PREP(PHY3P08_TX_EQ_PRE_G2, PHY3P_TX_EQ_PRE_G2_DEFAULT) | \
+ FIELD_PREP(PHY3P08_TX_IBOOST_LVL, PHY3P_TX_IBOOST_LVL_DEFAULT) | \
+ FIELD_PREP(PHY3P08_TX_TERM_CTRL, PHY3P_TX_TERM_CTRL_DEFAULT) \
+)
+
+#define PHY3P0C_DEFAULT \
+ PHY3P0C_TX_VBOOST_EN
+
+struct aspeed_usb3_phy {
+ void __iomem *regs;
+ struct reset_control *rst;
+ struct device *dev;
+ struct clk *clk;
+};
+
+static int aspeed_usb3_phy_init(struct phy *phy)
+{
+ struct aspeed_usb3_phy *aspeed_phy = phy_get_drvdata(phy);
+ u32 val;
+ int ret;
+
+ ret = clk_prepare_enable(aspeed_phy->clk);
+ if (ret) {
+ dev_err(aspeed_phy->dev, "Failed to enable clock %d\n", ret);
+ return ret;
+ }
+
+ ret = reset_control_deassert(aspeed_phy->rst);
+ if (ret) {
+ clk_disable_unprepare(aspeed_phy->clk);
+ return ret;
+ }
+
+ /* Wait for USB3 PHY internal SRAM initialization done */
+ ret = readl_poll_timeout(aspeed_phy->regs + PHY3S00, val,
+ val & PHY3S00_INIT_DONE,
+ USEC_PER_MSEC, 10 * USEC_PER_MSEC);
+ if (ret) {
+ dev_err(aspeed_phy->dev, "SRAM init timeout\n");
+ goto err_assert_reset;
+ }
+
+ val = readl(aspeed_phy->regs + PHY3S00);
+ val |= PHY3S00_SRAM_BYPASS;
+ writel(val, aspeed_phy->regs + PHY3S00);
+
+ /* Set protocol1_ext signals as default PHY3 settings based on SNPS documents.
+ * Including PCFGI[54]: protocol1_ext_rx_los_lfps_en for better compatibility
+ */
+ writel(PHY3P00_DEFAULT, aspeed_phy->regs + PHY3P00);
+ writel(PHY3P04_DEFAULT, aspeed_phy->regs + PHY3P04);
+ writel(PHY3P08_DEFAULT, aspeed_phy->regs + PHY3P08);
+ writel(PHY3P0C_DEFAULT, aspeed_phy->regs + PHY3P0C);
+
+ return 0;
+
+err_assert_reset:
+ reset_control_assert(aspeed_phy->rst);
+ clk_disable_unprepare(aspeed_phy->clk);
+ return ret;
+}
+
+static int aspeed_usb3_phy_exit(struct phy *phy)
+{
+ struct aspeed_usb3_phy *aspeed_phy = phy_get_drvdata(phy);
+
+ reset_control_assert(aspeed_phy->rst);
+ clk_disable_unprepare(aspeed_phy->clk);
+
+ return 0;
+}
+
+static const struct phy_ops aspeed_usb3_phy_ops = {
+ .init = aspeed_usb3_phy_init,
+ .exit = aspeed_usb3_phy_exit,
+ .owner = THIS_MODULE,
+};
+
+static int aspeed_usb3_phy_probe(struct platform_device *pdev)
+{
+ struct aspeed_usb3_phy *aspeed_phy;
+ struct phy_provider *phy_provider;
+ struct device *dev = &pdev->dev;
+ struct phy *phy;
+
+ aspeed_phy = devm_kzalloc(dev, sizeof(*aspeed_phy), GFP_KERNEL);
+ if (!aspeed_phy)
+ return -ENOMEM;
+
+ aspeed_phy->dev = dev;
+
+ aspeed_phy->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(aspeed_phy->clk))
+ return PTR_ERR(aspeed_phy->clk);
+
+ aspeed_phy->rst = devm_reset_control_get_exclusive(dev, NULL);
+ if (IS_ERR(aspeed_phy->rst))
+ return PTR_ERR(aspeed_phy->rst);
+
+ aspeed_phy->regs = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(aspeed_phy->regs))
+ return PTR_ERR(aspeed_phy->regs);
+
+ phy = devm_phy_create(dev, NULL, &aspeed_usb3_phy_ops);
+ if (IS_ERR(phy))
+ return PTR_ERR(phy);
+
+ phy_set_drvdata(phy, aspeed_phy);
+
+ phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
+ return PTR_ERR_OR_ZERO(phy_provider);
+}
+
+static const struct of_device_id aspeed_usb3_phy_match_table[] = {
+ {
+ .compatible = "aspeed,ast2700-usb3-phy",
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, aspeed_usb3_phy_match_table);
+
+static struct platform_driver aspeed_usb3_phy_driver = {
+ .probe = aspeed_usb3_phy_probe,
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .of_match_table = aspeed_usb3_phy_match_table,
+ },
+};
+module_platform_driver(aspeed_usb3_phy_driver);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("ASPEED USB3.2 PHY Driver");
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2] wifi: mt76: add wcid publish check in mt76_sta_add
From: Thorsten Leemhuis @ 2026-07-01 6:16 UTC (permalink / raw)
To: stable@vger.kernel.org, Greg KH, Sasha Levin
Cc: Felix Fietkau, Lorenzo Bianconi, Jiajia Liu, Ryder Lee,
Shayne Chen, Sean Wang, Matthias Brugger,
AngeloGioacchino Del Regno, Ming Yen Hsieh, Leon Yen,
linux-wireless, linux-kernel, linux-arm-kernel, linux-mediatek,
Linux kernel regressions list
In-Reply-To: <akSoHk-BozrpWPmZ@nature>
On 7/1/26 07:39, Jiajia Liu wrote:
> On Tue, Jun 30, 2026 at 01:29:51PM +0200, Thorsten Leemhuis wrote:
>> On 5/28/26 05:38, Jiajia Liu wrote:
>>> Since mt7925_mac_sta_add publishes wcid, add publish check in mt76_sta_add
>>> to avoid reinitializing the wcid->poll_list.
>>>
>>> Found dev->sta_poll_list corruption when using mt7925 and 7.1-rc4.
>>
>> Jiajia Liu, Felox:
BTW: @Felix, sorry for the typo!
>> given that the problem seems to be in 7.1, should we
>> ask the stable team to pick this regression fix up, as this change was
>> mainlined (as 20b126920a259d ("wifi: mt76: add wcid publish check in
>> mt76_sta_add") [v7.2-rc1]), but lacks both a Fixes and a Stable tag?
>
> Yes. It seems to be related to cbf5e61da660 ("wifi: mt76: initialize
> more wcid fields mt76_wcid_init") [v6.14-rc1]. But I didn't reproduce
> when I checked it out and tested. So Fixes was not added.
In that case:
@Stable team, you you please pick up 20b126920a259d ("wifi: mt76: add
wcid publish check in mt76_sta_add") [v7.2-rc1] for 7.1? It lacks a
fixes tag and the problem might be older, but I saw two reports about
this with 7.1-rc -- so it seems some recent change made that problem
more likely to occur, so it might be good to fix it at least in 7.1.y.
Ciao, Thorsten
>>> According to the corruption information, prev->next was changed to itself.
>>>
>>> wlan0: disconnect from AP 90:fb:5d:94:8b:e3 for new auth to 90:fb:5d:94:8b:e2
>>> wlan0: authenticate with 90:fb:5d:94:8b:e2 (local address=84:9e:56:9c:7e:6b)
>>> wlan0: send auth to 90:fb:5d:94:8b:e2 (try 1/3)
>>> slab kmalloc-8k start ffff8c80958a6000 pointer offset 4160 size 8192
>>> list_add corruption. prev->next should be next (ffff8c808a7488f8), but was ffff8c80958a7040. (prev=ffff8c80958a7040).
>>>
>>> mt76_wcid_add_poll+0x95/0xd0 [mt76]
>>> mt7925_mac_add_txs.part.0+0xa5/0xe0 [mt7925_common]
>>> mt7925_rx_check+0xa7/0xc0 [mt7925_common]
>>> mt76_dma_rx_poll+0x50d/0x790 [mt76]
>>> mt792x_poll_rx+0x52/0xe0 [mt792x_lib]
>>>
>>> Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
>>> ---
>>>
>>> Changes in v2:
>>> - use dev->wcid table instead of adding MT_WCID_FLAG_DRV_PUBLSH for
>>> wcid publish check suggested by Sean
>>> - subject and commit message update
>>>
>>> ---
>>> drivers/net/wireless/mediatek/mt76/mac80211.c | 15 ++++++++++++---
>>> 1 file changed, 12 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
>>> index 4ae5e4715a9c..b78b4cd206e0 100644
>>> --- a/drivers/net/wireless/mediatek/mt76/mac80211.c
>>> +++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
>>> @@ -1576,6 +1576,7 @@ mt76_sta_add(struct mt76_phy *phy, struct ieee80211_vif *vif,
>>> {
>>> struct mt76_wcid *wcid = (struct mt76_wcid *)sta->drv_priv;
>>> struct mt76_dev *dev = phy->dev;
>>> + struct mt76_wcid *published;
>>> int ret;
>>> int i;
>>>
>>> @@ -1595,11 +1596,19 @@ mt76_sta_add(struct mt76_phy *phy, struct ieee80211_vif *vif,
>>> mtxq->wcid = wcid->idx;
>>> }
>>>
>>> - ewma_signal_init(&wcid->rssi);
>>> - rcu_assign_pointer(dev->wcid[wcid->idx], wcid);
>>> + published = rcu_dereference_protected(dev->wcid[wcid->idx],
>>> + lockdep_is_held(&dev->mutex));
>>> + if (published != wcid) {
>>> + WARN_ON_ONCE(published);
>>> + ewma_signal_init(&wcid->rssi);
>>> + rcu_assign_pointer(dev->wcid[wcid->idx], wcid);
>>> + mt76_wcid_init(wcid, phy->band_idx);
>>> + } else {
>>> + wcid->phy_idx = phy->band_idx;
>>> + }
>>> +
>>> phy->num_sta++;
>>>
>>> - mt76_wcid_init(wcid, phy->band_idx);
>>> out:
>>> mutex_unlock(&dev->mutex);
>>>
^ permalink raw reply
* [PATCH 0/3] can: rockchip: add RK3588 CAN-FD support
From: 1579567540 @ 2026-07-01 7:01 UTC (permalink / raw)
To: Marc Kleine-Budde, linux-can
Cc: Vincent Mailhol, kernel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, luch00
From: luch00 <1579567540@qq.com>
Add initial support for the RK3588v2 CAN-FD controller.
RK3588 integrates three CAN-FD controllers that are closely related to
the existing Rockchip CAN-FD IP already supported in the kernel, but
they cannot reuse the rk3568v2 description unchanged.
This series therefore:
- extends the existing Rockchip CAN-FD binding with the
rockchip,rk3588v2-canfd compatible
- adds a dedicated RK3588v2 match entry and devtype in the driver
- describes the three CAN-FD controller nodes in rk3588-base.dtsi
The dedicated driver data is needed because RK3588v2 encodes
RX_FIFO_CNT in bits 7:5 instead of 6:4. Runtime validation on RK3588v2
also showed that its observed errata profile differs from rk3568v2 and
rk3568v3, so using a fallback compatible would be misleading.
Tested on an embedfire,rk3588-lubancat-5io board with can0/can1
directly connected. Runtime testing used a 198 MHz CAN clock, nominal
bitrate 500 kbit/s, data bitrate 1 Mbit/s, and included stress and
error-path coverage for the existing Rockchip errata handling.
luch00 (3):
dt-bindings: can: rockchip: add rk3588v2 CAN-FD compatible
can: rockchip: add RK3588 CAN-FD support
arm64: dts: rockchip: add CAN-FD nodes for RK3588
.../net/can/rockchip,rk3568v2-canfd.yaml | 1 +
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 39 +++++++++++++++++++
.../net/can/rockchip/rockchip_canfd-core.c | 14 +++++++
drivers/net/can/rockchip/rockchip_canfd-rx.c | 5 ++-
drivers/net/can/rockchip/rockchip_canfd.h | 12 +++++-
5 files changed, 69 insertions(+), 2 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH 1/3] dt-bindings: can: rockchip: add rk3588v2 CAN-FD compatible
From: 1579567540 @ 2026-07-01 7:01 UTC (permalink / raw)
To: Marc Kleine-Budde, linux-can
Cc: Vincent Mailhol, kernel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, luch00
In-Reply-To: <20260701070128.2096267-1-1579567540@qq.com>
From: luch00 <1579567540@qq.com>
The RK3588 CAN-FD controller uses the same DT properties as the
existing Rockchip CAN-FD blocks, so extend the current schema with a
SoC-specific rockchip,rk3588v2-canfd compatible instead of creating a
new binding file.
Keep RK3588v2 as its own compatible rather than an rk3568v2 fallback.
Driver support uses separate match data and the RX FIFO count field
layout differs from rk3568v2, so a dedicated compatible is the safer
description.
Signed-off-by: luch00 <1579567540@qq.com>
---
.../devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
index a077c0330..aa31ec78e 100644
--- a/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
+++ b/Documentation/devicetree/bindings/net/can/rockchip,rk3568v2-canfd.yaml
@@ -17,6 +17,7 @@ properties:
compatible:
oneOf:
- const: rockchip,rk3568v2-canfd
+ - const: rockchip,rk3588v2-canfd
- items:
- const: rockchip,rk3568v3-canfd
- const: rockchip,rk3568v2-canfd
--
2.34.1
^ permalink raw reply related
* [PATCH 2/3] can: rockchip: add RK3588 CAN-FD support
From: 1579567540 @ 2026-07-01 7:01 UTC (permalink / raw)
To: Marc Kleine-Budde, linux-can
Cc: Vincent Mailhol, kernel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, luch00
In-Reply-To: <20260701070128.2096267-1-1579567540@qq.com>
From: luch00 <1579567540@qq.com>
Add support for the RK3588v2 CAN-FD controller by introducing a
dedicated model ID and OF match entry.
The block is closely related to the existing RK3568 variants, but it
cannot reuse their match data unchanged. In particular, RK3588v2
encodes RX_FIFO_CNT in bits 7:5 instead of 6:4, so the RX path needs
SoC-specific handling.
Validation on RK3588v2 also shows that its observed errata profile does
not fully match rk3568v2/rk3568v3, so keep a dedicated devtype for this
variant instead of relying on an rk3568 fallback.
Signed-off-by: luch00 <1579567540@qq.com>
---
drivers/net/can/rockchip/rockchip_canfd-core.c | 14 ++++++++++++++
drivers/net/can/rockchip/rockchip_canfd-rx.c | 5 ++++-
drivers/net/can/rockchip/rockchip_canfd.h | 12 +++++++++++-
3 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/rockchip/rockchip_canfd-core.c b/drivers/net/can/rockchip/rockchip_canfd-core.c
index 29de0c01e..3c2480785 100644
--- a/drivers/net/can/rockchip/rockchip_canfd-core.c
+++ b/drivers/net/can/rockchip/rockchip_canfd-core.c
@@ -50,6 +50,15 @@ static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3568v3 = {
RKCANFD_QUIRK_CANFD_BROKEN,
};
+/* Tests on the rk3588v2 reproduce Erratum 5, but not
+ * Erratum 6 or the special CAN-FD frames that trigger Error Interrupts
+ * on rk3568v2/rk3568v3.
+ */
+static const struct rkcanfd_devtype_data rkcanfd_devtype_data_rk3588v2 = {
+ .model = RKCANFD_MODEL_RK3588V2,
+ .quirks = RKCANFD_QUIRK_RK3568_ERRATUM_5,
+};
+
static const char *__rkcanfd_get_model_str(enum rkcanfd_model model)
{
switch (model) {
@@ -57,6 +66,8 @@ static const char *__rkcanfd_get_model_str(enum rkcanfd_model model)
return "rk3568v2";
case RKCANFD_MODEL_RK3568V3:
return "rk3568v3";
+ case RKCANFD_MODEL_RK3588V2:
+ return "rk3588v2";
}
return "<unknown>";
@@ -846,6 +857,9 @@ static const struct of_device_id rkcanfd_of_match[] = {
}, {
.compatible = "rockchip,rk3568v3-canfd",
.data = &rkcanfd_devtype_data_rk3568v3,
+ }, {
+ .compatible = "rockchip,rk3588v2-canfd",
+ .data = &rkcanfd_devtype_data_rk3588v2,
}, {
/* sentinel */
},
diff --git a/drivers/net/can/rockchip/rockchip_canfd-rx.c b/drivers/net/can/rockchip/rockchip_canfd-rx.c
index 475c0409e..fe64db373 100644
--- a/drivers/net/can/rockchip/rockchip_canfd-rx.c
+++ b/drivers/net/can/rockchip/rockchip_canfd-rx.c
@@ -281,7 +281,10 @@ rkcanfd_rx_fifo_get_len(const struct rkcanfd_priv *priv)
{
const u32 reg = rkcanfd_read(priv, RKCANFD_REG_RX_FIFO_CTRL);
- return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT, reg);
+ if (priv->devtype_data.model == RKCANFD_MODEL_RK3588V2)
+ return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3588, reg);
+
+ return FIELD_GET(RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3568, reg);
}
int rkcanfd_handle_rx_int(struct rkcanfd_priv *priv)
diff --git a/drivers/net/can/rockchip/rockchip_canfd.h b/drivers/net/can/rockchip/rockchip_canfd.h
index 93131c7d7..f6105b904 100644
--- a/drivers/net/can/rockchip/rockchip_canfd.h
+++ b/drivers/net/can/rockchip/rockchip_canfd.h
@@ -214,7 +214,8 @@
#define RKCANFD_REG_TXEVENT_FIFO_CTRL_TXE_FIFO_ENABLE BIT(0)
#define RKCANFD_REG_RX_FIFO_CTRL 0x118
-#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT GENMASK(6, 4)
+#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3568 GENMASK(6, 4)
+#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_CNT_RK3588 GENMASK(7, 5)
#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_FULL_WATERMARK GENMASK(3, 1)
#define RKCANFD_REG_RX_FIFO_CTRL_RX_FIFO_ENABLE BIT(0)
@@ -331,6 +332,11 @@
* rarely with the standard clock of 300 MHz, but almost immediately
* at 80 MHz.
*
+ * Test on the rk3588v2 shows the same empty FIFO condition.
+ * In that setup rx_fifo_empty_errors increments when the bus
+ * transitions from idle to high CAN-FD load and stops growing once
+ * the bus reaches a steady state.
+ *
* To workaround this problem, check for empty FIFO with
* rkcanfd_fifo_header_empty() in rkcanfd_handle_rx_int_one() and exit
* early.
@@ -424,6 +430,9 @@
* cansequence -rv -i 1
*
* - TX starvation after repeated Bus-Off
+ * Tests on the rk3588v2 show the same problem. In a
+ * 10-cycle Bus-Off recovery test, 9 cycles failed to send after the
+ * controller restarted.
* To reproduce:
* host:
* sleep 3 && cangen can0 -I2 -Li -Di -p10 -g 0.0
@@ -434,6 +443,7 @@
enum rkcanfd_model {
RKCANFD_MODEL_RK3568V2 = 0x35682,
RKCANFD_MODEL_RK3568V3 = 0x35683,
+ RKCANFD_MODEL_RK3588V2 = 0x35882,
};
struct rkcanfd_devtype_data {
--
2.34.1
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: rockchip: add CAN-FD nodes for RK3588
From: 1579567540 @ 2026-07-01 7:01 UTC (permalink / raw)
To: Marc Kleine-Budde, linux-can
Cc: Vincent Mailhol, kernel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, luch00
In-Reply-To: <20260701070128.2096267-1-1579567540@qq.com>
From: luch00 <1579567540@qq.com>
Describe the three CAN-FD controllers integrated in RK3588 in the base
SoC .dtsi.
Add CAN0, CAN1 and CAN2 nodes with their register ranges, interrupts,
clocks and resets, and keep them disabled by default so board DTS files
can enable them as needed.
Signed-off-by: luch00 <1579567540@qq.com>
---
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 39 +++++++++++++++++++
1 file changed, 39 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
index fc1fdbfd3..f38cd8bd4 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
@@ -2648,6 +2648,45 @@ dmac1: dma-controller@fea30000 {
#dma-cells = <1>;
};
+ can0: can@fea50000 {
+ compatible = "rockchip,rk3588v2-canfd";
+ reg = <0x0 0xfea50000 0x0 0x1000>;
+ interrupts = <GIC_SPI 341 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru CLK_CAN0>, <&cru PCLK_CAN0>;
+ clock-names = "baud", "pclk";
+ resets = <&cru SRST_CAN0>, <&cru SRST_P_CAN0>;
+ reset-names = "core", "apb";
+ pinctrl-names = "default";
+ pinctrl-0 = <&can0m0_pins>;
+ status = "disabled";
+ };
+
+ can1: can@fea60000 {
+ compatible = "rockchip,rk3588v2-canfd";
+ reg = <0x0 0xfea60000 0x0 0x1000>;
+ interrupts = <GIC_SPI 342 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru CLK_CAN1>, <&cru PCLK_CAN1>;
+ clock-names = "baud", "pclk";
+ resets = <&cru SRST_CAN1>, <&cru SRST_P_CAN1>;
+ reset-names = "core", "apb";
+ pinctrl-names = "default";
+ pinctrl-0 = <&can1m0_pins>;
+ status = "disabled";
+ };
+
+ can2: can@fea70000 {
+ compatible = "rockchip,rk3588v2-canfd";
+ reg = <0x0 0xfea70000 0x0 0x1000>;
+ interrupts = <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru CLK_CAN2>, <&cru PCLK_CAN2>;
+ clock-names = "baud", "pclk";
+ resets = <&cru SRST_CAN2>, <&cru SRST_P_CAN2>;
+ reset-names = "core", "apb";
+ pinctrl-names = "default";
+ pinctrl-0 = <&can2m0_pins>;
+ status = "disabled";
+ };
+
i2c1: i2c@fea90000 {
compatible = "rockchip,rk3588-i2c", "rockchip,rk3399-i2c";
reg = <0x0 0xfea90000 0x0 0x1000>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 1/3] dt-bindings: vendor-prefixes: Add graperain
From: Krzysztof Kozlowski @ 2026-07-01 7:05 UTC (permalink / raw)
To: Coia Prant
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Dragan Simic, Jonas Karlman, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260630153810.3574714-4-coiaprant@gmail.com>
On Tue, Jun 30, 2026 at 11:38:09PM +0800, Coia Prant wrote:
> Add graperain to the vendor prefixes.
>
> Link: https://www.graperain.cn/ (China)
> Link: https://www.graperain.com/ (Global)
>
> Signed-off-by: Coia Prant <coiaprant@gmail.com>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
<form letter>
This is a friendly reminder during the review process.
It looks like you received a tag and forgot to add it.
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions of patchset, under or above your Signed-off-by tag, unless
patch changed significantly (e.g. new properties added to the DT
bindings). Tag is "received", when provided in a message replied to you
on the mailing list. Tools like b4 can help here. However, there's no
need to repost patches *only* to add the tags. The upstream maintainer
will do that for tags received on the version they apply.
Please read:
https://elixir.bootlin.com/linux/v6.12-rc3/source/Documentation/process/submitting-patches.rst#L577
If a tag was not added on purpose, please state in the patch changelog
or cover letter why and what changed.
</form letter>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: arm: rockchip: Add Graperain G3568 series
From: Krzysztof Kozlowski @ 2026-07-01 7:07 UTC (permalink / raw)
To: Coia Prant
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Dragan Simic, Jonas Karlman, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260630153810.3574714-6-coiaprant@gmail.com>
On Tue, Jun 30, 2026 at 11:38:11PM +0800, Coia Prant wrote:
> Document Graperain G3568 v2
> which is a development board based on RK3568 SoC.
Broken wrapping.
Best regards,
Krzysztof
^ 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