* [PATCH v2 0/6] phy: realtek: usb2: support for RTL9607C USB2 PHY
From: Rustam Adilov @ 2026-03-27 16:06 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stanley Chang, linux-phy, devicetree, linux-kernel
Cc: Rustam Adilov
This patch series for Realtek USB2 PHY driver adds support for RTL9607C
USB2 PHY.
RTL9607C is a big endian MIPS CPU which is quite far from RTD series SoCs
supported by realtek usb2 phy driver, but the phy initilization is found
to be very indentical in most areas.
Most of the code was based on the Realtek's usb driver from the GPL tarball
in [1] and adjusted to fit into the realtek usb2 phy driver code format.
The patch series was split into smaller patches that add/change something
in the driver that are not exactly related to RTL9607C and that also
helps for easier review. That also means, patch 5 depends on all the prior
patches that come before it.
USB2 PHY on RTL9607C is primarly used for its internal OHCI/EHCI controllers.
[1] - https://github.com/jameywine/GPL-for-GP3000/blob/main/linux-5.10.x/arch/mips/rtl9607c/usb.c
---
Changelog in v2:
- Patch 5
- removed the line about OHCI/EHCI controllers from description.
- set the resets to false for RTD SoC devices and changed the
commit message to reflect that.
- Link to v1: https://lore.kernel.org/linux-phy/20260326193419.48419-1-adilov@disroot.org/
Rustam Adilov (6):
phy: realtek: usb2: introduce vstatus/new_reg_req variables to driver
data
phy: realtek: usb2: introduce read and write functions to driver data
dt-bindings: phy: realtek,usb2phy.yaml: extend for resets and RTL9607C
support
phy: realtek: usb2: introduce reset controller struct
phy: realtek: usb2: add support for RTL9607C USB2 PHY
phy: realtek: usb2: Make configs available for MACH_REALTEK_RTL
.../bindings/phy/realtek,usb2phy.yaml | 25 ++-
drivers/phy/realtek/Kconfig | 2 +-
drivers/phy/realtek/phy-rtk-usb2.c | 189 ++++++++++++++++--
3 files changed, 196 insertions(+), 20 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH v1 1/1] arm64: dts: qcom: hamoa: Move PCIe PERST and Wake GPIOs to port nodes
From: Manivannan Sadhasivam @ 2026-03-27 16:02 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Bjorn Andersson, Tobias Heider, Ziyue Zhang, konradybcio, robh,
krzk+dt, conor+dt, jingoohan1, lpieralisi, kwilczynski, bhelgaas,
johan+linaro, vkoul, kishon, neil.armstrong, abel.vesa, kw,
linux-arm-msm, devicetree, linux-kernel, linux-pci, linux-phy,
qiang.yu, quic_krichai, quic_vbadigan
In-Reply-To: <20260327141756.GA1381857@bhelgaas>
On Fri, Mar 27, 2026 at 09:17:56AM -0500, Bjorn Helgaas wrote:
> [->to: Bjorn A.]
>
> On Tue, Mar 24, 2026 at 08:14:39PM +0100, Tobias Heider wrote:
> > On Tue, Mar 24, 2026 at 7:07 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > On Thu, Mar 19, 2026 at 02:50:37PM +0100, Tobias Heider wrote:
> > > > On Thu, Mar 19, 2026 at 6:39 AM Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > > On Wed, Mar 18, 2026 at 09:42:56PM -0500, Bjorn Andersson wrote:
> > > > > > On Mon, Mar 16, 2026 at 08:50:12AM +0530, Manivannan Sadhasivam wrote:
> > > > > > > On Sun, Mar 15, 2026 at 09:53:33PM -0500, Bjorn Andersson wrote:
> > > > > > > > On Sat, Mar 14, 2026 at 07:50:50PM +0530, Manivannan Sadhasivam wrote:
> > > > > > > > > On Fri, Mar 13, 2026 at 11:45:42AM -0500, Bjorn Helgaas wrote:
> > > > > > > > > > On Fri, Mar 13, 2026 at 05:46:18PM +0800, Ziyue Zhang wrote:
> > > > > > > > > > > Commit 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake
> > > > > > > > > > > GPIOs to PCIe port nodes and add port Nodes for all PCIe ports") did not
> > > > > > > > > > > convert all Hamoa‑based platforms to the new method of defining PERST and
> > > > > > > > > > > Wake GPIOs in the PCIe root port nodes.
> > > > > > > > > > >
> > > > > > > > > > > Without the change PCIe probe will fail. The probe failure happens because
> > > > > > > > > > > the PHY stays in the controller node while the PERST/Wake GPIOs were moved
> > > > > > > > > > > to the port nodes.
> > > > > > > > > > >
> > > > > > > > > > > This fixes probe failures seen on the following platforms:
> > > > > > > > > > > - x1-hp-omnibook-x14
> > > > > > > > > > > - x1-microsoft-denali
> > > > > > > > > > > - x1e80100-lenovo-yoga-slim7x
> > > > > > > > > > > - x1e80100-medion-sprchrgd-14-s1
> > > > > > > > > > > - x1p42100-lenovo-thinkbook-16
> > > > > > > > > > > - x1-asus-zenbook-a14
> > > > > > > > > > > - x1-crd
> > > > > > > > > > > - x1-dell-thena
> > > > > > > > > > >
> > > > > > > > > > > Fixes: 960609b22be5 ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe port nodes and add port Nodes for all PCIe ports")
> > > > > > > > > >
> > > > > > > > > > Are you saying that DTs in the field broke because of some kernel
> > > > > > > > > > change? That's not supposed to happen. Even though PHY, PERST, and
> > > > > > > > > > Wake GPIOs should be described in Root Port nodes instead of the Root
> > > > > > > > > > Complex node in *future* DTs, the kernel is still supposed to accept
> > > > > > > > > > the old style with them described in the Root Complex node.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > This is not related to the driver change. The driver correctly parses all Root
> > > > > > > > > Port properties either in the Root Complex node (old binding) or Root Port node
> > > > > > > > > (new binding). But commit 960609b22be5, left converting mentioned board DTS to
> > > > > > > > > the new binding, leaving those affected platforms in a half baked state i.e.,
> > > > > > > > > some properties in RC node and some in Root Port node. Driver cannot parse such
> > > > > > > > > combinations, so it fails correctly so.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Are you saying that above listed machines has broken PCIe support in
> > > > > > > > v7.0-rc?
> > > > > > > >
> > > > > > >
> > > > > > > I haven't verified it, but I'm pretty sure PCIe is broken on these platforms.
> > > > > > >
> > > > > >
> > > > > > In line with Bjorn's request, we shouldn't have to guess.
> > > > > >
> > > > > > > > It seems this is a (partial) revert of 960609b22be5, is this actually
> > > > > > > > fixing that change, or is it only applicable once some other changes are
> > > > > > > > applied?
> > > > > > > >
> > > > > > >
> > > > > > > This change is fixing the issue in the respective board DTS and is a standalone
> > > > > > > fix on top of v7.0-rc1.
> > > > > > >
> > > > > >
> > > > > > So 960609b22be5 was broken when I merged it?
> > > > > >
> > > > >
> > > > > Broken on the machines mentioned in the commit message, not for all Hamoa
> > > > > platforms.
> > > > >
> > > > > > The commit message says that the commit was incomplete, in that it
> > > > > > didn't fully convert from the old to the new style, so it sounds like
> > > > > > the offending commit was incomplete - but I believe the offending commit
> > > > > > was a workaround for the new solution not being in place and this commit
> > > > > > mostly reverts the changes in the offending commit.
> > > > > >
> > > > >
> > > > > So 960609b22be5 was supposed to move all the platforms from old PCIe binding to
> > > > > new for greater good, but it apparently decided to do so only for a subset of
> > > > > the platforms for some reason which don't know. But the problem arises due to
> > > > > 960609b22be5 changing the hamoa.dtsi to the new binding which also warrants the
> > > > > platform DTS to also be changed to the new binding. If we only have either dtsi
> > > > > or dts converted and not both to the new binding, the driver will get confused
> > > > > and fail. And this is what exactly happended for below machines:
> > > > >
> > > > > - x1-hp-omnibook-x14
> > > > > - x1-microsoft-denali
> > > > > - x1e80100-lenovo-yoga-slim7x
> > > > > - x1e80100-medion-sprchrgd-14-s1
> > > > > - x1p42100-lenovo-thinkbook-16
> > > > > - x1-asus-zenbook-a14
> > > > > - x1-crd
> > > > > - x1-dell-thena
> > > >
> > > > I can confirm the breakage for (some of) the listed devices on Ubuntu.
> > > > We are experimenting with 7.0-rcs ahead of our 26.04 release.
> > > >
> > > > I'll try to collect some test feedback for the fix.
> > > > I'd certainly appreciate this being included as an rc fix since
> > > > currently half of
> > > > the x1 laptop devices are broken.
> > > >
> > >
> > > Thanks for the report. We will try to get this patch into v7.0-rcS.
> > >
> > > It'd be appreciated if you can test this patch and give your tested-by tag.
> > >
> > > - Mani
> >
> > Thank you!
> >
> > Tested it myself and I have rolled this out to my ubuntu-concept testing repo.
> > I have tested the CRD and got user feedback that it works on at least an
> > Omnibook (where we first saw the regression without the patch) and Lenovo Yoga.
> > Potentially more but not everyone provides feedback when things don't break.
> >
> > Tested-by: Tobias Heider <tobias.heider@canonical.com>
>
> I don't see this patch upstream yet. It's a fix for 960609b22be5
> ("arm64: dts: qcom: hamoa: Move PHY, PERST, and Wake GPIOs to PCIe
> port nodes and add port Nodes for all PCIe ports"), which looks like
> it was merged by Bjorn A., so I assume the fix will go the same route?
>
> Just want to make sure it's not waiting on me :)
No. Ziyue will post it asap.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH net-next 4/4] net: dsa: initial support for MT7628 embedded switch
From: Joris Vaisvila @ 2026-03-27 15:39 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, horms, pabeni, kuba, edumazet, davem, olteanv, devicetree,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <e6d91e11-fe19-48c0-886f-e1c0c92b094d@lunn.ch>
Thanks for the review, will fix all of these in v2.
^ permalink raw reply
* Re: [PATCH 3/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Bastien Curutchet @ 2026-03-27 15:38 UTC (permalink / raw)
To: Marek Vasut, Vladimir Oltean, Fidelio Lawson
Cc: Woojung Huh, UNGLinuxDriver, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Marek Vasut, Maxime Chevallier,
netdev, devicetree, linux-kernel, Fidelio Lawson
In-Reply-To: <80e21085-84b9-4ebd-9a60-1d7acfc1a56b@nabladev.com>
Hi Marek,
On 3/27/26 3:55 PM, Marek Vasut wrote:
> On 3/27/26 3:47 PM, Bastien Curutchet wrote:
>
> Hello Bastien,
>
>>> FYI, the driver is in a restructuring process. The ksz88xx_switch_ops
>>> will be split out of the common ksz_switch_ops. This will conflict with
>>> your series, so you should rebase on top of that much larger set.
>>> You can coordinate with Bastien Curutchet to see what is the status:
>>> https://lore.kernel.org/netdev/20260313153849.qkfzv5c2u6fepjku@skbuf
>>
>> Indeed, I'm currently polishing a first iteration for it. I'll send it
>> ASAP.
> I would argue that this low-loss cable errata is a bugfix, so maybe that
> should have a priority over restructuring ?
Yes, I'm fine with that.
These three patches aren't big so I shouldn't encounter much difficulty
to fix the conflicts on my side.
Best regards,
Bastien
^ permalink raw reply
* RE: [PATCH net-next 1/5] dpll: zl3073x: clean up esync get/set and use zl3073x_out_is_ndiv()
From: Prathosh.Satish @ 2026-03-27 15:35 UTC (permalink / raw)
To: horms, ivecera
Cc: devicetree, vadim.fedorenko, jiri, netdev, pvaanane,
arkadiusz.kubalewski, robh, linux-kernel, conor+dt, krzk+dt,
mschmidt, poros
In-Reply-To: <20260321090108.GP74886@horms.kernel.org>
Reviewed-by: prathosh.satish@microchip.com
-----Original Message-----
From: Simon Horman <horms@kernel.org>
Sent: Saturday, March 21, 2026 9:01 AM
To: Ivan Vecera <ivecera@redhat.com>
Cc: devicetree@vger.kernel.org; vadim.fedorenko@linux.dev; jiri@resnulli.us; netdev@vger.kernel.org; pvaanane@redhat.com; arkadiusz.kubalewski@intel.com; robh@kernel.org; linux-kernel@vger.kernel.org; conor+dt@kernel.org; krzk+dt@kernel.org; Prathosh Satish - M66066 <Prathosh.Satish@microchip.com>; mschmidt@redhat.com; poros@redhat.com
Subject: Re: [PATCH net-next 1/5] dpll: zl3073x: clean up esync get/set and use zl3073x_out_is_ndiv()
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
On Fri, Mar 20, 2026 at 06:31:36PM +0100, Ivan Vecera wrote:
> Hi Simon,
>
> On 3/20/26 6:17 PM, Simon Horman 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.
> >
> > For local reproduction steps see
> > https://netdev-ai.bots.linux.dev/ai-local.html
> > ---
> > dpll: zl3073x: clean up esync get/set and use zl3073x_out_is_ndiv()
> >
> > Return -EOPNOTSUPP early in esync_get callbacks when esync is not
> > supported instead of conditionally populating the range at the end.
> > This simplifies the control flow by removing the finish label/goto
> > in the output variant and the conditional range assignment in both
> > input and output variants.
> >
> > Replace open-coded N-div signal format switch statements with
> > zl3073x_out_is_ndiv() helper in esync_get, esync_set and
> > frequency_set callbacks.
> >
> > > diff --git a/drivers/dpll/zl3073x/dpll.c
> > > b/drivers/dpll/zl3073x/dpll.c index a29f606318f6..79ef62d69a32
> > > 100644
> > > --- a/drivers/dpll/zl3073x/dpll.c
> > > +++ b/drivers/dpll/zl3073x/dpll.c
> > > @@ -131,6 +131,12 @@ zl3073x_dpll_input_pin_esync_get(const struct dpll_pin *dpll_pin,
> > > ref_id = zl3073x_input_pin_ref_get(pin->id);
> > > ref = zl3073x_ref_state_get(zldev, ref_id);
> > >
> > > + if (!pin->esync_control || zl3073x_ref_freq_get(ref) == 1)
> > > + return -EOPNOTSUPP;
> > > +
> > > + esync->range = esync_freq_ranges; range_num =
> > > + esync->ARRAY_SIZE(esync_freq_ranges);
> > > +
> > > switch (FIELD_GET(ZL_REF_SYNC_CTRL_MODE, ref->sync_ctrl)) {
> > > case ZL_REF_SYNC_CTRL_MODE_50_50_ESYNC_25_75:
> > > esync->freq = ref->esync_n_div ==
> > > ZL_REF_ESYNC_DIV_1HZ ? 1 : 0; @@ -142,17 +148,6 @@ zl3073x_dpll_input_pin_esync_get(const struct dpll_pin *dpll_pin,
> > > break;
> > > }
> > >
> > > - /* If the pin supports esync control expose its range but only
> > > - * if the current reference frequency is > 1 Hz.
> > > - */
> > > - if (pin->esync_control && zl3073x_ref_freq_get(ref) > 1) {
> > > - esync->range = esync_freq_ranges;
> > > - esync->range_num = ARRAY_SIZE(esync_freq_ranges);
> > > - } else {
> > > - esync->range = NULL;
> > > - esync->range_num = 0;
> > > - }
> > > -
> > > return 0;
> > > }
> >
> > The refactoring changes the behavior when the reference frequency is 0 Hz.
> >
> > The old code checked 'zl3073x_ref_freq_get(ref) > 1' which excluded
> > both
> > freq==0 and freq==1 from having the esync range exposed. The new
> > code checks
> > 'zl3073x_ref_freq_get(ref) == 1' which only excludes freq==1.
> >
> > When freq==0 (which can happen when freq_base, freq_mult, or
> > freq_ratio_m is 0), the old code would return 0 with
> > esync->range=NULL and
> > esync->range_num=0, while the new code returns 0 with
> > esync->range=esync_freq_ranges and esync->range_num=1.
> >
> > The removed comment documented the original intent: "if the current
> > reference frequency is > 1 Hz". Should the new check be 'zl3073x_ref_freq_get(ref) <= 1'
> > to preserve the original behavior for 0 Hz frequencies?
> >
> > >
> > > @@ -582,8 +577,8 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
> > > struct zl3073x_dpll_pin *pin = pin_priv;
> > > const struct zl3073x_synth *synth;
> > > const struct zl3073x_out *out;
> > > + u32 synth_freq, out_freq;
> > > u8 clock_type, out_id;
> > > - u32 synth_freq;
> > >
> > > out_id = zl3073x_output_pin_out_get(pin->id);
> > > out = zl3073x_out_state_get(zldev, out_id); @@ -592,17
> > > +587,19 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
> > > * for N-division is also used for the esync divider so both cannot
> > > * be used.
> > > */
> > > - switch (zl3073x_out_signal_format_get(out)) {
> > > - case ZL_OUTPUT_MODE_SIGNAL_FORMAT_2_NDIV:
> > > - case ZL_OUTPUT_MODE_SIGNAL_FORMAT_2_NDIV_INV:
> > > + if (zl3073x_out_is_ndiv(out))
> > > return -EOPNOTSUPP;
> > > - default:
> > > - break;
> > > - }
> > >
> > > /* Get attached synth frequency */
> > > synth = zl3073x_synth_state_get(zldev, zl3073x_out_synth_get(out));
> > > synth_freq = zl3073x_synth_freq_get(synth);
> > > + out_freq = synth_freq / out->div;
> > > +
> > > + if (!pin->esync_control || out_freq == 1)
> > > + return -EOPNOTSUPP;
> > > +
> > > + esync->range = esync_freq_ranges; range_num =
> > > + esync->ARRAY_SIZE(esync_freq_ranges);
> > >
> > > clock_type = FIELD_GET(ZL_OUTPUT_MODE_CLOCK_TYPE, out->mode);
> > > if (clock_type != ZL_OUTPUT_MODE_CLOCK_TYPE_ESYNC) { @@
> > > -610,11 +607,11 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
> > > esync->freq = 0;
> > > esync->pulse = 0;
> > >
> > > - goto finish;
> > > + return 0;
> > > }
> > >
> > > /* Compute esync frequency */
> > > - esync->freq = synth_freq / out->div / out->esync_n_period;
> > > + esync->freq = out_freq / out->esync_n_period;
> > >
> > > /* By comparing the esync_pulse_width to the half of the pulse width
> > > * the esync pulse percentage can be determined.
> > > @@ -623,18 +620,6 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
> > > */
> > > esync->pulse = (50 * out->esync_n_width) / out->div;
> > >
> > > -finish:
> > > - /* Set supported esync ranges if the pin supports esync control
> > > and
> > > - * if the output frequency is > 1 Hz.
> > > - */
> > > - if (pin->esync_control && (synth_freq / out->div) > 1) {
> > > - esync->range = esync_freq_ranges;
> > > - esync->range_num = ARRAY_SIZE(esync_freq_ranges);
> > > - } else {
> > > - esync->range = NULL;
> > > - esync->range_num = 0;
> > > - }
> > > -
> > > return 0;
> > > }
> >
> > Similar to the input variant, this changes the behavior for 0 Hz
> > output frequencies.
> >
> > The old code used '(synth_freq / out->div) > 1' to decide whether to
> > expose the esync range, which excluded both out_freq==0 and
> > out_freq==1. The new code uses 'out_freq == 1' for the early
> > -EOPNOTSUPP return, only excluding out_freq==1.
> >
> > When out_freq==0 (which can happen when synth_freq is 0 or
> > synth_freq <
> > out->div), the old code returned 0 with esync->range=NULL and
> > esync->range_num=0, while the new code returns 0 with
> > esync->range=esync_freq_ranges and esync->range_num=1.
> >
> > The removed comment documented the intent: "if the output frequency
> > is > 1 Hz". Should this also use 'out_freq <= 1' to maintain
> > consistency with the original behavior?
> >
> > [ ... ]
> >
>
> The frequency for both input and output pins cannot be zero... Cannot
> be set to 0 and device never returns configured frequency to be 0.
>
> I can modify the lines to be:
>
> if (!pin->esync_control || out_freq <= 1)
> return -EOPNOTSUPP;
>
> but it is needless - but let me know.
Thanks Ivan,
If it is needless then there is no need to handle it in the code.
Sorry for not understanding that before forwarding on the AI generated review.
^ permalink raw reply
* Re: [PATCH net-next 1/4] dt-bindings: net: dsa: add MT7628 ESW
From: Joris Vaisvila @ 2026-03-27 15:35 UTC (permalink / raw)
To: Daniel Golle
Cc: netdev, horms, pabeni, kuba, edumazet, davem, olteanv,
Andrew Lunn, devicetree, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <acZqvZfYXR_4sMlT@makrotopia.org>
On Fri, Mar 27, 2026 at 11:32:13AM +0000, Daniel Golle wrote:
> > [...]
> > On the hardware I'm testing on, it works fine with the port set to
> > "internal" or "rgmii". Would it make more sense to set "internal" then?
>
> "internal" then. It's a single-die SoC, the switch sharing the same
> memory space, clocking domain, ... with all the rest of the SoC makes
> it very unlikely that RGMII would be used as an on-die connection
> type. (unlike eg. MT7621 or MT7623A which are using multiple dies in
> the same package, and actually RGMII or TRGMII to connect the
> MDIO-managed switch part to the main SoC, see "MCM" / "multi-chip
> module" in the mt7530 driver...)
Makes sense, will change CPU port to internal in v2.
Thanks,
Joris
^ permalink raw reply
* RE: [PATCH net-next 2/5] dpll: zl3073x: use FIELD_MODIFY() for clear-and-set patterns
From: Prathosh.Satish @ 2026-03-27 15:35 UTC (permalink / raw)
To: ivecera, netdev
Cc: arkadiusz.kubalewski, jiri, mschmidt, poros, horms,
vadim.fedorenko, linux-kernel, conor+dt, krzk+dt, robh,
devicetree, pvaanane
In-Reply-To: <20260319174826.7623-3-ivecera@redhat.com>
Reviewed-by: prathosh.satish@microchip.com
-----Original Message-----
From: Ivan Vecera <ivecera@redhat.com>
Sent: Thursday, March 19, 2026 5:48 PM
To: netdev@vger.kernel.org
Cc: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>; Jiri Pirko <jiri@resnulli.us>; Michal Schmidt <mschmidt@redhat.com>; Petr Oros <poros@redhat.com>; Prathosh Satish - M66066 <Prathosh.Satish@microchip.com>; Simon Horman <horms@kernel.org>; Vadim Fedorenko <vadim.fedorenko@linux.dev>; linux-kernel@vger.kernel.org; Conor Dooley <conor+dt@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Rob Herring <robh@kernel.org>; devicetree@vger.kernel.org; Pasi Vaananen <pvaanane@redhat.com>
Subject: [PATCH net-next 2/5] dpll: zl3073x: use FIELD_MODIFY() for clear-and-set patterns
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
Replace open-coded clear-and-set bitfield operations with FIELD_MODIFY().
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
drivers/dpll/zl3073x/chan.h | 17 ++++++----------- drivers/dpll/zl3073x/core.c | 3 +-- drivers/dpll/zl3073x/flash.c | 3 +--
3 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/dpll/zl3073x/chan.h b/drivers/dpll/zl3073x/chan.h index e0f02d3432086..481da2133202b 100644
--- a/drivers/dpll/zl3073x/chan.h
+++ b/drivers/dpll/zl3073x/chan.h
@@ -66,8 +66,7 @@ static inline u8 zl3073x_chan_ref_get(const struct zl3073x_chan *chan)
*/
static inline void zl3073x_chan_mode_set(struct zl3073x_chan *chan, u8 mode) {
- chan->mode_refsel &= ~ZL_DPLL_MODE_REFSEL_MODE;
- chan->mode_refsel |= FIELD_PREP(ZL_DPLL_MODE_REFSEL_MODE, mode);
+ FIELD_MODIFY(ZL_DPLL_MODE_REFSEL_MODE, &chan->mode_refsel,
+ mode);
}
/**
@@ -77,8 +76,7 @@ static inline void zl3073x_chan_mode_set(struct zl3073x_chan *chan, u8 mode)
*/
static inline void zl3073x_chan_ref_set(struct zl3073x_chan *chan, u8 ref) {
- chan->mode_refsel &= ~ZL_DPLL_MODE_REFSEL_REF;
- chan->mode_refsel |= FIELD_PREP(ZL_DPLL_MODE_REFSEL_REF, ref);
+ FIELD_MODIFY(ZL_DPLL_MODE_REFSEL_REF, &chan->mode_refsel, ref);
}
/**
@@ -110,13 +108,10 @@ zl3073x_chan_ref_prio_set(struct zl3073x_chan *chan, u8 ref, u8 prio) {
u8 *val = &chan->ref_prio[ref / 2];
- if (!(ref & 1)) {
- *val &= ~ZL_DPLL_REF_PRIO_REF_P;
- *val |= FIELD_PREP(ZL_DPLL_REF_PRIO_REF_P, prio);
- } else {
- *val &= ~ZL_DPLL_REF_PRIO_REF_N;
- *val |= FIELD_PREP(ZL_DPLL_REF_PRIO_REF_N, prio);
- }
+ if (!(ref & 1))
+ FIELD_MODIFY(ZL_DPLL_REF_PRIO_REF_P, val, prio);
+ else
+ FIELD_MODIFY(ZL_DPLL_REF_PRIO_REF_N, val, prio);
}
/**
diff --git a/drivers/dpll/zl3073x/core.c b/drivers/dpll/zl3073x/core.c index 6363002d48d46..7eebfc1ad1019 100644
--- a/drivers/dpll/zl3073x/core.c
+++ b/drivers/dpll/zl3073x/core.c
@@ -743,8 +743,7 @@ int zl3073x_dev_phase_avg_factor_set(struct zl3073x_dev *zldev, u8 factor)
value = (factor + 1) & 0x0f;
/* Update phase measurement control register */
- dpll_meas_ctrl &= ~ZL_DPLL_MEAS_CTRL_AVG_FACTOR;
- dpll_meas_ctrl |= FIELD_PREP(ZL_DPLL_MEAS_CTRL_AVG_FACTOR, value);
+ FIELD_MODIFY(ZL_DPLL_MEAS_CTRL_AVG_FACTOR, &dpll_meas_ctrl,
+ value);
rc = zl3073x_write_u8(zldev, ZL_REG_DPLL_MEAS_CTRL, dpll_meas_ctrl);
if (rc)
return rc;
diff --git a/drivers/dpll/zl3073x/flash.c b/drivers/dpll/zl3073x/flash.c index 83452a77e3e98..f85535c8ad246 100644
--- a/drivers/dpll/zl3073x/flash.c
+++ b/drivers/dpll/zl3073x/flash.c
@@ -194,8 +194,7 @@ zl3073x_flash_cmd_wait(struct zl3073x_dev *zldev, u32 operation,
if (rc)
return rc;
- value &= ~ZL_WRITE_FLASH_OP;
- value |= FIELD_PREP(ZL_WRITE_FLASH_OP, operation);
+ FIELD_MODIFY(ZL_WRITE_FLASH_OP, &value, operation);
rc = zl3073x_write_u8(zldev, ZL_REG_WRITE_FLASH, value);
if (rc)
--
2.52.0
^ permalink raw reply
* RE: [PATCH net-next 3/5] dpll: zl3073x: add ref sync and output clock type helpers
From: Prathosh.Satish @ 2026-03-27 15:35 UTC (permalink / raw)
To: ivecera, netdev
Cc: arkadiusz.kubalewski, jiri, mschmidt, poros, horms,
vadim.fedorenko, linux-kernel, conor+dt, krzk+dt, robh,
devicetree, pvaanane
In-Reply-To: <20260319174826.7623-4-ivecera@redhat.com>
Reviewed-by: prathosh.satish@microchip.com
-----Original Message-----
From: Ivan Vecera <ivecera@redhat.com>
Sent: Thursday, March 19, 2026 5:48 PM
To: netdev@vger.kernel.org
Cc: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>; Jiri Pirko <jiri@resnulli.us>; Michal Schmidt <mschmidt@redhat.com>; Petr Oros <poros@redhat.com>; Prathosh Satish - M66066 <Prathosh.Satish@microchip.com>; Simon Horman <horms@kernel.org>; Vadim Fedorenko <vadim.fedorenko@linux.dev>; linux-kernel@vger.kernel.org; Conor Dooley <conor+dt@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Rob Herring <robh@kernel.org>; devicetree@vger.kernel.org; Pasi Vaananen <pvaanane@redhat.com>
Subject: [PATCH net-next 3/5] dpll: zl3073x: add ref sync and output clock type helpers
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
Add ZL_REF_SYNC_CTRL_MODE_REFSYNC_PAIR and ZL_REF_SYNC_CTRL_PAIR register definitions.
Add inline helpers to get and set the sync control mode and sync pair fields of the reference sync control register:
zl3073x_ref_sync_mode_get/set() - ZL_REF_SYNC_CTRL_MODE field
zl3073x_ref_sync_pair_get/set() - ZL_REF_SYNC_CTRL_PAIR field
Add inline helpers to get and set the clock type field of the output mode register:
zl3073x_out_clock_type_get/set() - ZL_OUTPUT_MODE_CLOCK_TYPE field
Convert existing esync callbacks to use the new helpers.
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
drivers/dpll/zl3073x/dpll.c | 24 ++++++++----------- drivers/dpll/zl3073x/out.h | 22 ++++++++++++++++++ drivers/dpll/zl3073x/ref.h | 46 +++++++++++++++++++++++++++++++++++++
drivers/dpll/zl3073x/regs.h | 2 ++
4 files changed, 80 insertions(+), 14 deletions(-)
diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c index 79ef62d69a32d..276f0a92db0b1 100644
--- a/drivers/dpll/zl3073x/dpll.c
+++ b/drivers/dpll/zl3073x/dpll.c
@@ -137,7 +137,7 @@ zl3073x_dpll_input_pin_esync_get(const struct dpll_pin *dpll_pin,
esync->range = esync_freq_ranges;
esync->range_num = ARRAY_SIZE(esync_freq_ranges);
- switch (FIELD_GET(ZL_REF_SYNC_CTRL_MODE, ref->sync_ctrl)) {
+ switch (zl3073x_ref_sync_mode_get(ref)) {
case ZL_REF_SYNC_CTRL_MODE_50_50_ESYNC_25_75:
esync->freq = ref->esync_n_div == ZL_REF_ESYNC_DIV_1HZ ? 1 : 0;
esync->pulse = 25;
@@ -173,8 +173,7 @@ zl3073x_dpll_input_pin_esync_set(const struct dpll_pin *dpll_pin,
else
sync_mode = ZL_REF_SYNC_CTRL_MODE_50_50_ESYNC_25_75;
- ref.sync_ctrl &= ~ZL_REF_SYNC_CTRL_MODE;
- ref.sync_ctrl |= FIELD_PREP(ZL_REF_SYNC_CTRL_MODE, sync_mode);
+ zl3073x_ref_sync_mode_set(&ref, sync_mode);
if (freq) {
/* 1 Hz is only supported frequency now */ @@ -578,7 +577,7 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
const struct zl3073x_synth *synth;
const struct zl3073x_out *out;
u32 synth_freq, out_freq;
- u8 clock_type, out_id;
+ u8 out_id;
out_id = zl3073x_output_pin_out_get(pin->id);
out = zl3073x_out_state_get(zldev, out_id); @@ -601,8 +600,7 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
esync->range = esync_freq_ranges;
esync->range_num = ARRAY_SIZE(esync_freq_ranges);
- clock_type = FIELD_GET(ZL_OUTPUT_MODE_CLOCK_TYPE, out->mode);
- if (clock_type != ZL_OUTPUT_MODE_CLOCK_TYPE_ESYNC) {
+ if (zl3073x_out_clock_type_get(out) !=
+ ZL_OUTPUT_MODE_CLOCK_TYPE_ESYNC) {
/* No need to read esync data if it is not enabled */
esync->freq = 0;
esync->pulse = 0;
@@ -635,8 +633,8 @@ zl3073x_dpll_output_pin_esync_set(const struct dpll_pin *dpll_pin,
struct zl3073x_dpll_pin *pin = pin_priv;
const struct zl3073x_synth *synth;
struct zl3073x_out out;
- u8 clock_type, out_id;
u32 synth_freq;
+ u8 out_id;
out_id = zl3073x_output_pin_out_get(pin->id);
out = *zl3073x_out_state_get(zldev, out_id); @@ -648,15 +646,13 @@ zl3073x_dpll_output_pin_esync_set(const struct dpll_pin *dpll_pin,
if (zl3073x_out_is_ndiv(&out))
return -EOPNOTSUPP;
- /* Select clock type */
+ /* Update clock type in output mode */
if (freq)
- clock_type = ZL_OUTPUT_MODE_CLOCK_TYPE_ESYNC;
+ zl3073x_out_clock_type_set(&out,
+
+ ZL_OUTPUT_MODE_CLOCK_TYPE_ESYNC);
else
- clock_type = ZL_OUTPUT_MODE_CLOCK_TYPE_NORMAL;
-
- /* Update clock type in output mode */
- out.mode &= ~ZL_OUTPUT_MODE_CLOCK_TYPE;
- out.mode |= FIELD_PREP(ZL_OUTPUT_MODE_CLOCK_TYPE, clock_type);
+ zl3073x_out_clock_type_set(&out,
+
+ ZL_OUTPUT_MODE_CLOCK_TYPE_NORMAL);
/* If esync is being disabled just write mailbox and finish */
if (!freq)
diff --git a/drivers/dpll/zl3073x/out.h b/drivers/dpll/zl3073x/out.h index edf40432bba5f..660889c57bffa 100644
--- a/drivers/dpll/zl3073x/out.h
+++ b/drivers/dpll/zl3073x/out.h
@@ -42,6 +42,28 @@ const struct zl3073x_out *zl3073x_out_state_get(struct zl3073x_dev *zldev, int zl3073x_out_state_set(struct zl3073x_dev *zldev, u8 index,
const struct zl3073x_out *out);
+/**
+ * zl3073x_out_clock_type_get - get output clock type
+ * @out: pointer to out state
+ *
+ * Return: clock type of given output (ZL_OUTPUT_MODE_CLOCK_TYPE_*) */
+static inline u8 zl3073x_out_clock_type_get(const struct zl3073x_out
+*out) {
+ return FIELD_GET(ZL_OUTPUT_MODE_CLOCK_TYPE, out->mode); }
+
+/**
+ * zl3073x_out_clock_type_set - set output clock type
+ * @out: pointer to out state
+ * @type: clock type (ZL_OUTPUT_MODE_CLOCK_TYPE_*) */ static inline
+void zl3073x_out_clock_type_set(struct zl3073x_out *out, u8 type) {
+ FIELD_MODIFY(ZL_OUTPUT_MODE_CLOCK_TYPE, &out->mode, type); }
+
/**
* zl3073x_out_signal_format_get - get output signal format
* @out: pointer to out state
diff --git a/drivers/dpll/zl3073x/ref.h b/drivers/dpll/zl3073x/ref.h index 06d8d4d97ea26..09fab97a71d7e 100644
--- a/drivers/dpll/zl3073x/ref.h
+++ b/drivers/dpll/zl3073x/ref.h
@@ -106,6 +106,52 @@ zl3073x_ref_freq_set(struct zl3073x_ref *ref, u32 freq)
return 0;
}
+/**
+ * zl3073x_ref_sync_mode_get - get sync control mode
+ * @ref: pointer to ref state
+ *
+ * Return: sync control mode (ZL_REF_SYNC_CTRL_MODE_*) */ static
+inline u8 zl3073x_ref_sync_mode_get(const struct zl3073x_ref *ref) {
+ return FIELD_GET(ZL_REF_SYNC_CTRL_MODE, ref->sync_ctrl); }
+
+/**
+ * zl3073x_ref_sync_mode_set - set sync control mode
+ * @ref: pointer to ref state
+ * @mode: sync control mode (ZL_REF_SYNC_CTRL_MODE_*) */ static inline
+void zl3073x_ref_sync_mode_set(struct zl3073x_ref *ref, u8 mode) {
+ FIELD_MODIFY(ZL_REF_SYNC_CTRL_MODE, &ref->sync_ctrl, mode); }
+
+/**
+ * zl3073x_ref_sync_pair_get - get sync pair reference index
+ * @ref: pointer to ref state
+ *
+ * Return: paired reference index
+ */
+static inline u8
+zl3073x_ref_sync_pair_get(const struct zl3073x_ref *ref) {
+ return FIELD_GET(ZL_REF_SYNC_CTRL_PAIR, ref->sync_ctrl); }
+
+/**
+ * zl3073x_ref_sync_pair_set - set sync pair reference index
+ * @ref: pointer to ref state
+ * @pair: paired reference index
+ */
+static inline void
+zl3073x_ref_sync_pair_set(struct zl3073x_ref *ref, u8 pair) {
+ FIELD_MODIFY(ZL_REF_SYNC_CTRL_PAIR, &ref->sync_ctrl, pair); }
+
/**
* zl3073x_ref_is_diff - check if the given input reference is differential
* @ref: pointer to ref state
diff --git a/drivers/dpll/zl3073x/regs.h b/drivers/dpll/zl3073x/regs.h index 5ae50cb761a97..d425dc67250fe 100644
--- a/drivers/dpll/zl3073x/regs.h
+++ b/drivers/dpll/zl3073x/regs.h
@@ -213,7 +213,9 @@
#define ZL_REG_REF_SYNC_CTRL ZL_REG(10, 0x2e, 1)
#define ZL_REF_SYNC_CTRL_MODE GENMASK(2, 0)
#define ZL_REF_SYNC_CTRL_MODE_REFSYNC_PAIR_OFF 0
+#define ZL_REF_SYNC_CTRL_MODE_REFSYNC_PAIR 1
#define ZL_REF_SYNC_CTRL_MODE_50_50_ESYNC_25_75 2
+#define ZL_REF_SYNC_CTRL_PAIR GENMASK(7, 4)
#define ZL_REG_REF_ESYNC_DIV ZL_REG(10, 0x30, 4)
#define ZL_REF_ESYNC_DIV_1HZ 0
--
2.52.0
^ permalink raw reply
* Re: [PATCH v1 3/3] arm64: dts: amlogic: meson-s4-s905y4-khadas-vim1s: use rc-khadas keymap
From: neil.armstrong @ 2026-03-27 15:34 UTC (permalink / raw)
To: Nick Xie, khilman, martin.blumenstingl, jbrunet
Cc: krzk+dt, robh, conor+dt, linux-amlogic, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260327093016.722095-4-nick@khadas.com>
On 3/27/26 10:30, Nick Xie wrote:
> The Khadas VIM1S board has an onboard IR receiver.
> Configure the default keymap to "rc-khadas" to support the official
> Khadas IR remote control.
>
> Signed-off-by: Nick Xie <nick@khadas.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts b/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts
> index 7314e0ab81da3..99d5df71b9cd4 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts
> @@ -242,6 +242,7 @@ &ir {
> status = "okay";
> pinctrl-0 = <&remote_pins>;
> pinctrl-names = "default";
> + linux,rc-map-name = "rc-khadas";
> };
>
> &pwm_ef {
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v1 2/3] arm64: dts: amlogic: meson-s4-s905y4-khadas-vim1s: enable HYM8563 RTC
From: neil.armstrong @ 2026-03-27 15:34 UTC (permalink / raw)
To: Nick Xie, khilman, martin.blumenstingl, jbrunet
Cc: krzk+dt, robh, conor+dt, linux-amlogic, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260327093016.722095-3-nick@khadas.com>
On 3/27/26 10:30, Nick Xie wrote:
> The Khadas VIM1S board has an on-board Haoyu Micro HYM8563 Real Time
> Clock (RTC) connected to the I2C1 bus.
>
> Enable the I2C1 controller and add the RTC child node to support
> hardware clock persistence.
>
> Signed-off-by: Nick Xie <nick@khadas.com>
> ---
> .../dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts b/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts
> index 792ab45c4c944..7314e0ab81da3 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-s4-s905y4-khadas-vim1s.dts
> @@ -20,6 +20,8 @@ aliases {
> mmc0 = &emmc; /* eMMC */
> mmc1 = &sd; /* SD card */
> mmc2 = &sdio; /* SDIO */
> + rtc0 = &rtc;
> + rtc1 = &vrtc;
> serial0 = &uart_b;
> };
>
> @@ -223,6 +225,19 @@ ðmac {
> phy-mode = "rmii";
> };
>
> +&i2c1 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1_pins2>;
> + clock-frequency = <100000>;
> +
> + rtc: rtc@51 {
> + compatible = "haoyu,hym8563";
> + reg = <0x51>;
> + #clock-cells = <0>;
> + };
> +};
> +
> &ir {
> status = "okay";
> pinctrl-0 = <&remote_pins>;
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v1 1/3] arm64: dts: amlogic: meson-s4: add VRTC node
From: neil.armstrong @ 2026-03-27 15:34 UTC (permalink / raw)
To: Nick Xie, khilman, martin.blumenstingl, jbrunet
Cc: krzk+dt, robh, conor+dt, linux-amlogic, linux-arm-kernel,
devicetree, linux-kernel
In-Reply-To: <20260327093016.722095-2-nick@khadas.com>
On 3/27/26 10:30, Nick Xie wrote:
> Add the Virtual RTC (VRTC) controller node to the Meson S4 SoC dtsi.
>
> Signed-off-by: Nick Xie <nick@khadas.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-s4.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-s4.dtsi b/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
> index 936a5c1353d15..2a6fbd5308362 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
> @@ -59,6 +59,11 @@ psci {
> method = "smc";
> };
>
> + vrtc: rtc@fe010288 {
> + compatible = "amlogic,meson-vrtc";
> + reg = <0x0 0xfe010288 0x0 0x4>;
> + };
> +
> xtal: xtal-clk {
> compatible = "fixed-clock";
> clock-frequency = <24000000>;
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* RE: [PATCH net-next 4/5] dt-bindings: dpll: add ref-sync-sources property
From: Prathosh.Satish @ 2026-03-27 15:33 UTC (permalink / raw)
To: ivecera, netdev
Cc: arkadiusz.kubalewski, jiri, mschmidt, poros, horms,
vadim.fedorenko, linux-kernel, conor+dt, krzk+dt, robh,
devicetree, pvaanane
In-Reply-To: <20260319174826.7623-5-ivecera@redhat.com>
Reviewed-by: prathosh.satish@microchip.com
-----Original Message-----
From: Ivan Vecera <ivecera@redhat.com>
Sent: Thursday, March 19, 2026 5:48 PM
To: netdev@vger.kernel.org
Cc: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>; Jiri Pirko <jiri@resnulli.us>; Michal Schmidt <mschmidt@redhat.com>; Petr Oros <poros@redhat.com>; Prathosh Satish - M66066 <Prathosh.Satish@microchip.com>; Simon Horman <horms@kernel.org>; Vadim Fedorenko <vadim.fedorenko@linux.dev>; linux-kernel@vger.kernel.org; Conor Dooley <conor+dt@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Rob Herring <robh@kernel.org>; devicetree@vger.kernel.org; Pasi Vaananen <pvaanane@redhat.com>
Subject: [PATCH net-next 4/5] dt-bindings: dpll: add ref-sync-sources property
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
Add ref-sync-sources phandle-array property to the dpll-pin schema allowing board designers to declare which input pins can serve as sync sources in a Reference-Sync pair. A Ref-Sync pair consists of a clock reference and a low-frequency sync signal where the DPLL locks to the clock but phase-aligns to the sync reference.
Update both examples in the Microchip ZL3073x binding to demonstrate the new property with a 1 PPS sync source paired to a clock source.
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
.../devicetree/bindings/dpll/dpll-pin.yaml | 11 +++++++
.../bindings/dpll/microchip,zl30731.yaml | 30 ++++++++++++++-----
2 files changed, 34 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/dpll/dpll-pin.yaml b/Documentation/devicetree/bindings/dpll/dpll-pin.yaml
index 51db93b77306f..7084f102e274c 100644
--- a/Documentation/devicetree/bindings/dpll/dpll-pin.yaml
+++ b/Documentation/devicetree/bindings/dpll/dpll-pin.yaml
@@ -36,6 +36,17 @@ properties:
description: String exposed as the pin board label
$ref: /schemas/types.yaml#/definitions/string
+ ref-sync-sources:
+ description: |
+ List of phandles to input pins that can serve as the sync source
+ in a Reference-Sync pair with this pin acting as the clock source.
+ A Ref-Sync pair consists of a clock reference and a low-frequency
+ sync signal. The DPLL locks to the clock reference but
+ phase-aligns to the sync reference.
+ Only valid for input pins. Each referenced pin must be a
+ different input pin on the same device.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+
supported-frequencies-hz:
description: List of supported frequencies for this pin, expressed in Hz.
diff --git a/Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml b/Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml
index 17747f754b845..fa5a8f8e390cd 100644
--- a/Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml
+++ b/Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml
@@ -52,11 +52,19 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
- pin@0 { /* REF0P */
+ sync0: pin@0 { /* REF0P - 1 PPS sync source */
reg = <0>;
connection-type = "ext";
- label = "Input 0";
- supported-frequencies-hz = /bits/ 64 <1 1000>;
+ label = "SMA1";
+ supported-frequencies-hz = /bits/ 64 <1>;
+ };
+
+ pin@1 { /* REF0N - clock source, can pair with sync0 */
+ reg = <1>;
+ connection-type = "ext";
+ label = "SMA2";
+ supported-frequencies-hz = /bits/ 64 <10000 10000000>;
+ ref-sync-sources = <&sync0>;
};
};
@@ -90,11 +98,19 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
- pin@0 { /* REF0P */
+ sync1: pin@0 { /* REF0P - 1 PPS sync source */
reg = <0>;
- connection-type = "ext";
- label = "Input 0";
- supported-frequencies-hz = /bits/ 64 <1 1000>;
+ connection-type = "gnss";
+ label = "GNSS_1PPS_IN";
+ supported-frequencies-hz = /bits/ 64 <1>;
+ };
+
+ pin@1 { /* REF0N - clock source */
+ reg = <1>;
+ connection-type = "gnss";
+ label = "GNSS_10M_IN";
+ supported-frequencies-hz = /bits/ 64 <10000000>;
+ ref-sync-sources = <&sync1>;
};
};
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Neil Armstrong @ 2026-03-27 15:28 UTC (permalink / raw)
To: Bryan O'Donoghue, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Bryan O'Donoghue, Vladimir Zapolskiy, linux-arm-msm,
linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <da3ed78d-fb5e-4820-95d6-527d540cf03e@linaro.org>
Le 27/03/2026 à 15:38, Bryan O'Donoghue a écrit :
> On 27/03/2026 10:07, Konrad Dybcio wrote:
>> On 3/26/26 2:04 AM, Bryan O'Donoghue wrote:
>>> Add a base schema initially compatible with x1e80100 to describe MIPI CSI2
>>> PHY devices.
>>>
>>> The hardware can support both CPHY, DPHY and a special split-mode DPHY. We
>>> capture those modes as:
>>>
>>> - PHY_QCOM_CSI2_MODE_DPHY
>>> - PHY_QCOM_CSI2_MODE_CPHY
>>> - PHY_QCOM_CSI2_MODE_SPLIT_DPHY
>> Does the_PHY_ DT node need to be aware about this upfront?
>
> Yeah that's a fair question.
>
> The standard model is to pass the mode via binding right now. You _could_ configure it @ run time in principle.
>
> And you could even conceive of a sensor hardware that might find value in that - but IMO it's a 100% hypothetical use-case - you'd basically need an FPGA that could output CPHY, DPHY or for some reason SPLIT_MODE DPHY.
>
> But that's a pretty off the wall use-case to hypothesize. Split-mode OTOH is a board-level physical reality which => a DT description not a runtime choice.
>
>> If we have some sideband signal (e.g. the sensor driver specifically
>> requesting C-PHY mode), we can simply throw all this complexity into
>> phy_mode + phy_configure_opts, all at runtime
>
> Like I say its conceivable but IMO not a real thing and unless your sensor is an FPGA not possible to support in real hardware.
>
>> Further, the combo/split mode may possibly be selected through
>> aggregation of requests.
>>
>> The question remains whether the sensor should have a direct connection to
>> the PHY itself (i.e. phys = <&csiphyN> or of_graph straight into the PHY)
>> or whether it's going to be translated by the camss node (which would be
>> the one holding a PHY reference) - there's probably surface for adding such
>> negotiation logic in both places
>
> To be frankly honest you can make an argument for it either way. However my honestly held position is analysing other upstream implementations connecting to the PHY means we can't make the PHY device a drivers/phy device - it would have to be a V4L2 device and then for me the question is why is that even required ?
This is plain wrong, DT definition is different from software implementation, you can do whatever you want if you describe HW accurately.
The CSIPHYs are not tied to a single "consumer" block, they can be connected to different consumers at runtime, which is not something classic PHY devices are designed for. So they are de facto a media element in the dynamic camera pipeline.
>
> The model we have right now, right or wrong is sensor endpoint to controller. Similarly the <&phy MODE_GOES_HERE> is a pattern Rob Herring suggested and IMO is a consistent pattern we should aim for upstream. We see it in latest Rockchip, Cadence.
This doesn’t properly describe the data path, we got out of this classic scheme when implementing the whole USB-C complex on qualcomm SoCs where we had to describe the data flow within all the USB/DSP/DP/PHYs elements, and we have a link between the DP controller and the Combo PHY acting as a DRM bridge.
And actually Rob Herring asked use to define the complete data flow, it was a strong requirement. I don't see why we wouldn't here.
Looking at other vendors and sticking to this is wrong, we need to solve how to describe the Qualcomm CAMSS complex with accurate representation of the data flow and hw components interconnections. The choice of kernel API to access an HW element is irrelevant in the discussion.
Starting refactoring the DT representation of CAMSS is good, starting with PHY is weird since I don't see what it does solve we can't solve already,
but you need to take in account how the CSIPHYs are connected to other HW blocks. Simply adding a "phys =" reference from CAMSS node doesn't reflect
at all which HW element will consume the PHY, and what are the link parameters between the consumer and the PHY and between the PHY and the Sensor.
Those are the whole meaning of the port/endpoint links, where we can define multiple endpoints for a same connection to, for example, define multiple sensors on a same PHY for the split-mode.
Neil
>
>
>> Note this is a question and I'm not aware of all the possible combinations
>>
>> Konrad
>
^ permalink raw reply
* RE: [PATCH net-next 0/5] dpll: zl3073x: add ref-sync pair support
From: Prathosh.Satish @ 2026-03-27 15:28 UTC (permalink / raw)
To: ivecera, netdev
Cc: arkadiusz.kubalewski, jiri, mschmidt, poros, horms,
vadim.fedorenko, linux-kernel, conor+dt, krzk+dt, robh,
devicetree, pvaanane
In-Reply-To: <20260319174826.7623-1-ivecera@redhat.com>
Reviewed-by: prathosh.satish@microchip.com
-----Original Message-----
From: Ivan Vecera <ivecera@redhat.com>
Sent: Thursday, March 19, 2026 5:48 PM
To: netdev@vger.kernel.org
Cc: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>; Jiri Pirko <jiri@resnulli.us>; Michal Schmidt <mschmidt@redhat.com>; Petr Oros <poros@redhat.com>; Prathosh Satish - M66066 <Prathosh.Satish@microchip.com>; Simon Horman <horms@kernel.org>; Vadim Fedorenko <vadim.fedorenko@linux.dev>; linux-kernel@vger.kernel.org; Conor Dooley <conor+dt@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Rob Herring <robh@kernel.org>; devicetree@vger.kernel.org; Pasi Vaananen <pvaanane@redhat.com>
Subject: [PATCH net-next 0/5] dpll: zl3073x: add ref-sync pair support
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
This series adds Reference-Sync pair support to the ZL3073x DPLL driver.
A Ref-Sync pair consists of a clock reference and a low-frequency sync signal (e.g. 1 PPS) where the DPLL locks to the clock reference but phase-aligns to the sync reference.
Patches 1-3 are preparatory cleanups and helper additions:
- Clean up esync get/set callbacks with early returns and use the
zl3073x_out_is_ndiv() helper
- Convert open-coded clear-and-set bitfield patterns to FIELD_MODIFY()
- Add ref sync control and output clock type accessor helpers
Patch 4 adds the 'ref-sync-sources' phandle-array property to the dpll-pin device tree binding schema and updates the ZL3073x binding examples.
Patch 5 implements the driver support:
- ref_sync_get/set callbacks with frequency validation
- Automatic sync source exclusion from reference selection
- Device tree based ref-sync pair registration
Tested and verified on Microchip EDS2 (pcb8385) development board.
Ivan Vecera (5):
dpll: zl3073x: clean up esync get/set and use zl3073x_out_is_ndiv()
dpll: zl3073x: use FIELD_MODIFY() for clear-and-set patterns
dpll: zl3073x: add ref sync and output clock type helpers
dt-bindings: dpll: add ref-sync-sources property
dpll: zl3073x: add ref-sync pair support
.../devicetree/bindings/dpll/dpll-pin.yaml | 11 +
.../bindings/dpll/microchip,zl30731.yaml | 30 +-
drivers/dpll/zl3073x/chan.h | 17 +-
drivers/dpll/zl3073x/core.c | 3 +-
drivers/dpll/zl3073x/dpll.c | 295 ++++++++++++++----
drivers/dpll/zl3073x/flash.c | 3 +-
drivers/dpll/zl3073x/out.h | 22 ++
drivers/dpll/zl3073x/ref.h | 46 +++
drivers/dpll/zl3073x/regs.h | 2 +
9 files changed, 348 insertions(+), 81 deletions(-)
--
2.52.0
^ permalink raw reply
* Re: [PATCH v2 2/2] ARM: tegra: transformers: add connector node
From: Svyatoslav Ryhel @ 2026-03-27 15:28 UTC (permalink / raw)
To: Thierry Reding
Cc: David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, Thierry Reding, Jonathan Hunter, dri-devel,
devicetree, linux-tegra, linux-kernel
In-Reply-To: <acafk7munaGrCTK3@orome>
27 березня 2026 р. 17:18:42 GMT+02:00, Thierry Reding <thierry.reding@kernel.org> пише:
>On Mon, Feb 23, 2026 at 08:55:00AM +0200, Svyatoslav Ryhel wrote:
>> All ASUS Transformers have micro-HDMI connector directly available. After
>> Tegra HDMI got bridge/connector support, we should use connector framework
>> for proper HW description.
>>
>> Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # ASUS TF T30
>> Tested-by: Robert Eckelmann <longnoserob@gmail.com> # ASUS TF101 T20
>> Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # ASUS TF201 T30
>> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
>> ---
>> .../boot/dts/nvidia/tegra30-asus-tf600t.dts | 21 +++++++++++++++++--
>> 1 file changed, 19 insertions(+), 2 deletions(-)
>
>Two things about you commit messages that I have to fixup every time:
>
> 1. caps after the subject prefix
Prefix ends with ':' which does not imply using of capital letter as '.' '!' or '?' do. Linux documentation does not regulate this.
Even more, examples use lower case
[PATCH 001/123] subsystem: summary phrase
> 2. wrap commit message at 72 characters
>
The body of the explanation, line wrapped at 75 columns, which will be copied to the permanent changelog to describe this patch.
The commit message is wrapped by 75 characters, as linux documentation requests.
>Both patches applied, thanks.
>
>Thierry
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: eliza: Add thermal sensors
From: Abel Vesa @ 2026-03-27 15:28 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260327101225.382493-2-krzysztof.kozlowski@oss.qualcomm.com>
On 26-03-27 11:12:26, Krzysztof Kozlowski wrote:
> Add TSENS thermal sensors to Qualcomm Eliza SoC among with thermal
> zones. The TSENS is compatible with previous generations.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v5 4/5] arm64: dts: qcom: x1-crd: Add Embedded controller node
From: Abel Vesa @ 2026-03-27 15:24 UTC (permalink / raw)
To: Anvesh Jain P
Cc: Sibi Sankar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, linux-arm-msm, devicetree,
linux-kernel, platform-driver-x86, Dmitry Baryshkov,
Konrad Dybcio
In-Reply-To: <20260317-add-driver-for-ec-v5-4-38d11f524856@oss.qualcomm.com>
On 26-03-17 17:57:58, Anvesh Jain P wrote:
> From: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
>
> Add embedded controller node for Hamoa/Purwa CRDs which adds fan control,
> temperature sensors, access to EC internal state changes and suspend
> entry/exit notifications to the EC.
>
> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Co-developed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
> Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v5 3/5] arm64: dts: qcom: glymur-crd: Add Embedded controller node
From: Abel Vesa @ 2026-03-27 15:23 UTC (permalink / raw)
To: Anvesh Jain P
Cc: Sibi Sankar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Bjorn Andersson, Konrad Dybcio, linux-arm-msm, devicetree,
linux-kernel, platform-driver-x86, Dmitry Baryshkov,
Konrad Dybcio
In-Reply-To: <20260317-add-driver-for-ec-v5-3-38d11f524856@oss.qualcomm.com>
On 26-03-17 17:57:57, Anvesh Jain P wrote:
> From: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
>
> Add embedded controller node for Glymur CRDs which adds fan control,
> temperature sensors, access to EC state changes through SCI events
> and suspend entry/exit notifications to the EC.
>
> Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Co-developed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
> Signed-off-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v1] arm64: dts: qcom: hamoa-iot-som: Add firmware-name to QUPv3 nodes
From: Abel Vesa @ 2026-03-27 15:21 UTC (permalink / raw)
To: Xueyao An
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260327085318.2771771-1-xueyao.an@oss.qualcomm.com>
On 26-03-27 16:53:17, Xueyao An wrote:
> Traditionally, firmware loading for Serial Engines (SE) in the QUP hardware
> of Qualcomm SoCs has been managed by TrustZone (TZ). While this approach
> ensures secure SE assignment and access control, it limits flexibility for
> developers who need to enable various protocols on different SEs.
>
> Add the firmware-name property to QUPv3 nodes in the device tree to enable
> firmware loading from the Linux environment. Handle SE assignments and
> access control permissions directly within Linux, removing the dependency
> on TrustZone.
>
> Signed-off-by: Xueyao An <xueyao.an@oss.qualcomm.com>
Hopefully, there is a DT binding schema update that goes with this...
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v3 01/11] arm64: dts: qcom: x1e80100: Add CAMCC block definition
From: Abel Vesa @ 2026-03-27 15:19 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Vladimir Zapolskiy, Konrad Dybcio
In-Reply-To: <20260326-x1e-camss-csi2-phy-dtsi-v3-1-1d5a9306116a@linaro.org>
On 26-03-26 10:27:38, Bryan O'Donoghue wrote:
> Add the CAMCC block for x1e80100. The x1e80100 CAMCC block is an iteration
> of previous CAMCC blocks with the exception of having two required
> power-domains not just one.
Nit: maybe we should be using Hamoa instead of x1e80100 ...
>
> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 0/4] ARM: tegra: lg-x3: add missing nodes
From: Svyatoslav Ryhel @ 2026-03-27 15:18 UTC (permalink / raw)
To: Thierry Reding
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Thierry Reding, Jonathan Hunter, Jonas Schwöbel, devicetree,
linux-tegra, linux-kernel
In-Reply-To: <acacdUaXVNIKHT2O@orome>
27 березня 2026 р. 17:05:34 GMT+02:00, Thierry Reding <thierry.reding@kernel.org> пише:
>On Mon, Jan 26, 2026 at 12:10:14PM +0200, Svyatoslav Ryhel wrote:
>> With the recent kernel updates, Tegra30-based LG smartphones now support
>> several additional features, including an RGB-DSI bridge, DSI panels,
>> MUIC, a charger, a battery temperature sensor, OTG mode, and capacitive
>> buttons on the P895. Add required nodes to device trees.
>>
>> ---
>> Changes in v2:
>> - fixed dw9714 and tx13d100vm0eaa nodes
>> - added video device pipes graph
>>
>> Regarding CHECK_DTBS output in v2:
>> - nvidia,tegra30-pcie, nvidia,tegra30-gmi, nvidia,tegra30-kbc,
>> nvidia,tegra20-kbc, nvidia,tegra30-ahub are not documented yet
>> - nvidia,tegra30-vi was adjusted and applied, change did not apper yet
>> (https://lore.kernel.org/lkml/176860988748.1688420.11717122647073678.b4-ty@nvidia.com/)
>> - st,m24c08 appers undocumented though it seems to be different from
>> st,24c08, at least they google as separate devices. atmel,24c08 is not
>> documented, though it is widey used in linux device trees and is
>> supported by driver. Here is one of examples:
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/allwinner/sun7i-a20-linutronix-testbox-v2.dts?h=next-20260123#n33
>> - onnn,mt9m114 does not have 'orientation' property, though it should
>> include it since it is generic for camera devices
>> - ti,lp8720 and maxim,max77663 have txt documentation and are not yet
>> converted to DT schema
>> - backlight in panel nodes was not added since lm3533 has no DT support
>> - missing '#io-channel-cells' in ti,tsc2007 addressed in
>> https://lore.kernel.org/lkml/20260122193549.29858-2-clamor95@gmail.com/
>> - missing dsi controller properties of ssd2825 addressed in
>> https://lore.kernel.org/lkml/20260123073411.7736-2-clamor95@gmail.com/
>> - missing '#io-channel-cells' in generic-adc-thermal was proposed in but rejected
>> https://lore.kernel.org/lkml/20250310075638.6979-2-clamor95@gmail.com/
>> ---
>>
>> Svyatoslav Ryhel (4):
>> ARM: tegra: lg-x3: add panel and bridge nodes
>> ARM: tegra: lg-x3: add USB and power related nodes
>> ARM: tegra: lg-x3: add node for capacitive buttons
>> ARM: tegra: lg-x3: complete video device graph
>>
>> arch/arm/boot/dts/nvidia/tegra30-lg-p880.dts | 39 +++
>> arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts | 79 +++++
>> arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi | 328 ++++++++++++++++++-
>> 3 files changed, 429 insertions(+), 17 deletions(-)
>
>Patches 1-3 applied. Patch 4 has checkpatch has checkpatch warnings:
>
> WARNING: DT compatible string "st,m24c08" appears un-documented -- check ./Documentation/devicetree/bindings/
> #255: FILE: arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi:1243:
> + compatible = "st,m24c08", "atmel,24c08";
>
>So I've left it out for now.
>
st,m24c08 appers undocumented though it seems to be different from
st,24c08 (in schema) at least they google as separate devices. atmel,24c08 is not
documented, though it is widey used in linux device trees and is
supported by driver. Here is one of examples:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/allwinner/sun7i-a20-linutronix-testbox-v2.dts?h=next-20260123#n33
I assume patch 4 should be fine and most likely schema needs to be adjusted to cover this compatible (since it exists and is used).
>Thierry
^ permalink raw reply
* Re: [PATCH v2 2/2] ARM: tegra: transformers: add connector node
From: Thierry Reding @ 2026-03-27 15:18 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, Thierry Reding, Jonathan Hunter, dri-devel,
devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260223065500.13357-3-clamor95@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 857 bytes --]
On Mon, Feb 23, 2026 at 08:55:00AM +0200, Svyatoslav Ryhel wrote:
> All ASUS Transformers have micro-HDMI connector directly available. After
> Tegra HDMI got bridge/connector support, we should use connector framework
> for proper HW description.
>
> Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # ASUS TF T30
> Tested-by: Robert Eckelmann <longnoserob@gmail.com> # ASUS TF101 T20
> Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # ASUS TF201 T30
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../boot/dts/nvidia/tegra30-asus-tf600t.dts | 21 +++++++++++++++++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
Two things about you commit messages that I have to fixup every time:
1. caps after the subject prefix
2. wrap commit message at 72 characters
Both patches applied, thanks.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 7/8] drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time
From: Luca Ceresoli @ 2026-03-27 15:17 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Jonas Karlman,
Jernej Skrabec, Liu Ying, Rob Herring, Saravana Kannan,
Kory Maincent (TI.com), Hervé Codina, Hui Pu, Ian Ray,
Thomas Petazzoni, dri-devel, imx, linux-arm-kernel, linux-kernel,
devicetree, Adam Ford, Alexander Stein, Anson Huang,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Joao Paulo Goncalves,
Josua Mayer, Kieran Bingham, Marco Felsch, Martyn Welch,
Oleksij Rempel, Peng Fan, Philippe Schenker, Richard Hu,
Shengjiu Wang, Stefan Eichenberger, Vitor Soares
In-Reply-To: <20260326082843.GB2670326@killaraus.ideasonboard.com>
Hi Laurent,
On Thu Mar 26, 2026 at 9:28 AM CET, Laurent Pinchart wrote:
>> Many dts files for imx8mp-based boards in the kernel have such a connector
>> described and linked to port@1, so a connector is added by the
>> display-connector driver along with a bridge wrapping it. Sadly some of
>> those dts files don't have the connector described. Adding it would solve
>> the problem easily, but this would break existing devices which do not
>> update the dtb when upgrading to a newer kernel.
>
> I think this series should also fix the in-tree dts files, to pave the
> way for removing the workaround.
Fixing all dts files can surely be done, but it won't allow removing the
workaround. Any devices shipped with a dtb without the connector and
upgrading their kernel later on but not the dtb will fail as soon as they
upgrade to a kernel with patch 8 but with this workaround removed.
That said, do you still think it's worth adding the hdmi-connector node to
all dtbs missing it?
It should be fairly simple and IIRC it would involve a couple dozen drivers
at most based on my initial research. However for most of them I have no
way to know which type of connector is installed, would it be OK if we
describe type A when the type is unknown, just like
dw_hdmi_connector_create() does right now programmatically [0]?
[0] https://elixir.bootlin.com/linux/v7.0-rc5/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L2601
Also, if such a change is to be done, I'd definitely do it as a separate
series, to avoid adding more stuff to this series in-flight.
>> --- a/drivers/gpu/drm/bridge/imx/Kconfig
>> +++ b/drivers/gpu/drm/bridge/imx/Kconfig
>> @@ -25,6 +25,23 @@ config DRM_IMX8MP_DW_HDMI_BRIDGE
>> Choose this to enable support for the internal HDMI encoder found
>> on the i.MX8MP SoC.
>>
>> +config DRM_IMX8MP_DW_HDMI_BRIDGE_CONNECTOR_FIXUP
>> + bool "Support device tree blobs without an hdmi-connector node"
>> + default y
>
> Can't we enable the workaround unconditionally ? Distributions will need
> to enable this option anyway as they can't know what device they will
> boot on. I fear a configuration option will confuse users and waste time
> on debugging.
Sure, good point.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v9 2/9] lib: vsprintf: export simple_strntoull() in a safe prototype
From: Rodrigo Alencar @ 2026-03-27 15:17 UTC (permalink / raw)
To: Andy Shevchenko, Rodrigo Alencar
Cc: Petr Mladek, rodrigo.alencar, linux-kernel, linux-iio, devicetree,
linux-doc, Jonathan Cameron, David Lechner, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Andrew Morton,
Steven Rostedt, Rasmus Villemoes, Sergey Senozhatsky, Shuah Khan
In-Reply-To: <acZaGUV0MwuHNDru@ashevche-desk.local>
On 26/03/27 12:21PM, Andy Shevchenko wrote:
> On Fri, Mar 27, 2026 at 10:11:56AM +0000, Rodrigo Alencar wrote:
> > On 26/03/27 11:17AM, Andy Shevchenko wrote:
> > > On Fri, Mar 27, 2026 at 09:45:17AM +0100, Petr Mladek wrote:
> > > > On Fri 2026-03-20 16:27:27, Rodrigo Alencar via B4 Relay wrote:
>
> ...
>
> > > > > +extern ssize_t __must_check simple_strntoull(const char *startp, const char **endp,
> > > > > + unsigned int base, size_t max_chars,
> > > > > + unsigned long long *res);
> > > >
> > > > Sigh, naming is hard. I personally find it a bit confusing that the
> > > > name is too similar to the unsafe API.
> > > >
> > > > IMHO, the semantic of the new API is closer to kstrtoull().
> > > > It just limits the size, so I would call it kstrntoull().
> > >
> > > It's not. kstrto*() quite strict about the input, this one is actually relaxed
> > > variant, so I wouldn't mix these two groups.
> > >
> > > > Also I would use int as the return parameter, see below.
>
> ...
>
> > > TBH, I am skeptical about this approach. My main objection is max_chars
> > > parameter. If we want to limit the input strictly to the given number of
> > > characters, we have to copy the string and then just use kstrto*() in a normal
> > > way. The whole idea of that parameter is to be able to parse the fractional
> > > part of the float number as 'iiiii.fffff', where 'i' is for integer part, and
> > > 'f' for the fractional. Since we have *endp, we may simply check that.
> >
> > A max_chars would not be only useful for that. It can prevent out-of-bounds
> > reads when the input isn't NUL-terminated (like buffers, file chunks,
> > network packets, memory-mapped data, ....). Even if there is a NUL later in
> > memory, a regular strtoull() function may consume characters that are outside
> > the field one intends to parse.
>
> Okay, but is it the current case or just an attempt to solve the problem that
> doesn't exist (yet)?
The current case can be seen as such. Copying the string and use regular ksrto*()
requires an unecessary scan of string from the user side, which is something that
_parse_integer_limit() already does, mostly because it checks for digits and stops
at any non-digit character. In the IIO case, we also want control over the consumed
characters because there are weird terminations like "dB", so having an implementation
like this ends up with a cleaner sequence of steps.
> > > In case if we want to parse only, say, 6 digits and input is longer there are
> > > a few options (in my personal preferences, the first is the better):
> > > - consider the input invalid
> > > - parse it as is up to the maximum and then do ceil() or floor() on top of that
> > > - copy only necessary amount of the (sub)string and parse that.
> >
> > Yes, my use case is the fixed point parsing, but I suppose we are implementing
> > things here for reuse.
>
> Yes, I'm full for reuse, but I want to have it balanced between complexity,
> existing use cases and possible reuse in the future.
Not seeing complexity here as in this case I am just exposing something
that already exists! No need for a completely different implementation.
I just want to get an agreement on the naming and interface prototype.
Bringing back the discussion again just because I suppose Petr havent even
seen the v8 of this patch series. If kstrtox.h is the right place for this,
kstrntoull() sounds like ideal. Specially because simple_strto*() is already
labeled as unsafe and kstrnto*() != kstrto*().
> > Also, the default behavior of the previous fixed point
> > parsing in IIO is flooring the result, which leads to the same result as
> > ignoring further digits.
>
> Correct, I also lean to implying floor() (as you can read below).
>
> > > The problem with precision is that we need to also consider floor() or ceil()
> > > and I don't think this should be burden of the library as it's individual
> > > preference of each of the callers (users). At least for the starter, we will
> > > see if it's only one approach is used, we may incorporate it into the library
> > > code.
> > >
> > > The easiest way out is to just consider the input invalid if it overflows the
> > > given type (s32 or s64).
> > >
> > > But we need to have an agreement what will be the representation of the
> > > fixed-width float numbers in the kernel? Currently IIO uses
> > > struct float // name is crafted for simplicity
> > > {
> > > int integer;
> > > int fraction;
> > > }
> >
> > Yes, but to represent things like that, an assumption is made to the precision that
> > "fraction" carries.
>
> Correct.
>
> > > This parser wants AFAIU to have at the end of the day something like
> > >
> > > struct float
> > > {
> > > s64 integer;
> > > s64 fraction;
> > > }
> > >
> > > but also wants to have the fraction part be limited in some cases to s32
> > > or so:
> > >
> > > struct float
> > > {
> > > s64 integer;
> > > s32 fraction; // precision may be lost if input is longer
> > > }
> > >
> > > Maybe we want to have kstrtof32() and kstrtof64() for these two cases?
> > >
> > > With that we will always consider the fraction part as 32- or 64-bit,
> > > imply floor() on the fraction for the sake of simplicity and require
> > > it to be NUL-terminated with possible trailing '\n'.
> >
> > I think this is a good idea, but calling it float or fixed point itself
> > is a bit confusing as float often refers to the IEEE 754 standard and
> > fixed point types is often expressed in Q-format.
>
> Yeah... I am lack of better naming.
decimals is the name, but they are often represented as:
DECIMAL = INT * 10^X + FRAC
in a single 64-bit number, which would be fine for my end use case.
However IIO decimal fixed point parsing is out there for quite some time a
lot of drivers use that. The interface often relies on breaking parsed values
into an integer array (for standard attributes int val and int val2 are expected).
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH v3 02/11] arm64: dts: qcom: x1e80100: Add CCI definitions
From: Abel Vesa @ 2026-03-27 15:16 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Konrad Dybcio, Vladimir Zapolskiy
In-Reply-To: <20260326-x1e-camss-csi2-phy-dtsi-v3-2-1d5a9306116a@linaro.org>
On 26-03-26 10:27:39, Bryan O'Donoghue wrote:
> Add in two CCI buses.
>
> One bus has two CCI bus master pinouts:
> cci_i2c_sda0 = gpio101
> cci_i2c_scl0 = gpio102
>
> cci_i2c_sda1 = gpio103
> cci_i2c_scl1 = gpio104
>
> The second bus has two CCI bus master pinouts:
> cci_i2c_sda2 = gpio105
> cci_i2c_scl2 = gpio106
>
> aon_cci_i2c_sda3 = gpio235
> aon_cci_i2c_scl3 = gpio236
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
^ 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