* [PATCH 1/5] drm/bridge: allow hpd_notify() to suppress connector hotplug events
From: Yongxing Mou @ 2026-06-29 14:48 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Rob Clark,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Sean Paul,
Marijn Suijten, Tomi Valkeinen, Bjorn Andersson, Konrad Dybcio
Cc: dri-devel, linux-kernel, linux-amlogic, linux-arm-kernel,
linux-arm-msm, freedreno, Yongxing Mou
In-Reply-To: <20260629-msm-dp-msttypec-v1-0-646a10256233@oss.qualcomm.com>
The bridge connector framework currently invokes all bridge
hpd_notify() callbacks and unconditionally emits a connector hotplug
event afterwards.
However, not every HPD notification requires a userspace hotplug event.
In particular, DP MST bridges may use hpd_notify() to propagate HPD and
IRQ notifications through the bridge chain while the actual hotplug
handling is performed by the DRM DP MST core. Connector creation,
removal and userspace hotplug events are already managed by the MST
topology framework.
Allow hpd_notify() implementations to suppress the bridge connector
hotplug event by introducing a bool *send_hotplug parameter. Drivers
can clear this flag when HPD processing should not result in a
connector hotplug notification.
A NULL pointer indicates that hotplug suppression is not supported by
the caller, such as the connector detect polling path.
Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
---
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 3 ++-
drivers/gpu/drm/display/drm_bridge_connector.c | 15 +++++++++------
drivers/gpu/drm/meson/meson_encoder_hdmi.c | 3 ++-
drivers/gpu/drm/msm/dp/dp_display.c | 3 ++-
drivers/gpu/drm/msm/dp/dp_drm.h | 3 ++-
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 3 ++-
include/drm/drm_bridge.h | 3 ++-
7 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
index 8cb17bd0e238..42e1cadcd3fb 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
@@ -430,7 +430,8 @@ static const struct drm_edid *lt9611uxc_bridge_edid_read(struct drm_bridge *brid
static void lt9611uxc_bridge_hpd_notify(struct drm_bridge *bridge,
struct drm_connector *connector,
enum drm_connector_status status,
- enum drm_connector_status_extra extra_status)
+ enum drm_connector_status_extra extra_status,
+ bool *send_hotplug)
{
const struct drm_edid *drm_edid;
diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c b/drivers/gpu/drm/display/drm_bridge_connector.c
index 8f7075fd2aa5..5edca47a025f 100644
--- a/drivers/gpu/drm/display/drm_bridge_connector.c
+++ b/drivers/gpu/drm/display/drm_bridge_connector.c
@@ -142,7 +142,8 @@ struct drm_bridge_connector {
static void drm_bridge_connector_hpd_notify(struct drm_connector *connector,
enum drm_connector_status status,
- enum drm_connector_status_extra extra_status)
+ enum drm_connector_status_extra extra_status,
+ bool *send_hotplug)
{
struct drm_bridge_connector *bridge_connector =
to_drm_bridge_connector(connector);
@@ -150,13 +151,14 @@ static void drm_bridge_connector_hpd_notify(struct drm_connector *connector,
/* Notify all bridges in the pipeline of hotplug events. */
drm_for_each_bridge_in_chain_scoped(bridge_connector->encoder, bridge) {
if (bridge->funcs->hpd_notify)
- bridge->funcs->hpd_notify(bridge, connector, status, extra_status);
+ bridge->funcs->hpd_notify(bridge, connector, status,
+ extra_status, send_hotplug);
}
}
static void drm_bridge_connector_handle_hpd(struct drm_bridge_connector *drm_bridge_connector,
- enum drm_connector_status status,
- enum drm_connector_status_extra extra_status)
+ enum drm_connector_status status,
+ enum drm_connector_status_extra extra_status)
{
struct drm_connector *connector = &drm_bridge_connector->base;
struct drm_device *dev = connector->dev;
@@ -165,7 +167,7 @@ static void drm_bridge_connector_handle_hpd(struct drm_bridge_connector *drm_bri
connector->status = status;
mutex_unlock(&dev->mode_config.mutex);
- drm_bridge_connector_hpd_notify(connector, status, extra_status);
+ drm_bridge_connector_hpd_notify(connector, status, extra_status, NULL);
drm_kms_helper_connector_hotplug_event(connector);
}
@@ -227,7 +229,8 @@ drm_bridge_connector_detect(struct drm_connector *connector, bool force)
if (hdmi)
drm_atomic_helper_connector_hdmi_hotplug(connector, status);
- drm_bridge_connector_hpd_notify(connector, status, DRM_CONNECTOR_NO_EXTRA_STATUS);
+ drm_bridge_connector_hpd_notify(connector, status,
+ DRM_CONNECTOR_NO_EXTRA_STATUS, NULL);
} else {
switch (connector->connector_type) {
case DRM_MODE_CONNECTOR_DPI:
diff --git a/drivers/gpu/drm/meson/meson_encoder_hdmi.c b/drivers/gpu/drm/meson/meson_encoder_hdmi.c
index 4aecf0ffcf75..a67e7b365c5b 100644
--- a/drivers/gpu/drm/meson/meson_encoder_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_encoder_hdmi.c
@@ -324,7 +324,8 @@ static int meson_encoder_hdmi_atomic_check(struct drm_bridge *bridge,
static void meson_encoder_hdmi_hpd_notify(struct drm_bridge *bridge,
struct drm_connector *connector,
enum drm_connector_status status,
- enum drm_connector_status_extra extra_status)
+ enum drm_connector_status_extra extra_status,
+ bool *send_hotplug)
{
struct meson_encoder_hdmi *encoder_hdmi = bridge_to_meson_encoder_hdmi(bridge);
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
index fcfee26f0078..6835c68fe510 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1763,7 +1763,8 @@ void msm_dp_bridge_hpd_disable(struct drm_bridge *bridge)
void msm_dp_bridge_hpd_notify(struct drm_bridge *bridge,
struct drm_connector *connector,
enum drm_connector_status status,
- enum drm_connector_status_extra extra_status)
+ enum drm_connector_status_extra extra_status,
+ bool *send_hotplug)
{
struct msm_dp_bridge *msm_dp_bridge = to_dp_bridge(bridge);
struct msm_dp *msm_dp_display = msm_dp_bridge->msm_dp_display;
diff --git a/drivers/gpu/drm/msm/dp/dp_drm.h b/drivers/gpu/drm/msm/dp/dp_drm.h
index f6b96c27408a..07ddcd055962 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.h
+++ b/drivers/gpu/drm/msm/dp/dp_drm.h
@@ -32,6 +32,7 @@ void msm_dp_bridge_hpd_disable(struct drm_bridge *bridge);
void msm_dp_bridge_hpd_notify(struct drm_bridge *bridge,
struct drm_connector *connector,
enum drm_connector_status status,
- enum drm_connector_status_extra extra_status);
+ enum drm_connector_status_extra extra_status,
+ bool *send_hotplug);
#endif /* _DP_DRM_H_ */
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index d02d432abde4..ad659cef16f5 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -430,7 +430,8 @@ static void hdmi4_bridge_disable(struct drm_bridge *bridge,
static void hdmi4_bridge_hpd_notify(struct drm_bridge *bridge,
struct drm_connector *connector,
enum drm_connector_status status,
- enum drm_connector_status_extra extra_status)
+ enum drm_connector_status_extra extra_status,
+ bool *send_hotplug)
{
struct omap_hdmi *hdmi = drm_bridge_to_hdmi(bridge);
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 9c4c88024cc5..e6de665ce8f6 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -616,7 +616,8 @@ struct drm_bridge_funcs {
void (*hpd_notify)(struct drm_bridge *bridge,
struct drm_connector *connector,
enum drm_connector_status status,
- enum drm_connector_status_extra extra_status);
+ enum drm_connector_status_extra extra_status,
+ bool *send_hotplug);
/**
* @hpd_enable:
--
2.43.0
^ permalink raw reply related
* [PATCH 0/5] drm/msm/dp: Add MSM Type-C MST support
From: Yongxing Mou @ 2026-06-29 14:48 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Rob Clark,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Sean Paul,
Marijn Suijten, Tomi Valkeinen, Bjorn Andersson, Konrad Dybcio
Cc: dri-devel, linux-kernel, linux-amlogic, linux-arm-kernel,
linux-arm-msm, freedreno, Yongxing Mou
The bridge connector framework currently treats every HPD notification
as a connector state update and emits a userspace hotplug event.
Once MST is enabled, however, connector creation, removal and hotplug
handling are already managed by the DRM DP MST topology manager.
As a result:
- the SST connector may transiently transition between connected and
disconnected during MST initialization
- MST IRQ notifications may generate duplicate userspace hotplug
events, once from the bridge connector layer and once from the MST
topology manager
Introduce explicit support for IRQ-only HPD notifications in the bridge
connector framework and allow bridge drivers to suppress connector
hotplug events when those events are already handled elsewhere.
MSM DP uses these mechanisms to integrate Type-C MST hubs without
generating duplicate or spurious userspace hotplug notifications.
Testing
-------
Tested on Hamoa-EVK with a Type-C MST hub and dual-monitor setup.
Both fbcon and Weston were exercised. No duplicate hotplug events,
connector state oscillation or display flickering were observed after
hub attachment.
Dependencies
------------
This patch series was made on top of:
[1] drm: handle IRQ_HPD events correctly (v4)
https://lore.kernel.org/r/20260608-hpd-irq-events-v4-0-30b62b335487@oss.qualcomm.com
[2] drm/msm/dp: Add MST support for MSM chipsets (v5)
https://patchwork.freedesktop.org/series/142207/#rev5
[3] drm/msm/dp: Prerequisite cleanup for upcoming MST support (v7)
https://lore.kernel.org/r/20260609-dp_mstclean-v7-0-ea04113e8233@oss.qualcomm.com
Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
---
Yongxing Mou (5):
drm/bridge: allow hpd_notify() to suppress connector hotplug events
drm/bridge_connector: preserve connector status for IRQ-only HPD events
drm/msm/dp: suppress bridge hotplug events during MST operation
drm/msm/dp: report IRQ_HPD as an IRQ-only notification
drm/msm/dp: mark the SST connector disconnected when MST is enabled
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 3 +-
drivers/gpu/drm/display/drm_bridge_connector.c | 31 ++++++++++++++++-----
drivers/gpu/drm/meson/meson_encoder_hdmi.c | 3 +-
drivers/gpu/drm/msm/dp/dp_display.c | 38 +++++++++++++++-----------
drivers/gpu/drm/msm/dp/dp_drm.h | 3 +-
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 3 +-
drivers/soc/qcom/pmic_glink_altmode.c | 14 ++++++----
include/drm/drm_bridge.h | 3 +-
8 files changed, 65 insertions(+), 33 deletions(-)
---
base-commit: e7d700e14934e68f86338c5610cf2ae76798b663
change-id: 20260629-msm-dp-msttypec-b420df7da587
prerequisite-message-id: <20260608-hpd-irq-events-v4-0-30b62b335487@oss.qualcomm.com>
prerequisite-patch-id: adc6d802a2f71d23c077a5cdb9a257809e9db50e
prerequisite-patch-id: bbd956a3b65a90c1fe9e884bc32c49bd83fd3129
prerequisite-patch-id: 014460a25c380d089764ab4e1a58577ebc1b9e71
prerequisite-patch-id: fc03fb9435b8c60321f9ae28e396a6bff2f347ae
prerequisite-patch-id: cd4cd57a72c798fc95afdfdeb9b81cc7a2dbd25d
prerequisite-patch-id: fe431fb614383eb6444f6bfb928e7e40c2de951e
prerequisite-patch-id: 2a058aa8309016f424b1d4ca19a9b20e92f4d8b6
prerequisite-patch-id: 64c3616bb979b663a01342d1f217588b347ae8bb
prerequisite-change-id: 20260410-msm-dp-mst-35130b6e8b84:v5
prerequisite-patch-id: 1d440cb9fed2bdd66d8de0e1e20475f0fe166973
prerequisite-patch-id: be0f4b80697df7224c80362b161b8a9f0a542184
prerequisite-patch-id: eefa6e6353df301420feae1da704a9db2c2155f2
prerequisite-patch-id: 9e9095f82dd6c131c9f3c1de4fdb8a62bd65ca24
prerequisite-patch-id: 3e635f008f9b56823101abd9253905f078fcb3b5
prerequisite-patch-id: e39e0dc124ed043c7a419610ebe03ad105da27db
prerequisite-patch-id: 945af39213cd4241e1a5929fada04a9286aeb5db
prerequisite-patch-id: 898ae7e4582a6b31492c223e7dd167fb9ce78096
prerequisite-patch-id: 3887553893357c1ffbda99eb010801bc2166cbad
prerequisite-patch-id: 7ccd961fa3c6f925659dee7d7a5bd167c8e7331b
prerequisite-patch-id: be2bf918e0e87ec2ea999927f36bd172c498748e
prerequisite-patch-id: 6aacdabb2dd0536dc04da04f8419ae39e35f8b19
prerequisite-patch-id: a9f27eff8f643ff445810b17d670891928f5b416
prerequisite-patch-id: efd300a2b52715153b8c1c7407db696eb331594b
prerequisite-patch-id: 950abefc4862050ef606404977fd27c5dd2cbb2b
prerequisite-patch-id: c6a9aaba753b5538864f7f6e065d910833baec21
prerequisite-patch-id: c73c1f6eb16b2a6ff11b20495fa0981683bdaaee
prerequisite-patch-id: 94957394b3870ec63ab766d682df592da978dd19
prerequisite-patch-id: f27cba0cf5f08d21f59f29a0c9ed7f197ddfa2c7
prerequisite-patch-id: 683855949a9ed37bc0cc4d1899373e55eac4ddc3
prerequisite-patch-id: 9b3a2b526476c32c8a859824e551e23412674766
prerequisite-patch-id: be866cf2acd4960f31f0dbd05e21f0722dcb70ab
prerequisite-patch-id: 58bd115be590c0d892a72e06794f5b244dbdb7f8
prerequisite-patch-id: 87435a0f6827516f4e2b5d8471a2b289bb73a88c
prerequisite-patch-id: 1064db7111fc77377dbf246eb0fdef90c18c46ee
prerequisite-patch-id: e112aaf6088f2bfa90bc67feaac86a4fc1ad23ca
prerequisite-patch-id: fcc0f2ee6dc0358d62593c1295d26a013fa11223
prerequisite-patch-id: 66364b8806fc6abeabe1a0b871e4e8c841ce2aa7
prerequisite-patch-id: 243046f52a14b416caead3469d580ea5b029f9bb
prerequisite-patch-id: efd8014f647a6aa5fadc9d62a6e1920d76a6c80f
prerequisite-patch-id: f4dbd5ae84a01ea89c7d00ca39fd76cd247bc353
prerequisite-patch-id: 30a16a45edefc8769b10d90a7807b6522cd31f15
prerequisite-patch-id: e12fd2908ca33de1f1265fd40190eaad8637e569
prerequisite-patch-id: 3baac076fdda664d00aa9a83481f76ec38c07e8a
prerequisite-patch-id: ee6a93ffa2d5461ee7b07929ff21626a14773b7a
prerequisite-patch-id: c8d444e2a6512f106da2675d4a42a92208d5c6f1
prerequisite-patch-id: 0491a69feb036cfa2e75401e093ebad387cf2846
prerequisite-patch-id: 707e7a3e5114c86f5bcc0b36e7cc8beb0c957780
prerequisite-patch-id: b1ae90d73bd7c3d19cfe4371b5dc9a816f1316a6
prerequisite-patch-id: 4c183b8ffd599169c8d3c5f3aad5ecc467b150f2
prerequisite-message-id: <20260609-dp_mstclean-v7-0-ea04113e8233@oss.qualcomm.com>
prerequisite-patch-id: 1d440cb9fed2bdd66d8de0e1e20475f0fe166973
prerequisite-patch-id: be0f4b80697df7224c80362b161b8a9f0a542184
prerequisite-patch-id: eefa6e6353df301420feae1da704a9db2c2155f2
prerequisite-patch-id: 9e9095f82dd6c131c9f3c1de4fdb8a62bd65ca24
prerequisite-patch-id: 3e635f008f9b56823101abd9253905f078fcb3b5
prerequisite-patch-id: e39e0dc124ed043c7a419610ebe03ad105da27db
prerequisite-patch-id: 945af39213cd4241e1a5929fada04a9286aeb5db
prerequisite-patch-id: 898ae7e4582a6b31492c223e7dd167fb9ce78096
prerequisite-patch-id: 3887553893357c1ffbda99eb010801bc2166cbad
prerequisite-patch-id: 7ccd961fa3c6f925659dee7d7a5bd167c8e7331b
prerequisite-patch-id: be2bf918e0e87ec2ea999927f36bd172c498748e
prerequisite-patch-id: 6aacdabb2dd0536dc04da04f8419ae39e35f8b19
prerequisite-patch-id: a9f27eff8f643ff445810b17d670891928f5b416
prerequisite-patch-id: efd300a2b52715153b8c1c7407db696eb331594b
prerequisite-patch-id: 950abefc4862050ef606404977fd27c5dd2cbb2b
Best regards,
--
Yongxing Mou <yongxing.mou@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on start/stop
From: Christian Hewitt @ 2026-06-29 14:47 UTC (permalink / raw)
To: Jerome Brunet
Cc: Martin Blumenstingl, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Neil Armstrong, Kevin Hilman, linux-sound,
linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <1jwlvha6xv.fsf@starbuckisacylon.baylibre.com>
> On 29 Jun 2026, at 4:04 pm, Jerome Brunet <jbrunet@baylibre.com> wrote:
>
> On ven. 26 juin 2026 at 22:41, Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:
>
>> On Fri, Jun 26, 2026 at 10:04 AM Christian Hewitt
>> <christianshewitt@gmail.com> wrote:
>>>
>>> The I2S FIFO soft-resets its fast domain on start (AIU_RST_SOFT bit 0 +
>>> AIU_I2S_SYNC read in aiu_fifo_i2s_trigger), mirroring the downstream
>>> vendor driver's audio_out_i2s_enable(). The S/PDIF FIFO has no equivalent:
>>> it only toggles the IEC958 DCU, so a stale datapath FIFO can be replayed,
>>> producing the "machine gun noise" buffer underrun - on start when switching
>>> outputs, and on stop when playback ends. The latter is audible on devices
>>> with an always-on S/PDIF-fed DAC (e.g. the ES7144 on the WeTek Play2).
>>>
>>> The vendor driver resets the IEC958 fast domain (AIU_RST_SOFT bit 2) on
>>> both enable and disable (audio_hw_958_enable), and when reconfiguring
>>> (audio_hw_958_reset clears AIU_958_DCU_FF_CTRL then resets). Do the same:
>>> reset before enabling the DCU on start, and after disabling it on stop.
>>>
>>> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
>> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>>
>> This matches the vendor driver, references:
>> - fast-reset SPDIF is triggered on enable and disable: [0]
>> - fast-reset SPDIF is triggered after all of the configuration is
>> written, then DCU_FF_CTRL is enabled: [1]
>
> Take what the vendor driver does with a grain of salt, especially when
> it comes to audio
>
>>
>> [...]
>>> case SNDRV_PCM_TRIGGER_SUSPEND:
>>> case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
>>> case SNDRV_PCM_TRIGGER_STOP:
>>> fifo_spdif_dcu_enable(component, false);
>>> + snd_soc_component_write(component, AIU_RST_SOFT,
>>> + AIU_RST_SOFT_958_FAST);
>> It doesn't seem to make any difference, so just for the record:
>> The vendor driver first triggers AIU_RST_SOFT_958_FAST then disables DCU: [2]
>>
>
> One could even wonder if there is any point in applying a reset when
> everything is stopped, if the enable path will apply this same
> reset before anything else is started again ? Does it really changes
> anything to the reported issue ?
Using disable/reset or reset/disable didn’t make any difference in my
testing, but without any reset playback stop on the WeTek Play2 board
with hardwired DAC always triggers the buffer underrun.
CH.
^ permalink raw reply
* Re: [PATCH 05/37] drm/display: bridge-connector: split code creating the connector to a subfunction
From: Laurent Pinchart @ 2026-06-29 14:44 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maxime Ripard, Maarten Lankhorst, Thomas Zimmermann, David Airlie,
Simona Vetter, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <DJJ4X22CJ3FG.5EYF84LVRNOG@bootlin.com>
On Fri, Jun 26, 2026 at 06:51:14PM +0200, Luca Ceresoli wrote:
> On Fri Jun 26, 2026 at 4:38 PM CEST, Maxime Ripard wrote:
> > On Fri, Jun 26, 2026 at 04:16:39PM +0200, Luca Ceresoli wrote:
> >> On Fri Jun 26, 2026 at 12:09 PM CEST, Maxime Ripard wrote:
> >> > On Wed, Jun 24, 2026 at 05:47:10PM +0200, Luca Ceresoli wrote:
> >> >> On Wed Jun 24, 2026 at 1:41 PM CEST, Maxime Ripard wrote:
> >> >> > On Fri, Jun 12, 2026 at 02:56:24PM +0200, Luca Ceresoli wrote:
> >> >> >> On Mon Jun 8, 2026 at 1:40 PM CEST, Maxime Ripard wrote:
> >> >> >> > On Tue, May 19, 2026 at 12:37:22PM +0200, Luca Ceresoli wrote:
> >> >> >> >> In preparation to introduce bridge hotplug, split out from
> >> >> >> >> drm_bridge_connector_init() the code adding the drm_connector into a
> >> >> >> >> dedicated function. This will be needed to be able to add (and re-add) the
> >> >> >> >> connector from different code paths.
> >> >> >> >
> >> >> >> > Same story here, explaining what you need later on that calls for that
> >> >> >> > change would be nice.
> >> >> >>
> >> >> >> Here's a more verbose version:
> >> >> >>
> >> >> >> Currently drm_bridge_connector_init() does two things:
> >> >> >>
> >> >> >> * allocate and initialize the drm_bridge_connector
> >> >> >> (which embeds a drm_connector)
> >> >> >> * initialize and register the embedded drm_connector
> >> >> >>
> >> >> >> For bridge hotplug we need to separate these two actions:
> >> >> >>
> >> >> >> * the drm_connector needs to be added and removed at any time based on
> >> >> >> hotplug events
> >> >> >> * the drm_bridge_connector is designated to create and remove the
> >> >> >> drm_connector, so it must be persistent for the card lifetime
> >> >> >>
> >> >> >> As the lifetimes of drm_bridge_connector and drm_connector become
> >> >> >> different, we need to create them in different moments.
> >> >> >>
> >> >> >> In preparation to support that, split out from
> >> >> >> drm_bridge_connector_init() the code adding the drm_connector into a
> >> >> >> dedicated function. No functional changes, just moving code around for
> >> >> >> now. A future commit will make the drm_connector be created based on
> >> >> >> hotplug events.
> >> >> >>
> >> >> >> Looks good?
> >> >> >
> >> >> > The message itself, yes, thanks.
> >> >> >
> >> >> > However, I have questions now :)
> >> >> >
> >> >> > Do we really expect drm_bridge_connector to stick around when a bridge
> >> >> > gets unplugged? If so, how does it cope with having, say, an HDMI
> >> >> > connector, and then swapping out the hotplugged part for an LVDS one?
> >> >> > Does the HDMI connector sticks around indefinitely?
> >> >>
> >> >> In your example, the HDMI drm_connector would be unregistered and put on
> >> >> hotunplug. Its allocation will stick around until the last put but that's
> >> >> quite irrelevant. Then, on plugging the LVDS addon, a new LVDS
> >> >> drm_connector will be created and registered.
> >> >>
> >> >> > *Especially* if we're using overlays for this, I'd expect everything
> >> >> > after the first hotplugged bridge to be destroyed, no?
> >> >>
> >> >> As said, it would be unregistered immediately but might be freed later on
> >> >> if still refcounted.
> >> >>
> >> >> This is visible in patches 36+15, the path to follow is:
> >> >>
> >> >> drm_bridge_connector_handle_event(event = DRM_BRIDGE_DETACHED) [patch 36]
> >> >> -> drm_bridge_connector_dynconn_release() [patch 15]
> >> >>
> >> >> Does this solve your concern?
> >> >
> >> > Not really, I'm talking about drm_bridge_connector. The fact that
> >> > bridges are destroyed make sense to me. The fact that
> >> > drm_bridge_connector sticks around doesn't. It's supposed to be a
> >> > connector for bridges. If you don't have bridges because they got
> >> > destroyed, and connector, drm_bridge_connector doesn't have a reason to
> >> > exist anymore, unless it's drm_bridge_hotplug in a trench coat :)
> >>
> >> It is not a hotplug-bridge in a trench coat, no :) The code is clear about
> >> this.
> >>
> >> I'd say with this series a "drm_bridge_connector" is just becoming
> >> something more (perhaps something else too). Somewhat as "a drm_bridge is
> >> either a bridge or something else". :)
> >>
> >>
> >> But let's leave names aside for a moment. If just looking at the current
> >> code, the drm_bridge_connector is "a handler, owned by the card/encoder and
> >> having the same lifetime, which takes care of drm_connector
> >> creation/destruction at card probe/removal".
> >>
> >> What we need now is just the same plug " and on hotplug events" appended.
> >>
> >> So in both cases there needs to be "a handler persitent with the card".
> >>
> >> Do we agree so far?
> >
> > Ish. If we go for that, then we need to update the name.
>
> drm_connector_manager?
> drm_bridge_connector_manager?
I'm fine with a rename. When developing drm_bridge_connector I've always
envisioned it as code that manages the creation of a connector for a
chain of bridges. In particular, the drm_bridge_connector object is
*not* and has never been a bridge.
Ideally all this should move to the DRM core and be transparent to
drivers. Drivers could set a flag somewhere to opt-in for connectors
managed by the DRM core.
> > drm_bridge_connector for something that is neither a bridge or a
> > connector is not great.
> >
> > But even then, I'm not even sure why we need to have that "manager" in
> > the first place. You want to make bridges be aware if they are the last
> > in the chain or not.
I don't think bridges should be aware of whether or not they're the last
one in the chain.
> > Use that property in attach to either create a
> > drm_bridge_connector instance if you're last, or attach the next bridge
> > if you aren't.
>
> What? o_O
>
> Several encoder drivers have been painfully converted to create a
> drm_bridge_connector. Now if the bridges start doing it themselves we
> should go back to those encoder drivers and ditch all the
> drm_bridge_connector from there?
>
> I must be missing something. Can you elaborate on this?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* ❌ FAIL: Test report for for-kernelci (7.2.0-rc1, upstream-arm-next, dc59e4fe)
From: cki-project @ 2026-06-29 14:43 UTC (permalink / raw)
To: linux-arm-kernel, ftjahjad, catalin.marinas, will, bgoncalv,
mmalik, omosnace
Hi, we tested your kernel and here are the results:
Overall result: FAILED
Merge: OK
Compile: OK
Test: FAILED
Kernel information:
Commit message: Linux 7.2-rc1
You can find all the details about the test run at
https://datawarehouse.cki-project.org/kcidb/checkouts/redhat:2636852511
One or more kernel tests failed:
Unrecognized or new issues:
Boot test
aarch64
Logs: https://datawarehouse.cki-project.org/kcidb/tests/redhat:2636852511_aarch64_kernel_kcidb_tool_21543639_6
Non-passing ran subtests:
❌ FAIL distribution/kpkginstall/journalctl-check
Reboot test
aarch64
Logs: https://datawarehouse.cki-project.org/kcidb/tests/redhat:2636852511_aarch64_kernel_kcidb_tool_21543639_11
Non-passing ran subtests:
❌ FAIL misc/reboot-test/journalctl-check
selinux-policy: serge-testsuite
aarch64
Logs: https://datawarehouse.cki-project.org/kcidb/tests/redhat:2636852511_aarch64_kernel_kcidb_tool_21543641_8
Non-passing ran subtests:
⚡ ERROR Setup
❌ FAIL Test
We also see the following known issues which are not related to your changes:
Issue: [upstream] Hardware - Firmware test suite - auto-waive failures
URL: https://gitlab.com/cki-project/infrastructure/-/issues/779
Affected tests:
Hardware - Firmware test suite [aarch64]
If you find a failure unrelated to your changes, please ask the test maintainer to review it.
This will prevent the failures from being incorrectly reported in the future.
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
^ permalink raw reply
* Re: [PATCH] mtd: nand: ecc-mtk: handle ECC clock enable failures
From: Miquel Raynal @ 2026-06-29 14:39 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Matthias Brugger,
AngeloGioacchino Del Regno, linux-mtd, linux-kernel,
linux-arm-kernel, linux-mediatek, Pengpeng Hou
In-Reply-To: <20260615063232.44383-1-pengpeng@iscas.ac.cn>
On Mon, 15 Jun 2026 14:32:32 +0800, Pengpeng Hou wrote:
> mtk_ecc_get() gets a reference to the ECC platform device, obtains the
> provider state and then enables the ECC clock before initializing the
> hardware.
>
> The clk_prepare_enable() return value is currently ignored. If enabling
> the clock fails, the code still touches the ECC registers and returns a
> live ECC handle to the caller. The provider device reference acquired
> by of_find_device_by_node() is also kept even though the handle setup
> failed.
>
> [...]
Applied to mtd/fixes, thanks!
[1/1] mtd: nand: ecc-mtk: handle ECC clock enable failures
commit: 82d9a2b45b170f0c52ac61e0e3e23f212cd065f0
Patche(s) should be available on mtd/linux.git and will be
part of the next PR (provided that no robot complains by then).
Kind regards,
Miquèl
^ permalink raw reply
* Re: [PATCH 1/9] dt-bindings: nvmem: imx-ocotp: Add support for secure-enclave
From: Frieder Schrempf @ 2026-06-29 14:37 UTC (permalink / raw)
To: Krzysztof Kozlowski, Frieder Schrempf
Cc: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <30e02780-52c7-4a71-9d4f-4b7a20494161@kernel.org>
On 22.06.26 15:12, Krzysztof Kozlowski wrote:
> On 17/06/2026 13:36, Frieder Schrempf wrote:
>> On 17.06.26 12:49, Krzysztof Kozlowski wrote:
>>> On Tue, Jun 16, 2026 at 01:52:16PM +0200, Frieder Schrempf wrote:
>>>> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>>>>
>>>> Some SoCs like the i.MX9 family allow full access to the fuses only
>>>> through the secure enclave firmware API. Add a property to reference
>>>> the secure enclave node and let the driver use the API.
>>>>
>>>> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
>>>> ---
>>>> Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml | 4 ++++
>>>> 1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
>>>> index a8076d0e2737..14a6429f4a4c 100644
>>>> --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
>>>> +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
>>>> @@ -53,6 +53,10 @@ properties:
>>>> reg:
>>>> maxItems: 1
>>>>
>>>> + secure-enclave:
>>>> + $ref: /schemas/types.yaml#/definitions/phandle
>>>> + description: A phandle to the secure enclave node
>>>
>>> Two things here:
>>> 1. Here you describe what for is that phandle, how it is used by the
>>> hardware. Currently the description repeats the property name and type,
>>> so not much useful.
>>
>> Ok, agree.
>>
>>>
>>> 2. If you access OTP via firmware, then this is completely different
>>> interface than MMIO, thus:
>>> A. reg is not appropriate
>>> B. Device is very different thus it has different compatible and I even
>>> claim should be in different binding. Devices having completely
>>> different SW interface should not be in the same binding, at least
>>> usually.
>>>
>>> If any of above is not accurate, then your commit msg should answer why
>>> and give some background.
>>
>> Thanks for the feedback!
>>
>> The driver currently uses the limited MMIO (FSB) interface to access the
>> OTPs. The intention is to support the firmware interface alongside the
>> MMIO interface so the driver can pick the interface that is available
>> (firmware might not be loaded) and fallback to MMIO.
>>
>> Following your argument would mean a driver deciding by itself which
>> interface to use at runtime is not something we want to have in general,
>> right?
>
> No, the property fits DT, but above information should be in commit msg.
> If this SoC has indeed both interfaces - MMIO and firmware calls - then
> everything is in general fine. I assumed that is not the case and MMIO
> is not really working.
>
> What was confusing is that it feels like you are changing existing
> interface, but why wasn't all this documented in the beginning? There is
> imx9 in this binding already, so was it working? Was it not working at
> all? Commit msg must clarify that.
Ok, thanks for clarifying. The MMIO interface for imx9 is working just
fine, but it's limited to access only a subset of the available OTP fuse
register space and only provides read access. Only the firmware
interface provides full access. I will extend the commit message
accordingly.
>
>>
>> In turn this would mean we need two drivers, or at least two
>> compatibles/bindings for something that is effectively the same hardware.
>
> Driver design is orthogonal choice here.
>
> It can reside in separate binding, if MMIO is still valid, but till
> everything is not yet too complex can be also this binding file.
>
> If it stays in this binding, then you need to restrict properties per
> variant, so add if:then: block which will disallow the phandle for other
> variants.
Of course! I totally forgot about this. I will restrict the property to
be only valid for variants that have the ELE firmware interface.
^ permalink raw reply
* [REGRESSION] mainline/master: Apalis iMX6 no longer boots
From: Leonardo Costa @ 2026-06-29 14:34 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam
Cc: leonardo.costa, devicetree, imx, linux-arm-kernel, linux-kernel,
regressions
Hello,
We are seeing a regression on Apalis iMX6 where the kernel doesn't boot in the
newest v7.2-rc1 (it was working before, in v7.1). The device tree being used is the imx6q-apalis-eval.dtb. The kernel
configuration used is the one shown below:
https://gist.github.com/lcosta37/53efdb2fb6e6e0fc05437c7e53b47737
The kernel logs stop almost immediately as the board starts to boot, and I
don't notice any difference in the logs that points to the cause.
Is this known? We are seeing this behavior on all Apalis iMX6 modules, though
we don't see it on Colibri iMX6, so it is not SoC-specific.
Logs from v7.2-rc1 (not working, printing stops after the last line pasted
here):
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 7.2.0-rc1-0.0.0-devel (oe-user@oe-host) (arm-tdx-linux-gnueabi-gcc (GCC) 16.1.0, GNU ld (GNU Binutils) 2.46.1) #1 SMP PREEMPT Sun Jun 28 19:01:31 UTC 2026
[ 0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: Toradex Apalis iMX6Q/D Module on Apalis Evaluation Board
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] cma: Reserved 256 MiB at 0x40000000
[ 0.000000] OF: reserved mem: Reserved memory: No reserved-memory node in the DT
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000010000000-0x000000003fffffff]
[ 0.000000] HighMem [mem 0x0000000040000000-0x000000004fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000010000000-0x000000004fffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000010000000-0x000000004fffffff]
[ 0.000000] percpu: Embedded 15 pages/cpu s28684 r8192 d24564 u61440
[ 0.000000] Kernel command line: root=PARTUUID=adb2cea1-02 ro rootwait console=tty1 console=ttymxc0,115200
[ 0.000000] printk: log buffer data + meta data: 131072 + 409600 = 540672 bytes
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 262144
[ 0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off
[ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] rcu: Preemptible hierarchical RCU implementation.
[ 0.000000] rcu: RCU event tracing is enabled.
[ 0.000000] Trampoline variant of Tasks RCU enabled.
[ 0.000000] Tracing variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[ 0.000000] RCU Tasks: Setting shift to 2 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=4.
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] L2C-310 errata 752271 769419 enabled
[ 0.000000] L2C-310 enabling early BRESP for Cortex-A9
[ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9
[ 0.000000] L2C-310 ID prefetch enabled, offset 16 lines
Logs from v7.1 (working) (full logs here: https://paste.debian.net/hidden/0f65ae5f)
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 7.1.0-0.0.0-devel (oe-user@oe-host) (arm-tdx-linux-gnueabi-gcc (GCC) 16.1.0, GNU ld (GNU Binutils) 2.46.1) #1 SMP PREEMPT Wed Jun 24 01:36:41 UTC 2026
[ 0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: Toradex Apalis iMX6Q/D Module on Apalis Evaluation Board
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] cma: Reserved 256 MiB at 0x40000000
[ 0.000000] OF: reserved mem: Reserved memory: No reserved-memory node in the DT
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000010000000-0x000000003fffffff]
[ 0.000000] HighMem [mem 0x0000000040000000-0x000000004fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000010000000-0x000000004fffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000010000000-0x000000004fffffff]
[ 0.000000] percpu: Embedded 15 pages/cpu s28684 r8192 d24564 u61440
[ 0.000000] pcpu-alloc: s28684 r8192 d24564 u61440 alloc=15*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[ 0.000000] Kernel command line: root=PARTUUID=4ce4ba92-02 ro rootwait console=tty1 console=ttymxc0,115200
[ 0.000000] printk: log buffer data + meta data: 131072 + 409600 = 540672 bytes
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 262144
[ 0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off
[ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] rcu: Preemptible hierarchical RCU implementation.
[ 0.000000] rcu: RCU event tracing is enabled.
[ 0.000000] Trampoline variant of Tasks RCU enabled.
[ 0.000000] Tracing variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[ 0.000000] RCU Tasks: Setting shift to 2 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=4.
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] L2C-310 errata 752271 769419 enabled
[ 0.000000] L2C-310 enabling early BRESP for Cortex-A9
[ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9
[ 0.000000] L2C-310 ID prefetch enabled, offset 16 lines
[ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[ 0.000000] L2C-310 cache controller enabled, 16 ways, 1024 kB
[ 0.000000] L2C-310: CACHE_ID 0x410000c7, AUX_CTRL 0x76470001
[ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[ 0.000000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.000000] Switching to timer-based delay loop, resolution 333ns
[ 0.000001] sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 715827882841ns
[ 0.000018] clocksource: mxc_timer1: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 637086815595 ns
[ 0.001910] Console: colour dummy device 80x30
[ 0.001926] printk: legacy console [tty1] enabled
[ 0.002519] Calibrating delay loop (skipped), value calculated using timer frequency.. 6.00 BogoMIPS (lpj=30000)
[ 0.002561] CPU: Testing write buffer coherency: ok
[ 0.002627] CPU0: Spectre v2: using BPIALL workaround
[ 0.002650] pid_max: default: 32768 minimum: 301
[ 0.002989] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.003038] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.003430] VFS: Finished mounting rootfs on nullfs
[ 0.004538] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.006552] Setting up static identity map for 0x10100000 - 0x10100060
[ 0.006835] rcu: Hierarchical SRCU implementation.
[ 0.006864] rcu: Max phase no-delay instances is 1000.
[ 0.007320] Timer migration: 1 hierarchy levels; 8 children per group; 1 crossnode level
[ 0.008854] smp: Bringing up secondary CPUs ...
[ 0.010035] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.010218] CPU1: Spectre v2: using BPIALL workaround
[ 0.011412] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[ 0.011581] CPU2: Spectre v2: using BPIALL workaround
[ 0.012747] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[ 0.012917] CPU3: Spectre v2: using BPIALL workaround
[ 0.013109] smp: Brought up 1 node, 4 CPUs
...
^ permalink raw reply
* Re: [PATCH 1/5] media: nxp: imx8-isi: Fix stream ID validation bypass in crossbar routing
From: Frank Li @ 2026-06-29 14:33 UTC (permalink / raw)
To: Guoniu Zhou
Cc: Laurent Pinchart, Mauro Carvalho Chehab, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Christian Hemp,
Stefan Riedmueller, Jacopo Mondi, Dong Aisheng, Guoniu Zhou,
linux-media, imx, linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260629-isi-v1-1-deebfdb1b07b@oss.nxp.com>
On Mon, Jun 29, 2026 at 03:44:55PM +0800, Guoniu Zhou wrote:
> The crossbar routing validation has a critical bug where it validates
> the wrong routing table, allowing userspace to bypass validation entirely.
>
> The __mxc_isi_crossbar_set_routing() function is called to validate and
> apply a new routing table from userspace. However, the validation loop
> iterates over state->routing (the currently active routing table) instead
> of the routing parameter (the new table being validated):
>
> for_each_active_route(&state->routing, route) {
>
> This means userspace can submit any invalid routing configuration and it
> will pass validation as long as the currently active routing is valid.
> This is a security issue as it allows userspace to configure routes that
> violate hardware constraints, potentially causing undefined hardware
> behavior.
>
> Fix by validating the routing table that will actually be applied:
>
> for_each_active_route(routing, route) {
>
> Additionally, add validation to enforce hardware constraints that were
> previously missing:
> - SOURCE stream must be 0 (ISI pipes are hardcoded to stream 0)
> - SINK stream must be less than the ISI channel count
> - Memory input can only route to the first pipeline (existing check)
Please use two patches to fix one, one fix for_each_active_route()
other other fix others.
Frank
>
> Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
> .../platform/nxp/imx8-isi/imx8-isi-crossbar.c | 24 ++++++++++++++++++++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c b/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
> index c580c831972e..29f14d30dbbb 100644
> --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
> +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
> @@ -106,8 +106,28 @@ static int __mxc_isi_crossbar_set_routing(struct v4l2_subdev *sd,
> if (ret)
> return ret;
>
> - /* The memory input can be routed to the first pipeline only. */
> - for_each_active_route(&state->routing, route) {
> + /*
> + * Validate routes against hardware constraints:
> + * - SOURCE stream must be 0 (pipes are hardcoded to stream 0)
> + * - SINK stream must be < ISI channel count
> + * - Memory input can only route to the first pipeline
> + */
> + for_each_active_route(routing, route) {
> + if (route->source_stream != 0) {
> + dev_dbg(xbar->isi->dev,
> + "route to pipe %u must use source_stream=0, got %u\n",
> + route->source_pad - xbar->num_sinks,
> + route->source_stream);
> + return -ENXIO;
> + }
> +
> + if (route->sink_stream >= xbar->num_sources) {
> + dev_dbg(xbar->isi->dev,
> + "sink_stream %u exceeds hardware limit %u\n",
> + route->sink_stream, xbar->num_sources - 1);
> + return -ENXIO;
> + }
> +
> if (route->sink_pad == xbar->num_sinks - 1 &&
> route->source_pad != xbar->num_sinks) {
> dev_dbg(xbar->isi->dev,
>
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Leo Yan @ 2026-06-29 14:28 UTC (permalink / raw)
To: Jie Gan
Cc: Suzuki K Poulose, Mike Leach, James Clark, Konrad Dybcio,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Abel Vesa,
Yuanfang Zhang, linux-arm-msm, devicetree, linux-kernel,
coresight, linux-arm-kernel
In-Reply-To: <9432df20-08bf-4134-b4b9-e6b5d618af81@oss.qualcomm.com>
On Mon, Jun 29, 2026 at 10:08:17AM +0800, Jie Gan wrote:
[...]
> Can I fix the issue by adding "arm,primecell-periphid" property. That's
> would be the best temp solution as it avoids breaking the original design of
> both the TraceNoC AMBA driver and interconnect TraceNoC platform driver.
Before proceeding with the "arm,primecell-periphid" property, could you
clarify a bit:
- For an interconnect TraceNoC, what would be the consequence of
enabling ATID? Would it simply be a no-op, or are there any side
effects? Or is the concern that the trace IDs could be exhausted?
- How can you guarantee that a interconnect TraceNoC will never
require ATID in the future?
> The TraceNoC device here must be treated as an AMBA device and I am
> continuing to investigate the issue with our hardware team.
> We aim to fix it from hardware perspetive for existing platforms if possible
> and ensure it is fixed in future platforms.
I'm concerned that all of use end up repeatedly fixing similar issues
whenever hardware configurations change or modules are reused in
different topologies.
For example, if future platforms may require ATID support for an
interconnect TraceNoC, then the issue will pop up again.
Thanks,
Leo
^ permalink raw reply
* Re: [PATCH 00/13] treewide: replace linux/gpio.h
From: Arnd Bergmann @ 2026-06-29 14:24 UTC (permalink / raw)
To: Andreas Schwab, Arnd Bergmann
Cc: open list:GPIO SUBSYSTEM, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, Netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <mvmik71win7.fsf@suse.de>
On Mon, Jun 29, 2026, at 16:01, Andreas Schwab wrote:
> On Jun 29 2026, Arnd Bergmann wrote:
>
>> From: Arnd Bergmann <arnd@arndb.de>
>>
>> The linux/gpio.h header used to be the global definition for the gpio
>> interfaces, with 1100 users back in linux-3.17. In linux-7.2, only about
>> 130 of those remain, so this series cleans out the rest.
>>
>> In each subsystem, we can replace the header either with
>> linux/gpio/consumer.h for users of the modern gpio descriptor interface,
>
> A few of them already used <linux/gpio/consumer.h>, and is duplicated
> now.
Indeed, I have removed the extra ones now and folded those into
the patches.
Arnd
diff --git a/drivers/gpib/gpio/gpib_bitbang.c b/drivers/gpib/gpio/gpib_bitbang.c
index 2e8d895db06a..34d14b94a0b8 100644
--- a/drivers/gpib/gpio/gpib_bitbang.c
+++ b/drivers/gpib/gpio/gpib_bitbang.c
@@ -64,7 +64,6 @@
#include <linux/gpio/consumer.h>
#include <linux/gpio/driver.h>
#include <linux/gpio/machine.h>
-#include <linux/gpio/consumer.h>
#include <linux/irq.h>
static int sn7516x_used = 1, sn7516x;
diff --git a/drivers/input/keyboard/matrix_keypad.c b/drivers/input/keyboard/matrix_keypad.c
index 98d0269a978f..8863b741d1a3 100644
--- a/drivers/input/keyboard/matrix_keypad.c
+++ b/drivers/input/keyboard/matrix_keypad.c
@@ -16,7 +16,6 @@
#include <linux/interrupt.h>
#include <linux/jiffies.h>
#include <linux/module.h>
-#include <linux/gpio/consumer.h>
#include <linux/input/matrix_keypad.h>
#include <linux/slab.h>
#include <linux/of.h>
diff --git a/drivers/input/misc/soc_button_array.c b/drivers/input/misc/soc_button_array.c
index eb11bf2e9436..a6c984205123 100644
--- a/drivers/input/misc/soc_button_array.c
+++ b/drivers/input/misc/soc_button_array.c
@@ -15,7 +15,6 @@
#include <linux/dmi.h>
#include <linux/gpio/consumer.h>
#include <linux/gpio_keys.h>
-#include <linux/gpio/consumer.h>
#include <linux/platform_device.h>
static bool use_low_level_irq;
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
index 88c5c52e0e38..5f5adc9c9e83 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
@@ -16,7 +16,6 @@
#include <linux/net_tstamp.h>
#include <linux/ptp_classify.h>
#include <linux/ptp_pch.h>
-#include <linux/gpio/consumer.h>
#define PCH_GBE_MAR_ENTRIES 16
#define PCH_GBE_SHORT_PKT 64
diff --git a/drivers/net/phy/mdio_device.c b/drivers/net/phy/mdio_device.c
index a18263d5bb02..06151f207134 100644
--- a/drivers/net/phy/mdio_device.c
+++ b/drivers/net/phy/mdio_device.c
@@ -9,7 +9,6 @@
#include <linux/delay.h>
#include <linux/errno.h>
#include <linux/gpio/consumer.h>
-#include <linux/gpio/consumer.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/kernel.h>
diff --git a/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c b/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
index d9c06129ed23..171bf097a8b8 100644
--- a/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
+++ b/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
@@ -4,7 +4,6 @@
#include <linux/delay.h>
#include <linux/extcon-provider.h>
#include <linux/gpio/consumer.h>
-#include <linux/gpio/consumer.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/io.h>
diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index 2233babc0078..1f5dba49ace4 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -12,7 +12,6 @@
#include <linux/clk.h>
#include <linux/clk-provider.h>
#include <linux/gpio/consumer.h>
-#include <linux/gpio/consumer.h>
#include <linux/io.h>
#include <linux/module.h>
#include <linux/mfd/syscon.h>
diff --git a/include/linux/mfd/ti-lmu.h b/include/linux/mfd/ti-lmu.h
index 5040c7d1e1b9..2089ec5124e8 100644
--- a/include/linux/mfd/ti-lmu.h
+++ b/include/linux/mfd/ti-lmu.h
@@ -10,7 +10,6 @@
#ifndef __MFD_TI_LMU_H__
#define __MFD_TI_LMU_H__
-#include <linux/gpio/consumer.h>
#include <linux/notifier.h>
#include <linux/regmap.h>
#include <linux/gpio/consumer.h>
diff --git a/sound/soc/codecs/cs42l84.c b/sound/soc/codecs/cs42l84.c
index 36c3abc21fed..f2448b4c11fc 100644
--- a/sound/soc/codecs/cs42l84.c
+++ b/sound/soc/codecs/cs42l84.c
@@ -16,7 +16,6 @@
#include <linux/init.h>
#include <linux/delay.h>
#include <linux/i2c.h>
-#include <linux/gpio/consumer.h>
#include <linux/regmap.h>
#include <linux/slab.h>
#include <linux/acpi.h>
diff --git a/sound/soc/codecs/dmic.c b/sound/soc/codecs/dmic.c
index 8b05d6f9b429..cbed11136935 100644
--- a/sound/soc/codecs/dmic.c
+++ b/sound/soc/codecs/dmic.c
@@ -7,7 +7,6 @@
#include <linux/delay.h>
#include <linux/gpio/consumer.h>
-#include <linux/gpio/consumer.h>
#include <linux/platform_device.h>
#include <linux/regulator/consumer.h>
#include <linux/slab.h>
^ permalink raw reply related
* [PATCH] clk: mediatek: fix memory leak on module removal
From: Akari Tsuyukusa @ 2026-06-29 14:23 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Matthias Brugger,
AngeloGioacchino Del Regno, Chen-Yu Tsai, Miles Chen
Cc: Akari Tsuyukusa, open list:COMMON CLK FRAMEWORK,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
Some MediaTek clock drivers do not call platform_set_drvdata() during
probe(), but their remove() callback calls platform_get_drvdata(). This
results in platform_get_drvdata() returning NULL, which leads to calling
mtk_free_clk_data(NULL) -> kfree(NULL).
Therefore, the actual clk_data is never released, causing a memory leak.
Fix this by calling platform_set_drvdata() during probe.
Fixes: 124294ff468f ("clk: mediatek: mt8192: Move apmixedsys clock driver to its own file")
Fixes: 4c02c9af3cb9 ("clk: mediatek: mt8173: Break down clock drivers and allow module build")
Fixes: 54b7026f011e ("clk: mediatek: mt8135-apmixedsys: Convert to platform_driver and module")
Fixes: c50e2ea6507b ("clk: mediatek: mt7622-apmixedsys: Add .remove() callback for module build")
Fixes: 0d363282bb0c ("clk: mediatek: Add MediaTek Helio X10 MT6795 clock drivers")
Fixes: c6368ce86435 ("clk: mediatek: mt2712-apmixedsys: Add .remove() callback for module build")
Fixes: 838b86331c5e ("clk: mediatek: mt7622: Move infracfg to clk-mt7622-infracfg.c")
Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com>
---
drivers/clk/mediatek/clk-mt2712-apmixedsys.c | 1 +
drivers/clk/mediatek/clk-mt6795-apmixedsys.c | 1 +
drivers/clk/mediatek/clk-mt6795-infracfg.c | 1 +
drivers/clk/mediatek/clk-mt6795-pericfg.c | 1 +
drivers/clk/mediatek/clk-mt7622-apmixedsys.c | 1 +
drivers/clk/mediatek/clk-mt7622-infracfg.c | 1 +
drivers/clk/mediatek/clk-mt8135-apmixedsys.c | 1 +
drivers/clk/mediatek/clk-mt8173-apmixedsys.c | 1 +
drivers/clk/mediatek/clk-mt8173-infracfg.c | 1 +
drivers/clk/mediatek/clk-mt8192-apmixedsys.c | 1 +
10 files changed, 10 insertions(+)
diff --git a/drivers/clk/mediatek/clk-mt2712-apmixedsys.c b/drivers/clk/mediatek/clk-mt2712-apmixedsys.c
index 54b18e9f83f8..24522fc24019 100644
--- a/drivers/clk/mediatek/clk-mt2712-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt2712-apmixedsys.c
@@ -129,6 +129,7 @@ static int clk_mt2712_apmixed_probe(struct platform_device *pdev)
goto unregister_plls;
}
+ platform_set_drvdata(pdev, clk_data);
return 0;
unregister_plls:
diff --git a/drivers/clk/mediatek/clk-mt6795-apmixedsys.c b/drivers/clk/mediatek/clk-mt6795-apmixedsys.c
index 123d5d7fea85..b607592a7c37 100644
--- a/drivers/clk/mediatek/clk-mt6795-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt6795-apmixedsys.c
@@ -175,6 +175,7 @@ static int clk_mt6795_apmixed_probe(struct platform_device *pdev)
dev_dbg(dev, "Performing initial setup for MD1\n");
clk_mt6795_apmixed_setup_md1(base);
+ platform_set_drvdata(pdev, clk_data);
return 0;
unregister_ref2usb:
diff --git a/drivers/clk/mediatek/clk-mt6795-infracfg.c b/drivers/clk/mediatek/clk-mt6795-infracfg.c
index e4559569f5b0..12146bb3b726 100644
--- a/drivers/clk/mediatek/clk-mt6795-infracfg.c
+++ b/drivers/clk/mediatek/clk-mt6795-infracfg.c
@@ -116,6 +116,7 @@ static int clk_mt6795_infracfg_probe(struct platform_device *pdev)
if (ret)
goto unregister_cpumuxes;
+ platform_set_drvdata(pdev, clk_data);
return 0;
unregister_cpumuxes:
diff --git a/drivers/clk/mediatek/clk-mt6795-pericfg.c b/drivers/clk/mediatek/clk-mt6795-pericfg.c
index d48240eb2a67..28faeb2e657a 100644
--- a/drivers/clk/mediatek/clk-mt6795-pericfg.c
+++ b/drivers/clk/mediatek/clk-mt6795-pericfg.c
@@ -125,6 +125,7 @@ static int clk_mt6795_pericfg_probe(struct platform_device *pdev)
if (ret)
goto unregister_composites;
+ platform_set_drvdata(pdev, clk_data);
return 0;
unregister_composites:
diff --git a/drivers/clk/mediatek/clk-mt7622-apmixedsys.c b/drivers/clk/mediatek/clk-mt7622-apmixedsys.c
index 8a29eaab0cfc..a9fc2e5536b3 100644
--- a/drivers/clk/mediatek/clk-mt7622-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt7622-apmixedsys.c
@@ -109,6 +109,7 @@ static int clk_mt7622_apmixed_probe(struct platform_device *pdev)
if (ret)
goto unregister_gates;
+ platform_set_drvdata(pdev, clk_data);
return 0;
unregister_gates:
diff --git a/drivers/clk/mediatek/clk-mt7622-infracfg.c b/drivers/clk/mediatek/clk-mt7622-infracfg.c
index cfdf3b07c3e0..b44baf521d2f 100644
--- a/drivers/clk/mediatek/clk-mt7622-infracfg.c
+++ b/drivers/clk/mediatek/clk-mt7622-infracfg.c
@@ -90,6 +90,7 @@ static int clk_mt7622_infracfg_probe(struct platform_device *pdev)
if (ret)
goto unregister_cpumuxes;
+ platform_set_drvdata(pdev, clk_data);
return 0;
unregister_cpumuxes:
diff --git a/drivers/clk/mediatek/clk-mt8135-apmixedsys.c b/drivers/clk/mediatek/clk-mt8135-apmixedsys.c
index 19e4ee489ec3..41e5cfbcbb76 100644
--- a/drivers/clk/mediatek/clk-mt8135-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt8135-apmixedsys.c
@@ -66,6 +66,7 @@ static int clk_mt8135_apmixed_probe(struct platform_device *pdev)
if (ret)
goto unregister_plls;
+ platform_set_drvdata(pdev, clk_data);
return 0;
unregister_plls:
diff --git a/drivers/clk/mediatek/clk-mt8173-apmixedsys.c b/drivers/clk/mediatek/clk-mt8173-apmixedsys.c
index d7d416172ab3..fe36d2eac3da 100644
--- a/drivers/clk/mediatek/clk-mt8173-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt8173-apmixedsys.c
@@ -179,6 +179,7 @@ static int clk_mt8173_apmixed_probe(struct platform_device *pdev)
if (r)
goto unregister_ref2usb;
+ platform_set_drvdata(pdev, clk_data);
return 0;
unregister_ref2usb:
diff --git a/drivers/clk/mediatek/clk-mt8173-infracfg.c b/drivers/clk/mediatek/clk-mt8173-infracfg.c
index fa2d1d557e04..b923b73c64f6 100644
--- a/drivers/clk/mediatek/clk-mt8173-infracfg.c
+++ b/drivers/clk/mediatek/clk-mt8173-infracfg.c
@@ -128,6 +128,7 @@ static int clk_mt8173_infracfg_probe(struct platform_device *pdev)
if (r)
goto unregister_clk_hw;
+ platform_set_drvdata(pdev, clk_data);
return 0;
unregister_clk_hw:
diff --git a/drivers/clk/mediatek/clk-mt8192-apmixedsys.c b/drivers/clk/mediatek/clk-mt8192-apmixedsys.c
index b0563a285bd6..446c55b77777 100644
--- a/drivers/clk/mediatek/clk-mt8192-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt8192-apmixedsys.c
@@ -176,6 +176,7 @@ static int clk_mt8192_apmixed_probe(struct platform_device *pdev)
if (r)
goto unregister_gates;
+ platform_set_drvdata(pdev, clk_data);
return r;
unregister_gates:
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3] irqchip/gic-v3-its: Fix OF node reference leak
From: Zenghui Yu @ 2026-06-29 12:19 UTC (permalink / raw)
To: Yuho Choi; +Cc: Marc Zyngier, Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20260628220723.1699972-1-dbgh9129@gmail.com>
On 6/29/26 6:07 AM, Yuho Choi wrote:
> of_get_cpu_node() returns a referenced device node. In
> its_cpu_init_collection(), the Cavium 23144 workaround only uses the
> node to compare the CPU NUMA node, but the reference is never dropped.
>
> Use the device_node cleanup helper for the CPU node reference so it is
> released when leaving the workaround block, including the NUMA mismatch
> return path.
>
> Fixes: fbf8f40e1658 ("irqchip/gicv3-its: numa: Enable workaround for Cavium thunderx erratum 23144")
> Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
> Acked-by: Marc Zyngier <maz@kernel.org>
> ---
> Changes in v3:
> - Keep the __free(device_node) assignment on a single line.
> - Fix indentation in the Cavium 23144 workaround block.
> - Add Marc's Acked-by.
> Changes in v2:
> - Use __free(device_node) for the CPU node reference.
> - Correct the Fixes tag to fbf8f40e1658.
> drivers/irqchip/irq-gic-v3-its.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index b57d81ad33a0..6f5811aae59c 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -3290,11 +3290,9 @@ static void its_cpu_init_collection(struct its_node *its)
>
> /* avoid cross node collections and its mapping */
> if (its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_23144) {
> - struct device_node *cpu_node;
> + struct device_node *cpu_node __free(device_node) = of_get_cpu_node(cpu, NULL);
>
> - cpu_node = of_get_cpu_node(cpu, NULL);
> - if (its->numa_node != NUMA_NO_NODE &&
> - its->numa_node != of_node_to_nid(cpu_node))
> + if (its->numa_node != NUMA_NO_NODE && its->numa_node != of_node_to_nid(cpu_node))
> return;
> }
Reviewed-by: Zenghui Yu (Huawei) <zenghui.yu@linux.dev>
Thanks,
Zenghui
^ permalink raw reply
* Re: [PATCH v7 7/7] KVM: arm64: Enforce strict SBZ checks in the FF-A proxy
From: Will Deacon @ 2026-06-29 14:17 UTC (permalink / raw)
To: Sebastian Ene
Cc: catalin.marinas, maz, oupton, joey.gouly, korneld, kvmarm,
linux-arm-kernel, linux-kernel, android-kvm, mrigendra.chaubey,
perlarsen, suzuki.poulose, vdonnefort, yuzenghui
In-Reply-To: <20260629093558.2425257-8-sebastianene@google.com>
On Mon, Jun 29, 2026 at 09:35:58AM +0000, Sebastian Ene wrote:
> Introduce a helper method ffa_check_unused_args_sbz to enforce strict
> arguments checking when the hypervisor acts as a relayer between the
> host and Trustzone.
>
> Signed-off-by: Sebastian Ene <sebastianene@google.com>
> Reviewed-by: Vincent Donnefort <vdonnefort@google.com>
> Acked-by: Will Deacon <will@kernel.org>
> ---
> arch/arm64/kvm/hyp/nvhe/ffa.c | 96 ++++++++++++++++++++++++++++++++++-
> 1 file changed, 95 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> index 712811e89435..334f8a28d942 100644
> --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> @@ -74,6 +74,21 @@ static u32 hyp_ffa_version;
> static bool has_version_negotiated;
> static hyp_spinlock_t version_lock;
>
> +static bool ffa_check_unused_args_sbz(struct kvm_cpu_context *ctxt, int first_reg)
> +{
> + DECLARE_REG(u32, func_id, ctxt, 0);
> + int reg, end_reg = 7;
> +
> + if (hyp_ffa_version >= FFA_VERSION_1_2 && ARM_SMCCC_IS_64(func_id))
> + end_reg = 17;
Sashiko gets angry about this check, but I don't think we need to change
anything. Yes, there is a data race on hyp_ffa_version if you issue
FFA_VERSION concurrently with itself, but FFA_VERSION is a 32-bit call
so it's all moot.
In fact, a 64-bit FFA_VERSION would be problematic for other reasons,
because a single (non-racy) CPU trying to attempt a version downgrade
could end up passing non-zero values in registers that SBZ in the running
version (of which it knows nothing about).
So my Ack stands.
Will
^ permalink raw reply
* Re: [PATCH v4 2/2] i2c: imx: Cancel hrtimer before clearing slave pointer
From: Frank Li @ 2026-06-29 14:14 UTC (permalink / raw)
To: Liem
Cc: carlos.song, andi.shyti, biwen.li, festevam, frank.li, imx,
kernel, linux-arm-kernel, linux-i2c, linux-kernel, o.rempel,
s.hauer, stable, wsa, Carlos Song
In-Reply-To: <20260629023829.152651-3-liem16213@gmail.com>
On Mon, Jun 29, 2026 at 10:38:29AM +0800, Liem wrote:
> In i2c_imx_unreg_slave(), the slave pointer is set to NULL after
> disabling interrupts. However, a pending interrupt might already
> have started the hrtimer (i2c_imx_slave_timeout) before the pointer
> was cleared. If the hrtimer fires after i2c_imx->slave is set to
> NULL, the timer callback i2c_imx_slave_finish_op() will call
> i2c_imx_slave_event() with a NULL slave pointer, which results in a
> use-after-free / NULL pointer dereference.
>
> Fix by canceling the hrtimer and waiting for it to complete after
> disabling interrupts, before clearing the slave pointer.
>
> Fixes: f7414cd6923f ("i2c: imx: support slave mode for imx I2C driver")
> Cc: stable@vger.kernel.org
> Acked-by: Carlos Song <carlos.song@nxp.com>
> Signed-off-by: Liem <liem16213@gmail.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> v3 -> v4: No changes, added Acked-by from Carlos Song.
> ---
> drivers/i2c/busses/i2c-imx.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index 2398c406e913..b1c6581db774 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -960,6 +960,7 @@ static int i2c_imx_unreg_slave(struct i2c_client *client)
>
> i2c_imx_reset_regs(i2c_imx);
>
> + hrtimer_cancel(&i2c_imx->slave_timer);
> i2c_imx->slave = NULL;
>
> /* Suspend */
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v4 1/2] i2c: imx: Fix slave registration race and error handling
From: Frank Li @ 2026-06-29 14:13 UTC (permalink / raw)
To: Liem
Cc: carlos.song, andi.shyti, biwen.li, festevam, frank.li, imx,
kernel, linux-arm-kernel, linux-i2c, linux-kernel, o.rempel,
s.hauer, stable, wsa
In-Reply-To: <20260629023829.152651-2-liem16213@gmail.com>
On Mon, Jun 29, 2026 at 10:38:28AM +0800, Liem wrote:
> In i2c_imx_reg_slave(), the slave pointer was assigned before
> pm_runtime_resume_and_get(). If pm_runtime_resume_and_get() failed,
> the error path returned without clearing i2c_imx->slave, leaving it
> non-NULL and causing all subsequent registration attempts to fail
> with -EBUSY.
>
> Additionally, because this driver uses a shared IRQ, the interrupt
> handler i2c_imx_isr() can execute concurrently and, after acquiring
> slave_lock, dereference i2c_imx->slave. The previous fix attempt
> added a lockless i2c_imx->slave = NULL on the error path, but that
> could race with the ISR under the lock and still cause a NULL pointer
> dereference.
>
> Fix both issues by deferring the assignment of i2c_imx->slave and
> i2c_imx->last_slave_event to after a successful resume, and by
> performing the assignment inside the slave_lock critical section.
> This guarantees that the slave pointer is never left stale on the
> error path and is always valid when observed by the interrupt handler.
>
> Fixes: f7414cd6923f ("i2c: imx: support slave mode for imx I2C driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Liem <liem16213@gmail.com>
> ---
anthor question, why v1..v3 use the thread? Suppose each new version should
start new thread. Do you use --in-reply-to in send patch?
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> v3 -> v4:
> - Instead of clearing the slave pointer on error, defer the
> assignment until after pm_runtime_resume_and_get() succeeds,
> and take slave_lock to avoid racing with the shared IRQ handler.
> Suggested by Sashiko and Carlos Song
> ---
> drivers/i2c/busses/i2c-imx.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index 28313d0fad37..2398c406e913 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -930,9 +930,6 @@ static int i2c_imx_reg_slave(struct i2c_client *client)
> if (i2c_imx->slave)
> return -EBUSY;
>
> - i2c_imx->slave = client;
> - i2c_imx->last_slave_event = I2C_SLAVE_STOP;
> -
> /* Resume */
> ret = pm_runtime_resume_and_get(i2c_imx->adapter.dev.parent);
> if (ret < 0) {
> @@ -940,6 +937,11 @@ static int i2c_imx_reg_slave(struct i2c_client *client)
> return ret;
> }
>
> + scoped_guard(spinlock_irqsave, &i2c_imx->slave_lock) {
> + i2c_imx->slave = client;
> + i2c_imx->last_slave_event = I2C_SLAVE_STOP;
> + }
> +
> i2c_imx_slave_init(i2c_imx);
>
> return 0;
> --
> 2.34.1
>
^ permalink raw reply
* Re: [External Mail] Re: [PATCH v3 2/7] net: wwan: t9xx: Add control plane transaction layer
From: Andrew Lunn @ 2026-06-29 14:10 UTC (permalink / raw)
To: Wu. JackBB (GSM)
Cc: Loic Poulain, Sergey Ryazanov, Johannes Berg, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Wen-Zhi Huang, Shi-Wei Yeh, Minano Tseng, Matthias Brugger,
AngeloGioacchino Del Regno, Simon Horman, Jonathan Corbet,
Shuah Khan, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <49939d4d682f4c1fb359973ea2cdbd00@compal.com>
> > > - devm_kfree(dev, mdev);
> > > + mtk_dev_free(mdev);
> >
> > Why are you removing devm_ calls?
>
> mtk_dev_alloc/mtk_dev_free are paired wrappers so the caller
> doesn't need to know the underlying allocation mechanism.
> The devm_kfree is still called inside mtk_dev_free.
Two different issues here:
1) If you don't want to use devm_, don't use devm_ from the
beginning. A patch should not change how a previous patch works, since
you are wasting reviewer time reviewing code which you later change.
2) Do you understand what devm_ actually does? Since you use
devm_free() i don't think you actually understand what devm_ is all
about.
Andrew
^ permalink raw reply
* Re: [PATCH v2] MAINTAINERS: Update Xilinx AMS driver maintainers
From: Michal Simek @ 2026-06-29 14:10 UTC (permalink / raw)
To: Sai Krishna Potthuri, Conall O'Griofa, Jonathan Cameron
Cc: linux-iio, linux-arm-kernel, linux-kernel
In-Reply-To: <20260629140615.213750-1-sai.krishna.potthuri@amd.com>
On 6/29/26 16:06, Sai Krishna Potthuri wrote:
> Salih Erim is no longer with AMD to maintain the Xilinx AMS driver.
> Replace Salih Erim with Sai Krishna Potthuri in the Xilinx AMS driver
> MAINTAINERS entry for continued development and maintenance of the driver.
>
> Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
> ---
> v2:
> - Replaced Salih Erim with Sai Krishna Potthuri.
>
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 6b4560681b51..d8591066f182 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -29458,7 +29458,7 @@ F: include/uapi/linux/dqblk_xfs.h
> F: include/uapi/linux/fsmap.h
>
> XILINX AMS DRIVER
> -M: Salih Erim <salih.erim@amd.com>
> +M: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
> M: Conall O'Griofa <conall.ogriofa@amd.com>
> L: linux-iio@vger.kernel.org
> S: Maintained
Acked-by: Michal Simek <michal.simek@amd.com>
Thanks,
Michal
^ permalink raw reply
* [PATCH v2] MAINTAINERS: Update Xilinx AMS driver maintainers
From: Sai Krishna Potthuri @ 2026-06-29 14:06 UTC (permalink / raw)
To: Conall O'Griofa, Jonathan Cameron, michal.simek
Cc: linux-iio, linux-arm-kernel, linux-kernel, Sai Krishna Potthuri
Salih Erim is no longer with AMD to maintain the Xilinx AMS driver.
Replace Salih Erim with Sai Krishna Potthuri in the Xilinx AMS driver
MAINTAINERS entry for continued development and maintenance of the driver.
Signed-off-by: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
---
v2:
- Replaced Salih Erim with Sai Krishna Potthuri.
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6b4560681b51..d8591066f182 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -29458,7 +29458,7 @@ F: include/uapi/linux/dqblk_xfs.h
F: include/uapi/linux/fsmap.h
XILINX AMS DRIVER
-M: Salih Erim <salih.erim@amd.com>
+M: Sai Krishna Potthuri <sai.krishna.potthuri@amd.com>
M: Conall O'Griofa <conall.ogriofa@amd.com>
L: linux-iio@vger.kernel.org
S: Maintained
--
2.25.1
^ permalink raw reply related
* Re: [PATCH net-next v11 1/7] dt-bindings: phy: document the serdes PHY on sa8255p
From: Bartosz Golaszewski @ 2026-06-29 14:07 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Vinod Koul, Giuseppe Cavallaro, Chen-Yu Tsai, Jernej Skrabec,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Shawn Guo,
Fabio Estevam, Jan Petrous, s32, Mohd Ayaan Anwar, Romain Gantois,
Magnus Damm, Maxime Ripard, Christophe Roullier,
Bartosz Golaszewski, Radu Rendec, linux-arm-msm, devicetree,
linux-kernel, netdev, linux-stm32, linux-arm-kernel, Drew Fustini,
linux-sunxi, linux-amlogic, linux-mips, imx, linux-renesas-soc,
linux-rockchip, sophgo, linux-riscv, Bartosz Golaszewski,
Bartosz Golaszewski
In-Reply-To: <CAMuHMdXen+E-Ai51aWBa_KV9W8Fz2cQPpT-FG_kQ7akhrrYa_A@mail.gmail.com>
On Mon, 29 Jun 2026 15:51:31 +0200, Geert Uytterhoeven
<geert@linux-m68k.org> said:
> Hi Bartosz,
>
> Thanks for your patch!
>
> On Mon, 29 Jun 2026 at 13:29, Bartosz Golaszewski
> <bartosz.golaszewski@oss.qualcomm.com> wrote:
>> Describe the SGMII/SerDes PHY present on the Qualcomm sa8255p platforms.
>> This is essentially the same hardware as sa8775p rev3 but the PHY is
>> managed by firmware over SCMI.
>
> So why can't it be reuse the DT bindings, and be compatible with
> qcom,sa8775p-dwmac-sgmii-phy?
>
>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom,sa8255p-dwmac-sgmii-phy.yaml
>
>> + power-domains:
>> + maxItems: 1
>> +
>> + power-domain-names:
>> + items:
>> + - const: serdes
>
>> +examples:
>> + - |
>> + phy@8901000 {
>> + compatible = "qcom,sa8255p-dwmac-sgmii-phy";
>> + reg = <0x08901000 0xe10>;
>> + #phy-cells = <0>;
>> + power-domains = <&scmi7_dvfs 0>;
>> + power-domain-names = "serdes";
>
> Ah, this uses power-domains, while the existing bindings for
> qcom,sa8775p-dwmac-sgmii-phy use a clock.
> I guess the clock is the correct hardware description?
>
> Adding to my list of examples for backing a hardware-to-SCMI remapping
> driver...
>
Russell King asked me to put the PHY logic for SCMI pm domains into the PHY
driver instead of the MAC driver where it was previously. Instead of cramming
both HLOS and firmware handling into the same driver, I figured it makes more
sense to have a dedicated, cleaner driver as the two share very little code (if
any).
Bart
^ permalink raw reply
* Re: [PATCH 00/13] treewide: replace linux/gpio.h
From: Andreas Schwab @ 2026-06-29 14:01 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-gpio, Arnd Bergmann, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <20260629132633.1300009-1-arnd@kernel.org>
On Jun 29 2026, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> The linux/gpio.h header used to be the global definition for the gpio
> interfaces, with 1100 users back in linux-3.17. In linux-7.2, only about
> 130 of those remain, so this series cleans out the rest.
>
> In each subsystem, we can replace the header either with
> linux/gpio/consumer.h for users of the modern gpio descriptor interface,
A few of them already used <linux/gpio/consumer.h>, and is duplicated
now.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
* [PATCH] [RFC] gpiolib: introduce gpio_name() helper
From: Arnd Bergmann @ 2026-06-29 13:56 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski
Cc: Arnd Bergmann, Marcel Holtmann, MyungJoo Ham, Chanwoo Choi,
Geert Uytterhoeven, Andy Shevchenko, Dmitry Torokhov, Ulf Hansson,
linux-bluetooth, linux-kernel, linux-gpio, dri-devel, linux-i2c,
linux-iio, linux-input, linux-mmc, linux-arm-kernel, linux-pm,
linux-usb
From: Arnd Bergmann <arnd@arndb.de>
Most remaining users of desc_to_gpio() only call it for printing debug
information.
Replace this with a new gpiod_name() helper that returns the
gpio_desc->name string after checking the gpio_desc pointer.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Not sure if this the way we want to take this, or if the gpio name is
an appropriate replacement in debug printk.
Since most of the callers of desc_to_gpio() and gpio_to_desc() are
otherwise in drivers that already depend on CONFIG_GPIOLIB_LEGACY and
include linux/gpio/legacy.h, only a handful of instances remain that
are otherwise in files that otherwise only use the descriptor interfaces:
arch/arm/mach-pxa/pxa27x.c: reset_gpio = desc_to_gpio(gpiod);
arch/arm/plat-orion/gpio.c: unsigned gpio = desc_to_gpio(desc);
drivers/gpio/gpio-nomadik.c: mode = nmk_prcm_gpiocr_get_mode(pctldev, desc_to_gpio(desc));
drivers/gpio/gpiolib-acpi-core.c: desc = gpio_to_desc(agpio->pin_table[pin_index]);
drivers/gpio/gpiolib-cdev.c: hte_init_line_attr(hdesc, desc_to_gpio(line->desc), flags, NULL,
drivers/gpio/gpiolib-sysfs.c: desc = gpio_to_desc(gpio);
drivers/gpio/gpiolib-sysfs.c: desc_to_gpio(desc));
drivers/gpio/gpiolib.c: trace_gpio_direction(desc_to_gpio(desc), 1, ret);
drivers/input/misc/soc_button_array.c: *gpio_ret = desc_to_gpio(desc);
drivers/pinctrl/core.c: gdev = gpiod_to_gpio_device(gpio_to_desc(gpio_num));
drivers/platform/x86/x86-android-tablets/core.c: * 2. Calling desc_to_gpio() to get an old style GPIO number for gpio-keys
drivers/soc/fsl/qe/gpio.c: gpio_num = desc_to_gpio(gpiod);
---
drivers/bluetooth/hci_intel.c | 4 ++--
drivers/extcon/extcon-rtk-type-c.c | 4 ++--
drivers/gpio/gpio-aggregator.c | 4 ++--
drivers/gpio/gpiolib.c | 13 +++++++++++++
drivers/gpu/drm/bridge/analogix/anx7625.c | 6 +++---
drivers/i2c/busses/i2c-gpio.c | 4 ++--
drivers/iio/accel/mma9551.c | 4 ++--
drivers/iio/humidity/dht11.c | 2 +-
drivers/input/touchscreen/edt-ft5x06.c | 6 +++---
drivers/input/touchscreen/hycon-hy46xx.c | 5 ++---
drivers/mmc/host/atmel-mci.c | 8 ++++----
drivers/power/supply/bq24257_charger.c | 2 +-
drivers/usb/gadget/udc/at91_udc.c | 4 ++--
include/linux/gpio/consumer.h | 8 ++++++++
14 files changed, 47 insertions(+), 27 deletions(-)
diff --git a/drivers/bluetooth/hci_intel.c b/drivers/bluetooth/hci_intel.c
index c31105b91e47..2e6ebc152bcb 100644
--- a/drivers/bluetooth/hci_intel.c
+++ b/drivers/bluetooth/hci_intel.c
@@ -1176,8 +1176,8 @@ static int intel_probe(struct platform_device *pdev)
list_add_tail(&idev->list, &intel_device_list);
mutex_unlock(&intel_device_list_lock);
- dev_info(&pdev->dev, "registered, gpio(%d)/irq(%d).\n",
- desc_to_gpio(idev->reset), idev->irq);
+ dev_info(&pdev->dev, "registered, gpio(%s)/irq(%d).\n",
+ gpiod_name(idev->reset), idev->irq);
return 0;
}
diff --git a/drivers/extcon/extcon-rtk-type-c.c b/drivers/extcon/extcon-rtk-type-c.c
index 82b60b927e41..fb57e9d7ddb6 100644
--- a/drivers/extcon/extcon-rtk-type-c.c
+++ b/drivers/extcon/extcon-rtk-type-c.c
@@ -1356,8 +1356,8 @@ static int extcon_rtk_type_c_probe(struct platform_device *pdev)
(int)PTR_ERR(gpio));
} else {
type_c->rd_ctrl_gpio_desc = gpio;
- dev_dbg(dev, "%s get rd-ctrl-gpios (id=%d) OK\n",
- __func__, desc_to_gpio(gpio));
+ dev_dbg(dev, "%s get rd-ctrl-gpios (id=%s) OK\n",
+ __func__, gpiod_name(gpio));
}
}
diff --git a/drivers/gpio/gpio-aggregator.c b/drivers/gpio/gpio-aggregator.c
index bc6699a821ee..27df680fbdbb 100644
--- a/drivers/gpio/gpio-aggregator.c
+++ b/drivers/gpio/gpio-aggregator.c
@@ -758,8 +758,8 @@ int gpiochip_fwd_desc_add(struct gpiochip_fwd *fwd, struct gpio_desc *desc,
fwd->descs[offset] = desc;
- dev_dbg(chip->parent, "%u => gpio %d irq %d\n", offset,
- desc_to_gpio(desc), gpiod_to_irq(desc));
+ dev_dbg(chip->parent, "%u => gpio %s irq %d\n", offset,
+ gpiod_name(desc), gpiod_to_irq(desc));
return 0;
}
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 1f498d6c8c68..00de24db74a5 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -4122,6 +4122,19 @@ int gpiod_set_consumer_name(struct gpio_desc *desc, const char *name)
}
EXPORT_SYMBOL_GPL(gpiod_set_consumer_name);
+/**
+ * gpiod_name() - get a name to print for a gpio descriptor
+ * @desc: gpio or NULL pointer to query
+ *
+ * Returns:
+ * The desc->name field or a dummy string for unknown GPIOs.
+ */
+const char *gpiod_name(const struct gpio_desc *desc)
+{
+ return desc ? desc->name : "(no gpio)";
+}
+EXPORT_SYMBOL_GPL(gpiod_name);
+
/**
* gpiod_is_shared() - check if this GPIO can be shared by multiple consumers
* @desc: GPIO to inspect
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c b/drivers/gpu/drm/bridge/analogix/anx7625.c
index fffcd6154c71..5dce097d4045 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -1448,9 +1448,9 @@ static void anx7625_init_gpio(struct anx7625_data *platform)
if (platform->pdata.gpio_p_on && platform->pdata.gpio_reset) {
platform->pdata.low_power_mode = 1;
- DRM_DEV_DEBUG_DRIVER(dev, "low power mode, pon %d, reset %d.\n",
- desc_to_gpio(platform->pdata.gpio_p_on),
- desc_to_gpio(platform->pdata.gpio_reset));
+ DRM_DEV_DEBUG_DRIVER(dev, "low power mode, pon %s, reset %s.\n",
+ gpiod_name(platform->pdata.gpio_p_on),
+ gpiod_name(platform->pdata.gpio_reset));
} else {
platform->pdata.low_power_mode = 0;
DRM_DEV_DEBUG_DRIVER(dev, "not low power mode.\n");
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
index f4355b17bfbf..4c320a833d9e 100644
--- a/drivers/i2c/busses/i2c-gpio.c
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -440,8 +440,8 @@ static int i2c_gpio_probe(struct platform_device *pdev)
* get accessors to get the actual name of the GPIO line,
* from the descriptor, then provide that instead.
*/
- dev_info(dev, "using lines %u (SDA) and %u (SCL%s)\n",
- desc_to_gpio(priv->sda), desc_to_gpio(priv->scl),
+ dev_info(dev, "using lines %s (SDA) and %s (SCL%s)\n",
+ gpiod_name(priv->sda), gpiod_name(priv->scl),
pdata->scl_is_output_only
? ", no clock stretching" : "");
diff --git a/drivers/iio/accel/mma9551.c b/drivers/iio/accel/mma9551.c
index 020370b0ec07..b9d1fc3caf83 100644
--- a/drivers/iio/accel/mma9551.c
+++ b/drivers/iio/accel/mma9551.c
@@ -426,8 +426,8 @@ static int mma9551_gpio_probe(struct iio_dev *indio_dev)
return ret;
}
- dev_dbg(dev, "gpio resource, no:%d irq:%d\n",
- desc_to_gpio(gpio), data->irqs[i]);
+ dev_dbg(dev, "gpio resource, no:%s irq:%d\n",
+ gpiod_name(gpio), data->irqs[i]);
}
return 0;
diff --git a/drivers/iio/humidity/dht11.c b/drivers/iio/humidity/dht11.c
index 980cb946bbf7..ca6b8c53e462 100644
--- a/drivers/iio/humidity/dht11.c
+++ b/drivers/iio/humidity/dht11.c
@@ -305,7 +305,7 @@ static int dht11_probe(struct platform_device *pdev)
dht11->irq = gpiod_to_irq(dht11->gpiod);
if (dht11->irq < 0) {
- dev_err(dev, "GPIO %d has no interrupt\n", desc_to_gpio(dht11->gpiod));
+ dev_err(dev, "GPIO %s has no interrupt\n", gpiod_name(dht11->gpiod));
return -EINVAL;
}
diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index d3b1177185a3..2d31c77614b0 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -1326,10 +1326,10 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client)
edt_ft5x06_ts_prepare_debugfs(tsdata);
dev_dbg(&client->dev,
- "EDT FT5x06 initialized: IRQ %d, WAKE pin %d, Reset pin %d.\n",
+ "EDT FT5x06 initialized: IRQ %d, WAKE pin %s, Reset pin %s.\n",
client->irq,
- tsdata->wake_gpio ? desc_to_gpio(tsdata->wake_gpio) : -1,
- tsdata->reset_gpio ? desc_to_gpio(tsdata->reset_gpio) : -1);
+ gpiod_name(tsdata->wake_gpio),
+ gpiod_name(tsdata->reset_gpio));
return 0;
}
diff --git a/drivers/input/touchscreen/hycon-hy46xx.c b/drivers/input/touchscreen/hycon-hy46xx.c
index 1513f20cbf51..797667c5dd99 100644
--- a/drivers/input/touchscreen/hycon-hy46xx.c
+++ b/drivers/input/touchscreen/hycon-hy46xx.c
@@ -528,9 +528,8 @@ static int hycon_hy46xx_probe(struct i2c_client *client)
return error;
dev_dbg(&client->dev,
- "HYCON HY46XX initialized: IRQ %d, Reset pin %d.\n",
- client->irq,
- tsdata->reset_gpio ? desc_to_gpio(tsdata->reset_gpio) : -1);
+ "HYCON HY46XX initialized: IRQ %d, Reset pin %s.\n",
+ client->irq, gpiod_name(tsdata->reset_gpio));
return 0;
}
diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
index 3b4928f5b9b2..b21820564315 100644
--- a/drivers/mmc/host/atmel-mci.c
+++ b/drivers/mmc/host/atmel-mci.c
@@ -2255,11 +2255,11 @@ static int atmci_init_slot(struct atmel_mci *host,
slot->sdio_irq = sdio_irq;
dev_dbg(&mmc->class_dev,
- "slot[%u]: bus_width=%u, detect_pin=%d, "
- "detect_is_active_high=%s, wp_pin=%d\n",
- id, slot_data->bus_width, desc_to_gpio(slot_data->detect_pin),
+ "slot[%u]: bus_width=%u, detect_pin=%s, "
+ "detect_is_active_high=%s, wp_pin=%s\n",
+ id, slot_data->bus_width, gpiod_name(slot_data->detect_pin),
str_true_false(!gpiod_is_active_low(slot_data->detect_pin)),
- desc_to_gpio(slot_data->wp_pin));
+ gpiod_name(slot_data->wp_pin));
mmc->ops = &atmci_ops;
mmc->f_min = DIV_ROUND_UP(host->bus_hz, 512);
diff --git a/drivers/power/supply/bq24257_charger.c b/drivers/power/supply/bq24257_charger.c
index 72f1bfea8d54..b756bab74eec 100644
--- a/drivers/power/supply/bq24257_charger.c
+++ b/drivers/power/supply/bq24257_charger.c
@@ -868,7 +868,7 @@ static void bq24257_pg_gpio_probe(struct bq24257_device *bq)
}
if (bq->pg)
- dev_dbg(bq->dev, "probed PG pin = %d\n", desc_to_gpio(bq->pg));
+ dev_dbg(bq->dev, "probed PG pin = %s\n", gpiod_name(bq->pg));
}
static int bq24257_fw_probe(struct bq24257_device *bq)
diff --git a/drivers/usb/gadget/udc/at91_udc.c b/drivers/usb/gadget/udc/at91_udc.c
index 5aa360ba4f03..099313604387 100644
--- a/drivers/usb/gadget/udc/at91_udc.c
+++ b/drivers/usb/gadget/udc/at91_udc.c
@@ -1896,8 +1896,8 @@ static int at91udc_probe(struct platform_device *pdev)
gpiod_to_irq(udc->board.vbus_pin),
at91_vbus_irq, 0, driver_name, udc);
if (retval) {
- DBG("request vbus irq %d failed\n",
- desc_to_gpio(udc->board.vbus_pin));
+ DBG("request vbus irq %s failed\n",
+ gpiod_name(udc->board.vbus_pin));
goto err_unprepare_iclk;
}
}
diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
index fceeefd5f893..9c91fae62f8c 100644
--- a/include/linux/gpio/consumer.h
+++ b/include/linux/gpio/consumer.h
@@ -172,6 +172,8 @@ int gpiod_set_consumer_name(struct gpio_desc *desc, const char *name);
bool gpiod_is_shared(const struct gpio_desc *desc);
+const char *gpiod_name(const struct gpio_desc *desc);
+
/* Convert between the old gpio_ and new gpiod_ interfaces */
struct gpio_desc *gpio_to_desc(unsigned gpio);
int desc_to_gpio(const struct gpio_desc *desc);
@@ -538,6 +540,12 @@ static inline bool gpiod_is_shared(const struct gpio_desc *desc)
return false;
}
+static inline const char *gpiod_name(const struct gpio_desc *desc)
+{
+ WARN_ON(desc);
+ return "(no gpio)";
+}
+
static inline struct gpio_desc *gpio_to_desc(unsigned gpio)
{
return NULL;
--
2.39.5
^ permalink raw reply related
* Re: [PATCH v2 03/17] ASoC: rockchip: rockchip_sai: #include <linux/platform_device.h> explicitly
From: Uwe Kleine-König (The Capable Hub) @ 2026-06-29 13:57 UTC (permalink / raw)
To: Mark Brown
Cc: Linus Torvalds, Greg Kroah-Hartman, Nicolas Frattaroli,
Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Heiko Stuebner,
linux-rockchip, linux-sound, linux-arm-kernel, linux-kernel
In-Reply-To: <8dcfcd10-4b9d-4775-9e23-3884b896a7b9@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 457 bytes --]
Hello Mark,
On Mon, Jun 29, 2026 at 12:17:04PM +0100, Mark Brown wrote:
> On Fri, Jun 26, 2026 at 08:00:22PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > Currently that header is only included via:
> >
> > <sound/dmaengine_pcm.h> ->
> > <sound/soc.h> ->
> > <linux/platform_device.h>
>
> Acked-by: Mark Brown <broonie@kernel.org>
You're too late for the Ack, this patch already is applied and part of
v7.2.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v11 1/7] dt-bindings: phy: document the serdes PHY on sa8255p
From: Geert Uytterhoeven @ 2026-06-29 13:51 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Vinod Koul, Giuseppe Cavallaro, Chen-Yu Tsai, Jernej Skrabec,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Shawn Guo,
Fabio Estevam, Jan Petrous, s32, Mohd Ayaan Anwar, Romain Gantois,
Magnus Damm, Maxime Ripard, Christophe Roullier,
Bartosz Golaszewski, Radu Rendec, linux-arm-msm, devicetree,
linux-kernel, netdev, linux-stm32, linux-arm-kernel, Drew Fustini,
linux-sunxi, linux-amlogic, linux-mips, imx, linux-renesas-soc,
linux-rockchip, sophgo, linux-riscv, Bartosz Golaszewski
In-Reply-To: <20260629-qcom-sa8255p-emac-v11-1-1b7fb95b51f9@oss.qualcomm.com>
Hi Bartosz,
Thanks for your patch!
On Mon, 29 Jun 2026 at 13:29, Bartosz Golaszewski
<bartosz.golaszewski@oss.qualcomm.com> wrote:
> Describe the SGMII/SerDes PHY present on the Qualcomm sa8255p platforms.
> This is essentially the same hardware as sa8775p rev3 but the PHY is
> managed by firmware over SCMI.
So why can't it be reuse the DT bindings, and be compatible with
qcom,sa8775p-dwmac-sgmii-phy?
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/qcom,sa8255p-dwmac-sgmii-phy.yaml
> + power-domains:
> + maxItems: 1
> +
> + power-domain-names:
> + items:
> + - const: serdes
> +examples:
> + - |
> + phy@8901000 {
> + compatible = "qcom,sa8255p-dwmac-sgmii-phy";
> + reg = <0x08901000 0xe10>;
> + #phy-cells = <0>;
> + power-domains = <&scmi7_dvfs 0>;
> + power-domain-names = "serdes";
Ah, this uses power-domains, while the existing bindings for
qcom,sa8775p-dwmac-sgmii-phy use a clock.
I guess the clock is the correct hardware description?
Adding to my list of examples for backing a hardware-to-SCMI remapping
driver...
> + };
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [Upstream] Re: [PATCH 2/2] arm64: dts: ti: Add support for the phyCORE-AM67x
From: Wadim Egorov @ 2026-06-29 13:57 UTC (permalink / raw)
To: Andrew Davis, Nathan Morrisson, nm, vigneshr, kristo, robh,
krzk+dt, conor+dt
Cc: linux-arm-kernel, devicetree, linux-kernel, upstream
In-Reply-To: <0aaf11b7-6043-4140-ac15-7c62f367c218@ti.com>
Hi Andrew,
On 6/25/26 11:37 PM, Andrew Davis wrote:
> On 6/25/26 11:02 AM, Nathan Morrisson wrote:
>> Add support for the PHYTEC phyCORE-AM67x SoM [1] and the
>> corresponding phyBOARD-Rigel carrier board [2]. The phyCORE-AM67x SoM
>> uses the TI AM67x SoC and can come with different sizes and models of
>> DDR, eMMC, and SPI NOR Flash.
>>
>> Supported features:
>> * Audio playback and recording
>> * CAN
>> * Debug UART
>> * eMMC
>> * Ethernet
>> * GPIO buttons
>> * Heartbeat LED
>> * I2C Current sensor
>> * I2C EEPROM
>> * I2C Light sensor
>> * I2C RTC
>> * Micro SD card
>> * PCIe
>> * SPI NOR flash
>> * USB
>>
>> [1] https://www.phytec.com/product/phycore-am67x/
>> [2] https://www.phytec.com/product/phyboard-am67x-development-kit/
>>
>> Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
>> ---
>> arch/arm64/boot/dts/ti/Makefile | 1 +
>> .../boot/dts/ti/k3-am67-phycore-som.dtsi | 328 ++++++++++++
>> .../boot/dts/ti/k3-am6754-phyboard-rigel.dts | 502 ++++++++++++++++++
>> 3 files changed, 831 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi
>> create mode 100644 arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts
>>
>> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
>> index 371f9a043fe5..623ee2369132 100644
>> --- a/arch/arm64/boot/dts/ti/Makefile
>> +++ b/arch/arm64/boot/dts/ti/Makefile
>> @@ -184,6 +184,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-pcie1-ep.dtbo
>> dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-usb0-type-a.dtbo
>> # Boards with J722s SoC
>> +dtb-$(CONFIG_ARCH_K3) += k3-am6754-phyboard-rigel.dtb
>> dtb-$(CONFIG_ARCH_K3) += k3-am67a-beagley-ai.dtb
>> dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm.dtb
>> dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm-csi2-quad-rpi-cam-imx219.dtbo
>> diff --git a/arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi b/arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi
>> new file mode 100644
>> index 000000000000..8a40f648098e
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi
>> @@ -0,0 +1,328 @@
>> +// SPDX-License-Identifier: GPL-2.0-only OR MIT
>> +/*
>> + * Copyright (C) 2026 PHYTEC America LLC
>> + * Author: Nathan Morrisson <nmorrisson@phytec.com>
>> + */
>> +
>> +#include <dt-bindings/net/ti-dp83867.h>
>> +#include <dt-bindings/leds/common.h>
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/interrupt-controller/irq.h>
>> +
>> +/ {
>> + compatible = "phytec,am67-phycore-som", "ti,j722s";
>> + model = "PHYTEC phyCORE-AM67";
>> +
>> + aliases {
>> + ethernet0 = &cpsw_port1;
>> + gpio0 = &main_gpio0;
>> + mmc0 = &sdhci0;
>> + rtc0 = &i2c_som_rtc;
>> + rtc1 = &wkup_rtc0;
>> + spi0 = &ospi0;
>> + };
>> +
>> + memory@80000000 {
>> + /* 4G RAM */
>> + reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
>> + <0x00000008 0x80000000 0x00000000 0x80000000>;
>> + device_type = "memory";
>> + bootph-all;
>> + };
>> +
>> + reserved_memory: reserved-memory {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> + secure_tfa_ddr: tfa@9e780000 {
>> + reg = <0x00 0x9e780000 0x00 0x80000>;
>> + no-map;
>> + };
>> +
>> + secure_ddr: optee@9e800000 {
>> + reg = <0x00 0x9e800000 0x00 0x01800000>;
>> + no-map;
>> + };
>> +
>> + wkup_r5fss0_core0_dma_memory_region: memory@a0000000 {
>> + compatible = "shared-dma-pool";
>> + reg = <0x00 0xa0000000 0x00 0x100000>;
>> + no-map;
>> + };
>> +
>> + wkup_r5fss0_core0_memory_region: memory@a0100000 {
>> + compatible = "shared-dma-pool";
>> + reg = <0x00 0xa0100000 0x00 0xf00000>;
>> + no-map;
>> + };
>> + };
>> +
>> + vcc_5v0_som: regulator-vcc-5v0-som {
>> + compatible = "regulator-fixed";
>> + regulator-name = "VCC_5V0_SOM";
>> + regulator-min-microvolt = <5000000>;
>> + regulator-max-microvolt = <5000000>;
>> + regulator-always-on;
>> + regulator-boot-on;
>> + };
>> +
>> + leds {
>> + compatible = "gpio-leds";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&leds_pins_default>;
>> +
>> + led-0 {
>> + color = <LED_COLOR_ID_GREEN>;
>> + gpios = <&main_gpio0 13 GPIO_ACTIVE_HIGH>;
>> + linux,default-trigger = "heartbeat";
>> + function = LED_FUNCTION_HEARTBEAT;
>> + };
>> + };
>> +};
>> +
>> +&main_pmx0 {
>> + leds_pins_default: leds-default-pins {
>> + pinctrl-single,pins = <
>> + J722S_IOPAD(0x034, PIN_OUTPUT, 7) /* (K22) OSPI0_CSN2.GPIO0_13 */
>> + >;
>> + };
>> +
>> + mdio_pins_default: mdio-default-pins {
>> + pinctrl-single,pins = <
>> + J722S_IOPAD(0x0160, PIN_OUTPUT, 0) /* (AC24) MDIO0_MDC */
>> + J722S_IOPAD(0x015c, PIN_INPUT, 0) /* (AD25) MDIO0_MDIO */
>> + >;
>> + bootph-all;
>> + };
>> +
>> + ospi0_pins_default: ospi0-default-pins {
>> + pinctrl-single,pins = <
>> + J722S_IOPAD(0x000, PIN_OUTPUT, 0) /* (L24) OSPI0_CLK */
>> + J722S_IOPAD(0x02c, PIN_OUTPUT, 0) /* (K26) OSPI0_CSn0 */
>> + J722S_IOPAD(0x00c, PIN_INPUT, 0) /* (K27) OSPI0_D0 */
>> + J722S_IOPAD(0x010, PIN_INPUT, 0) /* (L27) OSPI0_D1 */
>> + J722S_IOPAD(0x014, PIN_INPUT, 0) /* (L26) OSPI0_D2 */
>> + J722S_IOPAD(0x018, PIN_INPUT, 0) /* (L25) OSPI0_D3 */
>> + J722S_IOPAD(0x01c, PIN_INPUT, 0) /* (L21) OSPI0_D4 */
>> + J722S_IOPAD(0x020, PIN_INPUT, 0) /* (M26) OSPI0_D5 */
>> + J722S_IOPAD(0x024, PIN_INPUT, 0) /* (N27) OSPI0_D6 */
>> + J722S_IOPAD(0x028, PIN_INPUT, 0) /* (M27) OSPI0_D7 */
>> + J722S_IOPAD(0x008, PIN_INPUT, 0) /* (L22) OSPI0_DQS */
>> + J722S_IOPAD(0x038, PIN_INPUT, 7) /* (J22) OSPI0_CSn3.GPIO0_14 */
>> + >;
>> + bootph-all;
>> + };
>> +
>> + pmic_irq_pins_default: pmic-irq-default-pins {
>> + pinctrl-single,pins = <
>> + J722S_IOPAD(0x030, PIN_INPUT, 7) /* (K23) OSPI0_CSN1.GPIO0_12 */
>> + >;
>> + };
>> +
>> + rgmii1_pins_default: rgmii1-default-pins {
>> + pinctrl-single,pins = <
>> + J722S_IOPAD(0x014c, PIN_INPUT, 0) /* (AC25) RGMII1_RD0 */
>> + J722S_IOPAD(0x0150, PIN_INPUT, 0) /* (AD27) RGMII1_RD1 */
>> + J722S_IOPAD(0x0154, PIN_INPUT, 0) /* (AE24) RGMII1_RD2 */
>> + J722S_IOPAD(0x0158, PIN_INPUT, 0) /* (AE26) RGMII1_RD3 */
>> + J722S_IOPAD(0x0148, PIN_INPUT, 0) /* (AE27) RGMII1_RXC */
>> + J722S_IOPAD(0x0144, PIN_INPUT, 0) /* (AD23) RGMII1_RX_CTL */
>> + J722S_IOPAD(0x0134, PIN_OUTPUT, 0) /* (AF27) RGMII1_TD0 */
>> + J722S_IOPAD(0x0138, PIN_OUTPUT, 0) /* (AE23) RGMII1_TD1 */
>> + J722S_IOPAD(0x013c, PIN_OUTPUT, 0) /* (AG25) RGMII1_TD2 */
>> + J722S_IOPAD(0x0140, PIN_OUTPUT, 0) /* (AF24) RGMII1_TD3 */
>> + J722S_IOPAD(0x0130, PIN_OUTPUT, 0) /* (AG26) RGMII1_TXC */
>> + J722S_IOPAD(0x012c, PIN_OUTPUT, 0) /* (AF25) RGMII1_TX_CTL */
>> + >;
>> + bootph-all;
>> + };
>> +};
>> +
>> +&mcu_pmx0 {
>> + wkup_i2c0_pins_default: wkup-i2c0-default-pins {
>> + pinctrl-single,pins = <
>> + J722S_MCU_IOPAD(0x04c, PIN_INPUT_PULLUP, 0) /* (B9) WKUP_I2C0_SCL */
>> + J722S_MCU_IOPAD(0x050, PIN_INPUT_PULLUP, 0) /* (D11) WKUP_I2C0_SDA */
>> + >;
>> + bootph-all;
>> + };
>> +};
>> +
>> +&cpsw3g {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&rgmii1_pins_default>;
>> + bootph-all;
>> + status = "okay";
>> +};
>> +
>> +&cpsw3g_mdio {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mdio_pins_default>;
>> + status = "okay";
>> +
>> + cpsw3g_phy1: ethernet-phy@1 {
>> + compatible = "ethernet-phy-ieee802.3-c22";
>> + reg = <1>;
>> + ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
>> + tx-fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
>> + ti,min-output-impedance;
>> + };
>> +};
>> +
>> +&cpsw_port1 {
>> + phy-mode = "rgmii-id";
>> + phy-handle = <&cpsw3g_phy1>;
>> + status = "okay";
>> +};
>> +
>> +&cpsw_port2 {
>> + status = "disabled";
>
> This should already be default disabled in the SoC dtsi,
> no need to re-disable it here.
>
>> +};
>> +
>> +&ospi0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&ospi0_pins_default>;
>> + bootph-all;
>> + status = "okay";
>> +
>> + serial_flash: flash@0 {
>> + compatible = "jedec,spi-nor";
>> + reg = <0x0>;
>> + spi-tx-bus-width = <8>;
>> + spi-rx-bus-width = <8>;
>> + spi-max-frequency = <25000000>;
>> + vcc-supply = <&vdd_1v8>;
>> + cdns,tshsl-ns = <60>;
>> + cdns,tsd2d-ns = <60>;
>> + cdns,tchsh-ns = <60>;
>> + cdns,tslch-ns = <60>;
>> + cdns,read-delay = <0>;
>> + };
>> +};
>> +
>> +&sdhci0 {
>> + non-removable;
>> + bootph-all;
>> + ti,driver-strength-ohm = <50>;
>> + status = "okay";
>> +};
>> +
>> +&wkup_i2c0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&wkup_i2c0_pins_default>;
>> + clock-frequency = <400000>;
>> + bootph-all;
>> + status = "okay";
>> +
>> + pmic@30 {
>> + compatible = "ti,tps65219";
>> + reg = <0x30>;
>> + buck1-supply = <&vcc_5v0_som>;
>> + buck2-supply = <&vcc_5v0_som>;
>> + buck3-supply = <&vcc_5v0_som>;
>> + ldo1-supply = <&vdd_3v3>;
>> + ldo2-supply = <&vdd_1v8>;
>> + ldo3-supply = <&vdd_3v3>;
>> + ldo4-supply = <&vdd_3v3>;
>> +
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pmic_irq_pins_default>;
>> + interrupt-parent = <&main_gpio0>;
>> + interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
>> + interrupt-controller;
>> + #interrupt-cells = <1>;
>> +
>> + system-power-controller;
>> + ti,power-button;
>> +
>> + regulators {
>> + vdd_3v3: buck1 {
>> + regulator-name = "VDD_3V3";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-boot-on;
>> + regulator-always-on;
>> + };
>> +
>> + vdd_1v8: buck2 {
>> + regulator-name = "VDD_1V8";
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <1800000>;
>> + regulator-boot-on;
>> + regulator-always-on;
>> + };
>> +
>> + vdd_lpddr4: buck3 {
>> + regulator-name = "VDD_LPDDR4";
>> + regulator-min-microvolt = <1100000>;
>> + regulator-max-microvolt = <1100000>;
>> + regulator-boot-on;
>> + regulator-always-on;
>> + };
>> +
>> + vddshv_sdio: ldo1 {
>> + regulator-name = "VDDSHV_SDIO";
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-allow-bypass;
>> + regulator-boot-on;
>> + regulator-always-on;
>> + };
>> +
>> + vdd_1v2: ldo2 {
>> + regulator-name = "VDD_1V2";
>> + regulator-min-microvolt = <1200000>;
>> + regulator-max-microvolt = <1200000>;
>> + regulator-boot-on;
>> + regulator-always-on;
>> + };
>> +
>> + vdda_1v8_phy: ldo3 {
>> + regulator-name = "VDDA_1V8_PHY";
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <1800000>;
>> + regulator-boot-on;
>> + regulator-always-on;
>> + };
>> +
>> + vdd_1v8_pll: ldo4 {
>> + regulator-name = "VDD_1V8_PLL";
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <1800000>;
>> + regulator-boot-on;
>> + regulator-always-on;
>> + };
>> + };
>> + };
>> +
>> + vdd_core: regulator-vdd-core@44 {
>> + compatible = "ti,tps62873";
>> + reg = <0x44>;
>> + bootph-pre-ram;
>> + regulator-name = "VDD_CORE";
>> + regulator-min-microvolt = <850000>;
>> + regulator-max-microvolt = <850000>;
>> + regulator-boot-on;
>> + regulator-always-on;
>> + };
>> +
>> + eeprom@50 {
>> + compatible = "atmel,24c32";
>> + reg = <0x50>;
>> + pagesize = <32>;
>> + };
>> +
>> + som_eeprom_opt: eeprom@51 {
>> + compatible = "atmel,24c32";
>> + reg = <0x51>;
>> + pagesize = <32>;
>> + };
>> +
>> + i2c_som_rtc: rtc@52 {
>> + compatible = "microcrystal,rv3028";
>> + reg = <0x52>;
>> + };
>> +};
>> +
>> +#include "k3-j722s-ti-ipc-firmware.dtsi"
>> diff --git a/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts b/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts
>> new file mode 100644
>> index 000000000000..7853d4f5d3b9
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts
>> @@ -0,0 +1,502 @@
>> +// SPDX-License-Identifier: GPL-2.0-only OR MIT
>> +/*
>> + * Copyright (C) 2026 PHYTEC America LLC
>> + * Author: Nathan Morrisson <nmorrisson@phytec.com>
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include <dt-bindings/input/input.h>
>> +#include <dt-bindings/phy/phy.h>
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/interrupt-controller/irq.h>
>> +#include "k3-serdes.h"
>> +#include "k3-j722s.dtsi"
>
> This should be included by the som.dtsi, keeps the include chain sane.
I think we always included the soc.dtsi on carrier-board level. As far as I remember the idea was to keep the option open for SoM/CB combinations using a different SoC variant from the j722s family. E.g. if in the future there will be a need for different soc.dtsi which is not j722s. But since most variants are now handled by u-boot/dt fixups, it does not really matter anymore.
Regards,
Wadim
>
> Andrew
>
>> +#include "k3-am67-phycore-som.dtsi"
>> +
>> +/ {
>> + compatible = "phytec,am6754-phyboard-rigel",
>> + "phytec,am67-phycore-som", "ti,j722s";
>> + model = "PHYTEC phyBOARD-Rigel AM67";
>> +
>> + aliases {
>> + gpio1 = &main_gpio1;
>> + mmc1 = &sdhci1;
>> + serial2 = &main_uart0;
>> + usb0 = &usb0;
>> + usb1 = &usb1;
>> + };
>> +
>> + can_tc0: can-phy0 {
>> + compatible = "ti,tcan1042";
>> + #phy-cells = <0>;
>> + max-bitrate = <8000000>;
>> + standby-gpios = <&gpio_exp1 1 GPIO_ACTIVE_HIGH>;
>> + };
>> +
>> + usb0_connector: connector {
>> + compatible = "gpio-usb-b-connector", "usb-b-connector";
>> + label = "USB-C";
>> + data-role = "dual";
>> +
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&main_usbc_power_pins_default>;
>> +
>> + id-gpios = <&main_gpio1 15 GPIO_ACTIVE_HIGH>;
>> +
>> + port {
>> + usb0_con: endpoint {
>> + remote-endpoint = <&usb0_ep>;
>> + };
>> + };
>> + };
>> +
>> + keys {
>> + compatible = "gpio-keys";
>> + autorepeat;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&gpio_keys_pins_default>;
>> +
>> + key-home {
>> + label = "home";
>> + linux,code = <KEY_HOME>;
>> + gpios = <&main_gpio1 23 GPIO_ACTIVE_HIGH>;
>> + };
>> +
>> + key-menu {
>> + label = "menu";
>> + linux,code = <KEY_MENU>;
>> + gpios = <&gpio_exp1 4 GPIO_ACTIVE_HIGH>;
>> + };
>> + };
>> +
>> + pcie_refclk0: pcie-refclk0 {
>> + compatible = "gpio-gate-clock";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&main_pcie_usb_sel_pins_default>;
>> + clocks = <&serdes_refclk>;
>> + #clock-cells = <0>;
>> + enable-gpios = <&main_gpio0 22 GPIO_ACTIVE_LOW>;
>> + };
>> +
>> + vcc_1v8: regulator-vcc-1v8 {
>> + compatible = "regulator-fixed";
>> + regulator-name = "VCC_1V8";
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <1800000>;
>> + regulator-always-on;
>> + regulator-boot-on;
>> + };
>> +
>> + vcc_3v3_aud: regulator-vcc-3v3-aud {
>> + compatible = "regulator-fixed";
>> + regulator-name = "VCC_3V3_AUD";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-always-on;
>> + regulator-boot-on;
>> + };
>> +
>> + vcc_3v3_mmc: regulator-vcc-3v3-mmc {
>> + /* TPS22963C OUTPUT */
>> + compatible = "regulator-fixed";
>> + regulator-name = "VCC_3V3_MMC";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-always-on;
>> + regulator-boot-on;
>> + };
>> +
>> + vcc_3v3_sw: regulator-vcc-3v3-sw {
>> + compatible = "regulator-fixed";
>> + regulator-name = "VCC_3V3_SW";
>> + regulator-min-microvolt = <3300000>;
>> + regulator-max-microvolt = <3300000>;
>> + regulator-always-on;
>> + regulator-boot-on;
>> + };
>> +
>> + vcc_speaker: regulator-vcc-speaker {
>> + compatible = "regulator-fixed";
>> + regulator-name = "VCC_SPEAKER";
>> + regulator-min-microvolt = <5000000>;
>> + regulator-max-microvolt = <5000000>;
>> + regulator-always-on;
>> + regulator-boot-on;
>> + };
>> +
>> + sound {
>> + compatible = "simple-audio-card";
>> + simple-audio-card,widgets =
>> + "Microphone", "Mic Jack",
>> + "Headphone", "Headphone Jack",
>> + "Line", "Stereo Jack",
>> + "Speaker", "L SPKR",
>> + "Speaker", "R SPKR";
>> + simple-audio-card,routing =
>> + "MIC1RP", "Mic Jack",
>> + "Mic Jack", "MICBIAS",
>> + "Headphone Jack", "HPL",
>> + "Headphone Jack", "HPR",
>> + "MIC1LM", "Stereo Jack",
>> + "MIC1LP", "Stereo Jack",
>> + "SPL", "L SPKR",
>> + "SPR", "R SPKR";
>> + simple-audio-card,name = "phyBOARD-Rigel";
>> + simple-audio-card,format = "dsp_b";
>> + simple-audio-card,bitclock-master = <&sound_master>;
>> + simple-audio-card,frame-master = <&sound_master>;
>> + simple-audio-card,bitclock-inversion;
>> +
>> + simple-audio-card,cpu {
>> + sound-dai = <&mcasp0>;
>> + };
>> +
>> + sound_master: simple-audio-card,codec {
>> + sound-dai = <&audio_codec>;
>> + clocks = <&audio_refclk1>;
>> + };
>> + };
>> +};
>> +
>> +&main_pmx0 {
>> + audio_ext_refclk1_pins_default: audio-ext-refclk1-default-pins {
>> + pinctrl-single,pins = <
>> + J722S_IOPAD(0x0a0, PIN_OUTPUT, 1) /* (N24) GPMC0_WPn.AUDIO_EXT_REFCLK1 */
>> + >;
>> + };
>> +
>> + gpio_exp0_int_pins_default: gpio-exp0-int-default-pins {
>> + pinctrl-single,pins = <
>> + J722S_IOPAD(0x0054, PIN_INPUT, 7) /* (T21) GPMC0_AD6.GPIO0_21 */
>> + >;
>> + };
>> +
>> + gpio_exp1_int_pins_default: gpio-exp1-int-default-pins {
>> + pinctrl-single,pins = <
>> + J722S_IOPAD(0x0244, PIN_INPUT, 7) /* (A24) MMC1_SDWP.GPIO1_49 */
>> + >;
>> + };
>> +
>> + gpio_exp2_int_pins_default: gpio-exp2-int-default-pins {
>> + pinctrl-single,pins = <
>> + J722S_IOPAD(0x0050, PIN_INPUT, 7) /* (T24) GPMC0_AD5.GPIO0_20 */
>> + >;
>> + };
>> +
>> + gpio_keys_pins_default: gpio-keys-default-pins {
>> + pinctrl-single,pins = <
>> + J722S_IOPAD(0x01d4, PIN_INPUT, 7) /* (B21) UART0_RTSn.GPIO1_23 */
>> + >;
>> + };
>> +
>> + main_i2c0_pins_default: main-i2c0-default-pins {
>> + pinctrl-single,pins = <
>> + J722S_IOPAD(0x01e0, PIN_INPUT_PULLUP, 0) /* (D23) I2C0_SCL */
>> + J722S_IOPAD(0x01e4, PIN_INPUT_PULLUP, 0) /* (B22) I2C0_SDA */
>> + >;
>> + bootph-all;
>> + };
>> +
>> + main_i2c1_pins_default: main-i2c1-default-pins {
>> + pinctrl-single,pins = <
>> + J722S_IOPAD(0x01e8, PIN_INPUT_PULLUP, 0) /* (C24) I2C1_SCL */
>> + J722S_IOPAD(0x01ec, PIN_INPUT_PULLUP, 0) /* (A22) I2C1_SDA */
>> + >;
>> + bootph-all;
>> + };
>> +
>> + main_mcan0_pins_default: main-mcan0-default-pins {
>> + pinctrl-single,pins = <
>> + J722S_IOPAD(0x1dc, PIN_INPUT, 0) /* (C22) MCAN0_RX */
>> + J722S_IOPAD(0x1d8, PIN_OUTPUT, 0) /* (D22) MCAN0_TX */
>> + >;
>> + };
>> +
>> + main_mcasp0_pins_default: main-mcasp0-default-pins {
>> + pinctrl-single,pins = <
>> + J722S_IOPAD(0x1a8, PIN_INPUT, 0) /* (C26) MCASP0_AFSX */
>> + J722S_IOPAD(0x1a4, PIN_INPUT, 0) /* (D25) MCASP0_ACLKX */
>> + J722S_IOPAD(0x198, PIN_OUTPUT, 0) /* (A26) MCASP0_AXR2 */
>> + J722S_IOPAD(0x194, PIN_INPUT, 0) /* (A25) MCASP0_AXR3 */
>> + >;
>> + };
>> +
>> + main_mcasp1_pins_default: main-mcasp1-default-pins {
>> + pinctrl-single,pins = <
>> + J722S_IOPAD(0x0090, PIN_INPUT, 2) /* (P27) GPMC0_BE0n_CLE.MCASP1_ACLKX */
>> + J722S_IOPAD(0x0098, PIN_INPUT, 2) /* (V21) GPMC0_WAIT0.MCASP1_AFSX */
>> + J722S_IOPAD(0x008c, PIN_OUTPUT, 2) /* (N23) GPMC0_WEn.MCASP1_AXR0 */
>> + >;
>> + };
>> +
>> + main_mmc1_pins_default: main-mmc1-default-pins {
>> + pinctrl-single,pins = <
>> + J722S_IOPAD(0x023c, PIN_INPUT, 0) /* (H22) MMC1_CMD */
>> + J722S_IOPAD(0x0234, PIN_INPUT, 0) /* (H24) MMC1_CLK */
>> + J722S_IOPAD(0x0230, PIN_INPUT, 0) /* (H23) MMC1_DAT0 */
>> + J722S_IOPAD(0x022c, PIN_INPUT, 0) /* (H20) MMC1_DAT1 */
>> + J722S_IOPAD(0x0228, PIN_INPUT, 0) /* (J23) MMC1_DAT2 */
>> + J722S_IOPAD(0x0224, PIN_INPUT, 0) /* (H25) MMC1_DAT3 */
>> + J722S_IOPAD(0x0240, PIN_INPUT, 0) /* (B24) MMC1_SDCD */
>> + >;
>> + bootph-all;
>> + };
>> +
>> + main_pcie_pins_default: main-pcie-default-pins {
>> + pinctrl-single,pins = <
>> + J722S_IOPAD(0x07c, PIN_INPUT, 7) /* (T23) GPMC0_CLK.GPIO0_31 */
>> + >;
>> + };
>> +
>> + main_pcie_usb_sel_pins_default: main-pcie-usb-sel-default-pins {
>> + pinctrl-single,pins = <
>> + J722S_IOPAD(0x058, PIN_INPUT, 7) /* (T22) GPMC0_AD7.GPIO0_22 */
>> + >;
>> + };
>> +
>> + main_uart0_pins_default: main-uart0-default-pins {
>> + pinctrl-single,pins = <
>> + J722S_IOPAD(0x01c8, PIN_INPUT, 0) /* (F19) UART0_RXD */
>> + J722S_IOPAD(0x01cc, PIN_OUTPUT, 0) /* (F20) UART0_TXD */
>> + >;
>> + bootph-all;
>> + };
>> +
>> + main_usbc_power_pins_default: main-usbc-power-default-pins {
>> + pinctrl-single,pins = <
>> + J722S_IOPAD(0x1b4, PIN_INPUT, 7) /* (B20) SPI0_CS0.GPIO1_15 */
>> + >;
>> + };
>> +};
>> +
>> +&audio_refclk1 {
>> + assigned-clock-rates = <25000000>;
>> +};
>> +
>> +&main_i2c0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&main_i2c0_pins_default>;
>> + clock-frequency = <400000>;
>> + status = "okay";
>> +
>> + veml6030: light-sensor@10 {
>> + compatible = "vishay,veml6030";
>> + reg = <0x10>;
>> + vdd-supply = <&vcc_3v3_sw>;
>> + };
>> +};
>> +
>> +&main_i2c1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&main_i2c1_pins_default>;
>> + clock-frequency = <100000>;
>> + status = "okay";
>> +
>> + audio_codec: audio-codec@18 {
>> + compatible = "ti,tlv320aic3110";
>> + reg = <0x18>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&audio_ext_refclk1_pins_default>;
>> + #sound-dai-cells = <0>;
>> + ai3xx-micbias-vg = <2>;
>> + reset-gpios = <&gpio_exp1 7 GPIO_ACTIVE_LOW>;
>> +
>> + HPVDD-supply = <&vcc_3v3_aud>;
>> + SPRVDD-supply = <&vcc_speaker>;
>> + SPLVDD-supply = <&vcc_speaker>;
>> + AVDD-supply = <&vcc_3v3_aud>;
>> + IOVDD-supply = <&vcc_3v3_aud>;
>> + DVDD-supply = <&vcc_1v8>;
>> + };
>> +
>> + gpio_exp0: gpio@20 {
>> + compatible = "nxp,pcf8574";
>> + reg = <0x20>;
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&gpio_exp0_int_pins_default>;
>> + interrupt-parent = <&main_gpio0>;
>> + interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
>> + gpio-line-names = "CSI3_STROBE", "CSI3_TRIGGER",
>> + "CSI3_SHUTTER", "CSI3_OE",
>> + "CSI2_STROBE", "CSI2_TRIGGER",
>> + "CSI2_SHUTTER", "CSI2_OE";
>> + };
>> +
>> + gpio_exp1: gpio@21 {
>> + compatible = "nxp,pcf8574";
>> + reg = <0x21>;
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&gpio_exp1_int_pins_default>;
>> + interrupt-parent = <&main_gpio1>;
>> + interrupts = <49 IRQ_TYPE_LEVEL_LOW>;
>> + gpio-line-names = "GPIO0_HDMI_RST", "GPIO1_CAN_nEN",
>> + "GPIO2_LED", "GPIO3_MCU_CAN0_nEN",
>> + "GPIO4_BUT2", "GPIO5_MCU_CAN1_nEN",
>> + "GPIO6_AUDIO_GPIO", "GPIO7_AUDIO_USER_RESET";
>> + };
>> +
>> + gpio_exp2: gpio@23 {
>> + compatible = "nxp,pcf8574";
>> + reg = <0x23>;
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&gpio_exp2_int_pins_default>;
>> + interrupt-parent = <&main_gpio0>;
>> + interrupts = <20 IRQ_TYPE_LEVEL_LOW>;
>> + gpio-line-names = "CSI1_STROBE", "CSI1_TRIGGER",
>> + "CSI1_SHUTTER", "CSI1_OE",
>> + "CSI0_STROBE", "CSI0_TRIGGER",
>> + "CSI0_SHUTTER", "CSI0_OE";
>> + };
>> +
>> + current-sensor@40 {
>> + compatible = "ti,ina233";
>> + reg = <0x40>;
>> + shunt-resistor = <18000>;
>> + };
>> +
>> + eeprom@51 {
>> + compatible = "atmel,24c02";
>> + reg = <0x51>;
>> + pagesize = <16>;
>> + };
>> +};
>> +
>> +&main_mcan0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&main_mcan0_pins_default>;
>> + phys = <&can_tc0>;
>> + status = "okay";
>> +};
>> +
>> +&main_uart0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&main_uart0_pins_default>;
>> + bootph-all;
>> + status = "okay";
>> +};
>> +
>> +&mcasp0 {
>> + #sound-dai-cells = <0>;
>> + op-mode = <0>; /* MCASP_IIS_MODE */
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&main_mcasp0_pins_default>;
>> + tdm-slots = <2>;
>> + serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
>> + 0 0 1 2
>> + 0 0 0 0
>> + 0 0 0 0
>> + 0 0 0 0
>> + >;
>> + status = "okay";
>> +};
>> +
>> +&mcasp1 {
>> + #sound-dai-cells = <0>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&main_mcasp1_pins_default>;
>> + op-mode = <0>; /* MCASP_IIS_MODE */
>> + tdm-slots = <2>;
>> + serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
>> + 1 0 2 0
>> + 0 0 0 0
>> + 0 0 0 0
>> + 0 0 0 0
>> + >;
>> + status = "okay";
>> +};
>> +
>> +&pcie0_rc {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&main_pcie_pins_default>;
>> + num-lanes = <1>;
>> + phys = <&serdes1_pcie_link>;
>> + phy-names = "pcie-phy";
>> + reset-gpios = <&main_gpio0 31 GPIO_ACTIVE_HIGH>;
>> + status = "okay";
>> +};
>> +
>> +&sdhci1 {
>> + /* SD/MMC */
>> + vmmc-supply = <&vcc_3v3_mmc>;
>> + vqmmc-supply = <&vddshv_sdio>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&main_mmc1_pins_default>;
>> + disable-wp;
>> + no-1-8-v;
>> + bootph-all;
>> + status = "okay";
>> +};
>> +
>> +&serdes_ln_ctrl {
>> + idle-states = <J722S_SERDES0_LANE0_USB>,
>> + <J722S_SERDES1_LANE0_PCIE0_LANE0>;
>> +};
>> +
>> +&serdes0 {
>> + status = "okay";
>> +
>> + serdes0_usb_link: phy@0 {
>> + reg = <0>;
>> + cdns,num-lanes = <1>;
>> + #phy-cells = <0>;
>> + cdns,phy-type = <PHY_TYPE_USB3>;
>> + resets = <&serdes_wiz0 1>;
>> + };
>> +};
>> +
>> +&serdes_wiz0 {
>> + status = "okay";
>> +};
>> +
>> +&serdes1 {
>> + status = "okay";
>> +
>> + serdes1_pcie_link: phy@0 {
>> + reg = <0>;
>> + cdns,num-lanes = <1>;
>> + #phy-cells = <0>;
>> + cdns,phy-type = <PHY_TYPE_PCIE>;
>> + resets = <&serdes_wiz1 1>;
>> + };
>> +};
>> +
>> +&serdes_wiz1 {
>> + clocks = <&k3_clks 280 0>, <&k3_clks 280 1>, <&pcie_refclk0>;
>> + status = "okay";
>> +};
>> +
>> +&usbss0 {
>> + ti,vbus-divider;
>> + status = "okay";
>> +};
>> +
>> +&usb0 {
>> + dr_mode = "otg";
>> + usb-role-switch;
>> + maximum-speed = "high-speed";
>> +
>> + port {
>> + usb0_ep: endpoint {
>> + remote-endpoint = <&usb0_con>;
>> + };
>> + };
>> +};
>> +
>> +&usbss1 {
>> + ti,vbus-divider;
>> + status = "okay";
>> +};
>> +
>> +&usb1 {
>> + dr_mode = "host";
>> + phys = <&serdes0_usb_link>;
>> + phy-names = "cdns3,usb3-phy";
>> + maximum-speed = "super-speed";
>> +};
>
> _______________________________________________
> upstream mailing list -- upstream@lists.phytec.de
> To unsubscribe send an email to upstream-leave@lists.phytec.de
^ 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