* Re: [PATCH v2 2/4] iio: adc: meson-saradc: add support for Meson S4
From: Jonathan Cameron @ 2026-03-24 9:06 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Nick Xie, neil.armstrong, khilman, martin.blumenstingl, jbrunet,
dlechner, andy, krzk+dt, robh, conor+dt, linux-iio, linux-amlogic,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <171e30f3-e294-40fb-8731-476fb51d5a3c@kernel.org>
On Tue, 24 Mar 2026 08:07:15 +0100
Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 23/03/2026 21:05, Jonathan Cameron wrote:
> > On Mon, 23 Mar 2026 08:54:21 +0100
> > Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> >> On Mon, Mar 23, 2026 at 09:34:06AM +0800, Nick Xie wrote:
> >>> Add support for the SARADC found on the Amlogic Meson S4 SoC.
> >>> According to the documentation and current testing, it is fully
> >>> compatible with the G12A parameter set, so we reuse
> >>> `meson_sar_adc_g12a_data` for this new compatible string.
> >>>
> >>> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> >>> Signed-off-by: Nick Xie <nick@khadas.com>
> >>> ---
> >>> drivers/iio/adc/meson_saradc.c | 8 ++++++++
> >>> 1 file changed, 8 insertions(+)
> >>>
> >>> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> >>> index 47cd350498a0d..3ac48b7842c4f 100644
> >>> --- a/drivers/iio/adc/meson_saradc.c
> >>> +++ b/drivers/iio/adc/meson_saradc.c
> >>> @@ -1313,6 +1313,11 @@ static const struct meson_sar_adc_data meson_sar_adc_g12a_data = {
> >>> .name = "meson-g12a-saradc",
> >>> };
> >>>
> >>> +static const struct meson_sar_adc_data meson_sar_adc_s4_data = {
> >>> + .param = &meson_sar_adc_g12a_param,
> >>> + .name = "meson-s4-saradc",
> >>> +};
> >>> +
> >>> static const struct of_device_id meson_sar_adc_of_match[] = {
> >>> {
> >>> .compatible = "amlogic,meson8-saradc",
> >>> @@ -1341,6 +1346,9 @@ static const struct of_device_id meson_sar_adc_of_match[] = {
> >>> }, {
> >>> .compatible = "amlogic,meson-g12a-saradc",
> >>> .data = &meson_sar_adc_g12a_data,
> >>> + }, {
> >>> + .compatible = "amlogic,meson-s4-saradc",
> >>
> >> The point of compatible devices is to not add such entries. Drop.
> > It's used for naming in the userspace ABI which is supposed to reflect the part number.
>
> Indeed, I saw this pattern in more places. Does userspace need it? There
> is no "compatible" entry shown?
Yes. Userspace uses this (+ a label) to identify which of multiple devices
it is talking to. Given some of these parts are very specific rather than
covering a general purpose, people tend to be looking at datasheets if there
are multiple parts and they want to know which is which. Knowing whether
it's compatible with something else doesn't help with that identification
part.
>
> If there is no, then probably this could be automated by taking the name
> from compatible after ',', but that would be out of scope for this set,
> so here it is fine.
For DT that works but not for other firmware types. We had a bunch of bugs
where people ended up putting out ACPI IDs (some of which we've had to leave
in place to avoid regressions). Hence I've always been nervous about not
encoding the string explicitly in the driver. Obviously this is a bit
paranoid for DT where it's reasonably tightly defined.
Jonathan
>
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v3 14/14] drm/display: hdmi: Use drm_output_color_format instead of hdmi_colorspace
From: Nicolas Frattaroli @ 2026-03-24 9:08 UTC (permalink / raw)
To: Jani Nikula, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Harry Wentland, Leo Li,
Rodrigo Siqueira, Alex Deucher, Christian König,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Andy Yan, Liviu Dudau,
Chun-Kuang Hu, Philipp Zabel, Matthias Brugger,
AngeloGioacchino Del Regno, Sandy Huang, Heiko Stübner,
Liu Ying, Chen-Yu Tsai, Samuel Holland, Dave Stevenson,
Maíra Canal, Raspberry Pi Kernel Maintenance, Maxime Ripard
Cc: dri-devel, linux-kernel, amd-gfx, linux-mediatek,
linux-arm-kernel, linux-rockchip, linux-sunxi, Jani Nikula
In-Reply-To: <20260305-drm-rework-color-formats-v3-14-f3935f6db579@kernel.org>
On Thursday, 5 March 2026 10:05:06 Central European Standard Time Maxime Ripard wrote:
> The hdmi_colorspace enum was defined to represent the colorspace value
> of the HDMI infoframes. It was later used by some HDMI drivers to
> express the output format they should be setting up.
>
> During the introduction of the HDMI helpers, it then was used to
> represent it in the drm_connector_hdmi_state structure.
>
> However, it's always been somewhat redundant with the DRM_COLOR_FORMAT_*
> defines, and now with the drm_output_color_format enum. Let's
> consolidate around drm_output_color_format in drm_connector_hdmi_state
> to facilitate the current effort to provide a global output format
> selection mechanism.
>
> Acked-by: Jani Nikula <jani.nikula@intel.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/bridge/inno-hdmi.c | 6 +-
> drivers/gpu/drm/bridge/ite-it6263.c | 2 +-
> drivers/gpu/drm/display/drm_bridge_connector.c | 4 +-
> drivers/gpu/drm/display/drm_hdmi_helper.c | 7 +-
> drivers/gpu/drm/display/drm_hdmi_state_helper.c | 52 ++++--
> drivers/gpu/drm/drm_bridge.c | 2 +-
> drivers/gpu/drm/drm_connector.c | 16 +-
> drivers/gpu/drm/mediatek/mtk_hdmi_v2.c | 8 +-
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 2 +-
> drivers/gpu/drm/tests/drm_connector_test.c | 80 ++++-----
> drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 182 ++++++++++-----------
> drivers/gpu/drm/vc4/vc4_hdmi.c | 18 +-
> drivers/gpu/drm/vc4/vc4_hdmi.h | 2 +-
> include/drm/bridge/dw_hdmi_qp.h | 2 +-
> include/drm/display/drm_hdmi_helper.h | 3 +-
> include/drm/drm_bridge.h | 5 +-
> include/drm/drm_connector.h | 9 +-
> 17 files changed, 213 insertions(+), 187 deletions(-)
>
Since I've been relying this for a while now and could find no further
issues with the conversion, I'll give this a:
Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Thank you for the refactor!
^ permalink raw reply
* Re: [PATCH v3 04/14] drm/amdgpu: display: Convert to drm_output_color_format
From: Nicolas Frattaroli @ 2026-03-24 9:11 UTC (permalink / raw)
To: Jani Nikula, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Harry Wentland, Leo Li,
Rodrigo Siqueira, Alex Deucher, Christian König,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Andy Yan, Liviu Dudau,
Chun-Kuang Hu, Philipp Zabel, Matthias Brugger,
AngeloGioacchino Del Regno, Sandy Huang, Heiko Stübner,
Liu Ying, Chen-Yu Tsai, Samuel Holland, Dave Stevenson,
Maíra Canal, Raspberry Pi Kernel Maintenance, Maxime Ripard
Cc: dri-devel, linux-kernel, amd-gfx, linux-mediatek,
linux-arm-kernel, linux-rockchip, linux-sunxi, Jani Nikula
In-Reply-To: <20260305-drm-rework-color-formats-v3-4-f3935f6db579@kernel.org>
On Thursday, 5 March 2026 10:04:56 Central European Standard Time Maxime Ripard wrote:
> Now that we introduced a new drm_output_color_format enum to represent
> what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
> enum.
>
> The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
> drm_output_color_format is a proper enum. However, the enum was done is
> such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
> the transitition is easier.
>
> The only thing we need to consider is if the original code meant to use
> that value as a bitmask, in which case we do need to keep the bit shift,
> or as a discriminant in which case we don't.
>
> Acked-by: Jani Nikula <jani.nikula@intel.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index a8e4e3ab5e40276b3c723297ca6520688079e0a7..2fe9044e1e91d7581fd5032b9883548f8e5e1b43 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6723,15 +6723,15 @@ static void fill_stream_properties_from_drm_display_mode(
> timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
> else if (drm_mode_is_420_also(info, mode_in)
> && aconnector
> && aconnector->force_yuv420_output)
> timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
> - else if ((connector->display_info.color_formats & DRM_COLOR_FORMAT_YCBCR422)
> + else if ((connector->display_info.color_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422))
> && aconnector
> && aconnector->force_yuv422_output)
> timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR422;
> - else if ((connector->display_info.color_formats & DRM_COLOR_FORMAT_YCBCR444)
> + else if ((connector->display_info.color_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444))
> && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
> timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR444;
> else
> timing_out->pixel_encoding = PIXEL_ENCODING_RGB;
>
>
>
Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
I've been running this patch as part of my color format work and it
works precisely as it's supposed to (which is also quite evident from
the simple conversion in the code.)
Kind regards,
Nicolas Frattaroli
^ permalink raw reply
* Re: [PATCH net-next 0/8] net: stmmac: improve PCS support
From: Russell King (Oracle) @ 2026-03-24 9:14 UTC (permalink / raw)
To: Mohd Ayaan Anwar
Cc: Konrad Dybcio, Andrew Lunn, Alexandre Torgue, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, linux-arm-kernel,
linux-arm-msm, linux-stm32, netdev, Paolo Abeni, Vinod Koul
In-Reply-To: <acGhQ0oui+dVRdLY@oss.qualcomm.com>
On Tue, Mar 24, 2026 at 01:53:31AM +0530, Mohd Ayaan Anwar wrote:
> Hi,
> On Thu, Mar 19, 2026 at 03:11:24PM +0000, Russell King (Oracle) wrote:
> > On Thu, Mar 19, 2026 at 02:50:29PM +0100, Konrad Dybcio wrote:
> > > On 3/19/26 1:58 PM, Russell King (Oracle) wrote:
> > > > On Thu, Mar 19, 2026 at 11:09:33AM +0100, Konrad Dybcio wrote:
> > > >> On 3/19/26 10:24 AM, Russell King (Oracle) wrote:
> > > >>> On Thu, Mar 19, 2026 at 12:35:58AM +0000, Russell King (Oracle) wrote:
> > > >>>> On Thu, Mar 19, 2026 at 03:42:05AM +0530, Mohd Ayaan Anwar wrote:
> > > >>>>> [ 8.650486] qcom-ethqos 23040000.ethernet: clk_csr value out of range (0xffffff00 exceeds mask 0x00000f00), truncating
> > > >>>>
> > > >>>> Please look into this first - with the MDIO bus operating at
> > > >>>> who-knows-what frequency, this could make reading from the PHY
> > > >>>> unreliable.
> > > >>>
> > > >>> My guess is clk_get_rate(priv->plat->stmmac_clk) is returning zero,
> > > >>> which means we don't know the rate of the CSR clock.
> > > >>>
> > > >>> From what I can see in drivers/clk/qcom/gcc-qcs404.c and
> > > >>> drivers/clk/qcom/gcc-sdx55.c, this looks like this case - the
> > > >>> struct clk_branch makes no mention of any clock rate, nor does it
> > > >>> have any parent. From what I can see, neither of these drivers
> > > >>> specify any rates for any of their clocks, which likely means that
> > > >>> clk_get_rate() will be zero for all of them.
> > > >>>
> > > >>> Sadly, when I designed the clk API, I didn't think that people would
> > > >>> be stupid enough not to implement the API properly, more fool me.
> > > >>>
> > > >>> Under the old code, we would've used STMMAC_CSR_20_35M, which means
> > > >>> we're assuming that the CSR clock is between 20 and 35MHz, even
> > > >>> though the value is zero. Is that the case? If it's higher than
> > > >>> 35MHz, then you've been operating the MDIO bus out of IEEE 802.3
> > > >>> specification, which can make PHY access unrealible.
> > > >>>
> > > >>> In any case, please fix your clock drivers.
> > > >>
> > > >> I'm not 100% sure the currently-passed AXI clock is what we want
> > > >> there and the docs aren't super helpful.. is there a synopsys-name
> > > >> for it? What rates would you expect it to run at?
> > > >
> > > > There is no easy answer to that - it depends on the bus interfaces
> > > > and whether the CSR (register) clock is separate.
> > > >
> > > > The likely possible names are hclk_i (for AHB master), aclk_i (for
> > > > AXI master), or clk_csr_i.
> > > >
> > > > It does state that the CSR clock should have a minimum frequency of
> > > > 25MHz to allow all statistics to be properly collected.
> > > >
> > > > The rate of the CSR clock needs to be known, as selecting the divider
> > > > for generating MDC within IEEE 802.3 specifications is rather
> > > > fundamental. You may find something there which hints at what rate
> > > > the dwmac's CSR clock runs at.
> > >
> > > If it's either AXI or AHB, in both cases their direct parent is controlled
> > > by an entity external to Linux and their rates may change at runtime,
> > > based on aggregated needs of the bus. They're defined as levels/corners
> > > (abstract term for a hidden volt+freq combo).
> > >
> > > It may be that the operating range for the EMAC removes that variability,
> > > but with no concrete evidence and just anecdotal experience, that's only
> > > the case for the AHB clock
> >
> > The important thing is that the MDC doesn't exceed the max clock
> > frequency for the PHY and any other device connected to the MDIO
> > bus. IEEE 802.3 specifies a max frequency of 2.5MHz (minimum period
> > for MDC shall be 400 ns). Some PHYs can operate in excess of this,
> > but one would need to confirm that all devices on the MDIO bus
> > supports higher frequencies before using them. In the kernel, we
> > generally err on the side of caution and stick to IEEE 802.3.
> >
> > There are two ways to achieve the divider value with stmmac.
> >
> > 1. if priv->plat->csr_clk is set to a value other than -1, this
> > configures the hardware divisor (for "normal" cores, it takes
> > STMMAC_CSR_* constants that can be found in include/linux/stmmac.h)
> >
> > 2. otherwise, the rate of priv->plat->stmmac_clk is used as the CSR
> > clock value, which is the reference clock for the divider that
> > generates the MDC clock, and an appropriate divider is selected.
> > Given the available dividers, it works out at between 1.25MHz for
> > a CSR clock of just over 20MHz and 2.47MHz for 800MHz. (I have a
> > patch which documents the ranges for each of the STMMAC_CSR_xxx
> > values.)
> >
> > Note that the dividier constants are not the actual divider itself,
> > as can be seen in include/linux/stmmac.h
> >
>
> As noted by Konrad, the AXI and AHB clock rates are indeed unknown to
> the Linux kernel:
> [ 7.739389] [DBG] priv->plat->stmmac_clk rate = 0
> [ 7.739391] [DBG] priv->plat->pclk rate = 0
>
> Additionally, here's what I found (focusing on QCS9100 Ride R3, but
> most of this should be applicable to all qcom-ethqos consumers):
>
> 1. clk_csr_i is connected to the SLV_AHB clock, named "pclk" in the
> devicetree. This is the source for the MDC. The "stmmaceth" clock,
> provided by AXI, is used for data transfers. It appears that the
> devicetree gets it in reverse as per the stmmac clock
> documentation added by Russell, i.e., the right order would be:
The documentation wasn't generated with some special knowledge, but by
comparing the stmmac code with the databook and trying to work out what
is going on. I would suggest not changing the DT description at the
moment.
It seems to me that the original intention was for "stmmac_clk" to be
the "application clock", but then the Imagination Technologies
Pistachio board came along, and "pclk" was added for possibly the slave
interface - and thus pclk would really be more what CSR clock would be.
However, the code that derives the CSR clock divider wasn't changed,
and continued to use stmmac_clk.
So now we're stuck with an utter mess, and there is no way now to work
out exactly what was the case - I can find no documentation for this
Pistachio board let alone the SoC. Hence:
There is confusion around stmmac_clk and pclk which can't be easily
resolved today as the Imagination Technologies Pistachio board that
pclk was introduced for has no public documentation and is likely now
obsolete. So the origins of pclk are lost to the winds of time.
I haven't put much thought into whether this can be solved in some way.
One passing throught is to basically deprecate the existing clock names
and replace them with "application" and "csr-clock" which are the terms
used in the databook.
However, there's a couple of tables in the "Host (System Interface)
Clock" section in the databook which gives the clocking for the various
different configurations - the application clock is fairly easy to
understand, but the CSR clock is quite complex as it depends on the
master and slave interface configurations, as well as whether the
designer selected the "use different clock for CSR" option.
> 2. However, even with the correct naming, clk_get_rate() would return
> 0 for both clocks since they are firmware-managed.
>
> 3. For GCC_EMAC0_SLV_AHB_CLK, the hardware documentation mentions the
> range of 50 - 100 MHz. I am trying to check if there's any chance
> of it turboing to a higher rate. For now, I think we can assume
> this to be the working range.
>
> In view of this, would setting priv->plat->clk_csr to
> STMMAC_CSR_60_100M from the glue layer be correct?
For the patch which I haven't submitted yet where I worked out the
resulting ranges gives the following for this entry:
{ CSR_F_60M, STMMAC_CSR_60_100M }, // /42 1.43 - 2.38
So, the divider is 42, which gives a range up to 2.38MHz with the
100MHz input. At 50MHz, the MDIO clock will be 1.19MHz which is a
little slow but 802.3 doesn't give a minimum rate. It will just
take longer to access the PHY.
The important thing is that the MDIO clock isn't too fast, as that
will result in corrupted transfers. That said, some PHYs support
faster MDIO clocks than 802.3 specifies, but in general it is a
good idea that MACs stick to the 802.3 spec especially when they
don't know what PHY (or indeed other MDIO devices) will be
connected.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: watchdog: Convert TS-4800 to DT schema
From: Krzysztof Kozlowski @ 2026-03-24 9:16 UTC (permalink / raw)
To: Eduard Bostina
Cc: daniel.baluta, simona.toaca, d-gole, m-chawdhry, Wim Van Sebroeck,
Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Mark Brown, linux-watchdog, devicetree, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260323175948.302441-2-egbostina@gmail.com>
On Mon, Mar 23, 2026 at 07:59:44PM +0200, Eduard Bostina wrote:
> Convert the Technologic Systems TS-4800 watchdog timer bindings
> to DT schema.
>
> Signed-off-by: Eduard Bostina <egbostina@gmail.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 12/14] drm/rockchip: analogix: Convert to drm_output_color_format
From: Nicolas Frattaroli @ 2026-03-24 9:16 UTC (permalink / raw)
To: Jani Nikula, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Harry Wentland, Leo Li,
Rodrigo Siqueira, Alex Deucher, Christian König,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Andy Yan, Liviu Dudau,
Chun-Kuang Hu, Philipp Zabel, Matthias Brugger,
AngeloGioacchino Del Regno, Sandy Huang, Heiko Stübner,
Liu Ying, Chen-Yu Tsai, Samuel Holland, Dave Stevenson,
Maíra Canal, Raspberry Pi Kernel Maintenance, Maxime Ripard
Cc: dri-devel, linux-kernel, amd-gfx, linux-mediatek,
linux-arm-kernel, linux-rockchip, linux-sunxi, Jani Nikula
In-Reply-To: <20260305-drm-rework-color-formats-v3-12-f3935f6db579@kernel.org>
On Thursday, 5 March 2026 10:05:04 Central European Standard Time Maxime Ripard wrote:
> Now that we introduced a new drm_output_color_format enum to represent
> what DRM_COLOR_FORMAT_* bits were representing, we can switch to the new
> enum.
>
> The main difference is that while DRM_COLOR_FORMAT_ was a bitmask,
> drm_output_color_format is a proper enum. However, the enum was done is
> such a way than DRM_COLOR_FORMAT_X = BIT(DRM_OUTPUT_COLOR_FORMAT_X) so
> the transitition is easier.
>
> The only thing we need to consider is if the original code meant to use
> that value as a bitmask, in which case we do need to keep the bit shift,
> or as a discriminant in which case we don't.
>
> Acked-by: Jani Nikula <jani.nikula@intel.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index fdab71d51e2a71d644f128b1bf1c39429b4ad52a..96bd3dd239d251af3d5a7d0fbd4dd74942d44f2d 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -169,16 +169,16 @@ static int rockchip_dp_powerdown(struct analogix_dp_plat_data *plat_data)
> static int rockchip_dp_get_modes(struct analogix_dp_plat_data *plat_data,
> struct drm_connector *connector)
> {
> struct drm_display_info *di = &connector->display_info;
> /* VOP couldn't output YUV video format for eDP rightly */
> - u32 mask = DRM_COLOR_FORMAT_YCBCR444 | DRM_COLOR_FORMAT_YCBCR422;
> + u32 mask = BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR444) | BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422);
>
> if ((di->color_formats & mask)) {
> DRM_DEBUG_KMS("Swapping display color format from YUV to RGB\n");
> di->color_formats &= ~mask;
> - di->color_formats |= DRM_COLOR_FORMAT_RGB444;
> + di->color_formats |= BIT(DRM_OUTPUT_COLOR_FORMAT_RGB444);
> di->bpc = 8;
> }
>
> return 0;
> }
>
>
Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
I'm not the maintainer of this driver, but touched both the color
formats and rockchip code enough to confidently state that this
patch is trivially correct. I'm sure Heiko and Andy will agree. :)
Kind regards,
Nicolas Frattaroli
^ permalink raw reply
* Re: [PATCH v2 2/3] arm64: Kconfig: Add ARCH_HPE_GSC platform
From: Krzysztof Kozlowski @ 2026-03-24 9:18 UTC (permalink / raw)
To: nick.hawkins
Cc: Catalin Marinas, Will Deacon, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jean-Marie Verdun, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260323194223.683487-3-nick.hawkins@hpe.com>
On Mon, Mar 23, 2026 at 02:42:22PM -0500, nick.hawkins@hpe.com wrote:
> From: Nick Hawkins <nick.hawkins@hpe.com>
>
> Add the ARCH_HPE menuconfig group and ARCH_HPE_GSC config for the
> HPE GSC ARM64 BMC SoC.
>
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
> ---
> arch/arm64/Kconfig.platforms | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 54eb1d7fd419..4bbc27bb9b7b 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -168,6 +168,29 @@ config ARCH_HISI
> help
> This enables support for Hisilicon ARMv8 SoC family
>
> +
No need for multiple blank lines.
> +menuconfig ARCH_HPE
> + bool "HPE SoC Support"
> + help
> + This enables support for HPE ARM-based SoC chips used
> + on HPE servers. HPE SoCs serve as the Baseboard
> + Management Controller (BMC) providing out-of-band server
> + management.
> +
> +if ARCH_HPE
> +
> +config ARCH_HPE_GSC
Sorry, you don't get multiple ARCHs per vendor. Look at this file at
other entries to see how it should be created.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: hpe: Add HPE GSC SoC and DL340 Gen12 board DTS
From: Krzysztof Kozlowski @ 2026-03-24 9:20 UTC (permalink / raw)
To: nick.hawkins
Cc: Catalin Marinas, Will Deacon, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jean-Marie Verdun, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260323194223.683487-4-nick.hawkins@hpe.com>
On Mon, Mar 23, 2026 at 02:42:23PM -0500, nick.hawkins@hpe.com wrote:
> From: Nick Hawkins <nick.hawkins@hpe.com>
>
> Add SoC-level DTSI for the HPE GSC ARM64 BMC SoC, covering the CPU
> cluster, GIC v3 interrupt controller, ARM64 generic timer, and console
> UART.
>
> Add the board-level DTS for the HPE DL340 Gen12, which includes
> gsc.dtsi and adds memory and chosen nodes.
>
> Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
> ---
> arch/arm64/boot/dts/hpe/Makefile | 2 +
> arch/arm64/boot/dts/hpe/gsc-dl340gen12.dts | 18 ++++
> arch/arm64/boot/dts/hpe/gsc.dtsi | 106 +++++++++++++++++++++
> 3 files changed, 126 insertions(+)
> create mode 100644 arch/arm64/boot/dts/hpe/Makefile
> create mode 100644 arch/arm64/boot/dts/hpe/gsc-dl340gen12.dts
> create mode 100644 arch/arm64/boot/dts/hpe/gsc.dtsi
>
> diff --git a/arch/arm64/boot/dts/hpe/Makefile b/arch/arm64/boot/dts/hpe/Makefile
> new file mode 100644
> index 000000000000..804f7c54e9b6
> --- /dev/null
> +++ b/arch/arm64/boot/dts/hpe/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +dtb-$(CONFIG_ARCH_HPE_GSC) += gsc-dl340gen12.dtb
> diff --git a/arch/arm64/boot/dts/hpe/gsc-dl340gen12.dts b/arch/arm64/boot/dts/hpe/gsc-dl340gen12.dts
> new file mode 100644
> index 000000000000..42cfeac99029
> --- /dev/null
> +++ b/arch/arm64/boot/dts/hpe/gsc-dl340gen12.dts
> @@ -0,0 +1,18 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/dts-v1/;
> +
> +#include "gsc.dtsi"
> +
> +/ {
> + compatible = "hpe,gsc-dl340gen12", "hpe,gsc";
> + model = "HPE ProLiant DL340 Gen12";
> +
> + chosen {
> + stdout-path = &uartc;
> + };
> +
> + memory@0 {
> + device_type = "memory";
> + reg = <0x00000000 0x40000000>;
> + };
> +};
> diff --git a/arch/arm64/boot/dts/hpe/gsc.dtsi b/arch/arm64/boot/dts/hpe/gsc.dtsi
> new file mode 100644
> index 000000000000..3433c4a18512
> --- /dev/null
> +++ b/arch/arm64/boot/dts/hpe/gsc.dtsi
> @@ -0,0 +1,106 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Device Tree file for HPE GSC
> + */
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0 0xa0008048>;
> + };
> +
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <1>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0 0xa0008048>;
> + };
> + };
> +
> + clocks {
Drop node
> + osc: osc {
Please use name for all fixed clocks which matches current format
recommendation: 'clock-<freq>' (see also the pattern in the binding for
any other options).
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/clock/fixed-clock.yaml
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-output-names = "osc";
> + clock-frequency = <33333333>;
> + };
> + };
> +
> + timer {
Any particular reason not to follow DTS coding style for ordering nodes?
> + compatible = "arm,armv8-timer";
> + interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>,
> + <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-parent = <&gic>;
> + };
> +
> + ahb: ahb@80000000 {
Convention is rather soc@
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x80000000 0x80000000>;
> + ranges;
> +
> + gic: gic@ce000000 {
> + compatible = "arm,gic-v3";
> + #interrupt-cells = <3>;
> + #address-cells = <0>;
> + interrupt-controller;
> + redistributor-stride = <0x0 0x20000>;
> + #redistributor-regions = <1>;
> + reg = <0xce000000 0x10000>,
> + <0xce060000 0x40000>,
> + <0xce200000 0x40000>;
Same question - any reason to deviate from DTS coding style?
> + };
> +
> + uartc: serial@c00000f0 {
> + compatible = "ns16550a";
> + reg = <0xc00000f0 0x8>;
> + interrupts = <0 19 4>;
Use proper defines.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH net-next 0/5] net: stmmac: dwmac-socfpga: Cleanup .fix_mac_speed
From: Maxime Chevallier @ 2026-03-24 9:20 UTC (permalink / raw)
To: Andrew Lunn, Jakub Kicinski, davem, Eric Dumazet, Paolo Abeni,
Simon Horman, Maxime Coquelin, Alexandre Torgue, Russell King
Cc: Maxime Chevallier, thomas.petazzoni, Alexis Lothoré,
Rohan G Thomas, Mun Yew Tham, netdev, linux-kernel,
linux-arm-kernel, linux-stm32
Hi everyone,
This small series does a bit of cleanup in the dwmad-socfpga glue
driver, especially around the .fix_mac_speed() operation.
It's mostly about re-using existing helpers from the glue driver, as
well as reorganizing the code to make the local private structures a
little bit smaller.
No functionnal changes are intended, this was tested on cyclone V.
Maxime Chevallier (5):
net: stmmac: dwmac-socfpga: Move internal helpers
net: stmmac: dwmac-socfpga: Use the socfpga_sgmii_config() helper
net: stmmac: dwmac-socfpga: Use the correct type for interface modes
net: stmmac: dwmac-socfpga: get the phy_mode with the dedicated helper
net: stmmac: dwmac-sofcpga: Drop the struct device reference
.../ethernet/stmicro/stmmac/dwmac-socfpga.c | 58 +++++++++----------
1 file changed, 28 insertions(+), 30 deletions(-)
--
2.49.0
^ permalink raw reply
* [PATCH net-next 1/5] net: stmmac: dwmac-socfpga: Move internal helpers
From: Maxime Chevallier @ 2026-03-24 9:20 UTC (permalink / raw)
To: Andrew Lunn, Jakub Kicinski, davem, Eric Dumazet, Paolo Abeni,
Simon Horman, Maxime Coquelin, Alexandre Torgue, Russell King
Cc: Maxime Chevallier, thomas.petazzoni, Alexis Lothoré,
Rohan G Thomas, Mun Yew Tham, netdev, linux-kernel,
linux-arm-kernel, linux-stm32
In-Reply-To: <20260324092102.687082-1-maxime.chevallier@bootlin.com>
This is preparatory work to allow reusing the SGMII configuration helper
and the wrapper to get the interface in the fix_mac_speed() callback.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
.../ethernet/stmicro/stmmac/dwmac-socfpga.c | 24 +++++++++----------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index 5f89fd968ae9..42da73b92ceb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -72,6 +72,18 @@ struct socfpga_dwmac {
const struct socfpga_dwmac_ops *ops;
};
+static int socfpga_get_plat_phymode(struct socfpga_dwmac *dwmac)
+{
+ return dwmac->plat_dat->phy_interface;
+}
+
+static void socfpga_sgmii_config(struct socfpga_dwmac *dwmac, bool enable)
+{
+ u16 val = enable ? SGMII_ADAPTER_ENABLE : SGMII_ADAPTER_DISABLE;
+
+ writew(val, dwmac->sgmii_adapter_base + SGMII_ADAPTER_CTRL_REG);
+}
+
static void socfpga_dwmac_fix_mac_speed(void *bsp_priv,
phy_interface_t interface, int speed,
unsigned int mode)
@@ -244,18 +256,6 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac *dwmac, struct device *
return ret;
}
-static int socfpga_get_plat_phymode(struct socfpga_dwmac *dwmac)
-{
- return dwmac->plat_dat->phy_interface;
-}
-
-static void socfpga_sgmii_config(struct socfpga_dwmac *dwmac, bool enable)
-{
- u16 val = enable ? SGMII_ADAPTER_ENABLE : SGMII_ADAPTER_DISABLE;
-
- writew(val, dwmac->sgmii_adapter_base + SGMII_ADAPTER_CTRL_REG);
-}
-
static int socfpga_set_phy_mode_common(int phymode, u32 *val)
{
switch (phymode) {
--
2.49.0
^ permalink raw reply related
* [PATCH net-next 2/5] net: stmmac: dwmac-socfpga: Use the socfpga_sgmii_config() helper
From: Maxime Chevallier @ 2026-03-24 9:20 UTC (permalink / raw)
To: Andrew Lunn, Jakub Kicinski, davem, Eric Dumazet, Paolo Abeni,
Simon Horman, Maxime Coquelin, Alexandre Torgue, Russell King
Cc: Maxime Chevallier, thomas.petazzoni, Alexis Lothoré,
Rohan G Thomas, Mun Yew Tham, netdev, linux-kernel,
linux-arm-kernel, linux-stm32
In-Reply-To: <20260324092102.687082-1-maxime.chevallier@bootlin.com>
Use the existing socfpga_sgmii_config() helper in
socfpga_dwmac_fix_mac_speed(), instead of re-coding the register access.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index 42da73b92ceb..ed6448c0ad2a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -95,8 +95,7 @@ static void socfpga_dwmac_fix_mac_speed(void *bsp_priv,
u32 val;
if (sgmii_adapter_base)
- writew(SGMII_ADAPTER_DISABLE,
- sgmii_adapter_base + SGMII_ADAPTER_CTRL_REG);
+ socfpga_sgmii_config(dwmac, false);
if (splitter_base) {
val = readl(splitter_base + EMAC_SPLITTER_CTRL_REG);
@@ -121,8 +120,7 @@ static void socfpga_dwmac_fix_mac_speed(void *bsp_priv,
if ((priv->plat->phy_interface == PHY_INTERFACE_MODE_SGMII ||
priv->plat->phy_interface == PHY_INTERFACE_MODE_1000BASEX) &&
sgmii_adapter_base)
- writew(SGMII_ADAPTER_ENABLE,
- sgmii_adapter_base + SGMII_ADAPTER_CTRL_REG);
+ socfpga_sgmii_config(dwmac, true);
}
static int socfpga_dwmac_parse_data(struct socfpga_dwmac *dwmac, struct device *dev)
--
2.49.0
^ permalink raw reply related
* [PATCH net-next 3/5] net: stmmac: dwmac-socfpga: Use the correct type for interface modes
From: Maxime Chevallier @ 2026-03-24 9:20 UTC (permalink / raw)
To: Andrew Lunn, Jakub Kicinski, davem, Eric Dumazet, Paolo Abeni,
Simon Horman, Maxime Coquelin, Alexandre Torgue, Russell King
Cc: Maxime Chevallier, thomas.petazzoni, Alexis Lothoré,
Rohan G Thomas, Mun Yew Tham, netdev, linux-kernel,
linux-arm-kernel, linux-stm32
In-Reply-To: <20260324092102.687082-1-maxime.chevallier@bootlin.com>
The internal helper socfpga_get_plat_phymode() returns an int where we
actually return a PHY_INTERFACE_MODE_xxx, use the correct type for this.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index ed6448c0ad2a..629074dbbc15 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -72,7 +72,7 @@ struct socfpga_dwmac {
const struct socfpga_dwmac_ops *ops;
};
-static int socfpga_get_plat_phymode(struct socfpga_dwmac *dwmac)
+static phy_interface_t socfpga_get_plat_phymode(struct socfpga_dwmac *dwmac)
{
return dwmac->plat_dat->phy_interface;
}
@@ -386,7 +386,7 @@ static int smtg_crosststamp(ktime_t *device, struct system_counterval_t *system,
static int socfpga_gen5_set_phy_mode(struct socfpga_dwmac *dwmac)
{
struct regmap *sys_mgr_base_addr = dwmac->sys_mgr_base_addr;
- int phymode = socfpga_get_plat_phymode(dwmac);
+ phy_interface_t phymode = socfpga_get_plat_phymode(dwmac);
u32 reg_offset = dwmac->reg_offset;
u32 reg_shift = dwmac->reg_shift;
u32 ctrl, val, module;
@@ -444,7 +444,7 @@ static int socfpga_gen5_set_phy_mode(struct socfpga_dwmac *dwmac)
static int socfpga_gen10_set_phy_mode(struct socfpga_dwmac *dwmac)
{
struct regmap *sys_mgr_base_addr = dwmac->sys_mgr_base_addr;
- int phymode = socfpga_get_plat_phymode(dwmac);
+ phy_interface_t phymode = socfpga_get_plat_phymode(dwmac);
u32 reg_offset = dwmac->reg_offset;
u32 reg_shift = dwmac->reg_shift;
u32 ctrl, val, module;
--
2.49.0
^ permalink raw reply related
* [PATCH net-next 4/5] net: stmmac: dwmac-socfpga: get the phy_mode with the dedicated helper
From: Maxime Chevallier @ 2026-03-24 9:20 UTC (permalink / raw)
To: Andrew Lunn, Jakub Kicinski, davem, Eric Dumazet, Paolo Abeni,
Simon Horman, Maxime Coquelin, Alexandre Torgue, Russell King
Cc: Maxime Chevallier, thomas.petazzoni, Alexis Lothoré,
Rohan G Thomas, Mun Yew Tham, netdev, linux-kernel,
linux-arm-kernel, linux-stm32
In-Reply-To: <20260324092102.687082-1-maxime.chevallier@bootlin.com>
We enable/disable the sgmii_adapter in the .fix_mac_speed() ops based on
the phy_mode used in the plat_data. We currently get it with :
socfpga_dwmac
->dev
->drv_data
->netdev
->priv
->stmmac_priv
->plat
->phy_interface
where we can get it with :
socfpga_dwmac
->plat_data
->phy_interface (done by socfpga_get_plat_phymode)
Use that helper here.
Note that we are also being passed a phy_interface_t from the
.fix_mac_speed() callback, provided by phylink.
We can handle that in the future when dynamic interface selection is
supported. We'd need to guarantee that we have a Lynx PCS to handle it.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index 629074dbbc15..ae40de2ed8eb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -89,9 +89,9 @@ static void socfpga_dwmac_fix_mac_speed(void *bsp_priv,
unsigned int mode)
{
struct socfpga_dwmac *dwmac = (struct socfpga_dwmac *)bsp_priv;
- struct stmmac_priv *priv = netdev_priv(dev_get_drvdata(dwmac->dev));
- void __iomem *splitter_base = dwmac->splitter_base;
void __iomem *sgmii_adapter_base = dwmac->sgmii_adapter_base;
+ phy_interface_t phymode = socfpga_get_plat_phymode(dwmac);
+ void __iomem *splitter_base = dwmac->splitter_base;
u32 val;
if (sgmii_adapter_base)
@@ -117,9 +117,8 @@ static void socfpga_dwmac_fix_mac_speed(void *bsp_priv,
writel(val, splitter_base + EMAC_SPLITTER_CTRL_REG);
}
- if ((priv->plat->phy_interface == PHY_INTERFACE_MODE_SGMII ||
- priv->plat->phy_interface == PHY_INTERFACE_MODE_1000BASEX) &&
- sgmii_adapter_base)
+ if ((phymode == PHY_INTERFACE_MODE_SGMII ||
+ phymode == PHY_INTERFACE_MODE_1000BASEX) && sgmii_adapter_base)
socfpga_sgmii_config(dwmac, true);
}
--
2.49.0
^ permalink raw reply related
* [PATCH net-next 5/5] net: stmmac: dwmac-sofcpga: Drop the struct device reference
From: Maxime Chevallier @ 2026-03-24 9:21 UTC (permalink / raw)
To: Andrew Lunn, Jakub Kicinski, davem, Eric Dumazet, Paolo Abeni,
Simon Horman, Maxime Coquelin, Alexandre Torgue, Russell King
Cc: Maxime Chevallier, thomas.petazzoni, Alexis Lothoré,
Rohan G Thomas, Mun Yew Tham, netdev, linux-kernel,
linux-arm-kernel, linux-stm32
In-Reply-To: <20260324092102.687082-1-maxime.chevallier@bootlin.com>
We keep a reference to our the struct device in the socfpga_dwmac priv
structure, but now it's only ever used to produce logs in the
.set_phy_mode() ops, that are specific to this driver.
When we call that ops, we always have a ref to the struct device around,
so let's pass it to .set_phy_mode(). We can now discard that reference
from struct socfpga_dwmac.
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index ae40de2ed8eb..1d7f0a57d288 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -53,14 +53,14 @@
struct socfpga_dwmac;
struct socfpga_dwmac_ops {
- int (*set_phy_mode)(struct socfpga_dwmac *dwmac_priv);
+ int (*set_phy_mode)(struct socfpga_dwmac *dwmac_priv,
+ struct device *dev);
void (*setup_plat_dat)(struct socfpga_dwmac *dwmac_priv);
};
struct socfpga_dwmac {
u32 reg_offset;
u32 reg_shift;
- struct device *dev;
struct plat_stmmacenet_data *plat_dat;
struct regmap *sys_mgr_base_addr;
struct reset_control *stmmac_rst;
@@ -243,7 +243,6 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac *dwmac, struct device *
dwmac->reg_offset = reg_offset;
dwmac->reg_shift = reg_shift;
dwmac->sys_mgr_base_addr = sys_mgr_base_addr;
- dwmac->dev = dev;
of_node_put(np_sgmii_adapter);
return 0;
@@ -382,7 +381,8 @@ static int smtg_crosststamp(ktime_t *device, struct system_counterval_t *system,
return 0;
}
-static int socfpga_gen5_set_phy_mode(struct socfpga_dwmac *dwmac)
+static int socfpga_gen5_set_phy_mode(struct socfpga_dwmac *dwmac,
+ struct device *dev)
{
struct regmap *sys_mgr_base_addr = dwmac->sys_mgr_base_addr;
phy_interface_t phymode = socfpga_get_plat_phymode(dwmac);
@@ -391,7 +391,7 @@ static int socfpga_gen5_set_phy_mode(struct socfpga_dwmac *dwmac)
u32 ctrl, val, module;
if (socfpga_set_phy_mode_common(phymode, &val)) {
- dev_err(dwmac->dev, "bad phy mode %d\n", phymode);
+ dev_err(dev, "bad phy mode %d\n", phymode);
return -EINVAL;
}
@@ -440,7 +440,8 @@ static int socfpga_gen5_set_phy_mode(struct socfpga_dwmac *dwmac)
return 0;
}
-static int socfpga_gen10_set_phy_mode(struct socfpga_dwmac *dwmac)
+static int socfpga_gen10_set_phy_mode(struct socfpga_dwmac *dwmac,
+ struct device *dev)
{
struct regmap *sys_mgr_base_addr = dwmac->sys_mgr_base_addr;
phy_interface_t phymode = socfpga_get_plat_phymode(dwmac);
@@ -552,7 +553,7 @@ static int socfpga_dwmac_init(struct device *dev, void *bsp_priv)
{
struct socfpga_dwmac *dwmac = bsp_priv;
- return dwmac->ops->set_phy_mode(dwmac);
+ return dwmac->ops->set_phy_mode(dwmac, dev);
}
static void socfpga_gen5_setup_plat_dat(struct socfpga_dwmac *dwmac)
--
2.49.0
^ permalink raw reply related
* Re: [PATCH 2/2] ARM: dts: st: spear: fix dtbs warning on spear thermal sensor
From: Krzysztof Kozlowski @ 2026-03-24 9:26 UTC (permalink / raw)
To: Gopi Krishna Menon
Cc: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260323133814.14152-3-krishnagopi487@gmail.com>
On Mon, Mar 23, 2026 at 07:08:09PM +0530, Gopi Krishna Menon wrote:
> Running DTBS checks on st/spear1340-evb.dtb results in the following
> warning:
>
> thermal@e07008c4 (st,thermal-spear1340): Unevaluated properties are not allowed ('thermal_flags' was unexpected)
> from schema $id: http://devicetree.org/schemas/thermal/st,thermal-spear1340.yaml
How is it possible if there is no such file?
Did you just add new warning in patch #1 and then claim in patch #2 that
you fix it?
You completely miss the point why this change is needed: how could the
DTS work before? It could not. And that should be your justification for
the patch, with explanation why it could not work.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: st: spear: fix dtbs warning on spear thermal sensor
From: Krzysztof Kozlowski @ 2026-03-24 9:27 UTC (permalink / raw)
To: Gopi Krishna Menon
Cc: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260324-smoky-radical-hyrax-1274a9@quoll>
On 24/03/2026 10:26, Krzysztof Kozlowski wrote:
> On Mon, Mar 23, 2026 at 07:08:09PM +0530, Gopi Krishna Menon wrote:
>> Running DTBS checks on st/spear1340-evb.dtb results in the following
>> warning:
>>
>> thermal@e07008c4 (st,thermal-spear1340): Unevaluated properties are not allowed ('thermal_flags' was unexpected)
>> from schema $id: http://devicetree.org/schemas/thermal/st,thermal-spear1340.yaml
>
> How is it possible if there is no such file?
>
> Did you just add new warning in patch #1 and then claim in patch #2 that
> you fix it?
>
> You completely miss the point why this change is needed: how could the
> DTS work before? It could not. And that should be your justification for
> the patch, with explanation why it could not work.
... or you would notice that code was working and this part is just
redundant. Then fix would be completely different, though.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: thermal: st,thermal-spear1340: convert to dtschema
From: Krzysztof Kozlowski @ 2026-03-24 9:30 UTC (permalink / raw)
To: Gopi Krishna Menon
Cc: rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh, krzk+dt,
vireshk, conor+dt, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, soc, daniel.baluta, simona.toaca, d-gole,
m-chawdhry
In-Reply-To: <20260323133814.14152-2-krishnagopi487@gmail.com>
On Mon, Mar 23, 2026 at 07:08:08PM +0530, Gopi Krishna Menon wrote:
> +properties:
> + compatible:
> + const: st,thermal-spear1340
> +
> + reg:
> + maxItems: 1
> +
> + st,thermal-flags:
> + description: flags used to enable thermal sensor
> + $ref: /schemas/types.yaml#/definitions/uint32
> +
> +required:
> + - compatible
> + - reg
> + - st,thermal-flags
> +
> +unevaluatedProperties: false
additionalProperties: true
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 5/5] fpga: m10bmc-sec: switch show_canceled_csk() to using sysfs_emit()
From: Xu Yilun @ 2026-03-24 9:15 UTC (permalink / raw)
To: Yury Norov
Cc: linux-kernel, Christophe Leroy (CS GROUP), Peter Zijlstra (Intel),
Rafael J. Wysocki, Alexander Shishkin, Daniel Lezcano,
Ingo Molnar, James Clark, Kees Cook, Lukasz Luba,
Madhavan Srinivasan, Michael Ellerman, Mike Leach, Moritz Fischer,
Nicholas Piggin, Russ Weight, Shrikanth Hegde, Suki K Poulose,
Tom Rix, Thomas Weißschuh, Xu Yilun, Yury Norov, Zhang Rui,
coresight, linux-arm-kernel, linux-fpga, linux-pm, linuxppc-dev,
Jakub Kicinski
In-Reply-To: <20260303200842.124996-6-ynorov@nvidia.com>
On Tue, Mar 03, 2026 at 03:08:41PM -0500, Yury Norov wrote:
> Switch show_canceled_csk() to use the proper sysfs_emit("%*pbl").
>
> Reviewed-by: Russ Weight <russ.weight@linux.dev>
> Suggested-by: Thomas Weißschuh <linux@weissschuh.net>
> Signed-off-by: Yury Norov <ynorov@nvidia.com>
> ---
> drivers/fpga/intel-m10-bmc-sec-update.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/fpga/intel-m10-bmc-sec-update.c b/drivers/fpga/intel-m10-bmc-sec-update.c
> index 10f678b9ed36..ae364c6636eb 100644
> --- a/drivers/fpga/intel-m10-bmc-sec-update.c
> +++ b/drivers/fpga/intel-m10-bmc-sec-update.c
> @@ -10,6 +10,7 @@
> #include <linux/firmware.h>
> #include <linux/mfd/intel-m10-bmc.h>
> #include <linux/mod_devicetable.h>
> +#include <linux/mm.h>
Why add this header file?
Thanks,
Yilun
> #include <linux/module.h>
> #include <linux/platform_device.h>
> #include <linux/slab.h>
> @@ -183,7 +184,7 @@ show_canceled_csk(struct device *dev, u32 addr, char *buf)
>
> bitmap_from_arr32(csk_map, csk32, CSK_BIT_LEN);
> bitmap_complement(csk_map, csk_map, CSK_BIT_LEN);
> - return bitmap_print_to_pagebuf(1, buf, csk_map, CSK_BIT_LEN);
> + return sysfs_emit(buf, "%*pbl\n", CSK_BIT_LEN, csk_map);
> }
>
> #define DEVICE_ATTR_SEC_CSK_RO(_name) \
> --
> 2.43.0
>
>
^ permalink raw reply
* [PATCH v1 1/7] dt-bindings: arm: ti: Add verdin am62/am62p zinnia board
From: Francesco Dolcini @ 2026-03-24 9:36 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Francesco Dolcini, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260324093705.26730-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Add Toradex Verdin Zinnia carrier board mated with Verdin AM62 and AM62P.
Link: https://www.toradex.com/products/carrier-board/zinnia-carrier-board
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
Documentation/devicetree/bindings/arm/ti/k3.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml
index adda61e06173..2a6a9441c23d 100644
--- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
+++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
@@ -79,6 +79,7 @@ properties:
- toradex,verdin-am62-nonwifi-ivy # Verdin AM62 Module on Ivy
- toradex,verdin-am62-nonwifi-mallow # Verdin AM62 Module on Mallow
- toradex,verdin-am62-nonwifi-yavia # Verdin AM62 Module on Yavia
+ - toradex,verdin-am62-nonwifi-zinnia # Verdin AM62 Module on Zinnia
- const: toradex,verdin-am62-nonwifi # Verdin AM62 Module without Wi-Fi / BT
- const: toradex,verdin-am62 # Verdin AM62 Module
- const: ti,am625
@@ -91,6 +92,7 @@ properties:
- toradex,verdin-am62-wifi-ivy # Verdin AM62 Wi-Fi / BT Module on Ivy
- toradex,verdin-am62-wifi-mallow # Verdin AM62 Wi-Fi / BT Module on Mallow
- toradex,verdin-am62-wifi-yavia # Verdin AM62 Wi-Fi / BT Module on Yavia
+ - toradex,verdin-am62-wifi-zinnia # Verdin AM62 Wi-Fi / BT Module on Zinnia
- const: toradex,verdin-am62-wifi # Verdin AM62 Wi-Fi / BT Module
- const: toradex,verdin-am62 # Verdin AM62 Module
- const: ti,am625
@@ -103,6 +105,7 @@ properties:
- toradex,verdin-am62p-nonwifi-ivy # Verdin AM62P Module on Ivy
- toradex,verdin-am62p-nonwifi-mallow # Verdin AM62P Module on Mallow
- toradex,verdin-am62p-nonwifi-yavia # Verdin AM62P Module on Yavia
+ - toradex,verdin-am62p-nonwifi-zinnia # Verdin AM62P Module on Zinnia
- const: toradex,verdin-am62p-nonwifi # Verdin AM62P Module without Wi-Fi / BT
- const: toradex,verdin-am62p # Verdin AM62P Module
- const: ti,am62p5
@@ -115,6 +118,7 @@ properties:
- toradex,verdin-am62p-wifi-ivy # Verdin AM62P Wi-Fi / BT Module on Ivy
- toradex,verdin-am62p-wifi-mallow # Verdin AM62P Wi-Fi / BT Module on Mallow
- toradex,verdin-am62p-wifi-yavia # Verdin AM62P Wi-Fi / BT Module on Yavia
+ - toradex,verdin-am62p-wifi-zinnia # Verdin AM62P Wi-Fi / BT Module on Zinnia
- const: toradex,verdin-am62p-wifi # Verdin AM62P Wi-Fi / BT Module
- const: toradex,verdin-am62p # Verdin AM62P Module
- const: ti,am62p5
--
2.47.3
^ permalink raw reply related
* [PATCH v1 2/7] arm64: dts: ti: k3-am62-verdin: Fix SPI_1 GPIO CS pinctrl label
From: Francesco Dolcini @ 2026-03-24 9:36 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Francesco Dolcini, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260324093705.26730-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Fix SPI_1_CS GPIO pinmux label, this is spi1_cs, not qspi1_io4.
There are no user of this label yet, therefore this change does not
create any compatibility issue.
Fixes: fcb335934c51 ("arm64: dts: ti: verdin-am62: Improve spi1 chip-select pinctrl")
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi b/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
index 2a7242a2fef8..219b729d3caa 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
@@ -278,7 +278,7 @@ AM62X_IOPAD(0x0018, PIN_INPUT, 7) /* (F24) OSPI0_D3.GPIO0_6 */ /* SODIMM 62 */
};
/* Verdin SPI_1 CS as GPIO */
- pinctrl_qspi1_io4_gpio: main-gpio0-7-default-pins {
+ pinctrl_spi1_cs_gpio: main-gpio0-7-default-pins {
pinctrl-single,pins = <
AM62X_IOPAD(0x001c, PIN_INPUT, 7) /* (J23) OSPI0_D4.GPIO0_7 */ /* SODIMM 202 */
>;
--
2.47.3
^ permalink raw reply related
* [PATCH v1 5/7] arm64: dts: ti: k3-am62p-verdin: Split UART_2 pinctrl group
From: Francesco Dolcini @ 2026-03-24 9:37 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Francesco Dolcini, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260324093705.26730-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Some carrier board reuse the UART_2 control signals as GPIO, split
the pinctrl RTC/CTS in separated nodes to maximize flexibility.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi | 22 +++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi
index 34954df692a3..1c4c951e5e94 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi
@@ -767,15 +767,27 @@ AM62PX_MCU_IOPAD(0x0084, PIN_OUTPUT, 0) /* (F13) WKUP_CLKOUT0 */ /* SODIMM 91 */
>;
};
- /* Verdin UART_2 */
+ /* Verdin UART_2 RX/TX */
pinctrl_wkup_uart0: wkup-uart0-default-pins {
pinctrl-single,pins = <
- AM62PX_MCU_IOPAD(0x002c, PIN_INPUT, 0) /* (C7) WKUP_UART0_CTSn */ /* SODIMM 143 */
- AM62PX_MCU_IOPAD(0x0030, PIN_OUTPUT, 0) /* (C6) WKUP_UART0_RTSn */ /* SODIMM 141 */
AM62PX_MCU_IOPAD(0x0024, PIN_INPUT, 0) /* (D8) WKUP_UART0_RXD */ /* SODIMM 137 */
AM62PX_MCU_IOPAD(0x0028, PIN_OUTPUT, 0) /* (D7) WKUP_UART0_TXD */ /* SODIMM 139 */
>;
};
+
+ /* Verdin UART_2 CTS */
+ pinctrl_wkup_uart0_cts: wkup-uart0-cts-default-pins {
+ pinctrl-single,pins = <
+ AM62PX_MCU_IOPAD(0x002c, PIN_INPUT, 0) /* (C7) WKUP_UART0_CTSn */ /* SODIMM 143 */
+ >;
+ };
+
+ /* Verdin UART_2 RTS */
+ pinctrl_wkup_uart0_rts: wkup-uart0-rts-default-pins {
+ pinctrl-single,pins = <
+ AM62PX_MCU_IOPAD(0x0030, PIN_OUTPUT, 0) /* (C6) WKUP_UART0_RTSn */ /* SODIMM 141 */
+ >;
+ };
};
/* Verdin I2S_1_MCLK */
@@ -1410,7 +1422,9 @@ som_eeprom: eeprom@50 {
/* Verdin UART_2 */
&wkup_uart0 {
pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_wkup_uart0>;
+ pinctrl-0 = <&pinctrl_wkup_uart0>,
+ <&pinctrl_wkup_uart0_cts>,
+ <&pinctrl_wkup_uart0_rts>;
uart-has-rtscts;
status = "disabled";
};
--
2.47.3
^ permalink raw reply related
* [PATCH v1 3/7] arm64: dts: ti: k3-am62-verdin: Split UART_2 pinctrl group
From: Francesco Dolcini @ 2026-03-24 9:36 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Francesco Dolcini, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260324093705.26730-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Some carrier board reuse the UART_2 control signals as GPIO, split
the pinctrl RTC/CTS in separated nodes to maximize flexibility.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi b/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
index 219b729d3caa..735c43c67fc7 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
@@ -820,15 +820,27 @@ AM62X_MCU_IOPAD(0x0084, PIN_OUTPUT, 0) /* (A12) WKUP_CLKOUT0 */ /* SODIMM 91 */
>;
};
- /* Verdin UART_2 */
+ /* Verdin UART_2 RX/TX */
pinctrl_wkup_uart0: wkup-uart0-default-pins {
pinctrl-single,pins = <
- AM62X_MCU_IOPAD(0x002c, PIN_INPUT_PULLUP, 0) /* (C6) WKUP_UART0_CTSn */ /* SODIMM 143 */
- AM62X_MCU_IOPAD(0x0030, PIN_OUTPUT, 0) /* (A4) WKUP_UART0_RTSn */ /* SODIMM 141 */
AM62X_MCU_IOPAD(0x0024, PIN_INPUT_PULLUP, 0) /* (B4) WKUP_UART0_RXD */ /* SODIMM 137 */
AM62X_MCU_IOPAD(0x0028, PIN_OUTPUT, 0) /* (C5) WKUP_UART0_TXD */ /* SODIMM 139 */
>;
};
+
+ /* Verdin UART_2 CTS */
+ pinctrl_wkup_uart0_cts: wkup-uart0-cts-default-pins {
+ pinctrl-single,pins = <
+ AM62X_MCU_IOPAD(0x002c, PIN_INPUT_PULLUP, 0) /* (C6) WKUP_UART0_CTSn */ /* SODIMM 143 */
+ >;
+ };
+
+ /* Verdin UART_2 RTS */
+ pinctrl_wkup_uart0_rts: wkup-uart0-rts-default-pins {
+ pinctrl-single,pins = <
+ AM62X_MCU_IOPAD(0x0030, PIN_OUTPUT, 0) /* (A4) WKUP_UART0_RTSn */ /* SODIMM 141 */
+ >;
+ };
};
/* VERDIN I2S_1_MCLK */
@@ -1502,7 +1514,7 @@ &usb1 {
/* Verdin UART_2 */
&wkup_uart0 {
pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_wkup_uart0>;
+ pinctrl-0 = <&pinctrl_wkup_uart0>, <&pinctrl_wkup_uart0_cts>, <&pinctrl_wkup_uart0_rts>;
status = "disabled";
};
--
2.47.3
^ permalink raw reply related
* [PATCH v1 6/7] arm64: dts: ti: k3-am62p-verdin: Add SPI_1_CS as GPIO
From: Francesco Dolcini @ 2026-03-24 9:37 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Francesco Dolcini, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260324093705.26730-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Add a pinctrl to use SPI_1 CS as GPIO.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi
index 1c4c951e5e94..7ee894d59113 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi
@@ -247,6 +247,13 @@ AM62PX_IOPAD(0x0018, PIN_INPUT, 7) /* (M24) OSPI0_D3.GPIO0_6 */ /* SODIMM 62 */
>;
};
+ /* Verdin SPI_1_CS as GPIO */
+ pinctrl_spi1_cs_gpio: main-gpio0-7-default-pins {
+ pinctrl-single,pins = <
+ AM62PX_IOPAD(0x001c, PIN_OUTPUT, 7) /* (N21) OSPI0_D4.GPIO0_7 */ /* SODIMM 202 */
+ >;
+ };
+
/* Verdin QSPI_1_CS# as GPIO (conflict with Verdin QSPI_1 interface) */
pinctrl_qspi1_cs_gpio: main-gpio0-11-default-pins {
pinctrl-single,pins = <
--
2.47.3
^ permalink raw reply related
* [PATCH v1 4/7] arm64: dts: ti: k3-am62-verdin: Add Zinnia
From: Francesco Dolcini @ 2026-03-24 9:36 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Francesco Dolcini, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260324093705.26730-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Add Zinnia Carrier Board mated with Verdin AM62.
It features 1 x RS232, 1 x RS485, 1 x CAN, 3 x isolated digital I/O,
2 x 1GBit/s Ethernet, a mini PCIe slot with USB / SIM card connector
for a modem, USB and SD card interfaces.
Link: https://www.toradex.com/products/carrier-board/zinnia-carrier-board
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
arch/arm64/boot/dts/ti/Makefile | 2 +
.../boot/dts/ti/k3-am62-verdin-zinnia.dtsi | 493 ++++++++++++++++++
.../dts/ti/k3-am625-verdin-nonwifi-zinnia.dts | 22 +
.../dts/ti/k3-am625-verdin-wifi-zinnia.dts | 22 +
4 files changed, 539 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am62-verdin-zinnia.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-nonwifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-zinnia.dts
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 260e211ca277..08f325451038 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -19,11 +19,13 @@ dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-dev.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-ivy.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-mallow.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-yavia.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-nonwifi-zinnia.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-dahlia.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-dev.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-ivy.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-mallow.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-yavia.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-zinnia.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am62x-phyboard-lyra-gpio-fan.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am62-lp-sk.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am62-lp-sk-nand.dtbo
diff --git a/arch/arm64/boot/dts/ti/k3-am62-verdin-zinnia.dtsi b/arch/arm64/boot/dts/ti/k3-am62-verdin-zinnia.dtsi
new file mode 100644
index 000000000000..0ce8357797ed
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am62-verdin-zinnia.dtsi
@@ -0,0 +1,493 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * Common dtsi for Verdin AM62 SoM on Zinnia carrier board
+ *
+ * https://www.toradex.com/computer-on-modules/verdin-arm-family/ti-am62
+ * https://www.toradex.com/products/carrier-board/zinnia-carrier-board
+ */
+
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/net/ti-dp83867.h>
+
+/ {
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_zinnia_leds>;
+
+ /* LED1 Red - SODIMM 48 - LED1_R */
+ led-0 {
+ color = <LED_COLOR_ID_RED>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <1>;
+ gpios = <&main_gpio0 33 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED1 Blue - SODIMM 46 - LED1_B */
+ led-1 {
+ color = <LED_COLOR_ID_BLUE>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <1>;
+ gpios = <&main_gpio0 34 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED3 Red - SODIMM 44 - LED3_R */
+ led-2 {
+ color = <LED_COLOR_ID_RED>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <3>;
+ gpios = <&main_gpio0 37 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED3 Green - SODIMM 54 - LED3_G */
+ led-3 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <3>;
+ gpios = <&main_gpio0 11 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED3 Blue - SODIMM 36 - LED3_B */
+ led-4 {
+ color = <LED_COLOR_ID_BLUE>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <3>;
+ gpios = <&main_gpio1 9 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED4 Red - SODIMM 34 - LED4_R */
+ led-5 {
+ color = <LED_COLOR_ID_RED>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <4>;
+ gpios = <&main_gpio1 10 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED4 Green - SODIMM 32 - LED4_G */
+ led-6 {
+ color = <LED_COLOR_ID_GREEN>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <4>;
+ gpios = <&main_gpio1 12 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* LED4 Blue - SODIMM 30 - LED4_B */
+ led-7 {
+ color = <LED_COLOR_ID_BLUE>;
+ default-state = "off";
+ function = LED_FUNCTION_STATUS;
+ function-enumerator = <4>;
+ gpios = <&main_gpio1 11 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ zinnia-1v8-voltage {
+ compatible = "voltage-divider";
+ /* Verdin ADC_4 */
+ io-channels = <&verdin_som_adc 4>;
+ full-ohms = <39000>; /* 12K + 27K */
+ output-ohms = <27000>;
+ };
+
+ zinnia-3v3-voltage {
+ compatible = "voltage-divider";
+ /* Verdin ADC_3 */
+ io-channels = <&verdin_som_adc 5>;
+ full-ohms = <54000>; /* 27K + 27K */
+ output-ohms = <27000>;
+ };
+
+ zinnia-5v-voltage {
+ compatible = "voltage-divider";
+ /* Verdin ADC_2 */
+ io-channels = <&verdin_som_adc 6>;
+ full-ohms = <39000>; /* 27K + 12K */
+ output-ohms = <12000>;
+ };
+
+ /* Zinnia Power Supply Input Voltage */
+ zinnia-input-voltage {
+ compatible = "voltage-divider";
+ /* Verdin ADC_1 */
+ io-channels = <&verdin_som_adc 7>;
+ full-ohms = <204700>; /* 200K + 4.7K */
+ output-ohms = <4700>;
+ };
+};
+
+&main_pmx0 {
+ pinctrl_zinnia_leds: zinnia-leds-default-pins {
+ pinctrl-single,pins = <
+ AM62X_IOPAD(0x019c, PIN_INPUT, 7) /* (B18) MCASP0_AXR1.GPIO1_9 */ /* SODIMM 36 */
+ AM62X_IOPAD(0x01a0, PIN_INPUT, 7) /* (B20) MCASP0_AXR0.GPIO1_10 */ /* SODIMM 34 */
+ AM62X_IOPAD(0x01a4, PIN_INPUT, 7) /* (A19) MCASP0_ACLKX.GPIO1_11 */ /* SODIMM 30 */
+ AM62X_IOPAD(0x01a8, PIN_INPUT, 7) /* (A20) MCASP0_AFSX.GPIO1_12 */ /* SODIMM 32 */
+ AM62X_IOPAD(0x0088, PIN_INPUT, 7) /* (L17) GPMC0_OEn_REn.GPIO0_33 */ /* SODIMM 48 */
+ AM62X_IOPAD(0x0098, PIN_INPUT, 7) /* (R18) GPMC0_WAIT0.GPIO0_37 */ /* SODIMM 44 */
+ AM62X_IOPAD(0x008c, PIN_INPUT, 7) /* (L25) GPMC0_WEn.GPIO0_34 */ /* SODIMM 46 */
+ AM62X_IOPAD(0x002c, PIN_INPUT, 7) /* (F23) OSPI0_CSn0.GPIO0_11 */ /* SODIMM 54 */
+ >;
+ };
+};
+
+&mcu_pmx0 {
+ pinctrl_zinnia_spi1_cs0_gpio: mcu-gpio0-11-default-pins {
+ pinctrl-single,pins = <
+ AM62X_MCU_IOPAD(0x002c, PIN_INPUT, 7) /* (C6) WKUP_UART0_CTSn.GPIO0_11 */ /* SODIMM 143 */
+ >;
+ };
+};
+
+/* Verdin ETH */
+&cpsw3g {
+ status = "okay";
+};
+
+/* MDIO, shared by Verdin ETH_1 (On-module PHY) and Verdin ETH_2_RGMII */
+&cpsw3g_mdio {
+ status = "okay";
+
+ cpsw3g_phy1: ethernet-phy@2 {
+ reg = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_eth2_rgmii_int>;
+ interrupt-parent = <&main_gpio0>;
+ interrupts = <38 IRQ_TYPE_EDGE_FALLING>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
+ };
+};
+
+/* Verdin ETH_1 */
+&cpsw_port1 {
+ status = "okay";
+};
+
+/* Verdin ETH_2_RGMII */
+&cpsw_port2 {
+ phy-handle = <&cpsw3g_phy1>;
+ phy-mode = "rgmii-id";
+
+ status = "okay";
+};
+
+&main_gpio0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ctrl_sleep_moci>,
+ <&pinctrl_gpio_5>,
+ <&pinctrl_gpio_6>,
+ <&pinctrl_gpio_7>,
+ <&pinctrl_gpio_8>,
+ <&pinctrl_qspi1_io0_gpio>;
+ gpio-line-names =
+ "", /* 0 */
+ "",
+ "",
+ "DI3_RB", /* SODIMM 56 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 20 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 30 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "DI2_EN", /* SODIMM 218 */
+ "",
+ "",
+ "",
+ "DI2_RB", /* SODIMM 216 */ /* 40 */
+ "DO3_EN", /* SODIMM 220 */
+ "DI3_EN", /* SODIMM 222 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 50 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 60 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 70 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 80 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "";
+};
+
+&main_gpio1 {
+ gpio-line-names =
+ "", /* 0 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 10 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 20 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 30 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 40 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 50 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 60 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 70 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "", /* 80 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "";
+};
+
+/* Verdin I2C_1 */
+&main_i2c1 {
+ status = "okay";
+
+ temperature-sensor@4f {
+ compatible = "ti,tmp1075";
+ reg = <0x4f>;
+ };
+
+ eeprom@57 {
+ compatible = "st,24c02", "atmel,24c02";
+ reg = <0x57>;
+ pagesize = <16>;
+ };
+};
+
+/* Verdin CAN_1 */
+&main_mcan0 {
+ status = "okay";
+};
+
+/* Verdin SPI_1 */
+&main_spi1 {
+ pinctrl-0 = <&pinctrl_spi1>,
+ <&pinctrl_zinnia_spi1_cs0_gpio>,
+ <&pinctrl_spi1_cs_gpio>;
+ cs-gpios = <&mcu_gpio0 11 GPIO_ACTIVE_LOW>,
+ <&main_gpio0 7 GPIO_ACTIVE_LOW>;
+
+ status = "okay";
+
+ tpm@1 {
+ compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
+ reg = <1>;
+ spi-max-frequency = <18500000>;
+ };
+};
+
+/* Verdin UART_3 */
+&main_uart0 {
+ status = "okay";
+};
+
+/* Verdin UART_1 */
+&main_uart1 {
+ status = "okay";
+};
+
+&mcu_gpio0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_1>,
+ <&pinctrl_gpio_2>,
+ <&pinctrl_gpio_3>,
+ <&pinctrl_gpio_4>,
+ <&pinctrl_pcie_1_reset>;
+ gpio-line-names =
+ "",
+ "DO1_EN", /* SODIMM 206 */
+ "DI1_EN", /* SODIMM 208 */
+ "DI1_RB", /* SODIMM 210 */
+ "DO2_EN", /* SODIMM 212 */
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "",
+ "";
+};
+
+/* Verdin SD_1 */
+&sdhci1 {
+ status = "okay";
+};
+
+/* Verdin USB_1 */
+&usb0 {
+ status = "okay";
+};
+
+/* Verdin USB_2 */
+&usb1 {
+ status = "okay";
+};
+
+/* Verdin USB_1 */
+&usbss0 {
+ status = "okay";
+};
+
+/* Verdin USB_2 */
+&usbss1 {
+ status = "okay";
+};
+
+/* Verdin PCIE_1_RESET# */
+&verdin_pcie_1_reset_hog {
+ status = "okay";
+};
+
+/* Verdin UART_2 */
+&wkup_uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wkup_uart0>, <&pinctrl_wkup_uart0_rts>;
+ rs485-rts-active-low;
+ rs485-rx-during-tx;
+ linux,rs485-enabled-at-boot-time;
+
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am625-verdin-nonwifi-zinnia.dts b/arch/arm64/boot/dts/ti/k3-am625-verdin-nonwifi-zinnia.dts
new file mode 100644
index 000000000000..eba8d7a5b1bf
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am625-verdin-nonwifi-zinnia.dts
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/verdin-arm-family/ti-am62
+ * https://www.toradex.com/products/carrier-board/zinnia-carrier-board
+ */
+
+/dts-v1/;
+
+#include "k3-am625.dtsi"
+#include "k3-am62-verdin.dtsi"
+#include "k3-am62-verdin-nonwifi.dtsi"
+#include "k3-am62-verdin-zinnia.dtsi"
+
+/ {
+ model = "Toradex Verdin AM62 on Zinnia Board";
+ compatible = "toradex,verdin-am62-nonwifi-zinnia",
+ "toradex,verdin-am62-nonwifi",
+ "toradex,verdin-am62",
+ "ti,am625";
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-zinnia.dts b/arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-zinnia.dts
new file mode 100644
index 000000000000..6f3f8eb42ed6
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-zinnia.dts
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright (c) Toradex
+ *
+ * https://www.toradex.com/computer-on-modules/verdin-arm-family/ti-am62
+ * https://www.toradex.com/products/carrier-board/zinnia-carrier-board
+ */
+
+/dts-v1/;
+
+#include "k3-am625.dtsi"
+#include "k3-am62-verdin.dtsi"
+#include "k3-am62-verdin-wifi.dtsi"
+#include "k3-am62-verdin-zinnia.dtsi"
+
+/ {
+ model = "Toradex Verdin AM62 WB on Zinnia Board";
+ compatible = "toradex,verdin-am62-wifi-zinnia",
+ "toradex,verdin-am62-wifi",
+ "toradex,verdin-am62",
+ "ti,am625";
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v1 0/7] arm64: dts: ti: verdin-am62[p]: Add Zinnia
From: Francesco Dolcini @ 2026-03-24 9:36 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Francesco Dolcini, linux-arm-kernel, devicetree, linux-kernel
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Add Zinnia Carrier Board mated with Verdin AM62 and Verdin AM62P.
It features 1 x RS232, 1 x RS485, 1 x CAN, 3 x isolated digital I/O,
2 x 1GBit/s Ethernet, a mini PCIe slot with USB / SIM card connector
for a modem, USB and SD card interfaces.
Some small fixes and cleanup are done on the SOM dtsi file, in preparation
for the Zinnia addition.
Link: https://www.toradex.com/products/carrier-board/zinnia-carrier-board
Francesco Dolcini (7):
dt-bindings: arm: ti: Add verdin am62/am62p zinnia board
arm64: dts: ti: k3-am62-verdin: Fix SPI_1 GPIO CS pinctrl label
arm64: dts: ti: k3-am62-verdin: Split UART_2 pinctrl group
arm64: dts: ti: k3-am62-verdin: Add Zinnia
arm64: dts: ti: k3-am62p-verdin: Split UART_2 pinctrl group
arm64: dts: ti: k3-am62p-verdin: Add SPI_1_CS as GPIO
arm64: dts: ti: k3-am62p-verdin: Add Zinnia
.../devicetree/bindings/arm/ti/k3.yaml | 4 +
arch/arm64/boot/dts/ti/Makefile | 2 +
.../boot/dts/ti/k3-am62-verdin-zinnia.dtsi | 493 ++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi | 22 +-
.../dts/ti/k3-am625-verdin-nonwifi-zinnia.dts | 22 +
.../dts/ti/k3-am625-verdin-wifi-zinnia.dts | 22 +
.../boot/dts/ti/k3-am62p-verdin-zinnia.dtsi | 469 +++++++++++++++++
arch/arm64/boot/dts/ti/k3-am62p-verdin.dtsi | 29 +-
.../ti/k3-am62p5-verdin-nonwifi-zinnia.dts | 22 +
.../dts/ti/k3-am62p5-verdin-wifi-zinnia.dts | 22 +
10 files changed, 1098 insertions(+), 9 deletions(-)
create mode 100644 arch/arm64/boot/dts/ti/k3-am62-verdin-zinnia.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-nonwifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am625-verdin-wifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am62p-verdin-zinnia.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am62p5-verdin-nonwifi-zinnia.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am62p5-verdin-wifi-zinnia.dts
--
2.47.3
^ 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