* Re: (subset) [PATCH V14 00/12] pci-imx6: Add support for parsing the reset property in new Root Port binding
From: Frank Li @ 2026-05-13 18:56 UTC (permalink / raw)
To: Sherry Sun
Cc: Manivannan Sadhasivam, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com, lpieralisi@kernel.org,
kwilczynski@kernel.org, bhelgaas@google.com, Hongxing Zhu,
l.stach@pengutronix.de, imx@lists.linux.dev,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <VI0PR04MB121148EDDDA11C03C57EB4D3B92062@VI0PR04MB12114.eurprd04.prod.outlook.com>
On Wed, May 13, 2026 at 02:01:57AM +0000, Sherry Sun wrote:
> > Subject: Re: (subset) [PATCH V14 00/12] pci-imx6: Add support for parsing the
> > reset property in new Root Port binding
> >
> >
> > On Wed, 22 Apr 2026 17:35:37 +0800, Sherry Sun wrote:
> > > This patch set adds support for parsing the reset property in new Root
> > > Port binding in pci-imx6 driver, similar to the implementation in the
> > > qcom pcie driver[1].
> > >
> > > Also introduce generic helper functions to parse Root Port device tree
> > > nodes and extract common properties like reset GPIOs. This allows
> > > multiple PCI host controller drivers to share the same parsing logic.
> > >
> > > [...]
> >
> > Applied, thanks!
> >
> > [01/12] dt-bindings: PCI: fsl,imx6q-pcie: Add reset GPIO in Root Port node
> > commit: 556c5f7aa06d3e8119d35f40b6602d3a547cef9e
> > [02/12] PCI: host-generic: Add common helpers for parsing Root Port
> > properties
> > commit: 6cfd1e2fae1bbaa9258794ba9f3128afb752245c
> > [03/12] PCI: imx6: Assert PERST# before enabling regulators
> > commit: 97eacf72d1754eeff8624114074929606fc3f2bb
> > [04/12] PCI: imx6: Add support for parsing the reset property in new Root
> > Port binding
> > commit: 40b7f61a1a4d7fd18188f3f87e15ff5a90ce1d31
> >
>
> Hi Frank,
> Can you please help pick the remaining imx dts patches, thanks!
Thanks for reminder, please wait for few days to let it appeared linux-next.
Frank
>
> Best Regards
> Sherry
^ permalink raw reply
* Re: [PATCH v2 6/8] PCI: aardvark: Add 100 ms delay after link training
From: Pali Rohár @ 2026-05-13 18:54 UTC (permalink / raw)
To: Hans Zhang
Cc: bhelgaas, lpieralisi, kwilczynski, mani, vigneshr, jingoohan1,
thomas.petazzoni, ryder.lee, jianjun.wang, claudiu.beznea.uj,
mpillai, robh, s-vadapalli, linux-omap, linux-arm-kernel,
linux-mediatek, linux-renesas-soc, linux-pci, linux-kernel
In-Reply-To: <15532890-ce22-4b20-96d9-e7f7c47050d2@163.com>
On Wednesday 13 May 2026 15:34:46 Hans Zhang wrote:
> On 5/13/26 15:20, Pali Rohár wrote:
> > On Wednesday 13 May 2026 15:00:04 Hans Zhang wrote:
> > >
> > >
> > > On 5/13/26 05:25, Pali Rohár wrote:
> > > > On Wednesday 06 May 2026 23:23:44 Hans Zhang wrote:
> > > > > The Aardvark PCIe controller driver waits for the link to come up but
> > > > > does not implement the mandatory 100 ms delay after link training
> > > > > completes for speeds greater than 5.0 GT/s (PCIe r6.0 sec 6.6.1).
> > > > >
> > > > > The driver already maintains a 'link_gen' field that holds the negotiated
> > > > > link speed. Use it together with pcie_wait_after_link_train() to insert
> > > > > the required delay immediately after confirming that the link is up.
> > > > >
> > > > > Signed-off-by: Hans Zhang <18255117159@163.com>
> > > > > ---
> > > > > drivers/pci/controller/pci-aardvark.c | 4 +++-
> > > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/pci/controller/pci-aardvark.c b/drivers/pci/controller/pci-aardvark.c
> > > > > index e34bea1ff0ac..526351c21c49 100644
> > > > > --- a/drivers/pci/controller/pci-aardvark.c
> > > > > +++ b/drivers/pci/controller/pci-aardvark.c
> > > > > @@ -350,8 +350,10 @@ static int advk_pcie_wait_for_link(struct advk_pcie *pcie)
> > > > > /* check if the link is up or not */
> > > > > for (retries = 0; retries < LINK_WAIT_MAX_RETRIES; retries++) {
> > > > > - if (advk_pcie_link_up(pcie))
> > > > > + if (advk_pcie_link_up(pcie)) {
> > > > > + pcie_wait_after_link_train(pcie->link_gen);
> > > > > return 0;
> > > > > + }
> > > > > usleep_range(LINK_WAIT_USLEEP_MIN, LINK_WAIT_USLEEP_MAX);
> > > > > }
> > > > > --
> > > > > 2.34.1
> > > > >
> > > >
> > > > Are you sure that this is correct to do? Have you checked the A3720
> > > > Functional Specification which describes how to bring PCIe link up?
> > > >
> > > > A3720 PCIe controller is buggy and needs more timing hacks to make it
> > > > behave. Playing with random sleeps can break its internal logic.
> > > > I'm not sure if it could be safe without proper testing.
> > > >
> > > > And IIRC A3720 PCIe controller is just PCIe2.0 with 5 GT/s.
> > >
> > >
> > > Hi Pali,
> > >
> > > 1. This driver does not support A3720.
> > >
> > > static const struct of_device_id advk_pcie_of_match_table[] = {
> > > { .compatible = "marvell,armada-3700-pcie", },
> > > {},
> > > };
> > > MODULE_DEVICE_TABLE(of, advk_pcie_of_match_table);
> > >
> > > If you need support for A3720, please submit the corresponding patch so that
> > > Bjorn and Mani can review it.
> >
> > 3700 (or 37xx) is family and covers both a3710 and a3720. In most cases is the
> > a3720 dominant and hence identifiers 3700 and 3720 are begin mixed.
> >
> > >
> > > 2. If A3720 only supports GEN2, you can configure "max-link-speed" to be 2
> > > in the DT. This will not affect the functionality of this patch.
> >
> > Whole A37xx supports only GEN2. And in DT files for 37xx should be
> > already there max-link-speed.
> >
> > Seems that in advk_pcie_of_match_table there is no GEN3 device
> > specified.
> >
>
> Hi Pali,
>
> However, I saw many GEN3 assignments and conditions in the code.
>
> ret = of_pci_get_max_link_speed(dev->of_node);
> if (ret <= 0 || ret > 3)
> pcie->link_gen = 3;
> else
> pcie->link_gen = ret;
>
>
> static void advk_pcie_train_link(struct advk_pcie *pcie)
> {
> struct device *dev = &pcie->pdev->dev;
> u32 reg;
> int ret;
>
> /*
> * Setup PCIe rev / gen compliance based on device tree property
> * 'max-link-speed' which also forces maximal link speed.
> */
> reg = advk_readl(pcie, PCIE_CORE_CTRL0_REG);
> reg &= ~PCIE_GEN_SEL_MSK;
> if (pcie->link_gen == 3)
> reg |= SPEED_GEN_3;
> else if (pcie->link_gen == 2)
> reg |= SPEED_GEN_2;
> else
> reg |= SPEED_GEN_1;
> advk_writel(pcie, reg, PCIE_CORE_CTRL0_REG);
>
> /*
> * Set maximal link speed value also into PCIe Link Control 2 register.
> * Armada 3700 Functional Specification says that default value is based
> * on SPEED_GEN but tests showed that default value is always 8.0 GT/s.
> */
> reg = advk_readl(pcie, PCIE_CORE_PCIEXP_CAP + PCI_EXP_LNKCTL2);
> reg &= ~PCI_EXP_LNKCTL2_TLS;
> if (pcie->link_gen == 3)
> reg |= PCI_EXP_LNKCTL2_TLS_8_0GT;
> else if (pcie->link_gen == 2)
> reg |= PCI_EXP_LNKCTL2_TLS_5_0GT;
> else
> reg |= PCI_EXP_LNKCTL2_TLS_2_5GT;
> advk_writel(pcie, reg, PCIE_CORE_PCIEXP_CAP + PCI_EXP_LNKCTL2);
>
> ....
>
>
> If you are certain about the relevant information. Is it understandable that
> we need to delete the code related to GEN3?
Ok. So some explanation. pci-aardvark.c is implementing driver for PCIe
controller with codename aardvark. I have no idea from what this
codename comes and what is represents. What we know that the driver was
written for A37xx SoC platform according to A37xx functional specification.
As it is common in SoC world, vendors just buy some IP and integrate it
into SoC. In this case Marvell bought this PCIe controller IP and
integrated it into the A37xx. In past I tried to investigate what it
could be and IIRC my assumption was that it was PCIe IP from Denali.
Denali was acquired by Cadence, and when I compared Cadence PCIe
controller registers and PCIe controller registers in A37xx functional
specification there were large overlap. For me it looked like new
Cadence PCIe controller is an evolution (or new version) of what is in
A37xx. So this was some confirmation of my theory. Linux kernel has
separate driver for PCIe controller from Cadence and for refactoring
there were ideas to merge these two drivers... But there were more
important things, fix issues related to A37xx PCIe, lot of changes
which address these issues were sent to the list but they were not
taken. I do not think that it makes sense to do refactoring or doing any
other changes before addressing any existing issues with these
drivers (like PCIe card is not working correctly).
There are reported more HW erratas for this PCIe controller which needs
to be addressed in the software (meaning in Linux kernel) to make PCIe
card working properly. And there are more design HW decision which needs
does not conform to the PCIe specification and those deviations needs to
be "fixed" or "adjusted" in software (meaning in pci-aardvark.c driver)
to make PCI/PCIe compatible drivers to work correctly.
Now about GEN3. From register allocation it looks like that PCIe IP
supports GEN3. A37xx does not support it (or at least officially). This
does not mean that there cannot be some SoC with this "aardvark" PCIe IP
that is GEN3 capable. Just we see that such SoC is not supported by Linux.
Also as the comment in above code says, by default the speed is reported
as 8.0 GT/s, so changing it to 5.0 GT/s or 2.5 GT/s is needed as so code
some parts of GEN3 code in the driver is needed.
Does it makes sense to remove it? Does it makes sense to spend time on
such thing which does not address any existing issue? For me not.
Because it does not fix any _real_ issue with existing PCIe cards. And
for refactoring it is better to merge drivers as explained above and
IIRC cadence driver has HW on which is GEN3 used.
Now about your change. If you are sure that pcie_wait_after_link_train()
function is noop for pcie->link_gen == 2 || pcie->link_gen == 1 then go
ahead, I have no objects. I have not looked deeply at the change. I just
spotted some change which is touching timing critical code path which
was problematic in the past and broke many wifi cards. So I'm really
careful to prevent breaking Linux support again.
As maintainers decided to not take any new changes from me for this
driver, I have no motivation to prepare any new changes. I will rather
spend my free time on something which will make sense and not be wasting
of my free time.
>
> Best regards,
> Hans
>
>
> > > 3. This patch is a common delay requirement stipulated by the PCIe
> > > specification. If it is greater than GEN2, then msleep(100) will be added;
> > > otherwise, there will be no such delay.
> > >
> > > 4. For instance, we often come across the situation where some common APIs
> > > are modified, and in many cases, their functionality does not require the
> > > actual development board for verification. I believe that many other
> > > developers and maintainers have modified different parts of the code. For
> > > example, the recent submission:
> >
> > Switching one API to another is one thing. But changing code which looks
> > to be critical, specially when it is known that hw has bugs, can cause
> > breaking of existing boards.
> >
> > > commit 750277048afe7ce8ebfc0b120de7dfbc745058a7
> > > Author: Nam Cao <namcao@linutronix.de>
> > > Date: Thu Jun 26 16:47:53 2025 +0200
> > >
> > > PCI: aardvark: Switch to msi_create_parent_irq_domain()
> > >
> > > Switch to msi_create_parent_irq_domain() from
> > > pci_msi_create_irq_domain()
> > > which was using legacy MSI domain setup.
> > >
> > >
> > > And many controller drivers have been modified.
> > >
> > >
> > > Best regards,
> > > Hans
> > >
> > >
>
^ permalink raw reply
* [PATCH RESEND v3 1/6] drm/connector: report IRQ_HPD events to drm_connector_oob_hotplug_event()
From: Dmitry Baryshkov @ 2026-05-13 18:23 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Heikki Krogerus, Greg Kroah-Hartman, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Adrien Grassein, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Tomi Valkeinen,
Bjorn Andersson, Konrad Dybcio, Pengyu Luo, Nikita Travkin,
Yongxing Mou
Cc: dri-devel, linux-kernel, linux-usb, intel-gfx, intel-xe,
linux-amlogic, linux-arm-kernel, linux-arm-msm, freedreno,
Dmitry Baryshkov
In-Reply-To: <20260513-hpd-irq-events-v3-0-086857017f16@oss.qualcomm.com>
The DisplayPort standard defines a special kind of events called IRQ.
These events are used to notify DP Source about the events on the Sink
side. It is extremely important for DP MST handling, where the MST
events are reported through this IRQ.
In case of the USB-C DP AltMode there is no actual HPD pulse, but the
events are ported through the bits in the AltMode VDOs.
Extend the drm_connector_oob_hotplug_event() interface and report IRQ
events to the DisplayPort Sink drivers.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/gpu/drm/drm_connector.c | 5 ++++-
drivers/usb/typec/altmodes/displayport.c | 15 +++++++++++----
include/drm/drm_connector.h | 19 ++++++++++++++++++-
3 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 47dc53c4a738..edee9daccd51 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -3510,6 +3510,8 @@ struct drm_connector *drm_connector_find_by_fwnode(struct fwnode_handle *fwnode)
* drm_connector_oob_hotplug_event - Report out-of-band hotplug event to connector
* @connector_fwnode: fwnode_handle to report the event on
* @status: hot plug detect logical state
+ * @extra_status: additional information provided by the sink without changing
+ * the HPD state (or in addition to such a change).
*
* On some hardware a hotplug event notification may come from outside the display
* driver / device. An example of this is some USB Type-C setups where the hardware
@@ -3520,7 +3522,8 @@ struct drm_connector *drm_connector_find_by_fwnode(struct fwnode_handle *fwnode)
* a drm_connector reference through calling drm_connector_find_by_fwnode().
*/
void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
- enum drm_connector_status status)
+ enum drm_connector_status status,
+ enum drm_connector_status_extra extra_status)
{
struct drm_connector *connector;
diff --git a/drivers/usb/typec/altmodes/displayport.c b/drivers/usb/typec/altmodes/displayport.c
index 35d9c3086990..7182a8e2e710 100644
--- a/drivers/usb/typec/altmodes/displayport.c
+++ b/drivers/usb/typec/altmodes/displayport.c
@@ -189,7 +189,9 @@ static int dp_altmode_status_update(struct dp_altmode *dp)
} else {
drm_connector_oob_hotplug_event(dp->connector_fwnode,
hpd ? connector_status_connected :
- connector_status_disconnected);
+ connector_status_disconnected,
+ (hpd && irq_hpd) ? DRM_CONNECTOR_DP_IRQ_HPD :
+ DRM_CONNECTOR_NO_EXTRA_STATUS);
dp->hpd = hpd;
sysfs_notify(&dp->alt->dev.kobj, "displayport", "hpd");
if (hpd && irq_hpd) {
@@ -212,7 +214,10 @@ static int dp_altmode_configured(struct dp_altmode *dp)
*/
if (dp->pending_hpd) {
drm_connector_oob_hotplug_event(dp->connector_fwnode,
- connector_status_connected);
+ connector_status_connected,
+ dp->pending_irq_hpd ?
+ DRM_CONNECTOR_DP_IRQ_HPD :
+ DRM_CONNECTOR_NO_EXTRA_STATUS);
sysfs_notify(&dp->alt->dev.kobj, "displayport", "hpd");
dp->pending_hpd = false;
if (dp->pending_irq_hpd) {
@@ -397,7 +402,8 @@ static int dp_altmode_vdm(struct typec_altmode *alt,
dp->data.conf = 0;
if (dp->hpd) {
drm_connector_oob_hotplug_event(dp->connector_fwnode,
- connector_status_disconnected);
+ connector_status_disconnected,
+ DRM_CONNECTOR_NO_EXTRA_STATUS);
dp->hpd = false;
sysfs_notify(&dp->alt->dev.kobj, "displayport", "hpd");
}
@@ -827,7 +833,8 @@ void dp_altmode_remove(struct typec_altmode *alt)
if (dp->connector_fwnode) {
drm_connector_oob_hotplug_event(dp->connector_fwnode,
- connector_status_disconnected);
+ connector_status_disconnected,
+ DRM_CONNECTOR_NO_EXTRA_STATUS);
fwnode_handle_put(dp->connector_fwnode);
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index f83f28cae207..e05197e970d3 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -91,6 +91,22 @@ enum drm_connector_status {
connector_status_unknown = 3,
};
+/**
+ * enum drm_connector_status_extra - additional events sent by the sink /
+ * display together or in replacement of the HPD status changes.
+ */
+enum drm_connector_status_extra {
+ /**
+ * @DRM_CONNECTOR_NO_EXTRA_STATUS: No additional status reported.
+ */
+ DRM_CONNECTOR_NO_EXTRA_STATUS,
+ /**
+ * @DRM_CONNECTOR_DP_IRQ_HPD: DisplayPort Sink has sent the
+ * IRQ_HPD (either by the HPD short pulse or via the AltMode event).
+ */
+ DRM_CONNECTOR_DP_IRQ_HPD,
+};
+
/**
* enum drm_connector_registration_state - userspace registration status for
* a &drm_connector
@@ -2521,7 +2537,8 @@ drm_connector_is_unregistered(struct drm_connector *connector)
}
void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
- enum drm_connector_status status);
+ enum drm_connector_status status,
+ enum drm_connector_status_extra extra_status);
const char *drm_get_connector_type_name(unsigned int connector_type);
const char *drm_get_connector_status_name(enum drm_connector_status status);
const char *drm_get_subpixel_order_name(enum subpixel_order order);
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 0/5] scmi: Log client subsystem entity counts
From: Guenter Roeck @ 2026-05-13 18:27 UTC (permalink / raw)
To: Andy Shevchenko, Alex Tran, Greg Kroah-Hartman
Cc: Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Sudeep Holla, Cristian Marussi, Linus Walleij,
Rafael J. Wysocki, Philipp Zabel, Viresh Kumar, linux-iio,
linux-kernel, arm-scmi, linux-arm-kernel, linux-gpio, linux-pm,
linux-hwmon
In-Reply-To: <agS8udcvqgQmiqB4@ashevche-desk.local>
On 5/13/26 11:02, Andy Shevchenko wrote:
> +Greg (I believe the trend is to drop such messages and not add them [back]?)
>
Is there some common guidance on this ? I'd be all for dropping messages
instead of adding them, but there seems to be a perpetual battle between
people who want to log everything and people concerned about logging noise.
As maintainer I always seem to be stuck between those two camps.
Guenter
> On Wed, May 13, 2026 at 09:44:18AM -0700, Alex Tran wrote:
>> SCMI client drivers do not consistently log the number of supported
>> entities discovered from firmware. This information is useful during
>> debugging because it shows which domains or resources were exposed by
>> firmware during probe.
>>
>> Add logging of the number of supported entities to the SCMI cpufreq,
>> pinctrl, reset, hwmon, and powercap client drivers after a successful
>> probe. This aligns these drivers with the existing logging in the SCMI
>> power and performance domain drivers.
>
^ permalink raw reply
* [PATCH RESEND v3 6/6] usb: typec: ucsi: huawei-gaokun: pass down HPD_IRQ events
From: Dmitry Baryshkov @ 2026-05-13 18:23 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Heikki Krogerus, Greg Kroah-Hartman, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Adrien Grassein, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Tomi Valkeinen,
Bjorn Andersson, Konrad Dybcio, Pengyu Luo, Nikita Travkin,
Yongxing Mou
Cc: dri-devel, linux-kernel, linux-usb, intel-gfx, intel-xe,
linux-amlogic, linux-arm-kernel, linux-arm-msm, freedreno,
Dmitry Baryshkov
In-Reply-To: <20260513-hpd-irq-events-v3-0-086857017f16@oss.qualcomm.com>
Pass IRQ_HPD events to the HPD bridge, letting those to be delivered to
the DisplayPort driver.
Reviewed-by: Pengyu Luo <mitltlatltl@gmail.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
index ca749fde49bd..5e3f887ecbd8 100644
--- a/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
+++ b/drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
@@ -299,10 +299,13 @@ static void gaokun_ucsi_handle_altmode(struct gaokun_ucsi_port *port)
/* UCSI callback .connector_status() have set orientation */
if (port->bridge)
- drm_aux_hpd_bridge_notify(&port->bridge->dev,
- port->hpd_state ?
- connector_status_connected :
- connector_status_disconnected);
+ drm_aux_hpd_bridge_notify_extra(&port->bridge->dev,
+ port->hpd_state ?
+ connector_status_connected :
+ connector_status_disconnected,
+ port->hpd_irq ?
+ DRM_CONNECTOR_DP_IRQ_HPD :
+ DRM_CONNECTOR_NO_EXTRA_STATUS);
gaokun_ec_ucsi_pan_ack(uec->ec, port->idx);
}
--
2.47.3
^ permalink raw reply related
* [PATCH RESEND v3 5/6] soc: qcom: pmic-glink-altmode: pass down HPD_IRQ events
From: Dmitry Baryshkov @ 2026-05-13 18:23 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Heikki Krogerus, Greg Kroah-Hartman, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Adrien Grassein, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Tomi Valkeinen,
Bjorn Andersson, Konrad Dybcio, Pengyu Luo, Nikita Travkin,
Yongxing Mou
Cc: dri-devel, linux-kernel, linux-usb, intel-gfx, intel-xe,
linux-amlogic, linux-arm-kernel, linux-arm-msm, freedreno,
Dmitry Baryshkov
In-Reply-To: <20260513-hpd-irq-events-v3-0-086857017f16@oss.qualcomm.com>
Pass IRQ_HPD events to the HPD bridge, letting those to be delivered to
the DisplayPort driver.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/soc/qcom/pmic_glink_altmode.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/qcom/pmic_glink_altmode.c b/drivers/soc/qcom/pmic_glink_altmode.c
index 619bad2c27ee..946eb20b8f83 100644
--- a/drivers/soc/qcom/pmic_glink_altmode.c
+++ b/drivers/soc/qcom/pmic_glink_altmode.c
@@ -373,7 +373,11 @@ static void pmic_glink_altmode_worker(struct work_struct *work)
else
conn_status = connector_status_disconnected;
- drm_aux_hpd_bridge_notify(&alt_port->bridge->dev, conn_status);
+ drm_aux_hpd_bridge_notify_extra(&alt_port->bridge->dev,
+ conn_status,
+ alt_port->hpd_irq ?
+ DRM_CONNECTOR_DP_IRQ_HPD :
+ DRM_CONNECTOR_NO_EXTRA_STATUS);
} else if (alt_port->mux_ctrl == MUX_CTRL_STATE_TUNNELING) {
if (alt_port->svid == USB_TYPEC_TBT_SID)
pmic_glink_altmode_enable_tbt(altmode, alt_port);
--
2.47.3
^ permalink raw reply related
* [PATCH RESEND v3 4/6] drm/msm: dp: handle the IRQ_HPD events reported by USB-C
From: Dmitry Baryshkov @ 2026-05-13 18:23 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Heikki Krogerus, Greg Kroah-Hartman, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Adrien Grassein, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Tomi Valkeinen,
Bjorn Andersson, Konrad Dybcio, Pengyu Luo, Nikita Travkin,
Yongxing Mou
Cc: dri-devel, linux-kernel, linux-usb, intel-gfx, intel-xe,
linux-amlogic, linux-arm-kernel, linux-arm-msm, freedreno,
Dmitry Baryshkov
In-Reply-To: <20260513-hpd-irq-events-v3-0-086857017f16@oss.qualcomm.com>
Let the MSM DisplayPort driver properly track and handle IRQ_HPD
delivered over the OOB events (e.g. from the USB-C AltMode handler).
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/gpu/drm/msm/dp/dp_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
index 7a0623fdbd8e..8df579bb320a 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1800,4 +1800,7 @@ void msm_dp_bridge_hpd_notify(struct drm_bridge *bridge,
msm_dp_add_event(dp, EV_HPD_PLUG_INT, 0, 0);
else if (msm_dp_display->link_ready && status == connector_status_disconnected)
msm_dp_add_event(dp, EV_HPD_UNPLUG_INT, 0, 0);
+
+ if (extra_status == DRM_CONNECTOR_DP_IRQ_HPD)
+ msm_dp_add_event(dp, EV_IRQ_HPD_INT, 0, 0);
}
--
2.47.3
^ permalink raw reply related
* [PATCH RESEND v3 3/6] drm/bridge: aux-hpd: let drivers pass IRQ_HPD events
From: Dmitry Baryshkov @ 2026-05-13 18:23 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Heikki Krogerus, Greg Kroah-Hartman, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Adrien Grassein, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Tomi Valkeinen,
Bjorn Andersson, Konrad Dybcio, Pengyu Luo, Nikita Travkin,
Yongxing Mou
Cc: dri-devel, linux-kernel, linux-usb, intel-gfx, intel-xe,
linux-amlogic, linux-arm-kernel, linux-arm-msm, freedreno,
Dmitry Baryshkov
In-Reply-To: <20260513-hpd-irq-events-v3-0-086857017f16@oss.qualcomm.com>
Let users of aux-hpd, the UCSI and PMIC GLINK drivers pass the IRQ_HPD
events to the DisplayPort drivers.
The drm_aux_hpd_bridge_notify() is keps to ease merging of the series,
preventing extra cross-tree merges. It will be removed once all
drivers are converted. The drm_bridge_hpd_notify() function is kept for
the driver which only care about the connector status and will always
pass false as the irq_hpd event.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/gpu/drm/bridge/aux-hpd-bridge.c | 11 +++++++----
drivers/gpu/drm/drm_bridge.c | 17 ++++++++++-------
include/drm/bridge/aux-bridge.h | 13 +++++++++++--
include/drm/drm_bridge.h | 22 ++++++++++++++++++++--
4 files changed, 48 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/bridge/aux-hpd-bridge.c b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
index f02a38a2638a..0e2f0b046121 100644
--- a/drivers/gpu/drm/bridge/aux-hpd-bridge.c
+++ b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
@@ -136,16 +136,19 @@ struct device *drm_dp_hpd_bridge_register(struct device *parent, struct device_n
EXPORT_SYMBOL_GPL(drm_dp_hpd_bridge_register);
/**
- * drm_aux_hpd_bridge_notify - notify hot plug detection events
+ * drm_aux_hpd_bridge_notify_extra - notify hot plug detection events
* @dev: device created for the HPD bridge
* @status: output connection status
+ * @extra_status: extra status bits like DRM_CONNECTOR_DP_IRQ_HPD
*
* A wrapper around drm_bridge_hpd_notify() that is used to report hot plug
* detection events for bridges created via drm_dp_hpd_bridge_register().
*
* This function shall be called in a context that can sleep.
*/
-void drm_aux_hpd_bridge_notify(struct device *dev, enum drm_connector_status status)
+void drm_aux_hpd_bridge_notify_extra(struct device *dev,
+ enum drm_connector_status status,
+ enum drm_connector_status_extra extra_status)
{
struct auxiliary_device *adev = to_auxiliary_dev(dev);
struct drm_aux_hpd_bridge_data *data = auxiliary_get_drvdata(adev);
@@ -153,9 +156,9 @@ void drm_aux_hpd_bridge_notify(struct device *dev, enum drm_connector_status sta
if (!data)
return;
- drm_bridge_hpd_notify(&data->bridge, status);
+ drm_bridge_hpd_notify_extra(&data->bridge, status, extra_status);
}
-EXPORT_SYMBOL_GPL(drm_aux_hpd_bridge_notify);
+EXPORT_SYMBOL_GPL(drm_aux_hpd_bridge_notify_extra);
static int drm_aux_hpd_bridge_attach(struct drm_bridge *bridge,
struct drm_encoder *encoder,
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index c8c3301cd936..09c3f5954ade 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -1495,25 +1495,28 @@ void drm_bridge_hpd_disable(struct drm_bridge *bridge)
EXPORT_SYMBOL_GPL(drm_bridge_hpd_disable);
/**
- * drm_bridge_hpd_notify - notify hot plug detection events
+ * drm_bridge_hpd_notify_extra - notify hot plug detection and sink IRQ events
* @bridge: bridge control structure
* @status: output connection status
+ * @extra_status: additional status recorded by the sink
*
* Bridge drivers shall call this function to report hot plug events when they
- * detect a change in the output status, when hot plug detection has been
- * enabled by drm_bridge_hpd_enable().
+ * detect a change in the output status or when the sink has reported extra HPD
+ * status events (like the IRQ_HPD in case of the DisplayPort), when hot plug
+ * detection has been enabled by drm_bridge_hpd_enable().
*
* This function shall be called in a context that can sleep.
*/
-void drm_bridge_hpd_notify(struct drm_bridge *bridge,
- enum drm_connector_status status)
+void drm_bridge_hpd_notify_extra(struct drm_bridge *bridge,
+ enum drm_connector_status status,
+ enum drm_connector_status_extra extra_status)
{
mutex_lock(&bridge->hpd_mutex);
if (bridge->hpd_cb)
- bridge->hpd_cb(bridge->hpd_data, status, DRM_CONNECTOR_NO_EXTRA_STATUS);
+ bridge->hpd_cb(bridge->hpd_data, status, extra_status);
mutex_unlock(&bridge->hpd_mutex);
}
-EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
+EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify_extra);
#ifdef CONFIG_OF
/**
diff --git a/include/drm/bridge/aux-bridge.h b/include/drm/bridge/aux-bridge.h
index c2f5a855512f..f9a86886b0df 100644
--- a/include/drm/bridge/aux-bridge.h
+++ b/include/drm/bridge/aux-bridge.h
@@ -25,7 +25,9 @@ struct auxiliary_device *devm_drm_dp_hpd_bridge_alloc(struct device *parent, str
int devm_drm_dp_hpd_bridge_add(struct device *dev, struct auxiliary_device *adev);
struct device *drm_dp_hpd_bridge_register(struct device *parent,
struct device_node *np);
-void drm_aux_hpd_bridge_notify(struct device *dev, enum drm_connector_status status);
+void drm_aux_hpd_bridge_notify_extra(struct device *dev,
+ enum drm_connector_status status,
+ enum drm_connector_status_extra extra_status);
#else
static inline struct auxiliary_device *devm_drm_dp_hpd_bridge_alloc(struct device *parent,
struct device_node *np)
@@ -44,9 +46,16 @@ static inline struct device *drm_dp_hpd_bridge_register(struct device *parent,
return NULL;
}
-static inline void drm_aux_hpd_bridge_notify(struct device *dev, enum drm_connector_status status)
+static inline void drm_aux_hpd_bridge_notify_extra(struct device *dev,
+ enum drm_connector_status status,
+ enum drm_connector_status_extra extra_status)
{
}
#endif
+static inline void drm_aux_hpd_bridge_notify(struct device *dev, enum drm_connector_status status)
+{
+ drm_aux_hpd_bridge_notify_extra(dev, status, DRM_CONNECTOR_NO_EXTRA_STATUS);
+}
+
#endif
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 3e4672fbd7a8..2cf604cf02db 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -1556,8 +1556,26 @@ void drm_bridge_hpd_enable(struct drm_bridge *bridge,
enum drm_connector_status_extra extra_status),
void *data);
void drm_bridge_hpd_disable(struct drm_bridge *bridge);
-void drm_bridge_hpd_notify(struct drm_bridge *bridge,
- enum drm_connector_status status);
+void drm_bridge_hpd_notify_extra(struct drm_bridge *bridge,
+ enum drm_connector_status status,
+ enum drm_connector_status_extra extra_status);
+
+/**
+ * drm_bridge_hpd_notify - notify hot plug detection events
+ * @bridge: bridge control structure
+ * @status: output connection status
+ *
+ * Bridge drivers shall call this function to report hot plug events when they
+ * detect a change in the output status, when hot plug detection has been
+ * enabled by drm_bridge_hpd_enable().
+ *
+ * This function shall be called in a context that can sleep.
+ */
+static inline void drm_bridge_hpd_notify(struct drm_bridge *bridge,
+ enum drm_connector_status status)
+{
+ drm_bridge_hpd_notify_extra(bridge, status, DRM_CONNECTOR_NO_EXTRA_STATUS);
+}
#ifdef CONFIG_DRM_PANEL_BRIDGE
bool drm_bridge_is_panel(const struct drm_bridge *bridge);
--
2.47.3
^ permalink raw reply related
* [PATCH RESEND v3 2/6] drm/bridge: pass down IRQ_HPD to the drivers
From: Dmitry Baryshkov @ 2026-05-13 18:23 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Heikki Krogerus, Greg Kroah-Hartman, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Adrien Grassein, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Tomi Valkeinen,
Bjorn Andersson, Konrad Dybcio, Pengyu Luo, Nikita Travkin,
Yongxing Mou
Cc: dri-devel, linux-kernel, linux-usb, intel-gfx, intel-xe,
linux-amlogic, linux-arm-kernel, linux-arm-msm, freedreno,
Dmitry Baryshkov
In-Reply-To: <20260513-hpd-irq-events-v3-0-086857017f16@oss.qualcomm.com>
Pass down the notifications about the IRQ_HPD events down to the
individual drivers, letting them handle those as required.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/gpu/drm/bridge/chrontel-ch7033.c | 3 ++-
drivers/gpu/drm/bridge/lontium-lt8912b.c | 3 ++-
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 3 ++-
drivers/gpu/drm/bridge/ti-tfp410.c | 4 ++--
drivers/gpu/drm/display/drm_bridge_connector.c | 22 +++++++++++++---------
drivers/gpu/drm/drm_bridge.c | 5 +++--
drivers/gpu/drm/drm_connector.c | 2 +-
drivers/gpu/drm/i915/display/intel_dp.c | 3 ++-
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 | 9 ++++++---
include/drm/drm_connector.h | 3 ++-
14 files changed, 43 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/bridge/chrontel-ch7033.c b/drivers/gpu/drm/bridge/chrontel-ch7033.c
index 54d49d4882c8..04e6b4c00a28 100644
--- a/drivers/gpu/drm/bridge/chrontel-ch7033.c
+++ b/drivers/gpu/drm/bridge/chrontel-ch7033.c
@@ -259,7 +259,8 @@ static const struct drm_connector_helper_funcs ch7033_connector_helper_funcs = {
.best_encoder = ch7033_connector_best_encoder,
};
-static void ch7033_hpd_event(void *arg, enum drm_connector_status status)
+static void ch7033_hpd_event(void *arg, enum drm_connector_status status,
+ enum drm_connector_status_extra extra_status)
{
struct ch7033_priv *priv = arg;
diff --git a/drivers/gpu/drm/bridge/lontium-lt8912b.c b/drivers/gpu/drm/bridge/lontium-lt8912b.c
index 8a0b48efca58..b404f0cbf60d 100644
--- a/drivers/gpu/drm/bridge/lontium-lt8912b.c
+++ b/drivers/gpu/drm/bridge/lontium-lt8912b.c
@@ -504,7 +504,8 @@ static int lt8912_attach_dsi(struct lt8912 *lt)
return 0;
}
-static void lt8912_bridge_hpd_cb(void *data, enum drm_connector_status status)
+static void lt8912_bridge_hpd_cb(void *data, enum drm_connector_status status,
+ enum drm_connector_status_extra extra_status)
{
struct lt8912 *lt = data;
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
index 11aab07d88df..ca41ebe9f26f 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 status,
+ enum drm_connector_status_extra extra_status)
{
const struct drm_edid *drm_edid;
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c b/drivers/gpu/drm/bridge/ti-tfp410.c
index 3b6b0e92cf89..199916662895 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -39,7 +39,6 @@ drm_bridge_to_tfp410(struct drm_bridge *bridge)
{
return container_of(bridge, struct tfp410, bridge);
}
-
static inline struct tfp410 *
drm_connector_to_tfp410(struct drm_connector *connector)
{
@@ -110,7 +109,8 @@ static void tfp410_hpd_work_func(struct work_struct *work)
drm_helper_hpd_irq_event(dvi->bridge.dev);
}
-static void tfp410_hpd_callback(void *arg, enum drm_connector_status status)
+static void tfp410_hpd_callback(void *arg, enum drm_connector_status status,
+ enum drm_connector_status_extra extra_status)
{
struct tfp410 *dvi = arg;
diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c b/drivers/gpu/drm/display/drm_bridge_connector.c
index 39cc18f78eda..5fdb1a231cec 100644
--- a/drivers/gpu/drm/display/drm_bridge_connector.c
+++ b/drivers/gpu/drm/display/drm_bridge_connector.c
@@ -141,7 +141,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 status,
+ enum drm_connector_status_extra extra_status)
{
struct drm_bridge_connector *bridge_connector =
to_drm_bridge_connector(connector);
@@ -149,12 +150,13 @@ 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);
+ bridge->funcs->hpd_notify(bridge, connector, status, extra_status);
}
}
static void drm_bridge_connector_handle_hpd(struct drm_bridge_connector *drm_bridge_connector,
- enum drm_connector_status 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;
@@ -163,24 +165,26 @@ 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);
+ drm_bridge_connector_hpd_notify(connector, status, extra_status);
drm_kms_helper_connector_hotplug_event(connector);
}
static void drm_bridge_connector_hpd_cb(void *cb_data,
- enum drm_connector_status status)
+ enum drm_connector_status status,
+ enum drm_connector_status_extra extra_status)
{
- drm_bridge_connector_handle_hpd(cb_data, status);
+ drm_bridge_connector_handle_hpd(cb_data, status, extra_status);
}
static void drm_bridge_connector_oob_hotplug_event(struct drm_connector *connector,
- enum drm_connector_status status)
+ enum drm_connector_status status,
+ enum drm_connector_status_extra extra_status)
{
struct drm_bridge_connector *bridge_connector =
to_drm_bridge_connector(connector);
- drm_bridge_connector_handle_hpd(bridge_connector, status);
+ drm_bridge_connector_handle_hpd(bridge_connector, status, extra_status);
}
static void drm_bridge_connector_enable_hpd(struct drm_connector *connector)
@@ -223,7 +227,7 @@ 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_bridge_connector_hpd_notify(connector, status, DRM_CONNECTOR_NO_EXTRA_STATUS);
} else {
switch (connector->connector_type) {
case DRM_MODE_CONNECTOR_DPI:
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index d6f512b73389..c8c3301cd936 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -1444,7 +1444,8 @@ EXPORT_SYMBOL_GPL(drm_bridge_edid_read);
*/
void drm_bridge_hpd_enable(struct drm_bridge *bridge,
void (*cb)(void *data,
- enum drm_connector_status status),
+ enum drm_connector_status status,
+ enum drm_connector_status_extra extra_status),
void *data)
{
if (!(bridge->ops & DRM_BRIDGE_OP_HPD))
@@ -1509,7 +1510,7 @@ void drm_bridge_hpd_notify(struct drm_bridge *bridge,
{
mutex_lock(&bridge->hpd_mutex);
if (bridge->hpd_cb)
- bridge->hpd_cb(bridge->hpd_data, status);
+ bridge->hpd_cb(bridge->hpd_data, status, DRM_CONNECTOR_NO_EXTRA_STATUS);
mutex_unlock(&bridge->hpd_mutex);
}
EXPORT_SYMBOL_GPL(drm_bridge_hpd_notify);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index edee9daccd51..415eb834808c 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -3532,7 +3532,7 @@ void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
return;
if (connector->funcs->oob_hotplug_event)
- connector->funcs->oob_hotplug_event(connector, status);
+ connector->funcs->oob_hotplug_event(connector, status, extra_status);
drm_connector_put(connector);
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index 4955bd8b11d7..98bbcab2067b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -6779,7 +6779,8 @@ static int intel_dp_connector_atomic_check(struct drm_connector *_connector,
}
static void intel_dp_oob_hotplug_event(struct drm_connector *_connector,
- enum drm_connector_status hpd_state)
+ enum drm_connector_status hpd_state,
+ enum drm_connector_status_extra extra_status)
{
struct intel_connector *connector = to_intel_connector(_connector);
struct intel_display *display = to_intel_display(connector);
diff --git a/drivers/gpu/drm/meson/meson_encoder_hdmi.c b/drivers/gpu/drm/meson/meson_encoder_hdmi.c
index 1abb0572bb5f..691b9996c8a4 100644
--- a/drivers/gpu/drm/meson/meson_encoder_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_encoder_hdmi.c
@@ -323,7 +323,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 status,
+ enum drm_connector_status_extra extra_status)
{
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 d2124d625485..7a0623fdbd8e 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1785,7 +1785,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 status,
+ enum drm_connector_status_extra extra_status)
{
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 9eb3431dd93a..74da3ef6b625 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.h
+++ b/drivers/gpu/drm/msm/dp/dp_drm.h
@@ -41,6 +41,7 @@ void msm_dp_bridge_hpd_enable(struct drm_bridge *bridge);
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 status,
+ enum drm_connector_status_extra extra_status);
#endif /* _DP_DRM_H_ */
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index 29b2dfb90b5f..a7288791b2a5 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -429,7 +429,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 status,
+ enum drm_connector_status_extra extra_status)
{
struct omap_hdmi *hdmi = drm_bridge_to_hdmi(bridge);
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index a8d67bd9ee50..3e4672fbd7a8 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -615,7 +615,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 status,
+ enum drm_connector_status_extra extra_status);
/**
* @hpd_enable:
@@ -1260,7 +1261,8 @@ struct drm_bridge {
* @hpd_cb: Hot plug detection callback, registered with
* drm_bridge_hpd_enable().
*/
- void (*hpd_cb)(void *data, enum drm_connector_status status);
+ void (*hpd_cb)(void *data, enum drm_connector_status status,
+ enum drm_connector_status_extra extra_status);
/**
* @hpd_data: Private data passed to the Hot plug detection callback
* @hpd_cb.
@@ -1550,7 +1552,8 @@ const struct drm_edid *drm_bridge_edid_read(struct drm_bridge *bridge,
struct drm_connector *connector);
void drm_bridge_hpd_enable(struct drm_bridge *bridge,
void (*cb)(void *data,
- enum drm_connector_status status),
+ enum drm_connector_status status,
+ enum drm_connector_status_extra extra_status),
void *data);
void drm_bridge_hpd_disable(struct drm_bridge *bridge);
void drm_bridge_hpd_notify(struct drm_bridge *bridge,
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index e05197e970d3..5ac5a64f83d9 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1720,7 +1720,8 @@ struct drm_connector_funcs {
* has been received from a source outside the display driver / device.
*/
void (*oob_hotplug_event)(struct drm_connector *connector,
- enum drm_connector_status status);
+ enum drm_connector_status status,
+ enum drm_connector_status_extra extra_status);
/**
* @debugfs_init:
--
2.47.3
^ permalink raw reply related
* [PATCH RESEND v3 0/6] drm: handle IRQ_HPD events correctly
From: Dmitry Baryshkov @ 2026-05-13 18:23 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Heikki Krogerus, Greg Kroah-Hartman, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Adrien Grassein, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Tomi Valkeinen,
Bjorn Andersson, Konrad Dybcio, Pengyu Luo, Nikita Travkin,
Yongxing Mou
Cc: dri-devel, linux-kernel, linux-usb, intel-gfx, intel-xe,
linux-amlogic, linux-arm-kernel, linux-arm-msm, freedreno,
Dmitry Baryshkov
Both DisplayPort and HDMI standards define a way for the Sink / display
to notify the Source / host about some kinds of events. In case of HDMI
it's as simple as singnalling changes to the EDID. In case of
DisplayPort it's more complicated and requires actual checking of the
DPCD registers.
Currently USB-C drivers don't have a way to deliver the IRQ_HPD
notifications, leading to missing MST notifications. Provide necessary
plumbing to let IRQ_HPD events be passed to the DisplayPort drivers.
Note: the Yoga C630 UCSI driver and Acer Aspire1 EC driver are not yet
enabled to send the IRQ_HPD events. Both of them would need some more
reverse engineering to find out how the event is being reported by the
EC.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
Changes in v3:
- Fixed build error if aux bridges are disabled (Intel GFX CI)
- Link to v2: https://patch.msgid.link/20260420-hpd-irq-events-v2-0-402ffe27e9e9@oss.qualcomm.com
Changes in v2:
- Change irq_hpd arg to be an enum, possibly desribing other uses (Toni)
- Account for that, chaning the API accordingly (with_irq -> extra,
etc.)
- Wire up AUX bridge notifications
- Link to v1: https://patch.msgid.link/20260416-hpd-irq-events-v1-0-1ab1f1cfb2b2@oss.qualcomm.com
---
Dmitry Baryshkov (6):
drm/connector: report IRQ_HPD events to drm_connector_oob_hotplug_event()
drm/bridge: pass down IRQ_HPD to the drivers
drm/bridge: aux-hpd: let drivers pass IRQ_HPD events
drm/msm: dp: handle the IRQ_HPD events reported by USB-C
soc: qcom: pmic-glink-altmode: pass down HPD_IRQ events
usb: typec: ucsi: huawei-gaokun: pass down HPD_IRQ events
drivers/gpu/drm/bridge/aux-hpd-bridge.c | 11 +++++----
drivers/gpu/drm/bridge/chrontel-ch7033.c | 3 ++-
drivers/gpu/drm/bridge/lontium-lt8912b.c | 3 ++-
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 3 ++-
drivers/gpu/drm/bridge/ti-tfp410.c | 4 ++--
drivers/gpu/drm/display/drm_bridge_connector.c | 22 ++++++++++--------
drivers/gpu/drm/drm_bridge.c | 20 ++++++++++-------
drivers/gpu/drm/drm_connector.c | 7 ++++--
drivers/gpu/drm/i915/display/intel_dp.c | 3 ++-
drivers/gpu/drm/meson/meson_encoder_hdmi.c | 3 ++-
drivers/gpu/drm/msm/dp/dp_display.c | 6 ++++-
drivers/gpu/drm/msm/dp/dp_drm.h | 3 ++-
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 3 ++-
drivers/soc/qcom/pmic_glink_altmode.c | 6 ++++-
drivers/usb/typec/altmodes/displayport.c | 15 +++++++++----
drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c | 11 +++++----
include/drm/bridge/aux-bridge.h | 13 +++++++++--
include/drm/drm_bridge.h | 31 +++++++++++++++++++++-----
include/drm/drm_connector.h | 22 ++++++++++++++++--
19 files changed, 138 insertions(+), 51 deletions(-)
---
base-commit: c7275b05bc428c7373d97aa2da02d3a7fa6b9f66
change-id: 20260414-hpd-irq-events-e72bc076a5f1
Best regards,
--
With best wishes
Dmitry
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v2] clocksource: move NXP timer selection to drivers/clocksource
From: Enric Balletbo i Serra @ 2026-05-13 18:22 UTC (permalink / raw)
To: Russell King, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Daniel Lezcano, Thomas Gleixner
Cc: linux-arm-kernel, imx, linux-kernel, Enric Balletbo i Serra
From: Enric Balletbo i Serra <eballetb@redhat.com>
The Kconfig logic for selecting the scheduler clocksource on
NXP Vybrid (VF610) uses a `choice` block restricted to 32-bit ARM. This
prevents 64-bit architectures, such as the NXP S32 family, from enabling
the NXP Periodic Interrupt Timer (PIT) driver (CONFIG_NXP_PIT_TIMER).
Relocate the NXP clocksource selection from arch/arm/mach-imx/Kconfig to
drivers/clocksource/Kconfig. This allows the configuration to be shared
across different architectures.
Update the selection to include support for ARCH_S32 and add a "None"
option to allow using the standard ARM Architected Timer. The Vybrid
Global Timer option is restricted to ARCH_MULTI_V7 SOC_VF610 platforms
to prevent it from being visible on Cortex-M4 builds, which lack the
ARM Global Timer hardware.
Fixes: bee33f22d7c3 ("clocksource/drivers/nxp-pit: Add NXP Automotive s32g2 / s32g3 support")
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Enric Balletbo i Serra <eballetb@redhat.com>
---
Changes in v2:
- Fix VF_USE_ARM_GLOBAL_TIMER dependency: use ARCH_MULTI_V7 instead of
ARM to prevent the option from being visible on Cortex-M4 builds
(Sashiko AI review)
- Link to v1: https://lore.kernel.org/r/20260302-fix-nxp-timer-v1-1-af4bc62d4ffa@redhat.com
---
arch/arm/mach-imx/Kconfig | 21 ---------------------
drivers/clocksource/Kconfig | 30 ++++++++++++++++++++++++++++++
2 files changed, 30 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 6ea1bd55acf8..a361840d7a04 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -227,27 +227,6 @@ config SOC_VF610
help
This enables support for Freescale Vybrid VF610 processor.
-choice
- prompt "Clocksource for scheduler clock"
- depends on SOC_VF610
- default VF_USE_ARM_GLOBAL_TIMER
-
- config VF_USE_ARM_GLOBAL_TIMER
- bool "Use ARM Global Timer"
- depends on ARCH_MULTI_V7
- select ARM_GLOBAL_TIMER
- select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
- help
- Use the ARM Global Timer as clocksource
-
- config VF_USE_PIT_TIMER
- bool "Use PIT timer"
- select NXP_PIT_TIMER
- help
- Use SoC Periodic Interrupt Timer (PIT) as clocksource
-
-endchoice
-
endif
endif
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index d1a33a231a44..15c02d3e9dbf 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -793,4 +793,34 @@ config RTK_SYSTIMER
this option only when building for a Realtek platform or for compilation
testing.
+choice
+ prompt "NXP clocksource for scheduler clock"
+ depends on SOC_VF610 || ARCH_S32
+ # Default to Global Timer for Vybrid (32-bit)
+ default VF_USE_ARM_GLOBAL_TIMER if SOC_VF610
+ # Default to None for S32 (64-bit)
+ default VF_TIMER_NONE if ARCH_S32
+
+ config VF_USE_ARM_GLOBAL_TIMER
+ bool "Use NXP Vybrid Global Timer"
+ depends on ARCH_MULTI_V7 && SOC_VF610
+ select ARM_GLOBAL_TIMER
+ select CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
+ help
+ Use the NXP Vybrid Global Timer as clocksource.
+
+ config VF_USE_PIT_TIMER
+ bool "Use NXP PIT timer"
+ select NXP_PIT_TIMER
+ help
+ Use NXP Periodic Interrupt Timer (PIT) as clocksource.
+
+ config VF_TIMER_NONE
+ bool "None (Use standard Arch Timer)"
+ help
+ Do not use any specific NXP timer driver. Use the standard
+ ARM Architected Timer instead.
+
+endchoice
+
endmenu
---
base-commit: 7fd2df204f342fc17d1a0bfcd474b24232fb0f32
change-id: 20260302-fix-nxp-timer-9cb1fbd7afcd
Best regards,
--
Enric Balletbo i Serra <eballetb@redhat.com>
^ permalink raw reply related
* [PATCH] media: rkvdec: hevc: cap EXT SPS RPS control counts before descriptor assembly
From: Michael Bommarito @ 2026-05-13 18:19 UTC (permalink / raw)
To: Detlev Casanova, Ezequiel Garcia, Mauro Carvalho Chehab,
Heiko Stuebner, linux-media
Cc: linux-rockchip, linux-arm-kernel, linux-kernel
V4L2_CID_STATELESS_HEVC_EXT_SPS_ST_RPS and
V4L2_CID_STATELESS_HEVC_EXT_SPS_LT_RPS are registered as dynamic-size
controls with a per-control element cap of 65. The V4L2 control core
enforces only the payload-element cap. It does not bound the spec-derived
count fields that the rkvdec HEVC helper later uses to walk fixed hardware
descriptor tables and temporary helper arrays:
- struct rkvdec_rps::refs[32]
- struct rkvdec_rps::short_term_ref_sets[64]
- struct calculated_rps_st_set::delta_poc_s0[16] / delta_poc_s1[16]
A userspace V4L2 client that can open the Rockchip RKVDEC m2m decoder node
may submit SPS/RPS controls whose counts exceed those capacities or whose
prediction reference index underflows. rkvdec_hevc_assemble_hw_rps() then
walks past the descriptor table or temporary-array bounds.
KASAN under a small KUnit harness wrapping the real helper reports
slab-out-of-bounds in all of:
- num_short_term_ref_pic_sets = 65 (write past short_term_ref_sets[64])
- num_long_term_ref_pics_sps = 33 (write past refs[32], intra-struct)
- ext_sps_st_rps[i].num_negative_pics or num_positive_pics > 16
(write past delta_poc_s0[16] inside calculated_rps_st_set)
- INTER_REF_PIC_SET_PRED with delta_idx_minus1 + 1 > i
(u8 ref_rps_idx underflow then OOB read on calculated_rps_st_sets)
Validate the SPS/RPS counts before calling the assembly helpers. The cap
values match both the HEVC spec ranges (num_short_term_ref_pic_sets <= 64,
num_long_term_ref_pics_sps <= 32) and the fixed driver descriptor and
helper-array capacities. Reject controls whose counts exceed those, and
reject prediction entries whose reference index would underflow.
Fixes: c9a59dc2acc7 ("media: rkvdec: Add HEVC support for the VDPU381 variant")
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
Assisted-by: Claude:claude-opus-4-7
---
I don't have a RK3588 / RK3576 board to confirm this through a real
/dev/videoN request path yet, but was convinced enough by:
1. Static reach: registration of EXT_SPS_ST_RPS / EXT_SPS_LT_RPS with
.dims = { 65 } at drivers/media/platform/rockchip/rkvdec/rkvdec.c
:239-287, the SPS-count-driven loops in rkvdec-hevc-common.c
:213-225 and :228-251, and v4l2-ctrls-core.c :1213-1277, which
validates only EXT RPS flags and not the spec-derived count fields.
2. A KUnit harness (separate, not in this patch) that allocates one
struct rkvdec_rps + a single calculated_rps_st_sets element via
kunit_kzalloc / kzalloc and calls the real
rkvdec_hevc_assemble_hw_rps() helper. Under UML + KASAN_GENERIC with
the kasan_multi_shot boot param, on a stock tree it produces these
reports:
BUG: KASAN: slab-out-of-bounds in
rkvdec_hevc_assemble_hw_rps+0xb0c/0x1080
(num_short_term_ref_pic_sets = 65, write of size 36 0 bytes past
the rps allocation)
BUG: KASAN: slab-out-of-bounds in
rkvdec_hevc_assemble_hw_rps (num_negative_pics = 64, write past
the single-element kzalloc'd calculated_rps_st_sets buffer)
BUG: KASAN: slab-use-after-free / slab-out-of-bounds reads via
u8 ref_rps_idx underflow at calculated_rps_st_sets[255]
(INTER_REF_PIC_SET_PRED with delta_idx_minus1 = 0, idx = 0)
The num_long_term_ref_pics_sps = 33 case is invisible to KASAN
(the OOB write lands inside struct rkvdec_rps) but corrupts
short_term_ref_sets[0]; the harness asserts that case explicitly.
3. Same harness on the patched tree: all five cases (four adversarial
plus a legitimate-limit regression with ST=64, LT=32, num_neg=1)
pass clean, no KASAN reports.
If hardware-side validation actually does reject these counts before
rkvdec_hevc_assemble_hw_rps() runs and this patch is unnecessary, please
say so and I will withdraw it. If it is reachable, I will follow up with
a runtime hardware splat once the Orange Pi board I bought arrives.
Let me know if you want a patch set with the KUnit harnesses too.
checkpatch.pl: 0 errors / 0 warnings.
.../rockchip/rkvdec/rkvdec-hevc-common.c | 49 +++++++++++++++++++
1 file changed, 49 insertions(+)
diff --git a/drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-common.c b/drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-common.c
index 3119f3bc9f98..895fb16bc572 100644
--- a/drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-common.c
+++ b/drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-common.c
@@ -408,9 +408,58 @@ static void rkvdec_hevc_prepare_hw_st_rps(struct rkvdec_hevc_run *run, struct rk
memcpy(cache, run->ext_sps_st_rps, sizeof(struct v4l2_ctrl_hevc_ext_sps_st_rps));
}
+/*
+ * V4L2 caps the EXT_SPS RPS payload length but not the SPS-derived counts
+ * that the helpers walk. Caps match the HEVC spec ranges.
+ */
+#define RKVDEC_HEVC_MAX_SHORT_TERM_REF_PIC_SETS 64
+#define RKVDEC_HEVC_MAX_LONG_TERM_REF_PICS_SPS 32
+#define RKVDEC_HEVC_MAX_RPS_NEG_POS_PICS 16
+
+static int rkvdec_hevc_validate_rps_ctrls(struct rkvdec_hevc_run *run)
+{
+ const struct v4l2_ctrl_hevc_sps *sps = run->sps;
+
+ if (run->ext_sps_lt_rps &&
+ sps->num_long_term_ref_pics_sps >
+ RKVDEC_HEVC_MAX_LONG_TERM_REF_PICS_SPS)
+ return -EINVAL;
+
+ if (run->ext_sps_st_rps) {
+ unsigned int i;
+
+ if (sps->num_short_term_ref_pic_sets >
+ RKVDEC_HEVC_MAX_SHORT_TERM_REF_PIC_SETS)
+ return -EINVAL;
+
+ for (i = 0; i < sps->num_short_term_ref_pic_sets; i++) {
+ const struct v4l2_ctrl_hevc_ext_sps_st_rps *r =
+ &run->ext_sps_st_rps[i];
+
+ if (r->num_negative_pics >
+ RKVDEC_HEVC_MAX_RPS_NEG_POS_PICS ||
+ r->num_positive_pics >
+ RKVDEC_HEVC_MAX_RPS_NEG_POS_PICS)
+ return -EINVAL;
+
+ if ((r->flags &
+ V4L2_HEVC_EXT_SPS_ST_RPS_FLAG_INTER_REF_PIC_SET_PRED) &&
+ (unsigned int)r->delta_idx_minus1 + 1 > i)
+ return -EINVAL;
+ }
+ }
+
+ return 0;
+}
+
void rkvdec_hevc_assemble_hw_rps(struct rkvdec_hevc_run *run, struct rkvdec_rps *rps,
struct v4l2_ctrl_hevc_ext_sps_st_rps *st_cache)
{
+ if (rkvdec_hevc_validate_rps_ctrls(run)) {
+ pr_err_ratelimited("rkvdec: rejecting HEVC SPS/RPS controls with out-of-range counts\n");
+ return;
+ }
+
rkvdec_hevc_prepare_hw_st_rps(run, rps, st_cache);
rkvdec_hevc_assemble_hw_lt_rps(run, rps);
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 5/5] pinctrl: pinctrl-scmi: Log number of pins, groups, functions
From: Andy Shevchenko @ 2026-05-13 18:06 UTC (permalink / raw)
To: Alex Tran
Cc: Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Sudeep Holla, Cristian Marussi, Linus Walleij,
Rafael J. Wysocki, Philipp Zabel, Viresh Kumar, Guenter Roeck,
linux-iio, linux-kernel, arm-scmi, linux-arm-kernel, linux-gpio,
linux-pm, linux-hwmon
In-Reply-To: <20260513-scmi-client-probe-log-v2-5-36607e9dd540@oss.qualcomm.com>
On Wed, May 13, 2026 at 10:16:58AM -0700, Alex Tran wrote:
> The SCMI pinctrl driver does not currently log the number of pins,
> groups, and functions discovered from firmware. This information is
> useful for confirming the firmware exposed pinctrl resources during
> debugging.
>
> Log these counts after a successful probe to align with the existing
> SCMI client driver logging pattern.
NAK. Even for debug level. This can be easily derived from debugfs.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 3/7] dt-bindings: media: sun4i-a10-video-engine: Add H616 compatible
From: Rob Herring (Arm) @ 2026-05-13 18:05 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Mauro Carvalho Chehab, Maxime Ripard, linux-staging, linux-sunxi,
linux-media, Paul Kocialkowski, devicetree, linux-kernel,
Greg Kroah-Hartman, Conor Dooley, Krzysztof Kozlowski,
linux-arm-kernel, Samuel Holland, Jernej Skrabec
In-Reply-To: <20260505134812.408316-4-wens@kernel.org>
On Tue, 05 May 2026 21:48:07 +0800, Chen-Yu Tsai wrote:
> The H616 contains a video engine similar to past SoCs.
>
> Add a new compatible for it.
>
> Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
> ---
> .../bindings/media/allwinner,sun4i-a10-video-engine.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 0/5] scmi: Log client subsystem entity counts
From: Andy Shevchenko @ 2026-05-13 18:04 UTC (permalink / raw)
To: Alex Tran
Cc: Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Sudeep Holla, Cristian Marussi, Linus Walleij,
Rafael J. Wysocki, Philipp Zabel, Viresh Kumar, Guenter Roeck,
linux-iio, linux-kernel, arm-scmi, linux-arm-kernel, linux-gpio,
linux-pm, linux-hwmon
In-Reply-To: <20260513-scmi-client-probe-log-v2-0-36607e9dd540@oss.qualcomm.com>
On Wed, May 13, 2026 at 10:16:53AM -0700, Alex Tran wrote:
> SCMI client drivers do not consistently log the number of supported
> entities discovered from firmware. This information is useful during
> debugging because it shows which domains or resources were exposed by
> firmware during probe.
>
> Add logging of the number of supported entities to the SCMI cpufreq,
> pinctrl, reset, hwmon, and powercap client drivers after a successful
> probe. This aligns these drivers with the existing logging in the SCMI
> power and performance domain drivers.
Too quick between the series, the v1 discussion is still ongoing.
Hence this should not be applied (at least yet).
Read Submitting Patches and other process documentation that suggest at least
24h period for review and in patch series even week or so.
> ---
> Changes in v2:
> - Use dev_dbg instead of dev_info log level
> - Link to v1: https://lore.kernel.org/r/20260513-scmi-client-probe-log-v1-0-00b47b1be009@oss.qualcomm.com
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 0/5] scmi: Log client subsystem entity counts
From: Andy Shevchenko @ 2026-05-13 18:02 UTC (permalink / raw)
To: Alex Tran, Greg Kroah-Hartman
Cc: Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Sudeep Holla, Cristian Marussi, Linus Walleij,
Rafael J. Wysocki, Philipp Zabel, Viresh Kumar, Guenter Roeck,
linux-iio, linux-kernel, arm-scmi, linux-arm-kernel, linux-gpio,
linux-pm, linux-hwmon
In-Reply-To: <20260513-scmi-client-probe-log-v1-0-00b47b1be009@oss.qualcomm.com>
+Greg (I believe the trend is to drop such messages and not add them [back]?)
On Wed, May 13, 2026 at 09:44:18AM -0700, Alex Tran wrote:
> SCMI client drivers do not consistently log the number of supported
> entities discovered from firmware. This information is useful during
> debugging because it shows which domains or resources were exposed by
> firmware during probe.
>
> Add logging of the number of supported entities to the SCMI cpufreq,
> pinctrl, reset, hwmon, and powercap client drivers after a successful
> probe. This aligns these drivers with the existing logging in the SCMI
> power and performance domain drivers.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: media: sun4i-a10-video-engine: Fix IOMMU count for H6
From: Rob Herring (Arm) @ 2026-05-13 18:03 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: linux-staging, linux-kernel, Conor Dooley, Paul Kocialkowski,
linux-arm-kernel, Maxime Ripard, Krzysztof Kozlowski,
Samuel Holland, Jernej Skrabec, Greg Kroah-Hartman, devicetree,
Mauro Carvalho Chehab, linux-media, linux-sunxi
In-Reply-To: <20260505134812.408316-2-wens@kernel.org>
On Tue, 05 May 2026 21:48:05 +0800, Chen-Yu Tsai wrote:
> On the H6 SoC, the Video Engine has two memory ports, thus two IOMMU
> connections. The secondary one that is missing is likely used for
> reading reference frames. The newer H616 is the same. On the other
> hand, the D1 only has one memory port.
>
> Add the missing IOMMU connection for the Video Engine.
>
> Fixes: 62a8ccf3a248 ("arm64: dts: allwinner: h6: Fix Cedrus IOMMU usage")
> Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
> ---
> .../allwinner,sun4i-a10-video-engine.yaml | 21 ++++++++++++++++++-
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/7] dt-bindings: media: sun4i-a10-video-engine: Fix SRAM count for H6
From: Rob Herring (Arm) @ 2026-05-13 18:02 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: linux-media, Paul Kocialkowski, linux-sunxi, linux-arm-kernel,
Krzysztof Kozlowski, Greg Kroah-Hartman, linux-kernel,
Mauro Carvalho Chehab, Samuel Holland, Jernej Skrabec,
Maxime Ripard, Conor Dooley, devicetree, linux-staging
In-Reply-To: <20260505134812.408316-3-wens@kernel.org>
On Tue, 05 May 2026 21:48:06 +0800, Chen-Yu Tsai wrote:
> On the H6, the SRAM C region includes an alias of part of the VE SRAM
> used by the video engine. This region should also be claimed so that no
> access happens through the alias window.
>
> Add a second SRAM region phandle to the video engine for the H6.
>
> Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
> ---
> .../allwinner,sun4i-a10-video-engine.yaml | 21 ++++++++++++++++++-
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 5/8] dt-bindings: arm: ras: Introduce bindings for ARM AEST
From: Rob Herring @ 2026-05-13 17:58 UTC (permalink / raw)
To: Umang Chheda
Cc: Ruidong Tian, Tony Luck, Borislav Petkov, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, catalin.marinas,
will, lpieralisi, rafael, mark.rutland, Sudeep Holla,
linux-arm-msm, linux-acpi, linux-arm-kernel, linux-edac,
linux-kernel, devicetree
In-Reply-To: <20260505-aest-devicetree-support-v1-5-d5d6ffacf0a5@oss.qualcomm.com>
On Tue, May 05, 2026 at 05:53:49PM +0530, Umang Chheda wrote:
> The Arm Error Source Table (AEST) specification describes how firmware
> exposes RAS error source topology to the operating system. On ACPI
> systems this information is provided via the AEST ACPI table.
>
> Introduce Device Tree bindings that provide an equivalent description
> of AEST error sources for DT-based platforms.
>
> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
> ---
> .../devicetree/bindings/arm/arm,aest.yaml | 406 +++++++++++++++++++++
> include/dt-bindings/arm/aest.h | 43 +++
> 2 files changed, 449 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/arm,aest.yaml b/Documentation/devicetree/bindings/arm/arm,aest.yaml
> new file mode 100644
> index 000000000000..7809a0d38270
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/arm,aest.yaml
> @@ -0,0 +1,406 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/arm,aest.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Arm Error Source Table (AEST)
> +
> +maintainers:
> + - Umang Chheda <umang.chheda@oss.qualcomm.com>
> +
> +description:
> + The Arm Error Source Table (AEST) describes RAS error sources and their
> + register interfaces. Each error source exposes one or more error records
> + through either system registers or a memory-mapped register window, and
> + may signal errors via interrupts. The top-level node acts as a container
> + for one or more child nodes, each describing a single AEST error source.
> + Refer to the Arm AEST specification (DEN0085 / DDI 0587B) for details.
> + Flag bit constants for use in DT source files are defined in
> + <dt-bindings/arm/aest.h>.
> +
> +properties:
> + compatible:
> + const: arm,aest
> +
> + "#address-cells":
> + const: 2
> +
> + "#size-cells":
> + const: 2
> +
> + ranges: true
> +
> +required:
> + - compatible
> +
> +additionalProperties: false
> +
> +patternProperties:
> + "^aest-[a-z0-9-]+(@[0-9a-f]+)?$":
> + type: object
> + description:
> + An AEST error source node describing one error source defined by
> + the Arm AEST specification.
> +
> + properties:
> + compatible:
> + description:
> + Identifies the type of AEST error source. Each value corresponds to
> + a distinct error source class defined by the Arm AEST specification.
> + arm,aest-proxy represents a proxy error source that forwards errors
> + from another error source.
> + enum:
> + - arm,aest-processor
> + - arm,aest-memory
> + - arm,aest-smmu
> + - arm,aest-gic
> + - arm,aest-pcie
> + - arm,aest-vendor
> + - arm,aest-proxy
This is a fundamental difference how DT and ACPI get structured. ACPI
defines new table for some feature and puts everything in that table.
For DT, these all belong in the node for the corresponding h/w. For
example, if the GIC supports AEST, then that belongs in the GIC node.
> +
> + reg:
> + description:
> + Register ranges for the error source. Absence of reg implies
> + system-register access (interface type 0). A single range implies
> + memory-mapped access (interface type 1). Two ranges imply
> + single-record memory-mapped access (interface type 2).
> + minItems: 1
> + maxItems: 4
> +
> + reg-names:
> + description:
> + Names for the register ranges. The base error-record window is
> + unnamed (or first entry). Optional named ranges provide access to
> + the fault-injection, error-group, and interrupt-config register
> + windows defined by the AEST specification.
> + minItems: 1
> + maxItems: 4
> + items:
> + enum:
> + - fault-inject
> + - err-group
> + - irq-config
> +
> + interrupts:
> + description: Interrupts associated with the error source.
> + minItems: 1
> + maxItems: 2
> +
> + interrupt-names:
> + description: Names of the interrupts associated with the error source.
> + minItems: 1
> + maxItems: 2
> + items:
> + enum:
> + - fhi
> + - eri
> +
> + arm,fhi-flags:
> + description:
> + Bitmask of flags for the fault-handling interrupt (FHI), as defined
> + in the AEST node interrupt structure flags field. Constants are
> + defined in <dt-bindings/arm/aest.h> - AEST_IRQ_MODE_LEVEL (0),
> + AEST_IRQ_MODE_EDGE (1).
DT already has a way to define interrupt flags. Why invent something
new?
Rob
^ permalink raw reply
* Re: [PATCH 8/8] arm64: dts: qcom: kaanapali-qrd: Enable GPU
From: Dmitry Baryshkov @ 2026-05-13 17:54 UTC (permalink / raw)
To: Akhil P Oommen
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sean Paul,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm,
freedreno, dri-devel
In-Reply-To: <20260512-kaana-gpu-dt-v1-8-13e1c07c2050@oss.qualcomm.com>
On Tue, May 12, 2026 at 03:53:22AM +0530, Akhil P Oommen wrote:
> Add the secure firmware name property and enable GPU support on
> Kaanapali QRD device.
>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 7/8] arm64: dts: qcom: kaanapali-mtp: Enable GPU
From: Dmitry Baryshkov @ 2026-05-13 17:54 UTC (permalink / raw)
To: Akhil P Oommen
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sean Paul,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm,
freedreno, dri-devel
In-Reply-To: <20260512-kaana-gpu-dt-v1-7-13e1c07c2050@oss.qualcomm.com>
On Tue, May 12, 2026 at 03:53:21AM +0530, Akhil P Oommen wrote:
> Add the secure firmware name property and enable GPU support on
> Kaanapali MTP device.
>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 6/8] arm64: dts: qcom: kaanapali: Add GPU cooling
From: Dmitry Baryshkov @ 2026-05-13 17:53 UTC (permalink / raw)
To: Akhil P Oommen
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sean Paul,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm,
freedreno, dri-devel, Gaurav Kohli
In-Reply-To: <20260512-kaana-gpu-dt-v1-6-13e1c07c2050@oss.qualcomm.com>
On Tue, May 12, 2026 at 03:53:20AM +0530, Akhil P Oommen wrote:
> From: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
>
> Unlike the CPU, the GPU does not throttle its speed automatically when it
> reaches high temperatures.
>
> Set up GPU cooling by throttling the GPU speed
> when reaching 105°C.
>
> Signed-off-by: Gaurav Kohli <gaurav.kohli@oss.qualcomm.com>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/kaanapali.dtsi | 165 ++++++++++++++++++++++++++------
> 1 file changed, 135 insertions(+), 30 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> index c57aea44218e..5089416ec32c 100644
> --- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
> @@ -26,6 +26,7 @@
> #include <dt-bindings/soc/qcom,gpr.h>
> #include <dt-bindings/soc/qcom,rpmh-rsc.h>
> #include <dt-bindings/sound/qcom,q6dsp-lpass-ports.h>
> +#include <dt-bindings/thermal/thermal.h>
>
> #include "kaanapali-ipcc.h"
>
> @@ -7045,13 +7046,15 @@ nsphmx-3-critical {
> };
>
> gpuss-0-thermal {
> + polling-delay-passive = <200>;
Other DT files use 10 for GPU thermal zones polling interval.
> +
> thermal-sensors = <&tsens5 0>;
>
> trips {
> - gpuss-0-hot {
> - temperature = <120000>;
> + gpuss_0_alert0: gpuss-0-alert0 {
> + temperature = <105000>;
> hysteresis = <5000>;
> - type = "hot";
> + type = "passive";
> };
Why don't we keep both passive and hot trip points?
>
> gpuss-0-critical {
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu-v3-sva: Enable Hardware Access and Hardware Dirty bits
From: Pranjal Shrivastava @ 2026-05-13 17:38 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Will Deacon, Nicolin Chen, Robin Murphy, Joerg Roedel,
Jean-Philippe Brucker, Catalin Marinas, Mikołaj Lenczewski,
linux-arm-kernel, iommu, linux-kernel
In-Reply-To: <20260513143213.GA787748@nvidia.com>
On Wed, May 13, 2026 at 11:32:13AM -0300, Jason Gunthorpe wrote:
> On Wed, May 13, 2026 at 02:27:48PM +0000, Pranjal Shrivastava wrote:
>
> > Now, if we're work on an SVA page, with only SMMU supporting HTTU. A DMA
> > writes to the page and the process (CPU) calls fsync(). IIUC, it performs
> > a lookup in the Page Cache specifically for folios tagged as DIRTY.
> > Since, vmscan didn't run yet, this could potentally drop the writes..
>
> How does it work differently in the MM when the CPU has BBM support?
Hmm... I looked at fsync and I see that it eventually calls
folio_mkclean() (via writeback [1]), which performs an rmap_walk() [2]
to harvest dirty bits from PTEs into the respective struct folios.
Similarly, the vm_scan path does the same thing via try_to_unmap [3].
Since the MM subsystem actively scans the tables during writeback, it
doesn't matter if the dirty bits were flipped asynchronously by HW (w/o
kernel traps).
I guess that settles it, we don't need to gate this behind cpu_has_hw_af()
and we need not care about the CONFIG_ARM64_HW_AFDBM either.
Reviewed by: Pranjal Shrivastava <praan@google.com>
Thanks,
Praan
[1] https://elixir.bootlin.com/linux/v7.1-rc3/source/mm/page-writeback.c#L2905
[2] https://elixir.bootlin.com/linux/v7.1-rc3/source/mm/rmap.c#L1103
[3] https://elixir.bootlin.com/linux/v7.1-rc3/source/mm/rmap.c#L2164
^ permalink raw reply
* Re: [PATCH v4 04/13] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
From: Jason Gunthorpe @ 2026-05-13 17:24 UTC (permalink / raw)
To: Mostafa Saleh
Cc: Aneesh Kumar K.V (Arm), iommu, linux-arm-kernel, linux-kernel,
linux-coco, Robin Murphy, Marek Szyprowski, Will Deacon,
Marc Zyngier, Steven Price, Suzuki K Poulose, Catalin Marinas,
Jiri Pirko, Petr Tesarik, Alexey Kardashevskiy, Dan Williams,
Xu Yilun, linuxppc-dev, linux-s390, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP),
Alexander Gordeev, Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <agSKQrSIhizCXKwx@google.com>
On Wed, May 13, 2026 at 02:27:14PM +0000, Mostafa Saleh wrote:
> > + /*
> > + * if platform supports memory encryption,
> > + * restricted mem pool is decrypted by default
> > + */
> > + if (cc_platform_has(CC_ATTR_MEM_ENCRYPT)) {
> > + mem->unencrypted = true;
> > + set_memory_decrypted((unsigned long)phys_to_virt(rmem->base),
> > + rmem->size >> PAGE_SHIFT);
> > + } else {
> > + mem->unencrypted = false;
> > + }
>
> This breaks pKVM as it doesn’t set CC_ATTR_MEM_ENCRYPT, so all virtio
> traffic now fails.
How will pKVM signal what kind of memory the DMA needs then?
Does it use set_memory_decrypted()? How can it use
set_memory_decrypted() without offering CC_ATTR_MEM_ENCRYPT ?
> Also, by design, some drivers are clueless about bouncing, so
Oh? What does this mean? We take quite a dim view of drivers mis-using
the DMA API..
> I believe that the pool should have a way to control it’s property
> (encrypted or decrypted) and that takes priority over whatever
> attributes comes from allocation.
We should get here because dma_capable() fails, and then swiotlb needs
to return something that makes dma_capable() succeed. Yes, it should
return details about the thing it decided, but it shouldn't have been
pre-created with some idea how to make dma_capable() work.
If dma_capable() can fail, then swiotlb should know exactly what to do
to fix it.
If pkvm wants to use the hacky scheme where you force a swiotlb pool
configuration during arch init with force swiotlb that's a somewhat
different flow and, sure the forced pool should force do whatever it
is forced to.
But lets try to keep them seperated in the discussion..
> And that brings us to the same point whether it’s better to return
> the memory along with it’s state or we pass the requested state.
> I think for other cases it’s fine for the device/DMA-API to dictate
> the attrs, but not in restricted-dma case, the firmware just knows better.
The memory type must be returned back at some level so downstream
things can do the right transformation of the phys_addr_t.
One of the aspirational CC things that should work is a T=1 device
tries to DMA from a decrypted page, finds the address is above the dma
limit of the device, so it bounces it with SWIOTLB to an encrypted low
address page and then the DMA API internal flow switiches from working
with decrypted to encrypted phys_addr_t.
If we can make that work then maybe the flows are designed correctly.
Jason
^ permalink raw reply
* Re: [PATCH v3 0/2] arm_ffa, KVM: Fix FF-A emad offset calculations
From: Sudeep Holla @ 2026-05-13 17:23 UTC (permalink / raw)
To: Sebastian Ene
Cc: catalin.marinas, maz, oupton, Sudeep Holla, will, joey.gouly,
korneld, kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
mrigendra.chaubey, perlarsen, suzuki.poulose, vdonnefort,
yuzenghui
In-Reply-To: <20260512124442.1899107-1-sebastianene@google.com>
On Tue, May 12, 2026 at 12:44:40PM +0000, Sebastian Ene wrote:
> Hi all,
>
> This series fixes the Endpoint Memory Access Descriptor (EMAD) offset calculations
> and adds the necessary bounds checks for both the core FF-A driver and the pKVM
> hypervisor.
>
> Prior to FF-A version 1.1, the memory region header didn't specify an explicit offset
> for the EMADs, leading to the assumption that they immediately follow the header.
> However, from v1.1 onwards, the specification dictates using the `ep_mem_offset` field
> to determine the start of the memory access array.
>
> The patches in this series address this by:
> 1. Updating the core `arm_ffa` firmware driver to correctly calculate the descriptor
> offset using `ep_mem_offset` rather than defaulting to `sizeof(struct ffa_mem_region)`.
> It also introduces bounds checking against `max_fragsize`.
> 2. Enhancing the pKVM hypervisor validation logic to no longer strictly enforce that
> the descriptor strictly follows the header, aligning it with the driver behavior
> and the FF-A specification, while also ensuring the offset falls within the mailbox
> buffer bounds.
>
Looks good apart from the minor nits, but how do you plan to route these
changes as they are dependent for functionality but not for the build IIUC.
I don't think I have any conflicting change so far, so it can go along with
other pKVM changes. Let me know.
> Changelog
> #########
>
> v2 -> this:
> - Fixed typo in nvhe/ffa.c (missing sizeof)
>
> v1 -> v2:
> - For pKVM, removed the strict placement enforcement for `ep_mem_offset` as it is not
> compliant with the spec, and avoids making assumptions about the driver's memory
> layout.
>
> Link to:
> ########
>
> v2: https://lore.kernel.org/all/20260430160241.1934777-1-sebastianene@google.com/
> v1: https://lore.kernel.org/all/ae9KN9nkOgDYJcGP@google.com/T/#t
>
> Sebastian Ene (2):
> firmware: arm_ffa: Fix Endpoint Memory Access Descriptor offset
> calculation
> KVM: arm64: Validate the offset to the mem access descriptor
>
> arch/arm64/kvm/hyp/nvhe/ffa.c | 24 ++++++++++++++++++------
> drivers/firmware/arm_ffa/driver.c | 14 ++++++++++----
> include/linux/arm_ffa.h | 2 +-
> 3 files changed, 29 insertions(+), 11 deletions(-)
>
> --
> 2.54.0.563.g4f69b47b94-goog
>
--
Regards,
Sudeep
^ 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