* Re: [PATCH v4 10/10] iommu/arm-smmu-v3: Allow sharing domain across SMMUs
From: Jason Gunthorpe @ 2026-04-10 0:32 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <5293b61417f96dd58f25fe797e7d0c20dbe30da8.1773949042.git.nicolinc@nvidia.com>
On Thu, Mar 19, 2026 at 12:51:56PM -0700, Nicolin Chen wrote:
> @@ -987,6 +988,32 @@ struct arm_smmu_nested_domain {
> __le64 ste[2];
> };
>
> +static inline bool
> +arm_smmu_domain_can_share(struct arm_smmu_domain *smmu_domain,
> + struct arm_smmu_device *new_smmu)
> +{
Probably a bit big for an inline
> + struct io_pgtable *pgtbl =
> + io_pgtable_ops_to_pgtable(smmu_domain->pgtbl_ops);
> +
> + if (pgtbl->fmt == ARM_64_LPAE_S1 &&
> + !(new_smmu->features & ARM_SMMU_FEAT_TRANS_S1))
> + return false;
> + if (pgtbl->fmt == ARM_64_LPAE_S2 &&
> + !(new_smmu->features & ARM_SMMU_FEAT_TRANS_S2))
> + return false;
> + if (pgtbl->cfg.pgsize_bitmap & ~new_smmu->pgsize_bitmap)
> + return false;
I think this should check the lowest set bit in the
domain->pgsize_bitmap is set in new_smmu->pgsize_bitmap
ie that the selected tg is supported.
The cfg.pgsize_bitmap is something a little different IIRC
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
* Re: [PATCH v4 09/10] iommu/arm-smmu-v3: Remove ASID/VMID from arm_smmu_domain
From: Jason Gunthorpe @ 2026-04-10 0:27 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <b6d87a722635d29e896b277cb60f0208859073d6.1773949042.git.nicolinc@nvidia.com>
On Thu, Mar 19, 2026 at 12:51:55PM -0700, Nicolin Chen wrote:
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> index 846a278fa5469..0e48264ccd01b 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
> @@ -300,14 +300,6 @@ static void arm_smmu_sva_domain_free(struct iommu_domain *domain)
> */
> arm_smmu_domain_inv(smmu_domain);
>
> - /*
> - * Notice that the arm_smmu_mm_arch_invalidate_secondary_tlbs op can
> - * still be called/running at this point. We allow the ASID to be
> - * reused, and if there is a race then it just suffers harmless
> - * unnecessary invalidation.
> - */
> - xa_erase(&arm_smmu_asid_xa, smmu_domain->cd.asid);
> -
I don't think this artifact has disappeared so the comment should
probably remain too. It has become slightly different because it is
now running under RCU protections so it will clear alot faster.
Otherwise
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
* Re: [PATCH v4 08/10] iommu/arm-smmu-v3: Allocate INV_TYPE_S2_VMID_VSMMU in arm_vsmmu_init
From: Jason Gunthorpe @ 2026-04-10 0:19 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <05dd00dcb2f0d077f59bcbccac1820534ad7b5cf.1773949042.git.nicolinc@nvidia.com>
On Thu, Mar 19, 2026 at 12:51:54PM -0700, Nicolin Chen wrote:
> VMID owned by a vSMMU should be allocated in the viommu_init callback for
> - a straightforward lifecycle for a VMID used by a vSMMU
> - HW like tegra241-cmdqv needs to setup VINTF with the VMID
>
> Allocate/free a VMID in arm_vsmmu_init/destroy(). This decouples the VMID
> owned by vSMMU from the VMID living in the S2 parent domain (s2_cfg.vmid).
>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 +
> .../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 26 ++++++++++++++++---
> .../iommu/arm/arm-smmu-v3/tegra241-cmdqv.c | 1 +
> 3 files changed, 25 insertions(+), 3 deletions(-)
Yeah, this is exactly right now.. The vmid exists for the duration of
viommu and gets installed in the invs list when the s2 is actually
attached to a device.
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
* Re: [PATCH v3 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
From: Nicolin Chen @ 2026-04-10 0:04 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Tian, Kevin, will@kernel.org, robin.murphy@arm.com,
bhelgaas@google.com, joro@8bytes.org, praan@google.com,
baolu.lu@linux.intel.com, miko.lenczewski@arm.com,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
Williams, Dan J, jonathan.cameron@huawei.com, Vikram Sethi,
linux-cxl@vger.kernel.org
In-Reply-To: <20260409225252.GU3357077@nvidia.com>
On Thu, Apr 09, 2026 at 07:52:52PM -0300, Jason Gunthorpe wrote:
> On Thu, Apr 09, 2026 at 03:45:26PM -0700, Nicolin Chen wrote:
>
> > One question regarding VM case: if a device is ats_always_on, while
> > VM somehow doesn't set nested_domain->enable_ats. Should the kernel
> > at least spit a warning, given that it would surely fail the device?
>
> No, just let break, the resulting failure has to be contained to the
> VM or the platform is broken..
>
> The HV can't turn on ATS because we it can't know what invalidations
> to push so not much other choice.
I see. Thanks
Nicolin
^ permalink raw reply
* Re: [PATCH v4 07/10] iommu/arm-smmu-v3: Allocate IOTLB cache tag if no id to reuse
From: Jason Gunthorpe @ 2026-04-10 0:04 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <aea51cbf226d90436918dc09df5cf8f5c64ef8bb.1773949042.git.nicolinc@nvidia.com>
On Thu, Mar 19, 2026 at 12:51:53PM -0700, Nicolin Chen wrote:
> An IOTLB tag now is forwarded from arm_smmu_domain_get_iotlb_tag() to its
> final destination (a CD or STE entry).
>
> Thus, arm_smmu_domain_get_iotlb_tag() can safely delink its references to
> the cd->asid and s2_cfg->vmid in the smmu_domain. Instead, allocate a new
> IOTLB cache tag from the xarray/ida.
>
> The old ASID and VMID in the smmu_domain will be deprecated, once VMID is
> decoupled in the vSMMU use case too.
>
> Since invst->new_invs->inv[0] and invst->tag are basically the same thing,
> merge arm_smmu_inv_flush_iotlb_tag() into arm_smmu_iotlb_tag_free().
>
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 63 +++++++++++++--------
> 1 file changed, 38 insertions(+), 25 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
* Re: [PATCH v4 06/10] iommu/arm-smmu-v3: Introduce INV_TYPE_S2_VMID_VSMMU
From: Jason Gunthorpe @ 2026-04-09 23:59 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <c514aa533257ce67bf28645863abf5eaab437996.1773949042.git.nicolinc@nvidia.com>
On Thu, Mar 19, 2026 at 12:51:52PM -0700, Nicolin Chen wrote:
> @@ -655,6 +655,7 @@ struct arm_smmu_cmdq_batch {
> enum arm_smmu_inv_type {
> INV_TYPE_S1_ASID,
> INV_TYPE_S2_VMID,
> + INV_TYPE_S2_VMID_VSMMU,
> INV_TYPE_S2_VMID_S1_CLEAR,
> INV_TYPE_ATS,
> INV_TYPE_ATS_FULL,
> @@ -3246,7 +3248,10 @@ int arm_smmu_find_iotlb_tag(struct iommu_domain *domain,
> tag->type = INV_TYPE_S1_ASID;
> break;
> case ARM_SMMU_DOMAIN_S2:
> - tag->type = INV_TYPE_S2_VMID;
> + if (to_vsmmu(domain))
> + tag->type = INV_TYPE_S2_VMID_VSMMU;
> + else
> + tag->type = INV_TYPE_S2_VMID;
> break;
This shouldn't search, the vmid always comes from the vsmmu struct.
arm_smmu_alloc_iotlb_tag() fixes it after, but the call in
arm_smmu_attach_prepare_invs() should also only be using the
vsmmu->vmid so this is a bug.
Just set tag->id here and return. Move the tag->smmu up so that is
safe.
> @@ -3357,7 +3369,7 @@ arm_smmu_master_build_invs(struct arm_smmu_master *master, bool ats_enabled,
> return NULL;
>
> /* All the nested S1 ASIDs have to be flushed when S2 parent changes */
> - if (nesting) {
> + if (tag->type == INV_TYPE_S2_VMID_VSMMU) {
> if (!arm_smmu_master_build_inv(master,
> INV_TYPE_S2_VMID_S1_CLEAR,
> tag->id, IOMMU_NO_PASID, 0))
I think this function should not mix nesting and type at the same
time..
If INV_TYPE_S2_VMID_VSMMU means the tag is used as a nesting child
then that should also drive the atc decision:
if (!arm_smmu_master_build_inv(
master, nesting ? INV_TYPE_ATS_FULL : INV_TYPE_ATS,
master->streams[i].id, ssid, 0))
Because it is exactly the same reasoning for the IOTLB full
invalidation.
This is the only place reading domain->nest_parent so we can get rid
of it too, instead it effectively becomes driven by tag which derives
the S2_VMID from domain->type == IOMMU_DOMAIN_NESTED
Jason
^ permalink raw reply
* Re: [PATCH v5 0/4] firmware: ti_sci: Introduce BOARDCFG_MANAGED mode for Jacinto family
From: Kendall Willis @ 2026-04-09 23:50 UTC (permalink / raw)
To: Thomas Richard (TI), Nishanth Menon, Tero Kristo,
Santosh Shilimkar, Michael Turquette, Stephen Boyd
Cc: Gregory CLEMENT, richard.genoud, Udit Kumar, Prasanth Mantena,
Abhash Kumar, Thomas Petazzoni, linux-arm-kernel, linux-kernel,
linux-clk, Dhruva Gole
In-Reply-To: <20260407-ti-sci-jacinto-s2r-restore-irq-v5-0-97b28f2d93f9@bootlin.com>
On 4/7/26 09:25, Thomas Richard (TI) wrote:
> This is the 5th iteration of this series. Nothing new, I just rebased on
> v7.0-rc7, added Dhruva's RB tags, and use kzalloc_obj() in Patch 2.
>
> Best Regards,
> Thomas
>
> Signed-off-by: Thomas Richard (TI) <thomas.richard@bootlin.com>
For the series,
Reviewed-by: Kendall Willis <k-willis@ti.com>
> ---
> Changes in v5:
> - rebase on v7.0-rc7.
> - add Dhruva's RB tag.
> - use kzalloc_obj() in ti_sci driver.
> - Link to v4: https://lore.kernel.org/r/20260204-ti-sci-jacinto-s2r-restore-irq-v4-0-67820af39eac@bootlin.com
>
> Changes in v4:
> - rebase on linux-next next-20260202.
> - fix BOARDCFG_MANAGED value.
> - add MSG_FLAG_CAPS_LPM_IRQ_CONTEXT_LOST firmware capability.
> - add MSG_FLAG_CAPS_LPM_CLK_CONTEXT_LOST firmware capability.
> - Link to v3: https://lore.kernel.org/r/20251205-ti-sci-jacinto-s2r-restore-irq-v3-0-d06963974ad4@bootlin.com
>
> Changes in v3:
> - rebased on linux-next
> - sci-clk: context_restore() operation restores also rate.
> - Link to v2: https://lore.kernel.org/r/20251127-ti-sci-jacinto-s2r-restore-irq-v2-0-a487fa3ff221@bootlin.com
>
> Changes in v2:
> - ti_sci: use hlist to store IRQs.
> - sci-clk: add context_restore operation
> - ti_sci: restore clock parents during resume
> - Link to v1: https://lore.kernel.org/r/20251017-ti-sci-jacinto-s2r-restore-irq-v1-0-34d4339d247a@bootlin.com
>
> ---
> Thomas Richard (TI) (4):
> firmware: ti_sci: add BOARDCFG_MANAGED mode support
> firmware: ti_sci: add support for restoring IRQs during resume
> clk: keystone: sci-clk: add restore_context() operation
> firmware: ti_sci: add support for restoring clock context during resume
>
> drivers/clk/keystone/sci-clk.c | 42 +++++++++--
> drivers/firmware/ti_sci.c | 164 ++++++++++++++++++++++++++++++++++++++---
> drivers/firmware/ti_sci.h | 6 ++
> 3 files changed, 192 insertions(+), 20 deletions(-)
> ---
> base-commit: d843b67129e266054d8fa2e41e270a9f779381bd
> change-id: 20251010-ti-sci-jacinto-s2r-restore-irq-428e008fd10c
>
> Best regards,
^ permalink raw reply
* Re: [PATCH v4 04/10] iommu/arm-smmu-v3: Pass in IOTLB cache tag to arm_smmu_master_build_invs()
From: Jason Gunthorpe @ 2026-04-09 23:43 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <87419a1f7371643959a037f1ee7119ffa054a9a1.1773949042.git.nicolinc@nvidia.com>
On Thu, Mar 19, 2026 at 12:51:50PM -0700, Nicolin Chen wrote:
> Now struct arm_smmu_attach_state carrys an IOTLB cache tag in invst->tag.
>
> Instead of getting the tag from smmu_domain again, pass in the invst->tag
> to arm_smmu_master_build_invs(). This could simplify the function.
/This could simplify/This does simplify/
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
* Re: [PATCH v4 03/10] iommu/arm-smmu-v3: Store IOTLB cache tags in struct arm_smmu_attach_state
From: Jason Gunthorpe @ 2026-04-09 23:42 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <ceb8150f229ee7bd355ec42d23e422ae2185492e.1773949042.git.nicolinc@nvidia.com>
On Thu, Mar 19, 2026 at 12:51:49PM -0700, Nicolin Chen wrote:
> So far, an IOTLB tag (ASID or VMID) has been stored in the arm_smmu_domain
> +static int __arm_smmu_domain_find_iotlb_tag(struct arm_smmu_domain *smmu_domain,
> + struct arm_smmu_inv *tag)
> +{
> + struct arm_smmu_invs *invs = rcu_dereference_protected(
> + smmu_domain->invs, lockdep_is_held(&arm_smmu_asid_lock));
> + size_t i;
> +
> + arm_smmu_inv_assert_iotlb_tag(tag);
> +
> + for (i = 0; i != invs->num_invs; i++) {
> + if (invs->inv[i].type == tag->type &&
> + invs->inv[i].smmu == tag->smmu &&
> + READ_ONCE(invs->inv[i].users)) {
> + *tag = invs->inv[i];
This users thing has become to hard to understand and it isn't how it
should be.
All writers *with the possibility of concurrent access* need to use
WRITE_ONCE since there is a RCU reader. IIRC that is just
arm_smmu_invs_unref()
The one in arm_smmu_invs_merge() is just writing to newly allocated
memory so it shouldn't be marked.
Only readers *with the possibility of concurrent access* should be
marked with READ_ONCE. IIRC this is just the invalidation walker.
Places like this have to be protected by a lock or the whole thing is
wrong, so it should have a lockdep annoation.
Now what is the locking supposed to be? It looks wrong, it probably
wants to be arm_smmu_asid_lock, but arm_smmu_mm_release() doesn't grab
it.
But why does arm_smmu_mm_release() need a tag in the first place? ASID
isn't going to be used when EPD0|EPD1 is set, so the tag can just be
0. Probably make a patch with that change early on..
All the locking is important because this:
> +/* Find an existing IOTLB cache tag in smmu_domain->invs (users counter != 0) */
Must be held as an invarient into the caller, meaning the caller must
hold arm_smmu_asid_lock while it has an active tag on the stack, and
that should be documented here. As well as a lockdep of course.
From what I can tell the final result is correct (aside from
arm_smmu_mm_release), just under documented.
> +int arm_smmu_find_iotlb_tag(struct iommu_domain *domain,
> + struct arm_smmu_device *smmu,
> + struct arm_smmu_inv *tag)
> +{
> + struct arm_smmu_domain *smmu_domain = to_smmu_domain_devices(domain);
> +
> + if (WARN_ON(!smmu_domain))
> + return -EINVAL;
> +
> + /* Decide the type of the iotlb cache tag */
> + switch (smmu_domain->stage) {
> + case ARM_SMMU_DOMAIN_SVA:
> + case ARM_SMMU_DOMAIN_S1:
> + tag->type = INV_TYPE_S1_ASID;
> + break;
> + case ARM_SMMU_DOMAIN_S2:
> + tag->type = INV_TYPE_S2_VMID;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + tag->smmu = smmu;
> +
> + return __arm_smmu_domain_find_iotlb_tag(smmu_domain, tag);
This is the only caller it probably doesn't need a special __
function..
> +/* Allocate a new IOTLB cache tag (users counter == 0) */
> +static int arm_smmu_alloc_iotlb_tag(struct iommu_domain *domain,
> + struct arm_smmu_device *smmu,
> + struct arm_smmu_inv *tag)
> +{
> + struct arm_smmu_domain *smmu_domain = to_smmu_domain_devices(domain);
> + int ret;
> +
> + /* Only allocate if there is no IOTLB cache tag to re-use */
> + ret = arm_smmu_find_iotlb_tag(domain, smmu, tag);
> + if (!ret || ret != -ENOENT)
> + return ret;
Lets not call the function 'alloc_iotlb_tag' if it doesn't always
allocate.. 'get_iotlb_tag' more implies the find or allocate behavior.
Again the locking is important and the caller must ensure it holds the
asid_lock while the tag is alive on the stack. Mention it in the kdoc.
> +
> + /* FIXME replace with an actual allocation from the bitmap */
> + if (tag->type == INV_TYPE_S1_ASID)
> + tag->id = smmu_domain->cd.asid;
> + else
> + tag->id = smmu_domain->s2_cfg.vmid;
I don't usually put FIXMEs that will be fixed in the next patches.
Jason
^ permalink raw reply
* Re: [PATCH v4 02/10] iommu/arm-smmu-v3: Pass in arm_smmu_make_cd_fn to arm_smmu_set_pasid()
From: Jason Gunthorpe @ 2026-04-09 23:17 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <d629f81f2a30bb6fa06ec00b35134cb6bab80a48.1773949042.git.nicolinc@nvidia.com>
On Thu, Mar 19, 2026 at 12:51:48PM -0700, Nicolin Chen wrote:
> To install a domain (CD) to a substream, the common flow in the driver is:
> - Make an S1 or SVA CD outside arm_smmu_asid_lock
> - Invoke arm_smmu_set_pasid() where it takes arm_smmu_asid_lock, and fix
> the ASID in the CD.
>
> The reason for such a flow is for the timing of arm_smmu_asid_lock, since
> it was too early to take the mutex outside the function.
>
> Tidy it up by passing in a function pointer for CD making,, which supports
> both existing functions: arm_smmu_make_s1_cd() and arm_smmu_make_sva_cd().
>
> Then arm_smmu_set_pasid() can make a CD inside the lock where ASID is safe
> to access.
>
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 7 ++++++-
> .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 4 ++--
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 19 ++++---------------
> 3 files changed, 12 insertions(+), 18 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
* Re: [PATCH v4 01/10] iommu/arm-smmu-v3: Add a wrapper for arm_smmu_make_sva_cd()
From: Jason Gunthorpe @ 2026-04-09 23:14 UTC (permalink / raw)
To: Nicolin Chen
Cc: will, robin.murphy, joro, jpb, praan, smostafa, linux-arm-kernel,
iommu, linux-kernel, linux-tegra, jonathan.cameron
In-Reply-To: <7889322d41b1d8fa83bb318df2bd705a6241f6b1.1773949042.git.nicolinc@nvidia.com>
On Thu, Mar 19, 2026 at 12:51:47PM -0700, Nicolin Chen wrote:
> Rename the existing arm_smmu_make_sva_cd() to __arm_smmu_make_sva_cd().
>
> Add a higher-level wrapper arm_smmu_make_s1_cd() receiving smmu_domain
> and master pointers, aligning with arm_smmu_make_s1_cd(). Then, the two
> function can share a common typedef function pointer.
>
> No functional changes.
>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 6 ++---
> .../iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 22 +++++++++++++------
> .../iommu/arm/arm-smmu-v3/arm-smmu-v3-test.c | 4 ++--
> 3 files changed, 20 insertions(+), 12 deletions(-)
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Jason
^ permalink raw reply
* ✅ PASS (MISSED 51 of 56): Test report for for-kernelci (7.0.0-rc7, upstream-arm-next, 222ce592)
From: cki-project @ 2026-04-09 23:13 UTC (permalink / raw)
To: will, catalin.marinas, linux-arm-kernel
Hi, we tested your kernel and here are the results:
Overall result: PASSED
Merge: OK
Compile: OK
Test: OK
Tested-by: CKI Project <cki-project@redhat.com>
Kernel information:
Commit message: Merge remote-tracking branch 'origin/nocache-cleanup' into for-kernelci
You can find all the details about the test run at
https://datawarehouse.cki-project.org/kcidb/checkouts/redhat:2442210584
Tests that were not ran because of internal issues:
/distribution/check-install [aarch64]
/distribution/command [aarch64]
/test/misc/machineinfo [aarch64]
Boot test [aarch64]
CKI/restraint [aarch64]
Hardware - Firmware test suite [aarch64]
Reboot test [aarch64]
SELinux Custom Module Setup [aarch64]
selinux-policy: serge-testsuite [aarch64]
Storage - blktests - throtl [aarch64]
Storage - blktests - ublk [aarch64]
stress: stress-ng - cpu-cache [aarch64]
stress: stress-ng - memory [aarch64]
xfstests - btrfs [aarch64]
xfstests - ext4 [aarch64]
xfstests - xfs [aarch64]
If you find a failure unrelated to your changes, please ask the test maintainer to review it.
This will prevent the failures from being incorrectly reported in the future.
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests
From: Yang Shi @ 2026-04-09 23:08 UTC (permalink / raw)
To: Catalin Marinas
Cc: Kevin Brodsky, Ryan Roberts, Will Deacon, David Hildenbrand (Arm),
Dev Jain, Suzuki K Poulose, Jinjiang Tu, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <adfw_hNDsIWwSAIv@arm.com>
On 4/9/26 11:33 AM, Catalin Marinas wrote:
> On Thu, Apr 09, 2026 at 09:48:58AM -0700, Yang Shi wrote:
>> On 4/9/26 8:20 AM, Catalin Marinas wrote:
>>> On Thu, Apr 09, 2026 at 11:53:41AM +0200, Kevin Brodsky wrote:
>>>> What would make more sense to me is to enable the use of BBML2-noabort
>>>> unconditionally if !force_pte_mapping(). We can then have
>>>> can_set_direct_map() return true if we have BBML2-noabort, and we no
>>>> longer need to check it in map_mem().
>>> Indeed.
>> I'm trying to wrap up my head for this discussion. IIUC, if none of the
>> features is enabled, it means we don't need do anything because the direct
>> map is not changed. For example, if vmalloc doesn't change direct map
>> permission when rodata != full, there is no need to call
>> set_direct_map_*_noflush(). So unconditionally checking BBML2_NOABORT will
>> change the behavior unnecessarily. Did I miss something?
>>
>> I think the only exception is secretmem if I don't miss something.
>> Currently, secretmem is actually not supported if none of the features is
>> enabled. But BBML2_NOABORT allows to lift the restriction.
> Yes, it's secretmem only AFAICT. I think execmem will only change the
> linear map if rodata_full anyway.
Yes, execmem calls set_memory_rox(), which won't change linear map
permission if rodata_full is not enabled.
Thanks,
Yang
>
^ permalink raw reply
* Re: [PATCH RFC net-next 02/10] net: stmmac: rename dev_id to userver
From: Jitendra Vegiraju @ 2026-04-09 23:07 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, Chen-Yu Tsai,
David S. Miller, Eric Dumazet, Jakub Kicinski, linux-arm-kernel,
linux-stm32, linux-sunxi, netdev, Paolo Abeni, Samuel Holland
In-Reply-To: <E1wAPBR-0000000F7ju-1fD9@rmk-PC.armlinux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 4607 bytes --]
Hi Russell,
On Wed, Apr 8, 2026 at 2:27 AM Russell King (Oracle)
<rmk+kernel@armlinux.org.uk> wrote:
>
> The Synopsys Databook and several implementation TRMs identify bits
> 15:8 of the version register in dwmac v3.xx and v4.xx as "userver".
> We even print its value with "User ID". Rather than using "dev_id",
> use "userver" instead.
>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
> drivers/net/ethernet/stmicro/stmmac/hwif.c | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.c b/drivers/net/ethernet/stmicro/stmmac/hwif.c
> index 3774af66db48..830ff816ab4f 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/hwif.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/hwif.c
> @@ -15,7 +15,7 @@
>
> struct stmmac_version {
> u8 snpsver;
> - u8 dev_id;
> + u8 userver;
> };
From the XGMAC databook that I have access to bits(15:8) identify the
DEVID field of MAC_version register.
The userver field is from bits(23:16) of the same register. This is a
customer defined field (configured with coreConsultant).
Currently stmmac doesn't care about bits(23:16).
I think the confusion is coming from macro name in common.h
#define DWMAC_USERVER GENMASK_U32(15, 8)
This should be named
#define DWMAC_DEVID GENMASK_U32(15, 8)
Hope someone with access to another databook can confirm this.
>
> static void stmmac_get_version(struct stmmac_priv *priv,
> @@ -26,7 +26,7 @@ static void stmmac_get_version(struct stmmac_priv *priv,
> u32 version;
>
> ver->snpsver = 0;
> - ver->dev_id = 0;
> + ver->userver = 0;
>
> if (core_type == DWMAC_CORE_MAC100)
> return;
> @@ -48,7 +48,7 @@ static void stmmac_get_version(struct stmmac_priv *priv,
>
> ver->snpsver = FIELD_GET(DWMAC_SNPSVER, version);
> if (core_type == DWMAC_CORE_XGMAC)
> - ver->dev_id = FIELD_GET(DWMAC_USERVER, version);
> + ver->userver = FIELD_GET(DWMAC_USERVER, version);
> }
>
> static void stmmac_dwmac_mode_quirk(struct stmmac_priv *priv)
> @@ -111,7 +111,7 @@ int stmmac_reset(struct stmmac_priv *priv)
> static const struct stmmac_hwif_entry {
> enum dwmac_core_type core_type;
> u32 min_snpsver;
> - u32 dev_id;
> + u32 userver;
> const struct stmmac_regs_off regs;
> const void *desc;
> const void *dma;
> @@ -247,7 +247,7 @@ static const struct stmmac_hwif_entry {
> }, {
> .core_type = DWMAC_CORE_XGMAC,
> .min_snpsver = DWXGMAC_CORE_2_10,
> - .dev_id = DWXGMAC_ID,
> + .userver = DWXGMAC_ID,
> .regs = {
> .ptp_off = PTP_XGMAC_OFFSET,
> .mmc_off = MMC_XGMAC_OFFSET,
> @@ -269,7 +269,7 @@ static const struct stmmac_hwif_entry {
> }, {
> .core_type = DWMAC_CORE_XGMAC,
> .min_snpsver = DWXLGMAC_CORE_2_00,
> - .dev_id = DWXLGMAC_ID,
> + .userver = DWXLGMAC_ID,
> .regs = {
> .ptp_off = PTP_XGMAC_OFFSET,
> .mmc_off = MMC_XGMAC_OFFSET,
> @@ -291,7 +291,7 @@ static const struct stmmac_hwif_entry {
> };
>
> static const struct stmmac_hwif_entry *
> -stmmac_hwif_find(enum dwmac_core_type core_type, u8 snpsver, u8 dev_id)
> +stmmac_hwif_find(enum dwmac_core_type core_type, u8 snpsver, u8 userver)
> {
> const struct stmmac_hwif_entry *entry;
> int i;
> @@ -305,7 +305,7 @@ stmmac_hwif_find(enum dwmac_core_type core_type, u8 snpsver, u8 dev_id)
> if (snpsver < entry->min_snpsver)
> continue;
> if (core_type == DWMAC_CORE_XGMAC &&
> - dev_id != entry->dev_id)
> + userver != entry->userver)
> continue;
>
> return entry;
> @@ -358,7 +358,7 @@ int stmmac_hwif_init(struct stmmac_priv *priv)
> /* Fallback to generic HW */
>
> /* Use synopsys_id var because some setups can override this */
> - entry = stmmac_hwif_find(core_type, priv->synopsys_id, version.dev_id);
> + entry = stmmac_hwif_find(core_type, priv->synopsys_id, version.userver);
> if (!entry) {
> dev_err(priv->device,
> "Failed to find HW IF (id=0x%x, gmac=%d/%d)\n",
> --
> 2.47.3
>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5435 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
From: Jason Gunthorpe @ 2026-04-09 22:52 UTC (permalink / raw)
To: Nicolin Chen
Cc: Tian, Kevin, will@kernel.org, robin.murphy@arm.com,
bhelgaas@google.com, joro@8bytes.org, praan@google.com,
baolu.lu@linux.intel.com, miko.lenczewski@arm.com,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
Williams, Dan J, jonathan.cameron@huawei.com, Vikram Sethi,
linux-cxl@vger.kernel.org
In-Reply-To: <adgsBgXYy68GmxAf@Asurada-Nvidia>
On Thu, Apr 09, 2026 at 03:45:26PM -0700, Nicolin Chen wrote:
> One question regarding VM case: if a device is ats_always_on, while
> VM somehow doesn't set nested_domain->enable_ats. Should the kernel
> at least spit a warning, given that it would surely fail the device?
No, just let break, the resulting failure has to be contained to the
VM or the platform is broken..
The HV can't turn on ATS because we it can't know what invalidations
to push so not much other choice.
Jason
^ permalink raw reply
* Re: [PATCH v3 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
From: Nicolin Chen @ 2026-04-09 22:45 UTC (permalink / raw)
To: Tian, Kevin
Cc: jgg@nvidia.com, will@kernel.org, robin.murphy@arm.com,
bhelgaas@google.com, joro@8bytes.org, praan@google.com,
baolu.lu@linux.intel.com, miko.lenczewski@arm.com,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
Williams, Dan J, jonathan.cameron@huawei.com, Vikram Sethi,
linux-cxl@vger.kernel.org
In-Reply-To: <BN9PR11MB5276A6B1B103C4B0201458348C53A@BN9PR11MB5276.namprd11.prod.outlook.com>
On Tue, Mar 31, 2026 at 08:19:19AM +0000, Tian, Kevin wrote:
> > From: Nicolin Chen <nicolinc@nvidia.com>
> > Sent: Saturday, March 7, 2026 7:41 AM
> >
> > Controlled by the IOMMU driver, ATS is usually enabled "on demand" when
> > a
> > device requests a translation service from its associated IOMMU HW running
> > on the channel of a given PASID. This is working even when a device has no
> > translation on its RID (i.e., the RID is IOMMU bypassed).
>
> ATS is usually enabled "on demand" when a given PASID on the device
> is attached to an I/O page table. Above sounds like there will be a software
> action to enable ATS upon a device translation request.
> > +/*
> > + * CXL r4.0, sec 3.2.5.13 Memory Type on CXL.cache notes: to source
> > requests on
> > + * CXL.cache, devices need to get the Host Physical Address (HPA) from the
> > Host
> > + * by means of an ATS request on CXL.io.
> > + *
> > + * In other world, CXL.cache devices cannot access host physical memory
> > without
> > + * ATS.
> > + */
>
> s/world/words/
I have updated commit messages and inline comments. Thanks all for
the reviews!
One question regarding VM case: if a device is ats_always_on, while
VM somehow doesn't set nested_domain->enable_ats. Should the kernel
at least spit a warning, given that it would surely fail the device?
Nicolin
^ permalink raw reply
* [PATCH RFC v2] drm/rockchip: vop2: Add clock rate mode check
From: Sebastian Reichel @ 2026-04-09 21:34 UTC (permalink / raw)
To: Sandy Huang, Heiko Stübner, Andy Yan
Cc: Daniel Stone, Alexey Charkov, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, dri-devel,
linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
Sebastian Reichel
The display might offer modes, which exceed the maximum clock rate of a
video output. This usually happens for displays that offer refresh rates
above 60 Hz. This results in no picture (or a broken one) being displayed
without manual intervention. Fix this by teaching the driver about the
maximum achievable clock rates for each video port.
The information about the maximum clock rates for each video channel and
the tip about multiple pixels being processed per clock were provided by
Andy Yan and roughly checked against the information available in the
datasheet (which specifies limits like "2560x1600@60Hz with 10-bit"
instead of a specific pixel rate).
For the video ports supporting a 600 MHz input clock, there is some
logic to handle up to 4 pixels in parallel when needed resulting in
the extra multiplier.
Suggested-by: Andy Yan <andy.yan@rock-chips.com>
Link: https://lore.kernel.org/linux-rockchip/1528d788.186b.19d08ed974c.Coremail.andyshrk@163.com/
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
I've kept the RFC tag, as I'm not sure about the 4x parallel pixel
processing. IIUIC all of the video ports with a maximum of 600 MHz
input clock support it, considering they can go to 4K @ 120Hz,
which is above 1.2GHz while Andy mentioned a max. support clock rate
of 600 MHz.
---
Changes in v2:
- Link to v1: https://lore.kernel.org/r/20260217-vop2-clk-rate-check-v1-1-989b569119ba@collabora.com
- based on v7.0-rc7
- rename max_clock_rate into max_pixel_clock_rate to distinguish from
input clock
- update max clock rates to the numbers provided by Andy Yan with
extra 4x multiplier for 4K 120Hz VPs
---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 3 +++
drivers/gpu/drm/rockchip/rockchip_drm_vop2.h | 1 +
drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 10 ++++++++++
3 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index a195f5c819a2..35a0edda5375 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -1434,6 +1434,9 @@ static enum drm_mode_status vop2_crtc_mode_valid(struct drm_crtc *crtc,
if (mode->hdisplay > vp->data->max_output.width)
return MODE_BAD_HVALUE;
+ if (mode->clock > vp->data->max_pixel_clock_rate / 1000)
+ return MODE_CLOCK_HIGH;
+
return MODE_OK;
}
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
index 9124191899ba..fd46913f3346 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
@@ -225,6 +225,7 @@ struct vop2_video_port_data {
u16 gamma_lut_len;
u16 cubic_lut_len;
struct vop_rect max_output;
+ u32 max_pixel_clock_rate;
const u8 pre_scan_max_dly[4];
unsigned int offset;
/**
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
index f3950e8476a7..6ae3d506c476 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop2_reg.c
@@ -559,18 +559,21 @@ static const struct vop2_video_port_data rk3568_vop_video_ports[] = {
.gamma_lut_len = 1024,
.cubic_lut_len = 9 * 9 * 9,
.max_output = { 4096, 2304 },
+ .max_pixel_clock_rate = 600000000U,
.pre_scan_max_dly = { 69, 53, 53, 42 },
.offset = 0xc00,
}, {
.id = 1,
.gamma_lut_len = 1024,
.max_output = { 2048, 1536 },
+ .max_pixel_clock_rate = 200000000U,
.pre_scan_max_dly = { 40, 40, 40, 40 },
.offset = 0xd00,
}, {
.id = 2,
.gamma_lut_len = 1024,
.max_output = { 1920, 1080 },
+ .max_pixel_clock_rate = 150000000U,
.pre_scan_max_dly = { 40, 40, 40, 40 },
.offset = 0xe00,
},
@@ -775,6 +778,7 @@ static const struct vop2_video_port_data rk3576_vop_video_ports[] = {
.gamma_lut_len = 1024,
.cubic_lut_len = 9 * 9 * 9, /* 9x9x9 */
.max_output = { 4096, 2304 },
+ .max_pixel_clock_rate = 600000000U * 4,
/* win layer_mix hdr */
.pre_scan_max_dly = { 10, 8, 2, 0 },
.offset = 0xc00,
@@ -785,6 +789,7 @@ static const struct vop2_video_port_data rk3576_vop_video_ports[] = {
.gamma_lut_len = 1024,
.cubic_lut_len = 729, /* 9x9x9 */
.max_output = { 2560, 1600 },
+ .max_pixel_clock_rate = 300000000U,
/* win layer_mix hdr */
.pre_scan_max_dly = { 10, 6, 0, 0 },
.offset = 0xd00,
@@ -793,6 +798,7 @@ static const struct vop2_video_port_data rk3576_vop_video_ports[] = {
.id = 2,
.gamma_lut_len = 1024,
.max_output = { 1920, 1080 },
+ .max_pixel_clock_rate = 150000000U,
/* win layer_mix hdr */
.pre_scan_max_dly = { 10, 6, 0, 0 },
.offset = 0xe00,
@@ -1061,6 +1067,7 @@ static const struct vop2_video_port_data rk3588_vop_video_ports[] = {
.gamma_lut_len = 1024,
.cubic_lut_len = 9 * 9 * 9, /* 9x9x9 */
.max_output = { 4096, 2304 },
+ .max_pixel_clock_rate = 600000000U * 4,
/* hdr2sdr sdr2hdr hdr2hdr sdr2sdr */
.pre_scan_max_dly = { 76, 65, 65, 54 },
.offset = 0xc00,
@@ -1070,6 +1077,7 @@ static const struct vop2_video_port_data rk3588_vop_video_ports[] = {
.gamma_lut_len = 1024,
.cubic_lut_len = 729, /* 9x9x9 */
.max_output = { 4096, 2304 },
+ .max_pixel_clock_rate = 600000000U * 4,
.pre_scan_max_dly = { 76, 65, 65, 54 },
.offset = 0xd00,
}, {
@@ -1078,12 +1086,14 @@ static const struct vop2_video_port_data rk3588_vop_video_ports[] = {
.gamma_lut_len = 1024,
.cubic_lut_len = 17 * 17 * 17, /* 17x17x17 */
.max_output = { 4096, 2304 },
+ .max_pixel_clock_rate = 600000000U * 4,
.pre_scan_max_dly = { 52, 52, 52, 52 },
.offset = 0xe00,
}, {
.id = 3,
.gamma_lut_len = 1024,
.max_output = { 2048, 1536 },
+ .max_pixel_clock_rate = 150000000U,
.pre_scan_max_dly = { 52, 52, 52, 52 },
.offset = 0xf00,
},
---
base-commit: 591cd656a1bf5ea94a222af5ef2ee76df029c1d2
change-id: 20260217-vop2-clk-rate-check-268269778cac
Best regards,
--
Sebastian Reichel <sebastian.reichel@collabora.com>
^ permalink raw reply related
* Re: [PATCH net-next v9 1/4] net: stmmac: Add DW25GMAC support in stmmac core driver
From: Jitendra Vegiraju @ 2026-04-09 22:14 UTC (permalink / raw)
To: Jakub Kicinski
Cc: netdev, alexandre.torgue, davem, edumazet, pabeni,
mcoquelin.stm32, bcm-kernel-feedback-list, richardcochran, ast,
daniel, hawk, john.fastabend, rmk+kernel, rohan.g.thomas,
linux-kernel, linux-stm32, linux-arm-kernel, bpf, andrew+netdev,
horms, sdf, siyanteng, prabhakar.mahadev-lad.rj, weishangjuan,
wens, vladimir.oltean, lizhi2, boon.khai.ng, maxime.chevallier,
chenchuangyu, yangtiezhu, ovidiu.panait.rb, chenhuacai,
florian.fainelli, quic_abchauha
In-Reply-To: <20260407020954.3674529-1-kuba@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3227 bytes --]
On Mon, Apr 6, 2026 at 7:09 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> Subject: net: stmmac: Add DW25GMAC support in stmmac core driver
>
> This commit introduces support for the DW25GMAC hardware in the stmmac
> core driver, which uses a new Hyper-DMA (HDMA) architecture. It adds a
> new DMA ops instance mapping virtual DMA channels to physical DMA
> channels and sets up the basic device configurations.
>
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/dw25gmac.c b/drivers/net/ethernet/stmicro/stmmac/dw25gmac.c
> > new file mode 100644
> > index 0000000000000..82eb22bff73e0
> > --- /dev/null
> > +++ b/drivers/net/ethernet/stmicro/stmmac/dw25gmac.c
>
> [ ... ]
>
> > +static int rd_dma_ch_ind(void __iomem *ioaddr, u8 mode, u32 channel)
> > +{
> > + u32 reg_val = 0;
> > +
> > + reg_val |= FIELD_PREP(XXVGMAC_MODE_SELECT, mode);
> > + reg_val |= FIELD_PREP(XXVGMAC_ADDR_OFFSET, channel);
> > + reg_val |= XXVGMAC_CMD_TYPE | XXVGMAC_OB;
> > + writel(reg_val, ioaddr + XXVGMAC_DMA_CH_IND_CONTROL);
> > + return readl(ioaddr + XXVGMAC_DMA_CH_IND_DATA);
> > +}
>
> Does this readl() need to wait for the hardware to clear the XXVGMAC_OB
> (Operation Busy) bit? Returning immediately might read uninitialized or
> stale data if the hardware hasn't finished the fetch.
>
This is an issue. We will fix it.
> > +
> > +static void wr_dma_ch_ind(void __iomem *ioaddr, u8 mode, u32 channel, u32 val)
> > +{
> > + u32 reg_val = 0;
> > +
> > + writel(val, ioaddr + XXVGMAC_DMA_CH_IND_DATA);
> > + reg_val |= FIELD_PREP(XXVGMAC_MODE_SELECT, mode);
> > + reg_val |= FIELD_PREP(XXVGMAC_ADDR_OFFSET, channel);
> > + reg_val |= XGMAC_OB;
>
> This isn't a bug, but should this use the XXVGMAC_OB macro instead of
> XGMAC_OB here for consistency?
>
> > + writel(reg_val, ioaddr + XXVGMAC_DMA_CH_IND_CONTROL);
> > +}
>
> Similarly, does this function need to poll for the busy bit to clear after
> the writel()? If back-to-back operations occur, the next indirect write
> might overwrite the control and data registers while the hardware is still
> processing this request.
>
Agreed. This is bug, we will fix it.
> [ ... ]
>
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
> > index f02b434bbd505..64c38de294da2 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
>
> [ ... ]
>
> > -int dwxgmac2_setup(struct stmmac_priv *priv)
> > +static void dwxgmac2_common_setup(struct stmmac_priv *priv, char *mac_name)
> > {
>
> This isn't a bug, but should mac_name be declared as const char * since it
> is passed string literals like "XGMAC2" and "DW25GMAC"? This avoids
> discarded-qualifiers compiler warnings.
>
> > struct mac_device_info *mac = priv->hw;
> >
> > - dev_info(priv->device, "\tXGMAC2\n");
> > + dev_info(priv->device, "\t%s\n", mac_name);
>
Ack
> [ ... ]
> --
> pw-bot: cr
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5435 bytes --]
^ permalink raw reply
* Re: [PATCH v12 19/25] drm/connector: Register color format property on HDMI connectors
From: Dmitry Baryshkov @ 2026-04-09 22:09 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc
In-Reply-To: <20260409-color-format-v12-19-ce84e1817a27@collabora.com>
On Thu, Apr 09, 2026 at 05:45:09PM +0200, Nicolas Frattaroli wrote:
> The drmm_connector_hdmi_init function can figure out what DRM color
> formats are supported by a particular connector based on the supported
> HDMI format bitmask that's passed in.
>
> Use it to register the drm color format property.
>
> Reviewed-by: Maxime Ripard <mripard@kernel.org>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/drm_connector.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v12 05/25] drm/atomic-helper: Add HDMI bridge output bus formats helper
From: Dmitry Baryshkov @ 2026-04-09 22:09 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc
In-Reply-To: <20260409-color-format-v12-5-ce84e1817a27@collabora.com>
On Thu, Apr 09, 2026 at 05:44:55PM +0200, Nicolas Frattaroli wrote:
> The drm_bridge_funcs atomic_get_output_bus_fmts operation should be the
> same for likely every HDMI connector bridge, unless such an HDMI
> connector bridge has some special hardware restrictions that I cannot
> envision yet.
>
> To avoid code duplication and standardize on a set of media bus formats
> that the HDMI output color formats translate to, add a common helper
> function that implements this operation to the drm bridge helpers.
>
> The function returns a list of output bus formats based on the HDMI
> bridge's current output bits-per-component, and its bitmask of supported
> color formats.
>
> To guard against future expansion of DRM_OUTPUT_COLOR_FORMAT outgrowing
> the hweight8 call, add a BUILD_BUG_ON statement where it's used that
> checks for DRM_OUTPUT_COLOR_FORMAT_COUNT. The justification for not
> using hweight32 in all cases is that not all ISAs have a popcount
> instruction, and will benefit from a smaller/faster software
> implementation that doesn't have to operate across all bits.
>
> The justification for not defining an hweight_color depending on the
> value of DRM_OUTPUT_COLOR_FORMAT_COUNT is that this count enum value is
> only known at compile time, not at preprocessor time.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 81 +++++++++++++++++++++++++++++++++++++
> include/drm/drm_atomic_helper.h | 7 ++++
> 2 files changed, 88 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH net-next v9 0/4] net: stmmac: Add PCI driver support for BCM8958x
From: Jitendra Vegiraju @ 2026-04-09 22:08 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: netdev, alexandre.torgue, davem, edumazet, kuba, pabeni,
mcoquelin.stm32, bcm-kernel-feedback-list, richardcochran, ast,
daniel, hawk, john.fastabend, rohan.g.thomas, linux-kernel,
linux-stm32, linux-arm-kernel, bpf, andrew+netdev, horms, sdf,
siyanteng, prabhakar.mahadev-lad.rj, weishangjuan, wens,
vladimir.oltean, lizhi2, boon.khai.ng, maxime.chevallier,
chenchuangyu, yangtiezhu, ovidiu.panait.rb, chenhuacai,
florian.fainelli, quic_abchauha
In-Reply-To: <adSxQpAE0nY0ulfU@shell.armlinux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]
Hi Russell,
On Tue, Apr 7, 2026 at 12:25 AM Russell King (Oracle)
<linux@armlinux.org.uk> wrote:
>
> On Thu, Apr 02, 2026 at 02:36:25PM -0700, Jitendra Vegiraju wrote:
> > From: Jitendra Vegiraju <jitendra.vegiraju@broadcom.com>
> >
> > This patchset adds basic PCI ethernet device driver support for Broadcom
> > BCM8958x Automotive Ethernet switch SoC devices.
> >
> > The MAC block on BCM8958x is based on Synopsis XGMAC 4.00a core. This
> > MAC IP introduces new DMA architecture called Hyper-DMA for virtualization
> > scalability.
> >
> > Driver functionality specific to new MAC (DW25GMAC) is implemented in
> > new file dw25gmac.c.
>
> Sorry for suggesting this rather late, but I recently came across
> another stmmac driver in the kernel - drivers/net/ethernet/synopsys.
> This is for XLGMAC, but I wonder whether it may be a better bet for
> this core. Have you looked at it?
>
I wasn't aware of this driver earlier. We are looking into this driver now.
Thanks
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5435 bytes --]
^ permalink raw reply
* Re: [PATCH v12 04/25] drm/bridge: Act on the DRM color format property
From: Dmitry Baryshkov @ 2026-04-09 22:08 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc
In-Reply-To: <20260409-color-format-v12-4-ce84e1817a27@collabora.com>
On Thu, Apr 09, 2026 at 05:44:54PM +0200, Nicolas Frattaroli wrote:
> The new DRM color format property allows userspace to request a specific
> color format on a connector. In turn, this fills the connector state's
> color_format member to switch color formats.
>
> Make drm_bridges consider the color_format set in the connector state
> during the atomic bridge check. For bridges that represent HDMI bridges,
> rely on whatever format the HDMI logic set. Reject any output bus
> formats that do not correspond to the requested color format.
>
> Non-HDMI last bridges with DRM_CONNECTOR_COLOR_FORMAT_AUTO set will end
> up choosing the first output format that functions to make a whole
> recursive bridge chain format selection succeed.
>
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> ---
> drivers/gpu/drm/drm_bridge.c | 89 +++++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 88 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index ba80bebb5685..7c1516864d96 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -1150,6 +1150,47 @@ static int select_bus_fmt_recursive(struct drm_bridge *first_bridge,
> return ret;
> }
>
> +static bool __pure bus_format_is_color_fmt(u32 bus_fmt, enum drm_connector_color_format fmt)
> +{
> + if (fmt == DRM_CONNECTOR_COLOR_FORMAT_AUTO)
> + return true;
> +
> + switch (bus_fmt) {
> + case MEDIA_BUS_FMT_FIXED:
> + return true;
> + case MEDIA_BUS_FMT_RGB888_1X24:
> + case MEDIA_BUS_FMT_RGB101010_1X30:
> + case MEDIA_BUS_FMT_RGB121212_1X36:
> + case MEDIA_BUS_FMT_RGB161616_1X48:
> + return fmt == DRM_CONNECTOR_COLOR_FORMAT_RGB444;
> + case MEDIA_BUS_FMT_YUV8_1X24:
> + case MEDIA_BUS_FMT_YUV10_1X30:
> + case MEDIA_BUS_FMT_YUV12_1X36:
> + case MEDIA_BUS_FMT_YUV16_1X48:
> + return fmt == DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
> + case MEDIA_BUS_FMT_UYVY8_1X16:
> + case MEDIA_BUS_FMT_VYUY8_1X16:
> + case MEDIA_BUS_FMT_YUYV8_1X16:
> + case MEDIA_BUS_FMT_YVYU8_1X16:
> + case MEDIA_BUS_FMT_UYVY10_1X20:
> + case MEDIA_BUS_FMT_YUYV10_1X20:
> + case MEDIA_BUS_FMT_VYUY10_1X20:
> + case MEDIA_BUS_FMT_YVYU10_1X20:
> + case MEDIA_BUS_FMT_UYVY12_1X24:
> + case MEDIA_BUS_FMT_VYUY12_1X24:
> + case MEDIA_BUS_FMT_YUYV12_1X24:
> + case MEDIA_BUS_FMT_YVYU12_1X24:
> + return fmt == DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
> + case MEDIA_BUS_FMT_UYYVYY8_0_5X24:
> + case MEDIA_BUS_FMT_UYYVYY10_0_5X30:
> + case MEDIA_BUS_FMT_UYYVYY12_0_5X36:
> + case MEDIA_BUS_FMT_UYYVYY16_0_5X48:
> + return fmt == DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
> + default:
> + return false;
> + }
> +}
> +
> /*
> * This function is called by &drm_atomic_bridge_chain_check() just before
> * calling &drm_bridge_funcs.atomic_check() on all elements of the chain.
> @@ -1193,6 +1234,7 @@ drm_atomic_bridge_chain_select_bus_fmts(struct drm_bridge *bridge,
> struct drm_encoder *encoder = bridge->encoder;
> struct drm_bridge_state *last_bridge_state;
> unsigned int i, num_out_bus_fmts = 0;
> + enum drm_connector_color_format fmt;
> u32 *out_bus_fmts;
> int ret = 0;
>
> @@ -1234,13 +1276,58 @@ drm_atomic_bridge_chain_select_bus_fmts(struct drm_bridge *bridge,
> out_bus_fmts[0] = MEDIA_BUS_FMT_FIXED;
> }
>
> + /*
> + * On HDMI connectors, use the output format chosen by whatever does the
> + * HDMI logic. For everyone else, just trust that the bridge out_bus_fmts
> + * are sorted by preference for %DRM_CONNECTOR_COLOR_FORMAT_AUTO, as
> + * bus_format_is_color_fmt() always returns true for AUTO.
> + */
> + if (last_bridge->type == DRM_MODE_CONNECTOR_HDMIA) {
I still think this is misplaced (and misidentified). Consider HDMI
bridge being routed to the DVI-D connector. The last bridge would have
different type, but the HDMI-specific logic must still be applied. The
bridge must use RGB444, but it must be handled in a generic way.
Or other way around, a DVI bridge being routed through the HDMI
connector (thinking about PandaBoard here). The combo should not go
through the HDMI-specific color format selection although the last
bridge in the chanin is the HDMI-A bridge.
I think all these cases should be handled by the connector, which knows
if there is an OP_HDMI bridge in the chain or not.
> + drm_dbg_kms(last_bridge->dev,
> + "HDMI bridge requests format %s\n",
> + drm_hdmi_connector_get_output_format_name(
> + conn_state->hdmi.output_format));
> + switch (conn_state->hdmi.output_format) {
> + case DRM_OUTPUT_COLOR_FORMAT_RGB444:
> + fmt = DRM_CONNECTOR_COLOR_FORMAT_RGB444;
> + break;
> + case DRM_OUTPUT_COLOR_FORMAT_YCBCR444:
> + fmt = DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
> + break;
> + case DRM_OUTPUT_COLOR_FORMAT_YCBCR422:
> + fmt = DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
> + break;
> + case DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
> + fmt = DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
> + break;
> + default:
> + ret = -EINVAL;
> + goto out_free_bus_fmts;
> + }
> + } else {
> + fmt = conn_state->color_format;
> + drm_dbg_kms(last_bridge->dev, "Non-HDMI bridge requests format %d\n", fmt);
> + }
> +
> for (i = 0; i < num_out_bus_fmts; i++) {
> + if (!bus_format_is_color_fmt(out_bus_fmts[i], fmt)) {
> + drm_dbg_kms(last_bridge->dev,
> + "Skipping bus format 0x%04x as it doesn't match format %d\n",
> + out_bus_fmts[i], fmt);
> + ret = -ENOTSUPP;
> + continue;
> + }
> ret = select_bus_fmt_recursive(bridge, last_bridge, crtc_state,
> conn_state, out_bus_fmts[i]);
> - if (ret != -ENOTSUPP)
> + if (ret != -ENOTSUPP) {
> + drm_dbg_kms(last_bridge->dev,
> + "Found bridge chain ending with bus format 0x%04x\n",
> + out_bus_fmts[i]);
> break;
> + }
> }
>
> +out_free_bus_fmts:
> kfree(out_bus_fmts);
>
> return ret;
>
> --
> 2.53.0
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [RFC net PATCH v1] net: pcs: pcs-mtk-lynxi: fix bpi-r3 serdes configuration
From: Vladimir Oltean @ 2026-04-09 21:55 UTC (permalink / raw)
To: Frank Wunderlich
Cc: Alexander Couzens, Daniel Golle, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Matthias Brugger, AngeloGioacchino Del Regno,
Frank Wunderlich, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260409133344.129620-1-linux@fw-web.de>
On Thu, Apr 09, 2026 at 03:33:42PM +0200, Frank Wunderlich wrote:
> From: Frank Wunderlich <frank-w@public-files.de>
>
> Commit 8871389da151 introduces common pcs dts properties which writes
> rx=normal,tx=normal polarity to register SGMSYS_QPHY_WRAP_CTRL of switch.
> This is initialized with tx-bit set and so change inverts polarity
> compared to before.
>
> It looks like mt7531 has tx polarity inverted in hardware and set tx-bit
> by default to restore the normal polarity.
>
> Till this patch the register write was only called when mediatek,pnswap
> property was set which cannot be done for switch because the fw-node param
> was always NULL from switch driver in the mtk_pcs_lynxi_create call.
>
> Do not configure switch side like it's done before.
>
> Fixes: 8871389da151 ("net: pcs: pcs-mtk-lynxi: deprecate "mediatek,pnswap"")
> Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
> ---
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
^ permalink raw reply
* Re: [PATCH RFC 09/12] drm: Introduce drmm_connector_dp_init() with link training state properties
From: Dmitry Baryshkov @ 2026-04-09 21:53 UTC (permalink / raw)
To: Kory Maincent
Cc: Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
David Airlie, Simona Vetter, Dave Airlie, Jesse Barnes,
Eric Anholt, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Chun-Kuang Hu, Philipp Zabel,
Matthias Brugger, AngeloGioacchino Del Regno, Chris Wilson,
Thomas Petazzoni, Mark Yacoub, Sean Paul, Louis Chauvet,
intel-gfx, intel-xe, dri-devel, linux-kernel, linux-mediatek,
linux-arm-kernel, Simona Vetter
In-Reply-To: <20260409-feat_link_cap-v1-9-7069e8199ce2@bootlin.com>
On Thu, Apr 09, 2026 at 07:08:25PM +0200, Kory Maincent wrote:
> Add a managed DisplayPort connector initialization helper,
> drmm_connector_dp_init(), modeled after the existing HDMI counterpart
> drmm_connector_hdmi_init(). Cleanup is handled automatically via a
> DRM-managed action.
>
> The helper creates the following immutable connector properties to expose
> DP link training capabilities and state to userspace:
>
> - num_lanes: bitmask of supported lane counts (1, 2, 4)
> - link_rate: Array of supported link rates.
> - dsc_en: Display Stream Compression supported
> - voltage_swingN: per-lane voltage swing level bitmask
> - pre-emphasisN: per-lane pre-emphasis level bitmask
>
> Link rates are passed by the driver in deca-kbps, following the DRM
> convention, but exposed to userspace in kbps for clarity.
>
> Two additional helpers are provided to update and reset those properties
> at runtime:
> - drm_connector_dp_set_link_train_properties()
> - drm_connector_dp_reset_link_train_properties()
>
> Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
> ---
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/drm_dp_connector.c | 344 +++++++++++++++++++++++++++++++++++++
> include/drm/drm_connector.h | 38 ++++
> include/drm/drm_dp_connector.h | 109 ++++++++++++
> 4 files changed, 492 insertions(+)
>
> diff --git a/include/drm/drm_dp_connector.h b/include/drm/drm_dp_connector.h
> new file mode 100644
> index 0000000000000..77d2f4bb6df68
> --- /dev/null
> +++ b/include/drm/drm_dp_connector.h
> @@ -0,0 +1,109 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#ifndef DRM_DP_CONNECTOR_H_
> +#define DRM_DP_CONNECTOR_H_
> +
> +#include <drm/drm_connector.h>
> +
> +#define DRM_DP_1LANE BIT(0)
> +#define DRM_DP_2LANE BIT(1)
> +#define DRM_DP_4LANE BIT(2)
> +#define DRM_NLANES_MASK (DRM_DP_1LANE | DRM_DP_2LANE | DRM_DP_4LANE)
> +#define DRM_DP_VOLTAGE_SWING_LEVEL_0 BIT(0)
> +#define DRM_DP_VOLTAGE_SWING_LEVEL_1 BIT(1)
> +#define DRM_DP_VOLTAGE_SWING_LEVEL_2 BIT(2)
> +#define DRM_DP_VOLTAGE_SWING_LEVEL_3 BIT(3)
> +#define DRM_DP_VOLTAGE_SWING_LEVEL_MASK (DRM_DP_VOLTAGE_SWING_LEVEL_0 | \
> + DRM_DP_VOLTAGE_SWING_LEVEL_1 | \
> + DRM_DP_VOLTAGE_SWING_LEVEL_2 | \
> + DRM_DP_VOLTAGE_SWING_LEVEL_3)
> +#define DRM_DP_PRE_EMPH_LEVEL_0 BIT(0)
> +#define DRM_DP_PRE_EMPH_LEVEL_1 BIT(1)
> +#define DRM_DP_PRE_EMPH_LEVEL_2 BIT(2)
> +#define DRM_DP_PRE_EMPH_LEVEL_3 BIT(3)
> +#define DRM_DP_PRE_EMPH_LEVEL_MASK (DRM_DP_PRE_EMPH_LEVEL_0 | \
> + DRM_DP_PRE_EMPH_LEVEL_1 | \
> + DRM_DP_PRE_EMPH_LEVEL_2 | \
> + DRM_DP_PRE_EMPH_LEVEL_3)
> +
> +/**
> + * struct drm_connector_dp_link_train_caps - DRM DisplayPort link training
> + * capabilities
Those are not just link training caps. It is more like DP link caps.
They make sense to be a part of the DP-related drm_connector part.
> + */
> +struct drm_connector_dp_link_train_caps {
> + /**
> + * @nlanes: Bitmask of lanes number supported
> + */
> + u8 nlanes;
> +
> + /**
> + * @nrates: Number of link rates supported
> + */
> + u32 nrates;
> +
> + /**
> + * @rates: Array listing the supported link rates in deca-kbps
> + */
> + const u32 *rates;
> +
> + /**
> + * @dsc: Display Stream Compression supported
> + */
> + bool dsc;
> +
> + /**
> + * @v_swings: Bitmask of voltage swing level supported
> + */
> + u8 v_swings;
> +
> + /**
> + * @pre_emphs: Bitmask of pre-emphasis level supported
> + */
> + u8 pre_emphs;
> +};
> +
> +/**
> + * struct drm_connector_dp_link_train - DRM DisplayPort link training
> + * information report
> + */
> +struct drm_connector_dp_link_train {
THese define the current DP state. As such, they definitely make sense
to be a part of the drm_connector.
> + /**
> + * @nlanes: The number of lanes used
> + */
> + u8 nlanes;
> +
> + /**
> + * @rates: Link rate value selected in deca-kbps
> + */
> + u32 rate;
> +
> + /**
> + * @dsc: Display Stream Compression enabled
> + */
> + bool dsc_en;
> +
> + /**
> + * @v_swings: Array listing the bitmask voltage swing level per lanes
> + */
> + u8 v_swing[4];
> +
> + /**
> + * @pre_emph: Array listing the bitmask pre-emphasis level per lanes
> + */
> + u8 pre_emph[4];
Please consider following struct phy_configure_opts_dp (or using it as
is). Overall, please refer the talk and (more important) the lightning
resumee at this XDC. I have some bits and pieces ready in spite of that
proposal, but I didn't have time to finish it.
> +};
> +
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [RFC net PATCH v1] net: pcs: pcs-mtk-lynxi: fix bpi-r3 serdes configuration
From: Vladimir Oltean @ 2026-04-09 21:52 UTC (permalink / raw)
To: Daniel Golle
Cc: Frank Wunderlich, Chester A. Unal, Felix Fietkau,
Alexander Couzens, Andrew Lunn, Heiner Kallweit, Russell King,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Matthias Brugger, AngeloGioacchino Del Regno, Frank Wunderlich,
netdev, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <adgSXDUn-oL6V_TK@makrotopia.org>
On Thu, Apr 09, 2026 at 09:55:56PM +0100, Daniel Golle wrote:
> On Thu, Apr 09, 2026 at 07:49:42PM +0300, Vladimir Oltean wrote:
> > I notice Arınc, listed by ./scripts/get_maintainer.pl drivers/net/dsa/mt7530.c,
> > and Felix, listed by ./scripts/get_maintainer.pl drivers/net/ethernet/mediatek/mtk_eth_soc.c,
> > are not on CC. Maybe they have more info.
> >
> > Only the switch port has a chance of having a non-zero default polarity
> > setting? (coming from the efuse, if I understood this discussion properly)
> > https://lore.kernel.org/netdev/C59EED96-3973-4074-A4D8-C264949D447E@linux.dev/
> > The GMAC doesn't?
>
> Yes, vendor SDK uses DT mediatek,pnswap{,-rx,-tx} properties only for the
> SoC GMACs. For MT7531 there are **no** strap pins deciding the SerDes
> polarity, and also no software-way to override the defaults in the vendor
> SDK.
>
> However, the MT7531 datasheet quite clearly states:
> Register 000050EC QPHY_WRAP_CTRL -- QPHY wrapper control
> Reset value: 0x00000501
>
> BIT 1 RX_BIT_POLARITY -- RX bit polarity control
> 1'b0: normal
> 1'b1: inverted
>
> BIT 0 TX_BIT_POLARITY -- TX bit polarity control (TX default inversed in MT7531)
> 1'b0: normal
> 1'b1: inverted
>
> Hence the best would be to just assume the documented default in the driver
> as well.
>
> A quick register dump using the BPi-R3 confirms that this applies to *both*
> SerDes PCS on MT7531A (port 5 and port 6) equally, both read 0x00000501
> after reset.
OK. Excepting the DSA driver for MT7531 from polarity configuration
based on lack of a fwnode for the PCS should be fine (for now, to
address the regression).
^ 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