* RE: [PATCH 01/11] net: wwan: t9xx: Add PCIe core
From: Wu. JackBB (GSM) @ 2026-06-10 10:40 UTC (permalink / raw)
To: Jagielski, Jedrzej, 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, wojackbb@gmail.com
Cc: 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: <PH0PR11MB5902127C590230B9FE50F78AF0152@PH0PR11MB5902.namprd11.prod.outlook.com>
Hi Jagielski,
Thank you for the detailed review. Below are the changes and responses
for v2.
> > +#define BAR_NUM6
>
> please add driver prefix
Renamed to MTK_PCI_BAR_NUM at v2.
> > +#define SET_HW_BITS(dest, chs, mhccif, dev)\
> > +({\
> > +if ((chs) & (dev))
>
> what if any of these is equal to 0?
> just skip do not log anything?
This macro converts SW event bits to HW channel bits. The callers
always pass valid non-zero values for chs and dev. Even if either
is zero, the bitwise AND produces zero, so dest remains unchanged
and writing zero to the hardware will not trigger any event. This is
a safe no-op and does not warrant a warning or error log.
> > +u32 mtk_pci_mac_read32(struct mtk_pci_priv *priv, u64 addr)
> > +{
> > +return ioread32(priv->mac_reg_base + addr);
> > +}
> > ...
>
> would be lovely to have kdoc of the non-static functions from the series
Converted the four MMIO wrapper functions (mtk_pci_mac_read32,
mtk_pci_mac_write32, mtk_pci_read32, mtk_pci_write32) to static
inline in the header. These are trivial one-line wrappers around
ioread32/iowrite32 and do not warrant separate function definitions.
This also reduces the overall line count.
For the remaining non-static functions, kernel-doc comments have been
added in v2.
> > +size_l = FIELD_GET(GENMASK_ULL(31, 0), cfg->size);
> > +size_h = FIELD_GET(GENMASK_ULL(63, 32), cfg->size);
> > +pos = ffs(size_l);
> > +if (pos) {
> > +atr_size = pos - 2;
> > +} else {
> > +pos = ffs(size_h);
> > +atr_size = pos + 30;
>
> i believe better would be to have some defines instead of magic
Replaced magic numbers in mtk_pci_setup_atr() with named defines:
ATR_SIZE_LO32_MASK, ATR_SIZE_HI32_MASK, ATR_SIZE_BIAS_FROM_LO32,
ATR_ADDR_ALIGN_MASK, ATR_EN, ATR_PARAM_OFFSET.
> > +}
>
> please put some breaks to have the code logically separated
Added blank lines to separate logical blocks in mtk_pci_setup_atr().
> > +/* SRC_ADDR_H */
> > +addr = REG_ATR_PCIE_WIN0_T0_SRC_ADDR_MSB + offset;
> > +...
> > +/* SRC_ADDR_L */
> > +addr = REG_ATR_PCIE_WIN0_T0_SRC_ADDR_LSB + offset;
> > +...
> > +/* TRSL_ADDR_H */
> > +...
> > +/* TRSL_ADDR_L */
>
> comments seem to be redundant imo; clearer would be to have just newline
> instead
Replaced redundant inline comments with blank line separators.
> > +/* TRSL_PARAM */
> > +addr = REG_ATR_PCIE_WIN0_T0_TRSL_PARAM + offset;
> > +val = (cfg->trsl_param << 16) | cfg->trsl_id;
>
> again a lot of magic here
Replaced with ATR_PARAM_OFFSET define.
> > +int nr = 0;
>
> what's the point of zeroiniting if the value is assigned at
> the next line?
Removed the zero initialization and simplified the function. Also
added a guard for irq_cnt == 0 and irq_id < 0.
> > +nr = irq_id % priv->irq_cnt;
>
> are we sure irq_cnt won't be equal to 0 in any scenario?
Added a !priv->irq_cnt guard that returns -EINVAL before the modulo
operation. Also added an irq_id < 0 check for completeness.
> > +if (unlikely(irq_id < 0 || irq_id >= MTK_IRQ_CNT_MAX))
> > +return -EINVAL;
>
> is it anyhow beneficial to put unlikely here and in case of other
> appearances within the series?
Removed unlikely() from the IRQ parameter validation checks in
mtk_pci_get_irq_id(), mtk_pci_register_irq(),
mtk_pci_unregister_irq(), mtk_pci_mask_irq(),
mtk_pci_unmask_irq(), and mtk_pci_clear_irq(). These are not
hot paths and the branch hint provides no measurable benefit here.
> > +if (unlikely((irq_id < 0 || irq_id >= MTK_IRQ_CNT_MAX) || priv->irq_type != PCI_IRQ_MSIX)) {
>
> same here
Same as above, removed unlikely().
> > +void mtk_pci_mask_ext_evt(struct mtk_md_dev *mdev, u32 chs)
> > +{
> > +struct mtk_pci_priv *priv = mdev->hw_priv;
> > +u32 hw_bits;
> > +
> > +hw_bits = mtk_pci_ext_d2h_evt_hw_bits(chs);
>
> one of these is inited at declaration, 2nd one isnt
> please stay consistant, @hw_bits can be inited as well
Fixed. hw_bits is now initialized at declaration in
mtk_pci_mask_ext_evt(), mtk_pci_unmask_ext_evt(), and
mtk_pci_clear_ext_evt().
> > +int mtk_pci_send_ext_evt(struct mtk_md_dev *mdev, u32 ch)
> > +{
> > +struct mtk_pci_priv *priv = mdev->hw_priv;
> > +u32 rc_base;
> > +u32 hw_bits;
>
> missing kdoc here and there
Added kernel-doc comments to all non-static functions in v2.
> please squash variables of the same type into single line
Merged rc_base and hw_bits into a single declaration line.
> > +#else
>
> #else /* !CONFIG_ACPI */
Added comments to #else and #endif preprocessor directives.
> > +#endif
>
> #endif /* CONFIG_ACPI */
Done.
> > +msleep(500);
>
> please dont use magic number
> also where this value has been derived from?
Replaced with MTK_PLDR_POWER_OFF_DELAY_MS define. This 500ms delay
is the minimum time required by the MediaTek modem hardware to
complete the power-off sequence before re-initialization can begin.
> > +acpi_os_free(buffer.pointer);
>
> pleae add some newlines
Added newlines in mtk_pci_pldr() for better readability.
> > +default:
> > +break;
> > +}
> > +
> > +return -EINVAL;
>
> please put return into default label
Moved return -EINVAL into the default case label.
> > +struct mtk_pci_priv *priv = container_of(work, struct mtk_pci_priv, mhccif_work);
>
> isn't this line > 80 chars?
Wrapped the container_of line to stay within 80 columns.
> > +dev_err((mdev)->dev, "Failed to get mhccif_irq_id. ret=%d\n", ret);
> > +goto err;
>
> why cannot just return ret?
Simplified mtk_mhccif_init() to return directly instead of using
a goto label.
> > +dev_err((mdev)->dev, "Failed to register mhccif_irq callback\n");
> > +goto err;
>
> it's redundant
Removed the redundant goto. The function now returns directly.
> > +do {
> > +irq_id = fls(irq_state) - 1;
>
> are we sure irq_state cannot be 0?
The caller mtk_pci_irq_msix() already checks !irq_state and returns
IRQ_NONE before reaching mtk_pci_irq_handler(). So irq_state is
guaranteed to be non-zero when the handler is invoked.
> > +if (mtk_pci_link_check(mdev)) {
> > +pci_save_state(pdev);
> > +} else {
> > +ret = -EFAULT;
> > +goto clear_master;
>
> #defineEFAULT14/* Bad address */
> does it suit here?
Changed the error code from -EFAULT to -ENOLINK, which better
describes a PCIe link failure.
> > +mdev = devm_kzalloc(dev, sizeof(*mdev), GFP_KERNEL);
> > +if (!mdev) {
> > +ret = -ENOMEM;
> > +goto out;
>
> as for the rest of the labels please name what is done
> eg log_err
Renamed goto label "out" to "log_err".
> please also take a look on sashiko notes, there is some number of them
Addressed. The items from sashiko's review have been incorporated
into this revision.
Thanks.
Jack Wu
================================================================================================================================================================
This message may contain information which is private, privileged or confidential of Compal Electronics, Inc. If you are not the intended recipient of this message, please notify the sender and destroy/delete the message. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited.
================================================================================================================================================================
^ permalink raw reply
* Re: [PATCH v17 21/28] drm/tests: bridge: Add KUnit tests for bridge chain format selection
From: Jani Nikula @ 2026-06-10 10:32 UTC (permalink / raw)
To: Nicolas Frattaroli, Harry Wentland, Leo Li, Rodrigo Siqueira,
Alex Deucher, Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, Daniel Stone
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel,
Nicolas Frattaroli
In-Reply-To: <20260609-color-format-v17-21-35739b5782cc@collabora.com>
On Tue, 09 Jun 2026, Nicolas Frattaroli <nicolas.frattaroli@collabora.com> wrote:
> diff --git a/drivers/gpu/drm/tests/drm_bridge_test.c b/drivers/gpu/drm/tests/drm_bridge_test.c
> index 64b665580a88..92f142ca6695 100644
> --- a/drivers/gpu/drm/tests/drm_bridge_test.c
> +++ b/drivers/gpu/drm/tests/drm_bridge_test.c
> @@ -2,15 +2,23 @@
> /*
> * Kunit test for drm_bridge functions
> */
> +#include <linux/cleanup.h>
> +#include <linux/media-bus-format.h>
> +
> #include <drm/drm_atomic_state_helper.h>
> +#include <drm/drm_atomic_uapi.h>
> #include <drm/drm_bridge.h>
> #include <drm/drm_bridge_connector.h>
> #include <drm/drm_bridge_helper.h>
> +#include <drm/drm_edid.h>
> #include <drm/drm_kunit_helpers.h>
> +#include <drm/drm_managed.h>
>
> #include <kunit/device.h>
> #include <kunit/test.h>
>
> +#include "drm_kunit_edid.h"
So here's the problem with adding *any* arrays into headers: every
compilation unit that includes them duplicates all the arrays. It's only
really okay for single use.
And, in this case, most of the included arrays are unused, leading to
build failures:
CC [M] drivers/gpu/drm/tests/drm_bridge_test.o
In file included from ../drivers/gpu/drm/tests/drm_bridge_test.c:21:
../drivers/gpu/drm/tests/drm_kunit_edid.h:958:28: error: ‘test_edid_hdmi_4k_rgb_yuv420_dc_max_340mhz’ defined but not used [-Werror=unused-const-variable=]
958 | static const unsigned char test_edid_hdmi_4k_rgb_yuv420_dc_max_340mhz[] = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../drivers/gpu/drm/tests/drm_kunit_edid.h:726:28: error: ‘test_edid_hdmi_1080p_rgb_yuv_dc_max_340mhz’ defined but not used [-Werror=unused-const-variable=]
726 | static const unsigned char test_edid_hdmi_1080p_rgb_yuv_dc_max_340mhz[] = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../drivers/gpu/drm/tests/drm_kunit_edid.h:612:28: error: ‘test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz’ defined but not used [-Werror=unused-const-variable=]
612 | static const unsigned char test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz[] = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../drivers/gpu/drm/tests/drm_kunit_edid.h:498:28: error: ‘test_edid_hdmi_1080p_rgb_max_340mhz’ defined but not used [-Werror=unused-const-variable=]
498 | static const unsigned char test_edid_hdmi_1080p_rgb_max_340mhz[] = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../drivers/gpu/drm/tests/drm_kunit_edid.h:390:28: error: ‘test_edid_hdmi_1080p_rgb_max_200mhz_hdr’ defined but not used [-Werror=unused-const-variable=]
390 | static const unsigned char test_edid_hdmi_1080p_rgb_max_200mhz_hdr[] = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../drivers/gpu/drm/tests/drm_kunit_edid.h:271:28: error: ‘test_edid_hdmi_1080p_rgb_max_200mhz’ defined but not used [-Werror=unused-const-variable=]
271 | static const unsigned char test_edid_hdmi_1080p_rgb_max_200mhz[] = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../drivers/gpu/drm/tests/drm_kunit_edid.h:163:28: error: ‘test_edid_hdmi_1080p_rgb_max_100mhz’ defined but not used [-Werror=unused-const-variable=]
163 | static const unsigned char test_edid_hdmi_1080p_rgb_max_100mhz[] = {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../drivers/gpu/drm/tests/drm_kunit_edid.h:57:28: error: ‘test_edid_dvi_1080p’ defined but not used [-Werror=unused-const-variable=]
57 | static const unsigned char test_edid_dvi_1080p[] = {
| ^~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
This breaks the build for me, I don't know how it didn't for any of you.
Reverting these two fixes it:
ce1d0139adac ("drm/tests: bridge: Add test for HDMI output bus formats helper")
082fbc179c01 ("drm/tests: bridge: Add KUnit tests for bridge chain format selection")
I think the proper fix would be to move the arrays into a .c file, and
only have declarations in the headers. But that needs to happen real
soon or the commits need to be reverted.
BR,
Jani.
--
Jani Nikula, Intel
^ permalink raw reply
* Re: [PATCH] spi: meson-spifc: fix runtime PM leak on remove
From: Mark Brown @ 2026-06-09 23:06 UTC (permalink / raw)
To: linux-spi, Ruoyu Wang
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Beniamino Galvani, linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <20260609052647.5-1-ruoyuw560@gmail.com>
On Tue, 09 Jun 2026 13:26:47 +0800, Ruoyu Wang wrote:
> spi: meson-spifc: fix runtime PM leak on remove
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.2
Thanks!
[1/1] spi: meson-spifc: fix runtime PM leak on remove
https://git.kernel.org/broonie/spi/c/606c0826bd90
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: remoteproc: imx_rproc: document optional "memory-region-names"
From: Francesco Dolcini @ 2026-06-10 10:22 UTC (permalink / raw)
To: Laurentiu Mihalcea
Cc: Krzysztof Kozlowski, Bjorn Andersson, Mathieu Poirier,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Peng Fan, Fabio Estevam, Daniel Baluta, Francesco Dolcini,
linux-remoteproc, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <2fc48536-5af9-419e-b4df-746b678cb6ab@gmail.com>
On Wed, Jun 10, 2026 at 02:10:37AM -0700, Laurentiu Mihalcea wrote:
>
>
> On 6/10/2026 12:37 AM, Krzysztof Kozlowski wrote:
> > On Fri, Jun 05, 2026 at 04:36:18AM -0700, Laurentiu Mihalcea wrote:
> >> From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
> >>
> >> The names of the carveout regions are derived using the names of the
> >> reserved memory devicetree nodes, which are referenced using the
> >> "memory-region" property. This adds a restriction on the names of said
> >> devicetree nodes, often bearing specific names such as: "vdevbuffer",
> >> "vdev0vring0", "rsc-table", etc... This goes against the devicetree
> >> specification's recommendation, which states that the devicetree node
> >> names should be generic.
> >
> > No, it does not. Names like rsc-table feels exactly like DT spec is
> > asking - for a name matching purpose. Are you sure you read the spec?
>
> Quoting from the spec:
>
> "The name of a node should be somewhat generic, reflecting the function of the
> device and not its precise programming model"
>
> and looking at the examples provided in "2.2.2 Generic Names Recommendation",
> wouldn't "memory" be a more appropriate choice for the DT node name instead of
> "rsc-table" since it's more generic, while still matching the purpose
> of the device? Or perhaps I'm interpreting this the wrong way?
Please see
https://lore.kernel.org/all/CAL_JsqKRW-=er+DCTob0HmQv9OyVt7yiej-Yht6UR-mcW=LHUg@mail.gmail.com/
Francesco
^ permalink raw reply
* [PATCH] ASoC: meson: axg-tdm-formatter: Use guard() for mutex locks
From: phucduc.bui @ 2026-06-10 10:21 UTC (permalink / raw)
To: Mark Brown, Jerome Brunet
Cc: Liam Girdwood, Neil Armstrong, Kevin Hilman, Martin Blumenstingl,
Jaroslav Kysela, Takashi Iwai, linux-sound, linux-arm-kernel,
linux-amlogic, linux-kernel, bui duc phuc
From: bui duc phuc <phucduc.bui@gmail.com>
Clean up the code using guard() for mutex locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/meson/axg-tdm-formatter.c | 22 ++++++++--------------
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/sound/soc/meson/axg-tdm-formatter.c b/sound/soc/meson/axg-tdm-formatter.c
index f451e4dce442..a6ba401104d5 100644
--- a/sound/soc/meson/axg-tdm-formatter.c
+++ b/sound/soc/meson/axg-tdm-formatter.c
@@ -157,20 +157,19 @@ static int axg_tdm_formatter_attach(struct axg_tdm_formatter *formatter)
struct axg_tdm_stream *ts = formatter->stream;
int ret = 0;
- mutex_lock(&ts->lock);
+ guard(mutex)(&ts->lock);
/* Catch up if the stream is already running when we attach */
if (ts->ready) {
ret = axg_tdm_formatter_enable(formatter);
if (ret) {
pr_err("failed to enable formatter\n");
- goto out;
+ return ret;
}
}
list_add_tail(&formatter->list, &ts->formatter_list);
-out:
- mutex_unlock(&ts->lock);
+
return ret;
}
@@ -178,9 +177,8 @@ static void axg_tdm_formatter_dettach(struct axg_tdm_formatter *formatter)
{
struct axg_tdm_stream *ts = formatter->stream;
- mutex_lock(&ts->lock);
- list_del(&formatter->list);
- mutex_unlock(&ts->lock);
+ scoped_guard(mutex, &ts->lock)
+ list_del(&formatter->list);
axg_tdm_formatter_disable(formatter);
}
@@ -330,7 +328,7 @@ int axg_tdm_stream_start(struct axg_tdm_stream *ts)
struct axg_tdm_formatter *formatter;
int ret = 0;
- mutex_lock(&ts->lock);
+ guard(mutex)(&ts->lock);
ts->ready = true;
/* Start all the formatters attached to the stream */
@@ -338,12 +336,10 @@ int axg_tdm_stream_start(struct axg_tdm_stream *ts)
ret = axg_tdm_formatter_enable(formatter);
if (ret) {
pr_err("failed to start tdm stream\n");
- goto out;
+ return ret;
}
}
-out:
- mutex_unlock(&ts->lock);
return ret;
}
EXPORT_SYMBOL_GPL(axg_tdm_stream_start);
@@ -352,15 +348,13 @@ void axg_tdm_stream_stop(struct axg_tdm_stream *ts)
{
struct axg_tdm_formatter *formatter;
- mutex_lock(&ts->lock);
+ guard(mutex)(&ts->lock);
ts->ready = false;
/* Stop all the formatters attached to the stream */
list_for_each_entry(formatter, &ts->formatter_list, list) {
axg_tdm_formatter_disable(formatter);
}
-
- mutex_unlock(&ts->lock);
}
EXPORT_SYMBOL_GPL(axg_tdm_stream_stop);
--
2.43.0
^ permalink raw reply related
* [PATCH 10/10] ASoC: mediatek: mt8195: mt8365-dai-i2s: Use guard() for spin locks
From: phucduc.bui @ 2026-06-10 10:20 UTC (permalink / raw)
To: Mark Brown, Matthias Brugger
Cc: Liam Girdwood, AngeloGioacchino Del Regno, Linus Walleij,
Bartosz Golaszewski, Jaroslav Kysela, Takashi Iwai, linux-sound,
linux-arm-kernel, linux-mediatek, linux-kernel, linux-gpio,
bui duc phuc
In-Reply-To: <20260610102021.83273-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Clean up the code using guard() for spin locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/mediatek/mt8365/mt8365-dai-i2s.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/sound/soc/mediatek/mt8365/mt8365-dai-i2s.c b/sound/soc/mediatek/mt8365/mt8365-dai-i2s.c
index cb9beb172ed5..a058973662b3 100644
--- a/sound/soc/mediatek/mt8365/mt8365-dai-i2s.c
+++ b/sound/soc/mediatek/mt8365/mt8365-dai-i2s.c
@@ -463,7 +463,6 @@ static int mt8365_afe_set_2nd_i2s_asrc_enable(struct mtk_base_afe *afe,
void mt8365_afe_set_i2s_out_enable(struct mtk_base_afe *afe, bool enable)
{
int i;
- unsigned long flags;
struct mt8365_afe_private *afe_priv = afe->platform_priv;
struct mtk_afe_i2s_priv *i2s_data = NULL;
@@ -475,7 +474,7 @@ void mt8365_afe_set_i2s_out_enable(struct mtk_base_afe *afe, bool enable)
if (!i2s_data)
return;
- spin_lock_irqsave(&afe_priv->afe_ctrl_lock, flags);
+ guard(spinlock_irqsave)(&afe_priv->afe_ctrl_lock);
if (enable) {
i2s_data->i2s_out_on_ref_cnt++;
@@ -490,8 +489,6 @@ void mt8365_afe_set_i2s_out_enable(struct mtk_base_afe *afe, bool enable)
else if (i2s_data->i2s_out_on_ref_cnt < 0)
i2s_data->i2s_out_on_ref_cnt = 0;
}
-
- spin_unlock_irqrestore(&afe_priv->afe_ctrl_lock, flags);
}
static void mt8365_dai_set_enable(struct mtk_base_afe *afe,
--
2.43.0
^ permalink raw reply related
* [PATCH 09/10] ASoC: mediatek: mt8195: mt8365-dai-adda: Use guard() for spin locks
From: phucduc.bui @ 2026-06-10 10:20 UTC (permalink / raw)
To: Mark Brown, Matthias Brugger
Cc: Liam Girdwood, AngeloGioacchino Del Regno, Linus Walleij,
Bartosz Golaszewski, Jaroslav Kysela, Takashi Iwai, linux-sound,
linux-arm-kernel, linux-mediatek, linux-kernel, linux-gpio,
bui duc phuc
In-Reply-To: <20260610102021.83273-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Clean up the code using guard() for spin locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/mediatek/mt8365/mt8365-dai-adda.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/sound/soc/mediatek/mt8365/mt8365-dai-adda.c b/sound/soc/mediatek/mt8365/mt8365-dai-adda.c
index a04c24bbfcff..d8eda9e17eb8 100644
--- a/sound/soc/mediatek/mt8365/mt8365-dai-adda.c
+++ b/sound/soc/mediatek/mt8365/mt8365-dai-adda.c
@@ -63,10 +63,9 @@ static int mt8365_dai_set_adda_in(struct mtk_base_afe *afe, unsigned int rate)
int mt8365_dai_enable_adda_on(struct mtk_base_afe *afe)
{
- unsigned long flags;
struct mt8365_afe_private *afe_priv = afe->platform_priv;
- spin_lock_irqsave(&afe_priv->afe_ctrl_lock, flags);
+ guard(spinlock_irqsave)(&afe_priv->afe_ctrl_lock);
adda_afe_on_ref_cnt++;
if (adda_afe_on_ref_cnt == 1)
@@ -74,17 +73,14 @@ int mt8365_dai_enable_adda_on(struct mtk_base_afe *afe)
AFE_ADDA_UL_DL_ADDA_AFE_ON,
AFE_ADDA_UL_DL_ADDA_AFE_ON);
- spin_unlock_irqrestore(&afe_priv->afe_ctrl_lock, flags);
-
return 0;
}
int mt8365_dai_disable_adda_on(struct mtk_base_afe *afe)
{
- unsigned long flags;
struct mt8365_afe_private *afe_priv = afe->platform_priv;
- spin_lock_irqsave(&afe_priv->afe_ctrl_lock, flags);
+ guard(spinlock_irqsave)(&afe_priv->afe_ctrl_lock);
adda_afe_on_ref_cnt--;
if (adda_afe_on_ref_cnt == 0)
@@ -96,8 +92,6 @@ int mt8365_dai_disable_adda_on(struct mtk_base_afe *afe)
dev_warn(afe->dev, "Abnormal adda_on ref count. Force it to 0\n");
}
- spin_unlock_irqrestore(&afe_priv->afe_ctrl_lock, flags);
-
return 0;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 08/10] ASoC: mediatek: mt8195: mt8365-afe-clk: Use guard() for mutex & spin locks
From: phucduc.bui @ 2026-06-10 10:20 UTC (permalink / raw)
To: Mark Brown, Matthias Brugger
Cc: Liam Girdwood, AngeloGioacchino Del Regno, Linus Walleij,
Bartosz Golaszewski, Jaroslav Kysela, Takashi Iwai, linux-sound,
linux-arm-kernel, linux-mediatek, linux-kernel, linux-gpio,
bui duc phuc
In-Reply-To: <20260610102021.83273-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Clean up the code using guard() for mutex & spin locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/mediatek/mt8365/mt8365-afe-clk.c | 30 +++++-----------------
1 file changed, 7 insertions(+), 23 deletions(-)
diff --git a/sound/soc/mediatek/mt8365/mt8365-afe-clk.c b/sound/soc/mediatek/mt8365/mt8365-afe-clk.c
index 7078c01ba19b..af96aa446fe2 100644
--- a/sound/soc/mediatek/mt8365/mt8365-afe-clk.c
+++ b/sound/soc/mediatek/mt8365/mt8365-afe-clk.c
@@ -194,16 +194,13 @@ int mt8365_afe_enable_top_cg(struct mtk_base_afe *afe, unsigned int cg_type)
unsigned int reg = get_top_cg_reg(cg_type);
unsigned int mask = get_top_cg_mask(cg_type);
unsigned int val = get_top_cg_on_val(cg_type);
- unsigned long flags;
- spin_lock_irqsave(&afe_priv->afe_ctrl_lock, flags);
+ guard(spinlock_irqsave)(&afe_priv->afe_ctrl_lock);
afe_priv->top_cg_ref_cnt[cg_type]++;
if (afe_priv->top_cg_ref_cnt[cg_type] == 1)
regmap_update_bits(afe->regmap, reg, mask, val);
- spin_unlock_irqrestore(&afe_priv->afe_ctrl_lock, flags);
-
return 0;
}
@@ -213,9 +210,8 @@ int mt8365_afe_disable_top_cg(struct mtk_base_afe *afe, unsigned int cg_type)
unsigned int reg = get_top_cg_reg(cg_type);
unsigned int mask = get_top_cg_mask(cg_type);
unsigned int val = get_top_cg_off_val(cg_type);
- unsigned long flags;
- spin_lock_irqsave(&afe_priv->afe_ctrl_lock, flags);
+ guard(spinlock_irqsave)(&afe_priv->afe_ctrl_lock);
afe_priv->top_cg_ref_cnt[cg_type]--;
if (afe_priv->top_cg_ref_cnt[cg_type] == 0)
@@ -223,8 +219,6 @@ int mt8365_afe_disable_top_cg(struct mtk_base_afe *afe, unsigned int cg_type)
else if (afe_priv->top_cg_ref_cnt[cg_type] < 0)
afe_priv->top_cg_ref_cnt[cg_type] = 0;
- spin_unlock_irqrestore(&afe_priv->afe_ctrl_lock, flags);
-
return 0;
}
@@ -263,25 +257,21 @@ int mt8365_afe_emi_clk_off(struct mtk_base_afe *afe)
int mt8365_afe_enable_afe_on(struct mtk_base_afe *afe)
{
struct mt8365_afe_private *afe_priv = afe->platform_priv;
- unsigned long flags;
- spin_lock_irqsave(&afe_priv->afe_ctrl_lock, flags);
+ guard(spinlock_irqsave)(&afe_priv->afe_ctrl_lock);
afe_priv->afe_on_ref_cnt++;
if (afe_priv->afe_on_ref_cnt == 1)
regmap_update_bits(afe->regmap, AFE_DAC_CON0, 0x1, 0x1);
- spin_unlock_irqrestore(&afe_priv->afe_ctrl_lock, flags);
-
return 0;
}
int mt8365_afe_disable_afe_on(struct mtk_base_afe *afe)
{
struct mt8365_afe_private *afe_priv = afe->platform_priv;
- unsigned long flags;
- spin_lock_irqsave(&afe_priv->afe_ctrl_lock, flags);
+ guard(spinlock_irqsave)(&afe_priv->afe_ctrl_lock);
afe_priv->afe_on_ref_cnt--;
if (afe_priv->afe_on_ref_cnt == 0)
@@ -289,8 +279,6 @@ int mt8365_afe_disable_afe_on(struct mtk_base_afe *afe)
else if (afe_priv->afe_on_ref_cnt < 0)
afe_priv->afe_on_ref_cnt = 0;
- spin_unlock_irqrestore(&afe_priv->afe_ctrl_lock, flags);
-
return 0;
}
@@ -322,13 +310,11 @@ int mt8365_afe_enable_apll_tuner_cfg(struct mtk_base_afe *afe, unsigned int apll
{
struct mt8365_afe_private *afe_priv = afe->platform_priv;
- mutex_lock(&afe_priv->afe_clk_mutex);
+ guard(mutex)(&afe_priv->afe_clk_mutex);
afe_priv->apll_tuner_ref_cnt[apll]++;
- if (afe_priv->apll_tuner_ref_cnt[apll] != 1) {
- mutex_unlock(&afe_priv->afe_clk_mutex);
+ if (afe_priv->apll_tuner_ref_cnt[apll] != 1)
return 0;
- }
if (apll == MT8365_AFE_APLL1) {
regmap_update_bits(afe->regmap, AFE_APLL_TUNER_CFG,
@@ -342,7 +328,6 @@ int mt8365_afe_enable_apll_tuner_cfg(struct mtk_base_afe *afe, unsigned int apll
AFE_APLL_TUNER_CFG1_EN_MASK, 0x1);
}
- mutex_unlock(&afe_priv->afe_clk_mutex);
return 0;
}
@@ -350,7 +335,7 @@ int mt8365_afe_disable_apll_tuner_cfg(struct mtk_base_afe *afe, unsigned int apl
{
struct mt8365_afe_private *afe_priv = afe->platform_priv;
- mutex_lock(&afe_priv->afe_clk_mutex);
+ guard(mutex)(&afe_priv->afe_clk_mutex);
afe_priv->apll_tuner_ref_cnt[apll]--;
if (afe_priv->apll_tuner_ref_cnt[apll] == 0) {
@@ -365,7 +350,6 @@ int mt8365_afe_disable_apll_tuner_cfg(struct mtk_base_afe *afe, unsigned int apl
afe_priv->apll_tuner_ref_cnt[apll] = 0;
}
- mutex_unlock(&afe_priv->afe_clk_mutex);
return 0;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 07/10] ASoC: mediatek: mt8195: mt8195-dai-etdm: Use guard() for spin locks
From: phucduc.bui @ 2026-06-10 10:20 UTC (permalink / raw)
To: Mark Brown, Matthias Brugger
Cc: Liam Girdwood, AngeloGioacchino Del Regno, Linus Walleij,
Bartosz Golaszewski, Jaroslav Kysela, Takashi Iwai, linux-sound,
linux-arm-kernel, linux-mediatek, linux-kernel, linux-gpio,
bui duc phuc
In-Reply-To: <20260610102021.83273-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Clean up the code using guard() for spin locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/mediatek/mt8195/mt8195-dai-etdm.c | 16 ++++++----------
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/sound/soc/mediatek/mt8195/mt8195-dai-etdm.c b/sound/soc/mediatek/mt8195/mt8195-dai-etdm.c
index 5dcc8ed26e00..1a20adb2cbf5 100644
--- a/sound/soc/mediatek/mt8195/mt8195-dai-etdm.c
+++ b/sound/soc/mediatek/mt8195/mt8195-dai-etdm.c
@@ -1318,24 +1318,22 @@ static int mt8195_afe_enable_etdm(struct mtk_base_afe *afe, int dai_id)
struct etdm_con_reg etdm_reg;
struct mt8195_afe_private *afe_priv = afe->platform_priv;
struct mtk_dai_etdm_priv *etdm_data;
- unsigned long flags;
if (!mt8195_afe_etdm_is_valid(dai_id))
return -EINVAL;
etdm_data = afe_priv->dai_priv[dai_id];
- spin_lock_irqsave(&afe_priv->afe_ctrl_lock, flags);
+ guard(spinlock_irqsave)(&afe_priv->afe_ctrl_lock);
etdm_data->en_ref_cnt++;
if (etdm_data->en_ref_cnt == 1) {
ret = get_etdm_reg(dai_id, &etdm_reg);
if (ret < 0)
- goto out;
+ return ret;
regmap_update_bits(afe->regmap, etdm_reg.con0,
ETDM_CON0_EN, ETDM_CON0_EN);
}
-out:
- spin_unlock_irqrestore(&afe_priv->afe_ctrl_lock, flags);
+
return ret;
}
@@ -1345,26 +1343,24 @@ static int mt8195_afe_disable_etdm(struct mtk_base_afe *afe, int dai_id)
struct etdm_con_reg etdm_reg;
struct mt8195_afe_private *afe_priv = afe->platform_priv;
struct mtk_dai_etdm_priv *etdm_data;
- unsigned long flags;
if (!mt8195_afe_etdm_is_valid(dai_id))
return -EINVAL;
etdm_data = afe_priv->dai_priv[dai_id];
- spin_lock_irqsave(&afe_priv->afe_ctrl_lock, flags);
+ guard(spinlock_irqsave)(&afe_priv->afe_ctrl_lock);
if (etdm_data->en_ref_cnt > 0) {
etdm_data->en_ref_cnt--;
if (etdm_data->en_ref_cnt == 0) {
ret = get_etdm_reg(dai_id, &etdm_reg);
if (ret < 0)
- goto out;
+ return ret;
regmap_update_bits(afe->regmap, etdm_reg.con0,
ETDM_CON0_EN, 0);
}
}
-out:
- spin_unlock_irqrestore(&afe_priv->afe_ctrl_lock, flags);
+
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 06/10] ASoC: mediatek: mt8195: mt8195-afe-clk: Use guard() for spin locks
From: phucduc.bui @ 2026-06-10 10:20 UTC (permalink / raw)
To: Mark Brown, Matthias Brugger
Cc: Liam Girdwood, AngeloGioacchino Del Regno, Linus Walleij,
Bartosz Golaszewski, Jaroslav Kysela, Takashi Iwai, linux-sound,
linux-arm-kernel, linux-mediatek, linux-kernel, linux-gpio,
bui duc phuc
In-Reply-To: <20260610102021.83273-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Clean up the code using guard() for spin locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/mediatek/mt8195/mt8195-afe-clk.c | 42 ++++++++++------------
1 file changed, 18 insertions(+), 24 deletions(-)
diff --git a/sound/soc/mediatek/mt8195/mt8195-afe-clk.c b/sound/soc/mediatek/mt8195/mt8195-afe-clk.c
index f35318ae0739..618d8400913a 100644
--- a/sound/soc/mediatek/mt8195/mt8195-afe-clk.c
+++ b/sound/soc/mediatek/mt8195/mt8195-afe-clk.c
@@ -283,7 +283,6 @@ static int mt8195_afe_enable_apll_tuner(struct mtk_base_afe *afe,
unsigned int id)
{
struct mt8195_afe_tuner_cfg *cfg = mt8195_afe_found_apll_tuner(id);
- unsigned long flags;
int ret;
if (!cfg)
@@ -297,16 +296,14 @@ static int mt8195_afe_enable_apll_tuner(struct mtk_base_afe *afe,
if (ret)
return ret;
- spin_lock_irqsave(&cfg->ctrl_lock, flags);
-
- cfg->ref_cnt++;
- if (cfg->ref_cnt == 1)
- regmap_update_bits(afe->regmap,
- cfg->tuner_en_reg,
- cfg->tuner_en_maskbit << cfg->tuner_en_shift,
- 1 << cfg->tuner_en_shift);
-
- spin_unlock_irqrestore(&cfg->ctrl_lock, flags);
+ scoped_guard(spinlock_irqsave, &cfg->ctrl_lock) {
+ cfg->ref_cnt++;
+ if (cfg->ref_cnt == 1)
+ regmap_update_bits(afe->regmap,
+ cfg->tuner_en_reg,
+ cfg->tuner_en_maskbit << cfg->tuner_en_shift,
+ 1 << cfg->tuner_en_shift);
+ }
return 0;
}
@@ -315,24 +312,21 @@ static int mt8195_afe_disable_apll_tuner(struct mtk_base_afe *afe,
unsigned int id)
{
struct mt8195_afe_tuner_cfg *cfg = mt8195_afe_found_apll_tuner(id);
- unsigned long flags;
int ret;
if (!cfg)
return -EINVAL;
- spin_lock_irqsave(&cfg->ctrl_lock, flags);
-
- cfg->ref_cnt--;
- if (cfg->ref_cnt == 0)
- regmap_update_bits(afe->regmap,
- cfg->tuner_en_reg,
- cfg->tuner_en_maskbit << cfg->tuner_en_shift,
- 0 << cfg->tuner_en_shift);
- else if (cfg->ref_cnt < 0)
- cfg->ref_cnt = 0;
-
- spin_unlock_irqrestore(&cfg->ctrl_lock, flags);
+ scoped_guard(spinlock_irqsave, &cfg->ctrl_lock) {
+ cfg->ref_cnt--;
+ if (cfg->ref_cnt == 0)
+ regmap_update_bits(afe->regmap,
+ cfg->tuner_en_reg,
+ cfg->tuner_en_maskbit << cfg->tuner_en_shift,
+ 0 << cfg->tuner_en_shift);
+ else if (cfg->ref_cnt < 0)
+ cfg->ref_cnt = 0;
+ }
ret = mt8195_afe_disable_tuner_clk(afe, id);
if (ret)
--
2.43.0
^ permalink raw reply related
* [PATCH 05/10] ASoC: mediatek: mt8192: mt8192-afe-gpio: Use guard() for mutex locks
From: phucduc.bui @ 2026-06-10 10:20 UTC (permalink / raw)
To: Mark Brown, Matthias Brugger
Cc: Liam Girdwood, AngeloGioacchino Del Regno, Linus Walleij,
Bartosz Golaszewski, Jaroslav Kysela, Takashi Iwai, linux-sound,
linux-arm-kernel, linux-mediatek, linux-kernel, linux-gpio,
bui duc phuc
In-Reply-To: <20260610102021.83273-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Convert the explicit mutex_lock()/mutex_unlock() pair to guard(mutex)
to simplify the locking logic and automatically release the mutex on
all exit paths.
This changes the mutex release point from immediately before dev_warn()
to automatic cleanup at scope exit. However, the affected path only emits
a warning and immediately returns -EINVAL, without any further processing.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/mediatek/mt8192/mt8192-afe-gpio.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/sound/soc/mediatek/mt8192/mt8192-afe-gpio.c b/sound/soc/mediatek/mt8192/mt8192-afe-gpio.c
index de5e1deaa167..b993ca2dbd7c 100644
--- a/sound/soc/mediatek/mt8192/mt8192-afe-gpio.c
+++ b/sound/soc/mediatek/mt8192/mt8192-afe-gpio.c
@@ -208,7 +208,7 @@ static int mt8192_afe_gpio_adda_ch34_ul(struct device *dev, bool enable)
int mt8192_afe_gpio_request(struct device *dev, bool enable,
int dai, int uplink)
{
- mutex_lock(&gpio_request_mutex);
+ guard(mutex)(&gpio_request_mutex);
switch (dai) {
case MT8192_DAI_ADDA:
if (uplink)
@@ -296,11 +296,9 @@ int mt8192_afe_gpio_request(struct device *dev, bool enable,
}
break;
default:
- mutex_unlock(&gpio_request_mutex);
dev_warn(dev, "%s(), invalid dai %d\n", __func__, dai);
return -EINVAL;
}
- mutex_unlock(&gpio_request_mutex);
return 0;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 04/10] ASoC: mediatek: mt8188: mt8188-afe-clk: Use guard() for spin locks
From: phucduc.bui @ 2026-06-10 10:20 UTC (permalink / raw)
To: Mark Brown, Matthias Brugger
Cc: Liam Girdwood, AngeloGioacchino Del Regno, Linus Walleij,
Bartosz Golaszewski, Jaroslav Kysela, Takashi Iwai, linux-sound,
linux-arm-kernel, linux-mediatek, linux-kernel, linux-gpio,
bui duc phuc
In-Reply-To: <20260610102021.83273-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Clean up the code using guard() for spin locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/mediatek/mt8188/mt8188-afe-clk.c | 29 ++++++++--------------
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/sound/soc/mediatek/mt8188/mt8188-afe-clk.c b/sound/soc/mediatek/mt8188/mt8188-afe-clk.c
index 7f411b857782..fc6cb3f0469e 100644
--- a/sound/soc/mediatek/mt8188/mt8188-afe-clk.c
+++ b/sound/soc/mediatek/mt8188/mt8188-afe-clk.c
@@ -301,7 +301,6 @@ static int mt8188_afe_disable_tuner_clk(struct mtk_base_afe *afe,
static int mt8188_afe_enable_apll_tuner(struct mtk_base_afe *afe, unsigned int id)
{
struct mt8188_afe_tuner_cfg *cfg = mt8188_afe_found_apll_tuner(id);
- unsigned long flags;
int ret;
if (!cfg)
@@ -315,8 +314,7 @@ static int mt8188_afe_enable_apll_tuner(struct mtk_base_afe *afe, unsigned int i
if (ret)
return ret;
- spin_lock_irqsave(&cfg->ctrl_lock, flags);
-
+ guard(spinlock_irqsave)(&cfg->ctrl_lock);
cfg->ref_cnt++;
if (cfg->ref_cnt == 1)
regmap_update_bits(afe->regmap,
@@ -324,32 +322,27 @@ static int mt8188_afe_enable_apll_tuner(struct mtk_base_afe *afe, unsigned int i
cfg->tuner_en_maskbit << cfg->tuner_en_shift,
BIT(cfg->tuner_en_shift));
- spin_unlock_irqrestore(&cfg->ctrl_lock, flags);
-
return 0;
}
static int mt8188_afe_disable_apll_tuner(struct mtk_base_afe *afe, unsigned int id)
{
struct mt8188_afe_tuner_cfg *cfg = mt8188_afe_found_apll_tuner(id);
- unsigned long flags;
int ret;
if (!cfg)
return -EINVAL;
- spin_lock_irqsave(&cfg->ctrl_lock, flags);
-
- cfg->ref_cnt--;
- if (cfg->ref_cnt == 0)
- regmap_update_bits(afe->regmap,
- cfg->tuner_en_reg,
- cfg->tuner_en_maskbit << cfg->tuner_en_shift,
- 0 << cfg->tuner_en_shift);
- else if (cfg->ref_cnt < 0)
- cfg->ref_cnt = 0;
-
- spin_unlock_irqrestore(&cfg->ctrl_lock, flags);
+ scoped_guard(spinlock_irqsave, &cfg->ctrl_lock) {
+ cfg->ref_cnt--;
+ if (cfg->ref_cnt == 0)
+ regmap_update_bits(afe->regmap,
+ cfg->tuner_en_reg,
+ cfg->tuner_en_maskbit << cfg->tuner_en_shift,
+ 0 << cfg->tuner_en_shift);
+ else if (cfg->ref_cnt < 0)
+ cfg->ref_cnt = 0;
+ }
ret = mt8188_afe_disable_tuner_clk(afe, id);
if (ret)
--
2.43.0
^ permalink raw reply related
* [PATCH 03/10] ASoC: mediatek: mt8186: mt8186-afe-gpio: Use guard() for mutex locks
From: phucduc.bui @ 2026-06-10 10:20 UTC (permalink / raw)
To: Mark Brown, Matthias Brugger
Cc: Liam Girdwood, AngeloGioacchino Del Regno, Linus Walleij,
Bartosz Golaszewski, Jaroslav Kysela, Takashi Iwai, linux-sound,
linux-arm-kernel, linux-mediatek, linux-kernel, linux-gpio,
bui duc phuc
In-Reply-To: <20260610102021.83273-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Clean up the code using guard() for mutex locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/mediatek/mt8186/mt8186-afe-gpio.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c b/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c
index 9e86e7079718..aced8e7e920c 100644
--- a/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c
+++ b/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c
@@ -201,7 +201,7 @@ int mt8186_afe_gpio_request(struct device *dev, bool enable,
enum mt8186_afe_gpio sel;
int ret = -EINVAL;
- mutex_lock(&gpio_request_mutex);
+ guard(mutex)(&gpio_request_mutex);
switch (dai) {
case MT8186_DAI_ADDA:
@@ -209,7 +209,7 @@ int mt8186_afe_gpio_request(struct device *dev, bool enable,
ret = mt8186_afe_gpio_adda_ul(dev, enable);
else
ret = mt8186_afe_gpio_adda_dl(dev, enable);
- goto unlock;
+ return ret;
case MT8186_DAI_I2S_0:
sel = enable ? MT8186_AFE_GPIO_I2S0_ON : MT8186_AFE_GPIO_I2S0_OFF;
break;
@@ -230,13 +230,8 @@ int mt8186_afe_gpio_request(struct device *dev, bool enable,
break;
default:
dev_dbg(dev, "%s(), invalid dai %d\n", __func__, dai);
- goto unlock;
+ return ret;
}
- ret = mt8186_afe_gpio_select(dev, sel);
-
-unlock:
- mutex_unlock(&gpio_request_mutex);
-
- return ret;
+ return mt8186_afe_gpio_select(dev, sel);
}
--
2.43.0
^ permalink raw reply related
* [PATCH 02/10] ASoC: mediatek: common: mtk-btcvsd: Use guard() for spin locks
From: phucduc.bui @ 2026-06-10 10:20 UTC (permalink / raw)
To: Mark Brown, Matthias Brugger
Cc: Liam Girdwood, AngeloGioacchino Del Regno, Linus Walleij,
Bartosz Golaszewski, Jaroslav Kysela, Takashi Iwai, linux-sound,
linux-arm-kernel, linux-mediatek, linux-kernel, linux-gpio,
bui duc phuc
In-Reply-To: <20260610102021.83273-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Clean up the code using guard() for spin locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/mediatek/common/mtk-btcvsd.c | 81 +++++++++++---------------
1 file changed, 35 insertions(+), 46 deletions(-)
diff --git a/sound/soc/mediatek/common/mtk-btcvsd.c b/sound/soc/mediatek/common/mtk-btcvsd.c
index 5e7e85b4c98a..85cfc602dfd3 100644
--- a/sound/soc/mediatek/common/mtk-btcvsd.c
+++ b/sound/soc/mediatek/common/mtk-btcvsd.c
@@ -319,7 +319,6 @@ static int btcvsd_tx_clean_buffer(struct mtk_btcvsd_snd *bt)
{
unsigned int i;
unsigned int num_valid_addr;
- unsigned long flags;
enum BT_SCO_BAND band = bt->band;
/* prepare encoded mute data */
@@ -330,7 +329,7 @@ static int btcvsd_tx_clean_buffer(struct mtk_btcvsd_snd *bt)
table_msbc_silence, SCO_PACKET_180);
/* write mute data to bt tx sram buffer */
- spin_lock_irqsave(&bt->tx_lock, flags);
+ guard(spinlock_irqsave)(&bt->tx_lock);
num_valid_addr = bt->tx->buffer_info.num_valid_addr;
dev_info(bt->dev, "%s(), band %d, num_valid_addr %u\n",
@@ -349,7 +348,6 @@ static int btcvsd_tx_clean_buffer(struct mtk_btcvsd_snd *bt)
bt->tx->buffer_info.packet_length,
bt->tx->buffer_info.packet_num);
}
- spin_unlock_irqrestore(&bt->tx_lock, flags);
return 0;
}
@@ -365,7 +363,6 @@ static int mtk_btcvsd_read_from_bt(struct mtk_btcvsd_snd *bt,
int pv;
u8 *src;
unsigned int packet_buf_ofs;
- unsigned long flags;
unsigned long connsys_addr_rx, ap_addr_rx;
connsys_addr_rx = *bt->bt_reg_pkt_r;
@@ -385,7 +382,7 @@ static int mtk_btcvsd_read_from_bt(struct mtk_btcvsd_snd *bt,
bt->rx->temp_packet_buf, packet_length,
packet_num);
- spin_lock_irqsave(&bt->rx_lock, flags);
+ guard(spinlock_irqsave)(&bt->rx_lock);
for (i = 0; i < blk_size; i++) {
packet_buf_ofs = (bt->rx->packet_w & SCO_RX_PACKET_MASK) *
bt->rx->packet_size;
@@ -403,7 +400,7 @@ static int mtk_btcvsd_read_from_bt(struct mtk_btcvsd_snd *bt,
SCO_CVSD_PACKET_VALID_SIZE);
bt->rx->packet_w++;
}
- spin_unlock_irqrestore(&bt->rx_lock, flags);
+
return 0;
}
@@ -414,7 +411,6 @@ static int mtk_btcvsd_write_to_bt(struct mtk_btcvsd_snd *bt,
unsigned int blk_size)
{
unsigned int i;
- unsigned long flags;
u8 *dst;
unsigned long connsys_addr_tx, ap_addr_tx;
bool new_ap_addr_tx = true;
@@ -430,17 +426,17 @@ static int mtk_btcvsd_write_to_bt(struct mtk_btcvsd_snd *bt,
return -EIO;
}
- spin_lock_irqsave(&bt->tx_lock, flags);
- for (i = 0; i < blk_size; i++) {
- memcpy(bt->tx->temp_packet_buf + (bt->tx->packet_size * i),
- (bt->tx_packet_buf +
- (bt->tx->packet_r % SCO_TX_PACKER_BUF_NUM) *
- bt->tx->packet_size),
- bt->tx->packet_size);
+ scoped_guard(spinlock_irqsave, &bt->tx_lock) {
+ for (i = 0; i < blk_size; i++) {
+ memcpy(bt->tx->temp_packet_buf + (bt->tx->packet_size * i),
+ (bt->tx_packet_buf +
+ (bt->tx->packet_r % SCO_TX_PACKER_BUF_NUM) *
+ bt->tx->packet_size),
+ bt->tx->packet_size);
- bt->tx->packet_r++;
+ bt->tx->packet_r++;
+ }
}
- spin_unlock_irqrestore(&bt->tx_lock, flags);
dst = (u8 *)ap_addr_tx;
@@ -462,11 +458,11 @@ static int mtk_btcvsd_write_to_bt(struct mtk_btcvsd_snd *bt,
if (new_ap_addr_tx) {
unsigned int next_idx;
- spin_lock_irqsave(&bt->tx_lock, flags);
- bt->tx->buffer_info.num_valid_addr++;
- next_idx = bt->tx->buffer_info.num_valid_addr - 1;
- bt->tx->buffer_info.bt_sram_addr[next_idx] = ap_addr_tx;
- spin_unlock_irqrestore(&bt->tx_lock, flags);
+ scoped_guard(spinlock_irqsave, &bt->tx_lock) {
+ bt->tx->buffer_info.num_valid_addr++;
+ next_idx = bt->tx->buffer_info.num_valid_addr - 1;
+ bt->tx->buffer_info.bt_sram_addr[next_idx] = ap_addr_tx;
+ }
dev_info(bt->dev, "%s(), new ap_addr_tx = 0x%lx, num_valid_addr %d\n",
__func__, ap_addr_tx,
bt->tx->buffer_info.num_valid_addr);
@@ -701,17 +697,16 @@ static ssize_t mtk_btcvsd_snd_read(struct mtk_btcvsd_snd *bt,
{
ssize_t read_size = 0, read_count = 0, cur_read_idx, cont;
unsigned long avail;
- unsigned long flags;
unsigned int packet_size = bt->rx->packet_size;
while (count) {
- spin_lock_irqsave(&bt->rx_lock, flags);
- /* available data in RX packet buffer */
- avail = (bt->rx->packet_w - bt->rx->packet_r) * packet_size;
+ scoped_guard(spinlock_irqsave, &bt->rx_lock) {
+ /* available data in RX packet buffer */
+ avail = (bt->rx->packet_w - bt->rx->packet_r) * packet_size;
- cur_read_idx = (bt->rx->packet_r & SCO_RX_PACKET_MASK) *
- packet_size;
- spin_unlock_irqrestore(&bt->rx_lock, flags);
+ cur_read_idx = (bt->rx->packet_r & SCO_RX_PACKET_MASK) *
+ packet_size;
+ }
if (!avail) {
int ret = wait_for_bt_irq(bt, bt->rx);
@@ -749,9 +744,8 @@ static ssize_t mtk_btcvsd_snd_read(struct mtk_btcvsd_snd *bt,
return -EFAULT;
}
- spin_lock_irqsave(&bt->rx_lock, flags);
- bt->rx->packet_r += read_size / packet_size;
- spin_unlock_irqrestore(&bt->rx_lock, flags);
+ scoped_guard(spinlock_irqsave, &bt->rx_lock)
+ bt->rx->packet_r += read_size / packet_size;
read_count += read_size;
count -= read_size;
@@ -778,7 +772,6 @@ static ssize_t mtk_btcvsd_snd_write(struct mtk_btcvsd_snd *bt,
size_t count)
{
int written_size = count, avail, cur_write_idx, write_size, cont;
- unsigned long flags;
unsigned int packet_size = bt->tx->packet_size;
/*
@@ -794,14 +787,14 @@ static ssize_t mtk_btcvsd_snd_write(struct mtk_btcvsd_snd *bt,
bt->tx->buf_data_equivalent_time *= 1000;
while (count) {
- spin_lock_irqsave(&bt->tx_lock, flags);
- /* free space of TX packet buffer */
- avail = bt->tx->buf_size -
- (bt->tx->packet_w - bt->tx->packet_r) * packet_size;
+ scoped_guard(spinlock_irqsave, &bt->tx_lock) {
+ /* free space of TX packet buffer */
+ avail = bt->tx->buf_size -
+ (bt->tx->packet_w - bt->tx->packet_r) * packet_size;
- cur_write_idx = (bt->tx->packet_w % SCO_TX_PACKER_BUF_NUM) *
- packet_size;
- spin_unlock_irqrestore(&bt->tx_lock, flags);
+ cur_write_idx = (bt->tx->packet_w % SCO_TX_PACKER_BUF_NUM) *
+ packet_size;
+ }
if (!avail) {
int ret = wait_for_bt_irq(bt, bt->tx);
@@ -838,9 +831,8 @@ static ssize_t mtk_btcvsd_snd_write(struct mtk_btcvsd_snd *bt,
return -EFAULT;
}
- spin_lock_irqsave(&bt->tx_lock, flags);
- bt->tx->packet_w += write_size / packet_size;
- spin_unlock_irqrestore(&bt->tx_lock, flags);
+ scoped_guard(spinlock_irqsave, &bt->tx_lock)
+ bt->tx->packet_w += write_size / packet_size;
count -= write_size;
}
@@ -985,7 +977,6 @@ static snd_pcm_uframes_t mtk_pcm_btcvsd_pointer(
int hw_packet_ptr;
int packet_diff;
spinlock_t *lock; /* spinlock for bt stream control */
- unsigned long flags;
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
lock = &bt->tx_lock;
@@ -995,7 +986,7 @@ static snd_pcm_uframes_t mtk_pcm_btcvsd_pointer(
bt_stream = bt->rx;
}
- spin_lock_irqsave(lock, flags);
+ guard(spinlock_irqsave)(lock);
hw_packet_ptr = substream->stream == SNDRV_PCM_STREAM_PLAYBACK ?
bt->tx->packet_r : bt->rx->packet_w;
@@ -1018,8 +1009,6 @@ static snd_pcm_uframes_t mtk_pcm_btcvsd_pointer(
bt_stream->prev_frame = frame;
- spin_unlock_irqrestore(lock, flags);
-
return frame;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 01/10] ASoC: mediatek: common: mtk-afe-fe-dai: Use guard() for mutex locks
From: phucduc.bui @ 2026-06-10 10:20 UTC (permalink / raw)
To: Mark Brown, Matthias Brugger
Cc: Liam Girdwood, AngeloGioacchino Del Regno, Linus Walleij,
Bartosz Golaszewski, Jaroslav Kysela, Takashi Iwai, linux-sound,
linux-arm-kernel, linux-mediatek, linux-kernel, linux-gpio,
bui duc phuc
In-Reply-To: <20260610102021.83273-1-phucduc.bui@gmail.com>
From: bui duc phuc <phucduc.bui@gmail.com>
Clean up the code using guard() for mutex locks.
Merely code refactoring, and no behavior change.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
sound/soc/mediatek/common/mtk-afe-fe-dai.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/sound/soc/mediatek/common/mtk-afe-fe-dai.c b/sound/soc/mediatek/common/mtk-afe-fe-dai.c
index 3809068f5620..2a20fa5dba49 100644
--- a/sound/soc/mediatek/common/mtk-afe-fe-dai.c
+++ b/sound/soc/mediatek/common/mtk-afe-fe-dai.c
@@ -292,28 +292,24 @@ int mtk_dynamic_irq_acquire(struct mtk_base_afe *afe)
{
int i;
- mutex_lock(&afe->irq_alloc_lock);
+ guard(mutex)(&afe->irq_alloc_lock);
for (i = 0; i < afe->irqs_size; ++i) {
if (afe->irqs[i].irq_occupyed == 0) {
afe->irqs[i].irq_occupyed = 1;
- mutex_unlock(&afe->irq_alloc_lock);
return i;
}
}
- mutex_unlock(&afe->irq_alloc_lock);
return afe->irqs_size;
}
EXPORT_SYMBOL_GPL(mtk_dynamic_irq_acquire);
int mtk_dynamic_irq_release(struct mtk_base_afe *afe, int irq_id)
{
- mutex_lock(&afe->irq_alloc_lock);
+ guard(mutex)(&afe->irq_alloc_lock);
if (irq_id >= 0 && irq_id < afe->irqs_size) {
afe->irqs[irq_id].irq_occupyed = 0;
- mutex_unlock(&afe->irq_alloc_lock);
return 0;
}
- mutex_unlock(&afe->irq_alloc_lock);
return -EINVAL;
}
EXPORT_SYMBOL_GPL(mtk_dynamic_irq_release);
--
2.43.0
^ permalink raw reply related
* [PATCH 00/10] ASoC: mediatek: Use guard() for mutex & spin locks
From: phucduc.bui @ 2026-06-10 10:20 UTC (permalink / raw)
To: Mark Brown, Matthias Brugger
Cc: Liam Girdwood, AngeloGioacchino Del Regno, Linus Walleij,
Bartosz Golaszewski, Jaroslav Kysela, Takashi Iwai, linux-sound,
linux-arm-kernel, linux-mediatek, linux-kernel, linux-gpio,
bui duc phuc
From: bui duc phuc <phucduc.bui@gmail.com>
Hi all,
This series converts mutex and spinlock handling in Mediatek ASoC drivers
to use guard() helpers.
Most patches are straightforward conversions to guard() helpers with no
functional change intended.
One exception is mt8192-afe-gpio, where the mutex release point moves from
immediately before dev_warn() to scope exit. However, the affected path
only emits a warning and immediately returns -EINVAL, without any further
processing.
Compile-tested only.
Best regards,
Phuc
bui duc phuc (10):
ASoC: mediatek: common: mtk-afe-fe-dai: Use guard() for mutex locks
ASoC: mediatek: common: mtk-btcvsd: Use guard() for spin locks
ASoC: mediatek: mt8186: mt8186-afe-gpio: Use guard() for mutex locks
ASoC: mediatek: mt8188: mt8188-afe-clk: Use guard() for spin locks
ASoC: mediatek: mt8192: mt8192-afe-gpio: Use guard() for mutex locks
ASoC: mediatek: mt8195: mt8195-afe-clk: Use guard() for spin locks
ASoC: mediatek: mt8195: mt8195-dai-etdm: Use guard() for spin locks
ASoC: mediatek: mt8195: mt8365-afe-clk: Use guard() for mutex & spin
locks
ASoC: mediatek: mt8195: mt8365-dai-adda: Use guard() for spin locks
ASoC: mediatek: mt8195: mt8365-dai-i2s: Use guard() for spin locks
sound/soc/mediatek/common/mtk-afe-fe-dai.c | 8 +-
sound/soc/mediatek/common/mtk-btcvsd.c | 81 +++++++++------------
sound/soc/mediatek/mt8186/mt8186-afe-gpio.c | 13 +---
sound/soc/mediatek/mt8188/mt8188-afe-clk.c | 29 +++-----
sound/soc/mediatek/mt8192/mt8192-afe-gpio.c | 4 +-
sound/soc/mediatek/mt8195/mt8195-afe-clk.c | 42 +++++------
sound/soc/mediatek/mt8195/mt8195-dai-etdm.c | 16 ++--
sound/soc/mediatek/mt8365/mt8365-afe-clk.c | 30 ++------
sound/soc/mediatek/mt8365/mt8365-dai-adda.c | 10 +--
sound/soc/mediatek/mt8365/mt8365-dai-i2s.c | 5 +-
10 files changed, 87 insertions(+), 151 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v2 0/7] KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone
From: Will Deacon @ 2026-06-10 10:15 UTC (permalink / raw)
To: Vincent Donnefort
Cc: Sebastian Ene, catalin.marinas, maz, oupton, joey.gouly, korneld,
kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
mrigendra.chaubey, perlarsen, suzuki.poulose, yuzenghui
In-Reply-To: <aikt44sVnpL3_dYi@google.com>
On Wed, Jun 10, 2026 at 10:26:59AM +0100, Vincent Donnefort wrote:
> On Mon, Jun 08, 2026 at 04:55:42PM +0000, Sebastian Ene wrote:
> > Remove the FFA_NOTIFICATION* calls from the blocklist used by the pKVM
> > FF-A proxy. This restriction was preventing the use of asynchronous
> > signaling mechanisms defined by the Arm FF-A specification to
> > communicate with the secure services.
> > While these calls are markes as optional, there is no reason why the
> > hypervisor proxy would block them because:
> >
> > 1. Host is the Sole Non-Secure Endpoint: The Host operates as the
> > only Non-Secure VM ID (VM ID 0) recognized by the Secure World.
> > Because all forwarded notifications are inherently attributed to
> > the Host by the SPMC, there is no risk of VM ID spoofing
> > originating from the Normal World.
> >
> > 2. No Memory Pointers or Addresses: The FFA_NOTIFICATION_* ABIs
> > operate strictly via register-based parameters, passing only
> > VM IDs, VCPU IDs, flags, and bitmaps. Because these calls do
> > not contain memory addresses, offsets, or pointers, forwarding
> > them doesn't pose a risk of memory-based confused deputy attack
> > (e.g., tricking the SPMC into overwriting protected memory).
> >
> > While the pKVM proxy behaves as a relayer, it doesn't currently have its
> > own FF-A ID(only the host has the ID 0). The behavior of the setup
> > flow is covered by the spec in the: '10.9 Notification support without
> > a Hypervisor'.
>
> As it is only a relayer. Is it really important to check SBZ arguments and
> fields on behalf of Trustzone? It doesn't feel it brings any security. If the
> host passes broken arguments, I don't believe this puts pKVM at risk. Does it?
I think the problem would be if an update to FF-A allocated some of the
currently SBZ bits to implement some functionality that we would want
to filter at EL2.
Will
^ permalink raw reply
* Re: [RFC PATCH v3 0/9] accel: rocket: Add RK3568 NPU support
From: Diederik de Haas @ 2026-06-10 10:05 UTC (permalink / raw)
To: Chaoyi Chen, Midgy Balon
Cc: tomeu, ogabbay, heiko, robh, krzk+dt, conor+dt, joro, will,
robin.murphy, dri-devel, linux-rockchip, devicetree,
linux-arm-kernel, iommu, linux-kernel, Simon Xue, Finley Xiao,
Jonas Karlman
In-Reply-To: <b05f7154-e85f-4207-80ae-f080282ba780@rock-chips.com>
Hi,
On Wed Jun 10, 2026 at 3:14 AM CEST, Chaoyi Chen wrote:
> Hi Midgy,
>
> On 6/9/2026 7:11 PM, Midgy Balon wrote:
>> Hello Chaoyi,
>>
>> You were right - building rocket as a module fixes it. Thanks for the pointer.
>>
>> I rebuilt with CONFIG_DRM_ACCEL_ROCKET=m (everything else the same:
>> need_regulator on
>> the RK3568 NPU power domain via a DOMAIN_M_R variant, domain-supply =
>> <&vdd_npu>, and the
>> regulator-always-on workaround dropped). The board now boots cleanly
>> and, more importantly,
>> an NPU job submit no longer hangs: I ran the test workload five times
>> with no RCU stall and
>> no freeze.
>>
>> So with rocket=m the need_regulator approach works on RK3568, and I'll
>> keep it for v4
>> (domain-supply + need_regulator, instead of marking vdd_npu
>> always-on). rocket=m is the
>> normal configuration anyway; my earlier hang came from building it =y
>> in a self-contained
>> image, so it probed in the initcalls (around 2 s) and the genpd ->
>> I2C-PMIC regulator
>> transition ran before the system was ready. As a module it loads from
>> udev much later
>> (~6.8 s here), after the I2C controller and regulator core are fully up.
>>
>> On your question of when the device-link error is printed - it is at
>> power-domain
>> controller probe, not at the rocket probe:
>>
>> [ 2.700618] vdd_npu: Bringing 500000uV into 825000-825000uV
>> [ 2.749637] rockchip-pm-domain fdd90000.power-management:power-controller:
>> Failed to create device link (0x180) with supplier 0-0020 for
>> /power-management@fdd90000/power-controller/power-domain@6
>> [ 2.945955] platform fde40000.npu: Adding to iommu group 3
>> ...
>> [ 6.840374] rocket: loading out-of-tree module taints kernel.
>> [ 6.877647] [drm] Initialized rocket 0.0.0 for rknn on minor 0
>> [ 6.879950] rocket fde40000.npu: Rockchip NPU core 0 version: 0
>>
>> So the device-link to the rk809 PMIC (0-0020) fails to form at ~2.75
>> s, well before rocket
>> loads at ~6.8 s. It is non-fatal here - the vdd_npu rail is brought up
>> by the regulator core
>> and all jobs run - and there is no "failed to get ack on domain npu"
>> NoC warning this boot
>> (the always-on kernel had one). The complete boot log is attached.
>>
>> Two notes / one question:
>> - This boot used fw_devlink=permissive on the command line. Is the
>> "Failed to create device
>> link ... supplier 0-0020" at pmdomain probe expected/benign, or is
>> there a clean way to make
>> it order correctly (so it also works without permissive, and a =y
>> build wouldn't deadlock in
>> the initcalls)?
>
> We encountered the same issue on the RK3588 NPU before. And it was
> resolved with the following patch at that time.
>
> https://lore.kernel.org/all/20251216055247.13150-1-rmxpzlb@gmail.com/
>
> Please compare the differences in NPU pmdomain and DTS configuration
> between the RK3568 and RK3588.
About a month ago on #linux-rockchip we were discussing PM 'stuff':
https://libera.catirclogs.org/linux-rockchip/2026-05-15#39939137;
which references this paste
https://paste.sr.ht/~diederik/89d9f84e22474e837b55286d213b67f03859ce2e
I've since removed the DCDC_REG2 for PineTab2 and the 'fix' should likely
be extended to cover all RK3566/RK3568 devices though.
It's what I made at the time hoping to fix a suspend/resume issue when
trying upstream TF-A. It didn't fix the issue at the time, but may still
be useful/needed and I think it's what Chaoyi hinted at.
Just yesterday, Jonas posted this patch which may be useful/needed too:
https://lore.kernel.org/linux-rockchip/20260609154124.445182-1-jonas@kwiboo.se/
HTH,
Diederik
>> - (The convolution output is still uniform zero-point / the job times
>> out - that is the
>> separate NPU compute-completion issue, unrelated to the power-domain
>> work. Finley, that is
>> the one I flagged earlier re PVTPLL/NoC.)
>>
>> Kind regards,
>> Midgy
>>
^ permalink raw reply
* [PATCH v5 4/4] Documentation: PCI: Add documentation for DOE endpoint support
From: Aksh Garg @ 2026-06-10 10:02 UTC (permalink / raw)
To: linux-pci, linux-doc, mani, kwilczynski, bhelgaas, corbet, kishon,
skhan, lukas, cassel, alistair
Cc: linux-arm-kernel, linux-kernel, s-vadapalli, danishanwar, srk,
a-garg7
In-Reply-To: <20260610100256.1889111-1-a-garg7@ti.com>
Document the architecture and implementation details for the Data Object
Exchange (DOE) framework for PCIe Endpoint devices.
Co-developed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Aksh Garg <a-garg7@ti.com>
---
Changes from v4 to v5:
- Updated the DOE Abort handling setion.
Changes from v3 to v4:
- Updated the maximum size of the DOE object from 256KB to 1MB,
as per PCIe spec.
- Updated the DOE setup and cleanup sections.
Changes from v2 to v3:
- Rebased on 7.1-rc1.
Changes since v1:
- Squashed the patches [1] and [2], and moved the documentation file
to Documentation/PCI/endpoint/pci-endpoint-doe.rst to match the existing
naming scheme, as suggested by Niklas Cassel
- Updated the documentation as per the design and implementaion changes
made to previous patches in this series:
* Updated for static protocol array instead of dynamic registration
* Documented asynchronous callback model
* Updated request/response flow with new callback signature
* Updated memory ownership: DOE core frees request, driver frees response
* Updated initialization and cleanup sections for new APIs
v4: https://lore.kernel.org/all/20260522052434.802034-5-a-garg7@ti.com/
v3: https://lore.kernel.org/all/20260427051725.223704-5-a-garg7@ti.com/
v2: https://lore.kernel.org/all/20260401073022.215805-5-a-garg7@ti.com/
v1: [1] https://lore.kernel.org/all/20260213123603.420941-2-a-garg7@ti.com/
[2] https://lore.kernel.org/all/20260213123603.420941-5-a-garg7@ti.com/
Documentation/PCI/endpoint/index.rst | 1 +
.../PCI/endpoint/pci-endpoint-doe.rst | 333 ++++++++++++++++++
2 files changed, 334 insertions(+)
create mode 100644 Documentation/PCI/endpoint/pci-endpoint-doe.rst
diff --git a/Documentation/PCI/endpoint/index.rst b/Documentation/PCI/endpoint/index.rst
index dd1f62e731c9..7c03d5abd2ef 100644
--- a/Documentation/PCI/endpoint/index.rst
+++ b/Documentation/PCI/endpoint/index.rst
@@ -9,6 +9,7 @@ PCI Endpoint Framework
pci-endpoint
pci-endpoint-cfs
+ pci-endpoint-doe
pci-test-function
pci-test-howto
pci-ntb-function
diff --git a/Documentation/PCI/endpoint/pci-endpoint-doe.rst b/Documentation/PCI/endpoint/pci-endpoint-doe.rst
new file mode 100644
index 000000000000..679844e36493
--- /dev/null
+++ b/Documentation/PCI/endpoint/pci-endpoint-doe.rst
@@ -0,0 +1,333 @@
+.. SPDX-License-Identifier: GPL-2.0-only OR MIT
+
+.. include:: <isonum.txt>
+
+=============================================
+Data Object Exchange (DOE) for PCIe Endpoint
+=============================================
+
+:Copyright: |copy| 2026 Texas Instruments Incorporated
+:Author: Aksh Garg <a-garg7@ti.com>
+:Co-Author: Siddharth Vadapalli <s-vadapalli@ti.com>
+
+Overview
+========
+
+DOE (Data Object Exchange) is a standard PCIe extended capability feature
+introduced in the Data Object Exchange (DOE) ECN for PCIe r5.0. It is an optional
+mechanism for system firmware/software running on root complex (host) to perform
+:ref:`data object <data-object-term>` exchanges with an endpoint function. Each
+data object is uniquely identified by the Vendor ID of the vendor publishing the
+data object definition and a Data Object Type value assigned by that vendor.
+
+Think of DOE as a sophisticated mailbox system built into PCIe. The root complex
+can send structured requests to the endpoint device through DOE mailboxes, and
+the endpoint device responds with appropriate data. DOE mailboxes are implemented
+as PCIe Extended Capabilities in endpoint devices, allowing multiple mailboxes
+per function, each potentially supporting different data object protocols.
+
+The DOE support for root complex devices has already been implemented in
+``drivers/pci/doe.c``.
+
+How DOE Works
+=============
+
+The DOE mailbox operates through a simple request-response model:
+
+1. **Host sends request**: The root complex writes a data object (vendor ID, type,
+ and payload) to the DOE write mailbox register (one DWORD at a time) of the
+ endpoint function's config space and sets the GO bit in the DOE Control register
+ to indicate that a request is ready for processing.
+2. **Endpoint processes**: The endpoint function reads the request from DOE write
+ mailbox register, sets the BUSY bit in the DOE Status register, identifies the
+ protocol of the data object, and executes the appropriate handler.
+3. **Endpoint responds**: The endpoint function writes the response data object to the
+ DOE read mailbox register (one DWORD at a time), and sets the READY bit in the DOE
+ Status register to indicate that the response is ready. If an error occurs during
+ request processing (such as unsupported protocol or handler failure), the endpoint
+ sets the ERROR bit in the DOE Status register instead of the READY bit.
+4. **Host reads response**: The root complex retrieves the response data from the DOE read
+ mailbox register once the READY bit is set in the DOE Status register, and then writes
+ any value to this register to indicate a successful read. If the ERROR bit was set,
+ the root complex discards the response and performs error handling as needed.
+
+Each mailbox operates independently and can handle one transaction at a time. The
+DOE specification supports data objects of size up to 1MB (2\ :sup:`18` dwords).
+
+For complete DOE capability details, refer to `PCI Express Base Specification Revision 7.0,
+Section 6.30 - Data Object Exchange (DOE)`.
+
+Key Terminologies
+=================
+
+.. _data-object-term:
+
+**Data Object**
+ A structured, vendor-defined, or standard-defined message exchanged between
+ root complex and endpoint function via DOE capability registers in configuration
+ space of the function.
+
+**Mailbox**
+ A DOE capability on the endpoint device, where each physical function can have
+ multiple mailboxes.
+
+**Protocol**
+ A specific type of DOE communication data object identified by a Vendor ID and Type.
+
+**Handler**
+ A function that processes DOE requests of a specific protocol and generates responses.
+
+Architecture of DOE Implementation for Endpoint
+===============================================
+
+.. code-block:: text
+
+ +------------------+
+ | |
+ | Root Complex |
+ | |
+ +--------^---------+
+ |
+ | Config space access
+ | over PCIe link
+ |
+ +----------v-----------+
+ | |
+ | PCIe Controller |
+ | as Endpoint |
+ | |
+ | +-----------------+ |
+ | | DOE Mailbox | |
+ | +-------^---------+ |
+ +----------|-----------+
+ +-----------|---------------------------------------------------------------+
+ | | +--------------------+ |
+ | +---------v--------+ Allocate | +--------------+ | |
+ | | |-------------------------------->| Request | | |
+ | | EP Controller | +--->| Buffer | | |
+ | | Driver | Free | | +--------------+ | |
+ | | |--------------------------+ | | | |
+ | +--------^---------+ | | | | |
+ | | | | | | |
+ | | | | | | |
+ | | pci_ep_doe_process_request() | | | | |
+ | | | | | | |
+ | +--------v---------+ Free | | | | |
+ | | |----------------------------+ | DDR | |
+ | | DOE EP Core |<----+ | | | |
+ | | (pci-ep-doe.c) | | Discovery | | | |
+ | | |-----+ Protocol Handler | | | |
+ | +--------^---------+ | | | |
+ | | | | | |
+ | | protocol_handler() | | | |
+ | | | | | |
+ | +--------v---------+ | | | |
+ | | | | | +--------------+ | |
+ | | Protocol Handler | +----->| Response | | |
+ | | Module |-------------------------------->| Buffer | | |
+ | | (CMA/SPDM/Other) | Allocate | +--------------+ | |
+ | | | | | |
+ | +------------------+ | | |
+ | +--------------------+ |
+ +---------------------------------------------------------------------------+
+
+Initialization and Cleanup
+--------------------------
+
+**Framework Initialization and DOE Setup**
+
+The EPC core automatically initializes and sets up DOE mailboxes through the
+``pci_epc_init_capabilities()`` internal function, which is invoked during
+``pci_epc_init_notify()`` when the controller driver calls this API.
+Controller drivers do not need to explicitly handle DOE initialization,
+rather the EPC core manages this transparently.
+
+DOE initialization only occurs when the EPC driver reports DOE capability
+through the ``doe_capable`` flag in its ``pci_epc_features``.
+
+This internal function performs the following steps:
+
+1. Calls ``pci_ep_doe_init(epc)`` to initialize the xarray data structure
+ (a resizable array data structure defined in linux) named ``doe_mbs`` that
+ stores metadata of DOE mailboxes for the controller in ``struct pci_epc``.
+2. Calls ``pci_epc_doe_setup(epc)`` to discover all DOE capabilities in the
+ endpoint function's configuration space for each function. For each
+ discovered DOE capability, calls ``pci_ep_doe_add_mailbox(epc, func_no,
+ cap_offset)`` to register the mailbox.
+
+Each DOE mailbox structure created by ``pci_ep_doe_add_mailbox()`` gets an
+ordered workqueue allocated for processing DOE requests sequentially for that
+mailbox, enabling concurrent request handling across different mailboxes. Each
+mailbox is uniquely identified by the combination of physical function number
+and capability offset for that controller.
+
+**Cleanup**
+
+The EPC core automatically cleans up DOE mailboxes through the
+``pci_epc_deinit_capabilities()`` internal function, which is invoked during
+``pci_epc_deinit_notify()`` when the controller driver calls this API.
+Controller drivers do not need to explicitly handle DOE cleanup, rather
+the EPC core manages this transparently.
+
+DOE cleanup only occurs when the EPC device reported DOE capability
+through the ``doe_capable`` flag in its ``pci_epc_features``.
+
+This internal function calls ``pci_ep_doe_destroy(epc)``, which destroys all
+registered mailboxes, cancels any pending tasks, flushes and destroys the
+workqueues, and frees all memory allocated to the mailboxes.
+
+Protocol Handler Support
+------------------------
+
+Protocol implementations (such as CMA, SPDM, or vendor-specific protocols) are
+supported through a static array of protocol handlers.
+
+When a new DOE protocol library is introduced, its handler function is added to
+the static ``pci_doe_protocols`` array in ``drivers/pci/endpoint/pci-ep-doe.c``.
+The discovery protocol (VID = 0x0001 (PCI-SIG vendor ID), Type = 0x00 (discovery
+protocol)) is included in this static array and handled internally by the
+DOE EP core.
+
+Request Handling
+----------------
+
+The complete flow of a DOE request from the root complex to the response:
+
+**Step 1: Root Complex → EP Controller Driver**
+
+The root complex writes a DOE request (Vendor ID, Type, and Payload) to the
+DOE write mailbox register in the endpoint function's configuration space and sets
+the GO bit in the DOE Control register, indicating that the request is ready for
+processing.
+
+**Step 2: EP Controller Driver → DOE EP Core**
+
+The controller driver reads the request header to determine the data object
+length. Based on this length field, it allocates a request buffer in memory
+(DDR) of the appropriate size. The driver then reads the complete request
+payload from the DOE write mailbox register and converts the data from
+little-endian format (the format followed in the PCIe transactions over the
+link) to CPU-native format using ``le32_to_cpu()``. The driver defines a
+completion callback function with signature ``void (*complete)(struct pci_epc *epc,
+u8 func_no, u16 cap_offset, int status, u16 vendor, u8 type, void *response_pl,
+size_t response_pl_sz)`` to be invoked when the request processing completes.
+The driver then calls ``pci_ep_doe_process_request(epc, func_no, cap_offset,
+vendor, type, request, request_sz, complete)`` to hand off the request to the
+DOE EP core. This function returns immediately after queuing the work
+(without blocking), and the driver sets the BUSY bit in the DOE Status register.
+
+**Step 3: DOE EP Core Processing**
+
+The DOE EP core creates a task structure and submits it to the mailbox's ordered
+workqueue. This ensures that requests for each mailbox are processed
+sequentially, one at a time, as required by the DOE specification. It looks up
+the protocol handler based on the Vendor ID and Type from the request header,
+and executes the handler function.
+
+**Step 4: Protocol Handler Execution**
+
+The workqueue executes the task by calling the registered protocol handler:
+``handler(request, request_sz, &response, &response_sz)``. The handler processes
+the request, allocates a response buffer in memory (DDR), builds the response
+data, and returns the response pointer and size. For the discovery protocol,
+the DOE EP core handles this directly without invoking an external handler.
+
+**Step 5: DOE EP Core → EP Controller Driver**
+
+After the protocol handler completes, the DOE EP core frees the request buffer,
+and invokes the completion callback provided by the controller driver asynchronously.
+The callback receives the struct pci_epc, function number, capability offset (to
+identify the mailbox), status code indicating the result of request processing,
+vendor ID and type of the data object, the response buffer, and its size.
+
+**Step 6: EP Controller Driver → Root Complex**
+
+The controller driver converts the response from CPU-native format to
+little-endian format using ``cpu_to_le32()``, writes the response to DOE read
+mailbox register, and sets the READY bit in the DOE Status register. The root
+complex then reads the response from the read mailbox register. Finally, the controller
+driver frees the response buffer (which the handler allocated).
+
+Asynchronous Request Processing
+-------------------------------
+
+The DOE-EP framework implements asynchronous request processing because an
+endpoint function can have multiple instances of DOE mailboxes, and requests may
+be interleaved across these mailboxes. Request processing of one mailbox should
+not result in blocking request processing of other mailboxes. Hence, requests
+on each mailbox need to be handled in parallel for optimization.
+
+For the EP controller driver to handle requests on multiple mailboxes in
+parallel, ``pci_ep_doe_process_request()`` must be asynchronous. The function
+returns immediately after submitting the request to the mailbox's workqueue,
+without waiting for the request to complete. A completion callback provided by
+the controller driver is invoked asynchronously when request processing
+finishes. This asynchronous design enables concurrent processing of requests
+across different mailboxes.
+
+Abort Handling
+--------------
+
+The DOE specification allows the root complex to abort ongoing DOE operations
+by setting the ABORT bit in the DOE Control register.
+
+**Trigger**
+
+When the root complex sets the ABORT bit, the EP controller driver detects this
+condition (typically in an interrupt handler or register polling routine). The
+action taken depends on the timing of the abort:
+
+- **ABORT before request transfer**: If the ABORT bit is set before the root complex
+ transfers the request to the mailbox registers, the controller driver should not
+ call ``pci_ep_doe_abort()`` API.
+
+- **ABORT during request transfer**: If the ABORT bit is set while the root complex
+ is still transferring the request to the mailbox registers, the controller driver
+ should discard the request, and should not call ``pci_ep_doe_abort()`` and
+ ``pci_ep_doe_process_request()`` APIs in the respective IRQ handlers.
+
+- **ABORT after request submission**: If the ABORT bit is set after the request
+ has been fully received and submitted to the DOE EP core via
+ ``pci_ep_doe_process_request()``, the controller driver must call
+ ``pci_ep_doe_abort(epc, func_no, cap_offset)`` for the affected mailbox to
+ perform abort sequence in the DOE EP core.
+
+**Abort Sequence**
+
+The abort function sets the CANCEL flag on the mailbox to prevent queued requests
+from starting. Instead of waiting for the workqueue to flush, it returns immediately.
+
+The CANCEL flag gets cleared after invoking the completion callback, allowing the
+mailbox to accept new requests.
+
+Queued requests that have not started execution will be aborted with an error
+status. The currently executing request will complete normally, and the controller
+will reject the response if it arrives after the abort sequence has been triggered.
+
+.. note::
+ Independent of when the ABORT bit is triggered, the controller driver must
+ clear the ERROR, BUSY, and READY bits in the DOE Status register after
+ completing the abort operation to reset the mailbox to an idle state.
+
+Error Handling
+--------------
+
+Errors can occur during DOE request processing for various reasons, such as
+unsupported protocols, handler failures, or memory allocation failures.
+
+**Error Detection**
+
+When an error occurs during DOE request processing, the DOE EP core propagates this error
+back to the controller driver either through the ``pci_ep_doe_process_request()`` return value,
+or the status code passed to the completion callback.
+
+**Error Response**
+
+When the controller driver receives an error code, it sets the ERROR bit in the DOE Status
+register instead of writing a response to the read mailbox register, and frees the buffers.
+
+API Reference
+=============
+
+.. kernel-doc:: drivers/pci/endpoint/pci-ep-doe.c
+ :export:
--
2.34.1
^ permalink raw reply related
* [PATCH v5 2/4] PCI: endpoint: Add DOE mailbox support for endpoint functions
From: Aksh Garg @ 2026-06-10 10:02 UTC (permalink / raw)
To: linux-pci, linux-doc, mani, kwilczynski, bhelgaas, corbet, kishon,
skhan, lukas, cassel, alistair
Cc: linux-arm-kernel, linux-kernel, s-vadapalli, danishanwar, srk,
a-garg7
In-Reply-To: <20260610100256.1889111-1-a-garg7@ti.com>
DOE (Data Object Exchange) is a standard PCIe extended capability
feature introduced in the Data Object Exchange (DOE) ECN for
PCIe r5.0. It provides a communication mechanism primarily used for
implementing PCIe security features such as device authentication, and
secure link establishment. Think of DOE as a sophisticated mailbox
system built into PCIe. The root complex can send structured requests
to the endpoint device through DOE mailboxes, and the endpoint device
responds with appropriate data.
Add the DOE support for PCIe endpoint devices, enabling endpoint
functions to process the DOE requests from the host. The implementation
provides framework APIs for EPC core driver and controller drivers to
register mailboxes, and request processing with workqueues ensuring
sequential handling per mailbox, and parallel handling across mailboxes.
The Discovery protocol is handled internally by the DOE core.
This implementation complements the existing DOE implementation for
root complex in drivers/pci/doe.c.
Co-developed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Aksh Garg <a-garg7@ti.com>
---
Changes from v4 to v5:
- Addressed the review comments by Sashiko
- Added refcount per DOE Mailbox to fix Use-After-Free bug
- Change in the Abort Sequence:
* Instead of waiting on flush_workqueue() to clear the CANCEL flag,
return immediately after setting the CANCEL flag. The CANCEL flag
gets cleared in signal_task_complete(), allowing the mailbox to
accept new requests
* Abort sequence handling in various scenarios is updated and explained
in the documentation at PATCH 4/4
Changes from v3 to v4:
- Used 'Returns' instead of 'RETURNS' in the function docstrings to
comply with kernel-doc format, as suggested by Manivannan Sadhasivam.
- In pci_ep_doe_process_request(), changed the type of request buffer
from "const void *" to "void *", as the ownership is transferred to
DOE-EP framework, which is responsible to free the buffer.
- Added "struct pci_epc *epc" to typedef "pci_ep_doe_complete_t", to be
used by the EPC driver.
Changes from v2 to v3:
- Rebased on 7.1-rc1.
Changes since v1:
- Moved the DOE-EP core file to drivers/pci/endpoint/pci-ep-doe.c, and
corresponding Kconfig and Makefile to match the existing naming scheme,
as suggested by Niklas Cassel.
- Renamed the config from PCI_DOE_EP to PCI_ENDPOINT_DOE
- Moved the function declarations that need not be visible outside the
PCI core to drivers/pci/pci.h instead to include/linux/pci-doe.h as
suggested by Lukas Wunner
- Converted from synchronous to asynchronous request processing:
* Removed wait_for_completion() from pci_ep_doe_process_request()
* Function returns immediately after queuing to workqueue, hence
removed private data for completion in the task structure
* Added completion callback as an additional argument to
pci_ep_doe_process_request(), which takes the response and status
parameters as arguments (along with other required arguments), hence
removed task_status in the task structure
* Created a typedef pci_ep_doe_complete_t for completion callback
* Removed the pci_ep_doe_task_complete() function, as it would not be
required anymore with these changes
* Moved from INIT_WORK_ONSTACK() to INIT_WORK(), to initialize the work
on heap instead of stack
* signal_task_complete() now invokes the completion callback, once the
protocol handler completes its task
- Changed from dynamic xarray-based protocol registration to static array:
* Removed the register/unregister protocol APIs
* Replaced the dynamic xarray with static array of struct pci_doe_protocol
* Added discovery protocol to static array, instead of treating it specially,
hence removed the special handling for Discovery protocol in
doe_ep_task_work()
* Updated pci_ep_doe_handle_discovery() and pci_ep_doe_find_protocol()
accordingly.
- Memory Management:
* DOE core frees request buffer in signal_task_complete()
or during error handling
* pci_ep_doe_process_request() defines response_pl and response_pl_sz
as NULL and 0 respectively, whose pointer is passed to the protocol
handler, hence removed the arguments void **response, size_t *response_sz
to this function.
- Task structure refactoring:
* Response buffer: void **response_pl to void *response_pl
* Response size: size_t *response_pl_sz to size_t response_pl_sz
* Changed the completion callback to type pci_ep_doe_complete_t
* Removed void *private and int task_status
- Updated documentation comments of the functions according to the changes
v4: https://lore.kernel.org/all/20260522052434.802034-3-a-garg7@ti.com/
v3: https://lore.kernel.org/all/20260427051725.223704-3-a-garg7@ti.com/
v2: https://lore.kernel.org/all/20260401073022.215805-3-a-garg7@ti.com/
v1: https://lore.kernel.org/all/20260213123603.420941-4-a-garg7@ti.com/
drivers/pci/endpoint/Kconfig | 14 +
drivers/pci/endpoint/Makefile | 1 +
drivers/pci/endpoint/pci-ep-doe.c | 594 ++++++++++++++++++++++++++++++
drivers/pci/pci.h | 39 ++
include/linux/pci-doe.h | 5 +
include/linux/pci-epc.h | 3 +
6 files changed, 656 insertions(+)
create mode 100644 drivers/pci/endpoint/pci-ep-doe.c
diff --git a/drivers/pci/endpoint/Kconfig b/drivers/pci/endpoint/Kconfig
index 8dad291be8b8..15ae16aaa58f 100644
--- a/drivers/pci/endpoint/Kconfig
+++ b/drivers/pci/endpoint/Kconfig
@@ -36,6 +36,20 @@ config PCI_ENDPOINT_MSI_DOORBELL
doorbell. The RC can trigger doorbell in EP by writing data to a
dedicated BAR, which the EP maps to the controller's message address.
+config PCI_ENDPOINT_DOE
+ bool "PCI Endpoint Data Object Exchange (DOE) support"
+ depends on PCI_ENDPOINT
+ help
+ This enables support for Data Object Exchange (DOE) protocol
+ on PCI Endpoint controllers. It provides a communication
+ mechanism through mailboxes, primarily used for PCIe security
+ features.
+
+ Say Y here if you want be able to communicate using PCIe DOE
+ mailboxes.
+
+ If unsure, say N.
+
source "drivers/pci/endpoint/functions/Kconfig"
endmenu
diff --git a/drivers/pci/endpoint/Makefile b/drivers/pci/endpoint/Makefile
index b4869d52053a..1fa176b6792b 100644
--- a/drivers/pci/endpoint/Makefile
+++ b/drivers/pci/endpoint/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_PCI_ENDPOINT_CONFIGFS) += pci-ep-cfs.o
obj-$(CONFIG_PCI_ENDPOINT) += pci-epc-core.o pci-epf-core.o\
pci-epc-mem.o functions/
obj-$(CONFIG_PCI_ENDPOINT_MSI_DOORBELL) += pci-ep-msi.o
+obj-$(CONFIG_PCI_ENDPOINT_DOE) += pci-ep-doe.o
diff --git a/drivers/pci/endpoint/pci-ep-doe.c b/drivers/pci/endpoint/pci-ep-doe.c
new file mode 100644
index 000000000000..ea6a152461bb
--- /dev/null
+++ b/drivers/pci/endpoint/pci-ep-doe.c
@@ -0,0 +1,594 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * Data Object Exchange for PCIe Endpoint
+ * PCIe r7.0, sec 6.30 DOE
+ *
+ * Copyright (C) 2026 Texas Instruments Incorporated - https://www.ti.com
+ * Aksh Garg <a-garg7@ti.com>
+ * Siddharth Vadapalli <s-vadapalli@ti.com>
+ */
+
+#define dev_fmt(fmt) "DOE EP: " fmt
+
+#include <linux/bitfield.h>
+#include <linux/device.h>
+#include <linux/pci.h>
+#include <linux/pci-epc.h>
+#include <linux/pci-doe.h>
+#include <linux/refcount.h>
+#include <linux/slab.h>
+#include <linux/workqueue.h>
+#include <linux/xarray.h>
+
+#include "../pci.h"
+
+/* Forward declaration of discovery protocol handler */
+static int pci_ep_doe_handle_discovery(const void *request, size_t request_sz,
+ void **response, size_t *response_sz);
+
+/**
+ * struct pci_doe_protocol - DOE protocol handler entry
+ * @vid: Vendor ID
+ * @type: Protocol type
+ * @handler: Handler function pointer
+ */
+struct pci_doe_protocol {
+ u16 vid;
+ u8 type;
+ pci_doe_protocol_handler_t handler;
+};
+
+/**
+ * struct pci_ep_doe_mb - State for a single DOE mailbox on EP
+ *
+ * This state is used to manage a single DOE mailbox capability on the
+ * endpoint side.
+ *
+ * @epc: PCI endpoint controller this mailbox belongs to
+ * @func_no: Physical function number of the function this mailbox belongs to
+ * @cap_offset: Capability offset
+ * @work_queue: Queue of work items
+ * @flags: Bit array of PCI_DOE_FLAG_* flags
+ * @refs: Refcount to manage mailbox lifetime and ensure safe cleanup
+ */
+struct pci_ep_doe_mb {
+ struct pci_epc *epc;
+ u8 func_no;
+ u16 cap_offset;
+ struct workqueue_struct *work_queue;
+ unsigned long flags;
+ refcount_t refs;
+};
+
+/**
+ * struct pci_ep_doe_task - Represents a single DOE request/response task
+ *
+ * @feat: DOE feature (vendor ID and type)
+ * @request_pl: Request payload
+ * @request_pl_sz: Size of request payload in bytes
+ * @response_pl: Response buffer
+ * @response_pl_sz: Size of response buffer in bytes
+ * @complete: Completion callback
+ * @work: Work structure for workqueue
+ * @doe_mb: DOE mailbox handling this task
+ */
+struct pci_ep_doe_task {
+ struct pci_doe_feature feat;
+ const void *request_pl;
+ size_t request_pl_sz;
+ void *response_pl;
+ size_t response_pl_sz;
+ pci_ep_doe_complete_t complete;
+
+ /* Initialized by pci_ep_doe_submit_task() */
+ struct work_struct work;
+ struct pci_ep_doe_mb *doe_mb;
+};
+
+/*
+ * Global registry of protocol handlers.
+ * When a new DOE protocol, library is added, add an entry to this array.
+ */
+static const struct pci_doe_protocol pci_doe_protocols[] = {
+ {
+ .vid = PCI_VENDOR_ID_PCI_SIG,
+ .type = PCI_DOE_FEATURE_DISCOVERY,
+ .handler = pci_ep_doe_handle_discovery,
+ },
+};
+
+/*
+ * Combines function number and capability offset into a unique lookup key
+ * for storing/retrieving DOE mailboxes in an xarray.
+ */
+#define PCI_DOE_MB_KEY(func, offset) \
+ (((unsigned long)(func) << 16) | (offset))
+#define PCI_DOE_PROTOCOL_COUNT ARRAY_SIZE(pci_doe_protocols)
+
+/**
+ * pci_ep_doe_init() - Initialize the DOE framework for a controller in EP mode
+ * @epc: PCI endpoint controller
+ *
+ * Initialize the DOE framework data structures. This only initializes
+ * the xarray that will hold the mailboxes.
+ *
+ * Returns: 0 on success, -errno on failure
+ */
+int pci_ep_doe_init(struct pci_epc *epc)
+{
+ if (!epc)
+ return -EINVAL;
+
+ xa_init(&epc->doe_mbs);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pci_ep_doe_init);
+
+/**
+ * pci_ep_doe_add_mailbox() - Add a DOE mailbox for a physical function
+ * @epc: PCI endpoint controller
+ * @func_no: Physical function number
+ * @cap_offset: Offset of the DOE capability
+ *
+ * Create and register a DOE mailbox for the specified physical function
+ * and capability offset.
+ *
+ * EPC core driver calls this for each DOE capability discovered in the config
+ * space of each endpoint function if DOE support is available for the EPC.
+ *
+ * Returns: 0 on success, -errno on failure
+ */
+int pci_ep_doe_add_mailbox(struct pci_epc *epc, u8 func_no, u16 cap_offset)
+{
+ struct pci_ep_doe_mb *doe_mb;
+ unsigned long key;
+ int ret;
+
+ if (!epc)
+ return -EINVAL;
+
+ doe_mb = kzalloc_obj(*doe_mb, GFP_KERNEL);
+ if (!doe_mb)
+ return -ENOMEM;
+
+ doe_mb->epc = epc;
+ doe_mb->func_no = func_no;
+ doe_mb->cap_offset = cap_offset;
+
+ doe_mb->work_queue = alloc_ordered_workqueue("pci_ep_doe[%s:pf%d:offset%x]", 0,
+ dev_name(&epc->dev),
+ func_no, cap_offset);
+ if (!doe_mb->work_queue) {
+ dev_err(epc->dev.parent,
+ "[pf%d:offset%x] failed to allocate work queue\n",
+ func_no, cap_offset);
+ ret = -ENOMEM;
+ goto err_free;
+ }
+
+ /* Add to xarray with composite key */
+ key = PCI_DOE_MB_KEY(func_no, cap_offset);
+ ret = xa_insert(&epc->doe_mbs, key, doe_mb, GFP_KERNEL);
+ if (ret) {
+ dev_err(epc->dev.parent,
+ "[pf%d:offset%x] failed to insert mailbox: %d\n",
+ func_no, cap_offset, ret);
+ goto err_destroy;
+ }
+
+ refcount_set(&doe_mb->refs, 1);
+
+ dev_dbg(epc->dev.parent,
+ "DOE mailbox added: pf%d offset 0x%x\n",
+ func_no, cap_offset);
+
+ return 0;
+
+err_destroy:
+ destroy_workqueue(doe_mb->work_queue);
+err_free:
+ kfree(doe_mb);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pci_ep_doe_add_mailbox);
+
+/**
+ * pci_ep_doe_cancel_tasks() - Cancel all pending tasks
+ * @doe_mb: DOE mailbox
+ *
+ * Cancel all pending tasks in the mailbox. Mark the mailbox as dead
+ * so no new tasks can be submitted.
+ */
+static void pci_ep_doe_cancel_tasks(struct pci_ep_doe_mb *doe_mb)
+{
+ if (!doe_mb)
+ return;
+
+ /* Mark the mailbox as dead */
+ set_bit(PCI_DOE_FLAG_DEAD, &doe_mb->flags);
+
+ /* Stop all pending work items from starting */
+ set_bit(PCI_DOE_FLAG_CANCEL, &doe_mb->flags);
+}
+
+/**
+ * pci_ep_doe_get_mailbox() - Get DOE mailbox by function and offset
+ * @epc: PCI endpoint controller
+ * @func_no: Physical function number
+ * @cap_offset: Offset of the DOE capability
+ *
+ * Internal helper to look up a DOE mailbox by its function number and
+ * capability offset.
+ *
+ * Returns: Pointer to the mailbox or NULL if not found
+ */
+static struct pci_ep_doe_mb *pci_ep_doe_get_mailbox(struct pci_epc *epc,
+ u8 func_no, u16 cap_offset)
+{
+ struct pci_ep_doe_mb *doe_mb;
+ unsigned long key;
+
+ if (!epc)
+ return NULL;
+
+ key = PCI_DOE_MB_KEY(func_no, cap_offset);
+
+ xa_lock(&epc->doe_mbs);
+
+ doe_mb = xa_load(&epc->doe_mbs, key);
+ if (doe_mb && !refcount_inc_not_zero(&doe_mb->refs))
+ doe_mb = NULL;
+
+ xa_unlock(&epc->doe_mbs);
+
+ return doe_mb;
+}
+
+/**
+ * pci_ep_doe_put_mailbox() - Release a reference to a DOE mailbox
+ * @doe_mb: The mailbox structure to release
+ *
+ * Drops the reference count. If this was the last active reference,
+ * the memory allocated for the mailbox structure is freed.
+ */
+static void pci_ep_doe_put_mailbox(struct pci_ep_doe_mb *doe_mb)
+{
+ if (!doe_mb)
+ return;
+
+ if (refcount_dec_and_test(&doe_mb->refs))
+ kfree(doe_mb);
+}
+
+/**
+ * pci_ep_doe_find_protocol() - Find protocol handler in static array
+ * @vendor: Vendor ID
+ * @type: Protocol type
+ *
+ * Look up a protocol handler in the static protocol array by matching vendor ID
+ * and protocol type.
+ *
+ * Returns: Handler function pointer or NULL if not found
+ */
+static pci_doe_protocol_handler_t pci_ep_doe_find_protocol(u16 vendor, u8 type)
+{
+ int i;
+
+ /* Search static protocol array */
+ for (i = 0; i < PCI_DOE_PROTOCOL_COUNT; i++) {
+ if (pci_doe_protocols[i].vid == vendor &&
+ pci_doe_protocols[i].type == type)
+ return pci_doe_protocols[i].handler;
+ }
+
+ return NULL;
+}
+
+/**
+ * pci_ep_doe_handle_discovery() - Handle Discovery protocol request
+ * @request: Request payload
+ * @request_sz: Request size
+ * @response: Output pointer for response buffer
+ * @response_sz: Output pointer for response size
+ *
+ * Handle the DOE Discovery protocol. The request contains an index specifying
+ * which protocol to query. This function creates a response containing the
+ * vendor ID and protocol type for the requested index, along with the next
+ * index value for further discovery:
+ *
+ * - next_index = 0: Signals this is the last protocol supported
+ * - next_index = n (non-zero): Signals more protocols available,
+ * query index n next
+ *
+ * Returns: 0 on success, -errno on failure
+ */
+static int pci_ep_doe_handle_discovery(const void *request, size_t request_sz,
+ void **response, size_t *response_sz)
+{
+ struct pci_doe_protocol protocol;
+ u8 requested_index, next_index;
+ u32 *response_pl;
+ u32 request_pl;
+ u16 vendor;
+ u8 type;
+
+ if (request_sz != sizeof(u32))
+ return -EINVAL;
+
+ request_pl = *(u32 *)request;
+ requested_index = FIELD_GET(PCI_DOE_DATA_OBJECT_DISC_REQ_3_INDEX, request_pl);
+
+ if (requested_index >= PCI_DOE_PROTOCOL_COUNT) {
+ /* No more protocols to report */
+ vendor = 0;
+ type = 0;
+ } else {
+ /* Get protocol from array at requested_index */
+ protocol = pci_doe_protocols[requested_index];
+ vendor = protocol.vid;
+ type = protocol.type;
+ }
+
+ /* Calculate next index */
+ next_index = (requested_index + 1 < PCI_DOE_PROTOCOL_COUNT) ? requested_index + 1 : 0;
+
+ response_pl = kzalloc_obj(*response_pl, GFP_KERNEL);
+ if (!response_pl)
+ return -ENOMEM;
+
+ /* Build response */
+ *response_pl = FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_RSP_3_VID, vendor) |
+ FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_RSP_3_TYPE, type) |
+ FIELD_PREP(PCI_DOE_DATA_OBJECT_DISC_RSP_3_NEXT_INDEX, next_index);
+
+ *response = response_pl;
+ *response_sz = sizeof(*response_pl);
+
+ return 0;
+}
+
+static void signal_task_complete(struct pci_ep_doe_task *task, int status)
+{
+ struct pci_ep_doe_mb *doe_mb = task->doe_mb;
+
+ task->complete(doe_mb->epc, doe_mb->func_no, doe_mb->cap_offset,
+ status, task->feat.vid, task->feat.type,
+ task->response_pl, task->response_pl_sz);
+
+ /* Clear the CANCEL flag for next DOE request */
+ clear_bit(PCI_DOE_FLAG_CANCEL, &doe_mb->flags);
+
+ kfree(task->request_pl);
+ kfree(task);
+
+ /* Release the mailbox reference acquired during process_request */
+ pci_ep_doe_put_mailbox(doe_mb);
+}
+
+/**
+ * doe_ep_task_work() - Work function for processing DOE EP tasks
+ * @work: Work structure
+ *
+ * Process a DOE request by calling the appropriate protocol handler.
+ */
+static void doe_ep_task_work(struct work_struct *work)
+{
+ struct pci_ep_doe_task *task = container_of(work, struct pci_ep_doe_task,
+ work);
+ struct pci_ep_doe_mb *doe_mb = task->doe_mb;
+ pci_doe_protocol_handler_t handler;
+ int rc;
+
+ if (test_bit(PCI_DOE_FLAG_DEAD, &doe_mb->flags)) {
+ signal_task_complete(task, -EIO);
+ return;
+ }
+
+ /* Check if request was aborted */
+ if (test_bit(PCI_DOE_FLAG_CANCEL, &doe_mb->flags)) {
+ signal_task_complete(task, -ECANCELED);
+ return;
+ }
+
+ /* Find protocol handler in the array */
+ handler = pci_ep_doe_find_protocol(task->feat.vid, task->feat.type);
+ if (!handler) {
+ dev_warn_ratelimited(doe_mb->epc->dev.parent,
+ "[%d:%x] Unsupported protocol VID=%04x TYPE=%02x\n",
+ doe_mb->func_no, doe_mb->cap_offset,
+ task->feat.vid, task->feat.type);
+ signal_task_complete(task, -EOPNOTSUPP);
+ return;
+ }
+
+ /* Call protocol handler */
+ rc = handler(task->request_pl, task->request_pl_sz,
+ &task->response_pl, &task->response_pl_sz);
+
+ signal_task_complete(task, rc);
+}
+
+/**
+ * pci_ep_doe_submit_task() - Submit a task to be processed
+ * @doe_mb: DOE mailbox
+ * @task: Task to submit
+ *
+ * Submit a DOE task to the workqueue for asynchronous processing.
+ *
+ * Returns: 0 on success, -errno on failure
+ */
+static int pci_ep_doe_submit_task(struct pci_ep_doe_mb *doe_mb,
+ struct pci_ep_doe_task *task)
+{
+ if (test_bit(PCI_DOE_FLAG_DEAD, &doe_mb->flags))
+ return -EIO;
+
+ task->doe_mb = doe_mb;
+ INIT_WORK(&task->work, doe_ep_task_work);
+ queue_work(doe_mb->work_queue, &task->work);
+ return 0;
+}
+
+/**
+ * pci_ep_doe_process_request() - Process DOE request on endpoint
+ * @epc: PCI endpoint controller
+ * @func_no: Physical function number
+ * @cap_offset: DOE capability offset
+ * @vendor: Vendor ID from request header
+ * @type: Protocol type from request header
+ * @request: Request payload in CPU-native format
+ * @request_sz: Size of request payload (bytes)
+ * @complete: Callback to invoke upon completion
+ *
+ * Asynchronously process a DOE request received on the endpoint. The request
+ * payload should not include the DOE header (vendor/type/length). Ownership
+ * of the request buffer is transferred to DOE EP core, which frees the buffer
+ * either on error or after the completion callback fires. The protocol handler
+ * will allocate the response buffer, which the caller (controller driver) must
+ * free after use.
+ *
+ * This function returns immediately after queuing the request. The completion
+ * callback will be invoked asynchronously from workqueue context once the
+ * request is processed. The callback receives the function number and capability
+ * offset to identify the mailbox, along with a status code (0 on success, -errno
+ * on failure), and other required arguments.
+ *
+ * As per DOE specification, a mailbox processes one request at a time.
+ * Therefore, this function will never be called concurrently for the same
+ * mailbox by different callers.
+ *
+ * The caller is responsible for the conversion of the received DOE request
+ * with le32_to_cpu() before calling this function.
+ * Similarly, it is responsible for converting the response payload with
+ * cpu_to_le32() before sending it back over the DOE mailbox.
+ *
+ * The caller is also responsible for ensuring that the request size
+ * is within the limits defined by PCI_DOE_MAX_LENGTH.
+ *
+ * Returns: 0 if the request was successfully queued, -errno on failure
+ */
+int pci_ep_doe_process_request(struct pci_epc *epc, u8 func_no, u16 cap_offset,
+ u16 vendor, u8 type, void *request, size_t request_sz,
+ pci_ep_doe_complete_t complete)
+{
+ struct pci_ep_doe_mb *doe_mb;
+ struct pci_ep_doe_task *task;
+ int rc;
+
+ doe_mb = pci_ep_doe_get_mailbox(epc, func_no, cap_offset);
+ if (!doe_mb) {
+ kfree(request);
+ return -ENODEV;
+ }
+
+ task = kzalloc_obj(*task, GFP_ATOMIC);
+ if (!task) {
+ kfree(request);
+ pci_ep_doe_put_mailbox(doe_mb);
+ return -ENOMEM;
+ }
+
+ task->feat.vid = vendor;
+ task->feat.type = type;
+ task->request_pl = request;
+ task->request_pl_sz = request_sz;
+ task->response_pl = NULL;
+ task->response_pl_sz = 0;
+ task->complete = complete;
+
+ rc = pci_ep_doe_submit_task(doe_mb, task);
+ if (rc) {
+ kfree(request);
+ kfree(task);
+ pci_ep_doe_put_mailbox(doe_mb);
+ return rc;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pci_ep_doe_process_request);
+
+/**
+ * pci_ep_doe_abort() - Abort DOE operations on a mailbox
+ * @epc: PCI endpoint controller
+ * @func_no: Physical function number
+ * @cap_offset: DOE capability offset
+ *
+ * Abort the queued or in-flight DOE operation for the specified mailbox.
+ * This function is called by the EP controller driver when the RC sets the
+ * ABORT bit in the DOE Control register, and the BUSY bit is set in the
+ * DOE Status Register.
+ *
+ * The function sets the CANCEL flag on the mailbox to prevent queued requests
+ * from starting, and returns immediately. The CANCEL flag gets cleared in
+ * signal_task_complete(), allowing the mailbox to accept new requests.
+ *
+ * Returns: 0 on success, -errno on failure
+ */
+int pci_ep_doe_abort(struct pci_epc *epc, u8 func_no, u16 cap_offset)
+{
+ struct pci_ep_doe_mb *doe_mb;
+
+ if (!epc)
+ return -EINVAL;
+
+ doe_mb = pci_ep_doe_get_mailbox(epc, func_no, cap_offset);
+ if (!doe_mb)
+ return -ENODEV;
+
+ /* Set CANCEL flag - worker will abort queued requests */
+ set_bit(PCI_DOE_FLAG_CANCEL, &doe_mb->flags);
+
+ dev_dbg_ratelimited(epc->dev.parent,
+ "DOE mailbox abort initialized: PF%d offset 0x%x\n",
+ func_no, cap_offset);
+
+ pci_ep_doe_put_mailbox(doe_mb);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pci_ep_doe_abort);
+
+/**
+ * pci_ep_doe_destroy_mb() - Destroy a single DOE mailbox
+ * @doe_mb: DOE mailbox to destroy
+ *
+ * Internal function to destroy a mailbox and free its resources.
+ */
+static void pci_ep_doe_destroy_mb(struct pci_ep_doe_mb *doe_mb)
+{
+ if (!doe_mb)
+ return;
+
+ pci_ep_doe_cancel_tasks(doe_mb);
+
+ if (doe_mb->work_queue)
+ destroy_workqueue(doe_mb->work_queue);
+
+ pci_ep_doe_put_mailbox(doe_mb);
+}
+
+/**
+ * pci_ep_doe_destroy() - Destroy all DOE mailboxes
+ * @epc: PCI endpoint controller
+ *
+ * Destroy all DOE mailboxes and free associated resources.
+ *
+ * The EPC core driver calls this to free all DOE resources,
+ * if DOE support is available for the EPC.
+ */
+void pci_ep_doe_destroy(struct pci_epc *epc)
+{
+ struct pci_ep_doe_mb *doe_mb;
+ unsigned long index;
+
+ if (!epc)
+ return;
+
+ xa_for_each(&epc->doe_mbs, index, doe_mb) {
+ xa_erase(&epc->doe_mbs, index);
+ pci_ep_doe_destroy_mb(doe_mb);
+ }
+
+ xa_destroy(&epc->doe_mbs);
+}
+EXPORT_SYMBOL_GPL(pci_ep_doe_destroy);
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 5844deee2b5f..c4a0e25625e3 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -692,6 +692,13 @@ struct pci_doe_feature {
u8 type;
};
+struct pci_epc;
+
+typedef void (*pci_ep_doe_complete_t)(struct pci_epc *epc, u8 func_no,
+ u16 cap_offset, int status,
+ u16 vendor, u8 type,
+ void *response_pl, size_t response_pl_sz);
+
#ifdef CONFIG_PCI_DOE
void pci_doe_init(struct pci_dev *pdev);
void pci_doe_destroy(struct pci_dev *pdev);
@@ -702,6 +709,38 @@ static inline void pci_doe_destroy(struct pci_dev *pdev) { }
static inline void pci_doe_disconnected(struct pci_dev *pdev) { }
#endif
+#ifdef CONFIG_PCI_ENDPOINT_DOE
+int pci_ep_doe_init(struct pci_epc *epc);
+int pci_ep_doe_add_mailbox(struct pci_epc *epc, u8 func_no, u16 cap_offset);
+int pci_ep_doe_process_request(struct pci_epc *epc, u8 func_no, u16 cap_offset,
+ u16 vendor, u8 type, void *request,
+ size_t request_sz, pci_ep_doe_complete_t complete);
+int pci_ep_doe_abort(struct pci_epc *epc, u8 func_no, u16 cap_offset);
+void pci_ep_doe_destroy(struct pci_epc *epc);
+#else
+static inline int pci_ep_doe_init(struct pci_epc *epc) { return -EOPNOTSUPP; }
+static inline int pci_ep_doe_add_mailbox(struct pci_epc *epc, u8 func_no,
+ u16 cap_offset)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline int pci_ep_doe_process_request(struct pci_epc *epc, u8 func_no,
+ u16 cap_offset, u16 vendor, u8 type,
+ void *request, size_t request_sz,
+ pci_ep_doe_complete_t complete)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline int pci_ep_doe_abort(struct pci_epc *epc, u8 func_no, u16 cap_offset)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline void pci_ep_doe_destroy(struct pci_epc *epc) { }
+#endif
+
#ifdef CONFIG_PCI_NPEM
void pci_npem_create(struct pci_dev *dev);
void pci_npem_remove(struct pci_dev *dev);
diff --git a/include/linux/pci-doe.h b/include/linux/pci-doe.h
index abb9b7ae8029..c46e42f3ce78 100644
--- a/include/linux/pci-doe.h
+++ b/include/linux/pci-doe.h
@@ -22,6 +22,11 @@ struct pci_doe_mb;
/* Max data object length is 2^18 dwords */
#define PCI_DOE_MAX_LENGTH (1 << 18)
+typedef int (*pci_doe_protocol_handler_t)(const void *request,
+ size_t request_sz,
+ void **response,
+ size_t *response_sz);
+
struct pci_doe_mb *pci_find_doe_mailbox(struct pci_dev *pdev, u16 vendor,
u8 type);
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index 1eca1264815b..dd26294c8175 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -182,6 +182,9 @@ struct pci_epc {
unsigned long function_num_map;
int domain_nr;
bool init_complete;
+#ifdef CONFIG_PCI_ENDPOINT_DOE
+ struct xarray doe_mbs;
+#endif
};
/**
--
2.34.1
^ permalink raw reply related
* [PATCH v5 0/4] PCI: Add DOE support for endpoint
From: Aksh Garg @ 2026-06-10 10:02 UTC (permalink / raw)
To: linux-pci, linux-doc, mani, kwilczynski, bhelgaas, corbet, kishon,
skhan, lukas, cassel, alistair
Cc: linux-arm-kernel, linux-kernel, s-vadapalli, danishanwar, srk,
a-garg7
This patch series introduces the framework for supporting the Data
Object Exchange (DOE) feature for PCIe endpoint devices. Please refer
to the documentation added in patch 4 for details on the feature and
implementation architecture.
The implementation provides a common framework for all PCIe endpoint
controllers, not specific to any particular SoC vendor.
The changes since v1 are documented in the respective patch descriptions.
v4: https://lore.kernel.org/all/20260522052434.802034-1-a-garg7@ti.com/
v3: https://lore.kernel.org/all/20260427051725.223704-1-a-garg7@ti.com/
v2: https://lore.kernel.org/all/20260401073022.215805-1-a-garg7@ti.com/
v1 (RFC): https://lore.kernel.org/all/20260213123603.420941-1-a-garg7@ti.com/
Below is a code demonstration showing the integration of DOE-EP APIs with
EPC drivers.
Note: The provided code is just to show how an EPC driver is expected to
utilize the pci_ep_doe_process_request() and pci_ep_doe_abort() APIs,
and might not cover all the corner cases. The below implementation
also expects the EPC hardware to have some memory buffer to store the
data from(for) write_mailbox(read_mailbox) DOE capability registers.
============================================================================
/* ========== DOE Completion Callback (invoked by DOE-EP core) ========== */
static void doe_completion_cb(struct pci_epc *epc, u8 func_no, u16 cap_offset,
int status, u16 vendor, u8 type,
void *response_pl, size_t response_pl_sz)
{
struct epc_driver *drv = epc_get_drvdata(epc);
u32 *response = (u32 *)response_pl;
u32 header1, header2;
int payload_dw, i;
if (readl(drv->base + PF_DOE_CTRL_REG(func_no, cap_offset)) & DOE_CTRL_ABORT) {
/* Aborted: do not send response */
goto free;
}
if (status < 0) {
/* Error: set ERROR bit in DOE Status register */
writel(1 << DOE_STATUS_ERROR,
drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
goto free;
}
/* Success: write DOE headers first, then response to the read memory */
/* Header 1: Vendor ID (bits 15:0) | Type (bits 23:16) */
header1 = (type << 16) | vendor;
writel(header1, drv->base + PF_DOE_RD_MEMORY_WR_REG(func_no, cap_offset));
/* Header 2: Length in DW (including 2 DW of headers + payload) */
payload_dw = DIV_ROUND_UP(response_pl_sz, sizeof(u32));
header2 = 2 + payload_dw; /* 2 header DWs + payload */
writel(header2, drv->base + PF_DOE_RD_MEMORY_WR_REG(func_no, cap_offset));
/* Set READY bit to signal response ready */
writel(1 << DOE_STATUS_READY,
drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
/* Write response payload DWORDs to Read memory */
for (i = 0; i < payload_dw; i++)
writel(response[i],
drv->base + PF_DOE_RD_MEMORY_WR_REG(func_no, cap_offset));
/* Wait for the memory to empty before clearing the READY bit */
while (!RD_MEMORY_EMPTY()) {/* wait */}
writel(0 << DOE_STATUS_READY,
drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
free:
/* unset BUSY bit */
writel(0 << DOE_STATUS_BUSY,
drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
kfree(response_pl);
}
/* ========== DOE Interrupt Handler (triggered on GO bit from root complex) ========== */
static irqreturn_t doe_interrupt_handler(int irq, void *priv)
{
struct epc_driver *drv = priv;
u16 cap_offset = extract_cap_offset_from_irq(irq);
u8 func_no = extract_func_from_irq(irq);
u32 header1, header2, length_dw, *request;
u16 vendor;
u8 type;
int i, ret;
/* Read first header DWORD: Vendor ID (bits 15:0) | Type (bits 23:16) */
header1 = readl(drv->base + PF_DOE_WR_MEMORY_RD_REG(func_no, cap_offset));
vendor = header1 & 0xFFFF;
type = (header1 >> 16) & 0xFF;
/* Read second header DWORD: Length in DW (includes 2 DW of headers) */
header2 = readl(drv->base + PF_DOE_WR_MEMORY_RD_REG(func_no, cap_offset));
length_dw = header2 & 0x3FFFF; /* Bits 17:0 */
if (!length_dw)
length_dw = PCI_DOE_MAX_LENGTH;
length_dw -= 2; /* Subtract 2 DW of headers to get payload length */
/* Allocate buffer for complete request (headers + payload) */
request = kzalloc(length_dw * sizeof(u32), GFP_ATOMIC);
if (!request) {
writel(1 << DOE_STATUS_ERROR,
drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
return IRQ_HANDLED;
}
/* Read remaining payload DWORDs from Write memory */
for (i = 0; i < length_dw; i++) {
while (WR_MEMORY_EMPTY()) { /* wait */ }
request[i] = readl(drv->base + PF_DOE_WR_MEMORY_RD_REG(func_no, cap_offset));
}
mutex_lock(&lock);
/* Check the ABORT bit, if set then return */
if (readl(drv->base + PF_DOE_CTRL_REG(func_no, cap_offset)) & DOE_CTRL_ABORT) {
kfree(request);
mutex_unlock(&lock);
return IRQ_HANDLED;
}
/* Set BUSY bit */
writel(1 << DOE_STATUS_BUSY,
drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
mutex_unlock(&lock);
/* Hand off to DOE-EP core for asynchronous processing */
ret = pci_ep_doe_process_request(drv->epc, func_no, cap_offset,
vendor, type, (void *)request,
length_dw * sizeof(u32),
doe_completion_cb);
if (ret) {
writel(1 << DOE_STATUS_ERROR,
drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
kfree(request);
}
return IRQ_HANDLED;
}
/* ========== Abort Handler (triggered on ABORT bit from root complex) ========== */
static irqreturn_t doe_abort_handler(int irq, void *priv)
{
struct epc_driver *drv = priv;
u16 cap_offset = extract_cap_offset_from_irq(irq);
u8 func_no = extract_func_from_irq(irq);
mutex_lock(&lock);
/* call abort API only if BUSY bit set (pci_ep_doe_process_request() called) */
if (readl(drv->base + PF_DOE_STATUS_REG(func_no, cap_offset)) & DOE_STATUS_BUSY)
pci_ep_doe_abort(drv->epc, func_no, cap_offset);
mutex_unlock(&lock);
/* Discard Write memory contents */
writel(DOE_WR_MEMORY_CTRL_DISCARD,
drv->base + PF_DOE_WR_MEMORY_CTRL_REG(func_no, cap_offset));
/* Clear status bits */
writel((0 << DOE_STATUS_ERROR) | (0 << DOE_STATUS_READY),
drv->base + PF_DOE_STATUS_REG(func_no, cap_offset));
return IRQ_HANDLED;
}
====================================================================================
Aksh Garg (4):
PCI/DOE: Move common definitions to the header file
PCI: endpoint: Add DOE mailbox support for endpoint functions
PCI: endpoint: Add support for DOE initialization and setup in EPC
core
Documentation: PCI: Add documentation for DOE endpoint support
Documentation/PCI/endpoint/index.rst | 1 +
.../PCI/endpoint/pci-endpoint-doe.rst | 333 ++++++++++
drivers/pci/doe.c | 11 -
drivers/pci/endpoint/Kconfig | 14 +
drivers/pci/endpoint/Makefile | 1 +
drivers/pci/endpoint/pci-ep-doe.c | 594 ++++++++++++++++++
drivers/pci/endpoint/pci-epc-core.c | 104 +++
drivers/pci/pci.h | 48 ++
include/linux/pci-doe.h | 8 +
include/linux/pci-epc.h | 9 +
10 files changed, 1112 insertions(+), 11 deletions(-)
create mode 100644 Documentation/PCI/endpoint/pci-endpoint-doe.rst
create mode 100644 drivers/pci/endpoint/pci-ep-doe.c
--
2.34.1
^ permalink raw reply
* [PATCH v5 1/4] PCI/DOE: Move common definitions to the header file
From: Aksh Garg @ 2026-06-10 10:02 UTC (permalink / raw)
To: linux-pci, linux-doc, mani, kwilczynski, bhelgaas, corbet, kishon,
skhan, lukas, cassel, alistair
Cc: linux-arm-kernel, linux-kernel, s-vadapalli, danishanwar, srk,
a-garg7
In-Reply-To: <20260610100256.1889111-1-a-garg7@ti.com>
Move common macros and structures from drivers/pci/doe.c to
drivers/pci/pci.h to allow reuse across root complex and
endpoint DOE implementations.
PCI_DOE_MAX_LENGTH macro can be used outside the PCI core as well,
hence move the macro to include/linux/pci-doe.h.
These changes prepare the groundwork for the DOE endpoint implementation
that will reuse these common definitions.
Co-developed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Aksh Garg <a-garg7@ti.com>
---
Changes from v4 to v5:
- None.
Changes from v3 to v4:
- None.
Changes from v2 to v3:
- Rebased on 7.1-rc1.
Changes since v1:
- Moved the common macros that need not be visible outside the PCI core
to drivers/pci/pci.h instead to include/linux/pci-doe.h as suggested
by Lukas Wunner
- Removed the redundant empty inlines guarded with CONFIG_PCI_DOE in
include/linux/pci-doe.h.
v4: https://lore.kernel.org/all/20260522052434.802034-2-a-garg7@ti.com/
v3: https://lore.kernel.org/all/20260427051725.223704-2-a-garg7@ti.com/
v2: https://lore.kernel.org/all/20260401073022.215805-2-a-garg7@ti.com/
v1: https://lore.kernel.org/all/20260213123603.420941-3-a-garg7@ti.com/
drivers/pci/doe.c | 11 -----------
drivers/pci/pci.h | 9 +++++++++
include/linux/pci-doe.h | 3 +++
3 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/pci/doe.c b/drivers/pci/doe.c
index 7b41da4ec11a..e8d9e95644b3 100644
--- a/drivers/pci/doe.c
+++ b/drivers/pci/doe.c
@@ -28,12 +28,6 @@
#define PCI_DOE_TIMEOUT HZ
#define PCI_DOE_POLL_INTERVAL (PCI_DOE_TIMEOUT / 128)
-#define PCI_DOE_FLAG_CANCEL 0
-#define PCI_DOE_FLAG_DEAD 1
-
-/* Max data object length is 2^18 dwords */
-#define PCI_DOE_MAX_LENGTH (1 << 18)
-
/**
* struct pci_doe_mb - State for a single DOE mailbox
*
@@ -63,11 +57,6 @@ struct pci_doe_mb {
#endif
};
-struct pci_doe_feature {
- u16 vid;
- u8 type;
-};
-
/**
* struct pci_doe_task - represents a single query/response
*
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 4a14f88e543a..5844deee2b5f 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -683,6 +683,15 @@ struct pci_sriov {
bool drivers_autoprobe; /* Auto probing of VFs by driver */
};
+/* DOE Mailbox state flags */
+#define PCI_DOE_FLAG_CANCEL 0
+#define PCI_DOE_FLAG_DEAD 1
+
+struct pci_doe_feature {
+ u16 vid;
+ u8 type;
+};
+
#ifdef CONFIG_PCI_DOE
void pci_doe_init(struct pci_dev *pdev);
void pci_doe_destroy(struct pci_dev *pdev);
diff --git a/include/linux/pci-doe.h b/include/linux/pci-doe.h
index bd4346a7c4e7..abb9b7ae8029 100644
--- a/include/linux/pci-doe.h
+++ b/include/linux/pci-doe.h
@@ -19,6 +19,9 @@ struct pci_doe_mb;
#define PCI_DOE_FEATURE_CMA 1
#define PCI_DOE_FEATURE_SSESSION 2
+/* Max data object length is 2^18 dwords */
+#define PCI_DOE_MAX_LENGTH (1 << 18)
+
struct pci_doe_mb *pci_find_doe_mailbox(struct pci_dev *pdev, u16 vendor,
u8 type);
--
2.34.1
^ permalink raw reply related
* [PATCH v5 3/4] PCI: endpoint: Add support for DOE initialization and setup in EPC core
From: Aksh Garg @ 2026-06-10 10:02 UTC (permalink / raw)
To: linux-pci, linux-doc, mani, kwilczynski, bhelgaas, corbet, kishon,
skhan, lukas, cassel, alistair
Cc: linux-arm-kernel, linux-kernel, s-vadapalli, danishanwar, srk,
a-garg7
In-Reply-To: <20260610100256.1889111-1-a-garg7@ti.com>
Add pci_epc_init_capabilities() in EPC core driver to initialize and
setup the capabilities supported by the EPC driver. This calls
pci_epc_doe_setup() to setup the DOE framework for an endpoint controller,
which discovers the DOE capabilities (extended capability ID 0x2E), and
registers each discovered DOE mailbox for all the functions in the
endpoint controller.
Add pci_epc_deinit_capabilities() in EPC core driver for cleanup of the
resources used by the capabilities of the EPC driver. This calls
pci_ep_doe_destroy() to destroy all DOE mailboxes and free associated
resources.
Co-developed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Signed-off-by: Aksh Garg <a-garg7@ti.com>
---
Changes from v4 to v5:
- Addressed the review comments by Sashiko
Changes from v3 to v4:
- Call DOE setup and destroy APIs directly within the EPC core, instead of
relying on the EPC drivers to call them individually. EPC drivers do not
need to explicitly handle DOE setup, rather the EPC core manages this
transparently. (Suggested by Manivannan Sadhasivam).
- Removed pci_epc_doe_destroy() API, which was just calling pci_ep_doe_destroy().
Instead, called pci_ep_doe_destroy() directly during cleanup.
- Called pci_ep_doe_init() before the "!epc->ops->find_ext_capability" check,
because if doe-capable=1 and find_ext_capability() op is undefined, this
would not initialize the epc->doe_mbs xarray. However during cleanup, the
check "!epc->ops->find_ext_capability" would be unnecessary, and it will
try to destroy the epc->doe_mbs xarray even when it was not initialized.
Changes from v2 to v3:
- Rebased on 7.1-rc1.
Changes since v1:
- New patch added to v2 (not present in v1)
v4: https://lore.kernel.org/all/20260522052434.802034-4-a-garg7@ti.com/
v3: https://lore.kernel.org/all/20260427051725.223704-4-a-garg7@ti.com/
v2: https://lore.kernel.org/all/20260401073022.215805-4-a-garg7@ti.com/
This patch is introduced based on the feedback provided by Manivannan
Sadhasivam at [1].
[1]: https://lore.kernel.org/all/p57x6jleaim5w7t2k3v7tioujnaxuovfpj5euop5ogefvw23se@y5fw3che5p5d/
drivers/pci/endpoint/pci-epc-core.c | 104 ++++++++++++++++++++++++++++
include/linux/pci-epc.h | 6 ++
2 files changed, 110 insertions(+)
diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
index 6c3c58185fc5..e48f40eeed29 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -14,6 +14,8 @@
#include <linux/pci-epf.h>
#include <linux/pci-ep-cfs.h>
+#include "../pci.h"
+
static const struct class pci_epc_class = {
.name = "pci_epc",
};
@@ -842,6 +844,81 @@ void pci_epc_linkdown(struct pci_epc *epc)
}
EXPORT_SYMBOL_GPL(pci_epc_linkdown);
+/**
+ * pci_epc_doe_setup() - Discover and setup DOE mailboxes for all functions
+ * @epc: the EPC device on which DOE mailboxes has to be setup
+ *
+ * Discover DOE (Data Object Exchange) capabilities for all physical functions
+ * in the endpoint controller and register DOE mailboxes.
+ *
+ * Returns: 0 on success, -errno on failure
+ */
+static int pci_epc_doe_setup(struct pci_epc *epc)
+{
+ u8 func_no, vfunc_no = 0;
+ u16 cap_offset;
+ int ret;
+
+ if (!epc->ops || !epc->ops->find_ext_capability)
+ return -EINVAL;
+
+ /* Discover DOE capabilities for all functions */
+ for (func_no = 0; func_no < epc->max_functions; func_no++) {
+ mutex_lock(&epc->lock);
+ cap_offset = epc->ops->find_ext_capability(epc, func_no,
+ vfunc_no, 0,
+ PCI_EXT_CAP_ID_DOE);
+ mutex_unlock(&epc->lock);
+
+ while (cap_offset) {
+ /* Register this DOE mailbox */
+ ret = pci_ep_doe_add_mailbox(epc, func_no, cap_offset);
+ if (ret) {
+ dev_warn(&epc->dev,
+ "[pf%d:offset %x] failed to add DOE mailbox\n",
+ func_no, cap_offset);
+ }
+
+ mutex_lock(&epc->lock);
+ cap_offset = epc->ops->find_ext_capability(epc, func_no,
+ vfunc_no, cap_offset,
+ PCI_EXT_CAP_ID_DOE);
+ mutex_unlock(&epc->lock);
+ }
+ }
+
+ dev_dbg(&epc->dev, "DOE mailboxes setup complete\n");
+ return 0;
+}
+
+/**
+ * pci_epc_init_capabilities() - Initialize EPC capabilities
+ * @epc: the EPC device whose capabilities need to be initialized
+ *
+ * Invoke to initialize capabilities supported by the EPC device.
+ */
+static void pci_epc_init_capabilities(struct pci_epc *epc)
+{
+ const struct pci_epc_features *epc_features;
+ int ret;
+
+ epc_features = pci_epc_get_features(epc, 0, 0);
+ if (!epc_features)
+ return;
+
+ if (IS_ENABLED(CONFIG_PCI_ENDPOINT_DOE) && epc_features->doe_capable) {
+ ret = pci_ep_doe_init(epc);
+ if (ret) {
+ dev_warn(&epc->dev, "DOE initialization failed: %d\n", ret);
+ return;
+ }
+
+ ret = pci_epc_doe_setup(epc);
+ if (ret)
+ dev_warn(&epc->dev, "DOE setup failed: %d\n", ret);
+ }
+}
+
/**
* pci_epc_init_notify() - Notify the EPF device that EPC device initialization
* is completed.
@@ -857,6 +934,9 @@ void pci_epc_init_notify(struct pci_epc *epc)
if (IS_ERR_OR_NULL(epc))
return;
+ if (!epc->init_complete)
+ pci_epc_init_capabilities(epc);
+
mutex_lock(&epc->list_lock);
list_for_each_entry(epf, &epc->pci_epf, list) {
mutex_lock(&epf->lock);
@@ -890,6 +970,27 @@ void pci_epc_notify_pending_init(struct pci_epc *epc, struct pci_epf *epf)
}
EXPORT_SYMBOL_GPL(pci_epc_notify_pending_init);
+/**
+ * pci_epc_deinit_capabilities() - Cleanup EPC capabilities
+ * @epc: the EPC device whose capabilities need to be cleaned up
+ *
+ * Invoke to cleanup capabilities supported by the EPC device,
+ * and free the associated resources.
+ */
+static void pci_epc_deinit_capabilities(struct pci_epc *epc)
+{
+ const struct pci_epc_features *epc_features;
+
+ epc_features = pci_epc_get_features(epc, 0, 0);
+ if (!epc_features)
+ return;
+
+ if (IS_ENABLED(CONFIG_PCI_ENDPOINT_DOE) && epc_features->doe_capable) {
+ pci_ep_doe_destroy(epc);
+ dev_dbg(&epc->dev, "DOE mailboxes destroyed\n");
+ }
+}
+
/**
* pci_epc_deinit_notify() - Notify the EPF device about EPC deinitialization
* @epc: the EPC device whose deinitialization is completed
@@ -903,6 +1004,9 @@ void pci_epc_deinit_notify(struct pci_epc *epc)
if (IS_ERR_OR_NULL(epc))
return;
+ if (epc->init_complete)
+ pci_epc_deinit_capabilities(epc);
+
mutex_lock(&epc->list_lock);
list_for_each_entry(epf, &epc->pci_epf, list) {
mutex_lock(&epf->lock);
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index dd26294c8175..11474e337db3 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -84,6 +84,8 @@ struct pci_epc_map {
* @start: ops to start the PCI link
* @stop: ops to stop the PCI link
* @get_features: ops to get the features supported by the EPC
+ * @find_ext_capability: ops to find extended capability offset for a function
+ * in endpoint controller
* @owner: the module owner containing the ops
*/
struct pci_epc_ops {
@@ -115,6 +117,8 @@ struct pci_epc_ops {
void (*stop)(struct pci_epc *epc);
const struct pci_epc_features* (*get_features)(struct pci_epc *epc,
u8 func_no, u8 vfunc_no);
+ u16 (*find_ext_capability)(struct pci_epc *epc, u8 func_no,
+ u8 vfunc_no, u16 start, u8 cap);
struct module *owner;
};
@@ -270,6 +274,7 @@ struct pci_epc_bar_desc {
* @msi_capable: indicate if the endpoint function has MSI capability
* @msix_capable: indicate if the endpoint function has MSI-X capability
* @intx_capable: indicate if the endpoint can raise INTx interrupts
+ * @doe_capable: indicate if the endpoint function has DOE capability
* @bar: array specifying the hardware description for each BAR
* @align: alignment size required for BAR buffer allocation
*/
@@ -280,6 +285,7 @@ struct pci_epc_features {
unsigned int msi_capable : 1;
unsigned int msix_capable : 1;
unsigned int intx_capable : 1;
+ unsigned int doe_capable : 1;
struct pci_epc_bar_desc bar[PCI_STD_NUM_BARS];
size_t align;
};
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: rockchip: Add HINLINK H28K
From: Chukun Pan @ 2026-06-10 10:00 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Rob Herring, Chukun Pan, Conor Dooley, Krzysztof Kozlowski,
linux-arm-kernel, linux-rockchip, linux-kernel, devicetree
In-Reply-To: <20260610100006.366963-1-amadeus@jmu.edu.cn>
The HINLINK H28K (LinkStar H28K) is a SBC with the
Rockchip RK3528 SoC. It has the following features:
- 1x USB 2.0
- 8/32GB eMMC
- 1/2/4GB LPDDR4
- MicroSD card slot
- 1x 1GbE RTL8111H Ethernet
- 1x 1GbE RTL8211F Ethernet
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3528-hinlink-h28k.dts | 318 ++++++++++++++++++
2 files changed, 319 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 761d82b4f4f2..a68d07296c9f 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -92,6 +92,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire-excavator.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399pro-rock-pi-n10.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-armsom-sige1.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-hinlink-h28k.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-nanopi-zero2.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-radxa-e20c.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-rock-2a.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts b/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
new file mode 100644
index 000000000000..0ec50e9156eb
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
@@ -0,0 +1,318 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pwm/pwm.h>
+#include "rk3528.dtsi"
+
+/ {
+ model = "HINLINK H28K";
+ compatible = "hinlink,h28k", "rockchip,rk3528";
+
+ aliases {
+ ethernet0 = &gmac1;
+ mmc0 = &sdhci;
+ mmc1 = &sdmmc;
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:1500000n8";
+ };
+
+ keys {
+ compatible = "adc-keys";
+ io-channels = <&saradc 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <1800000>;
+ poll-interval = <100>;
+
+ button-boot {
+ label = "BOOT";
+ linux,code = <KEY_SETUP>;
+ press-threshold-microvolt = <0>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&lan_led>, <&wan_led>, <&work_led>;
+
+ led-0 {
+ color = <LED_COLOR_ID_AMBER>;
+ function = LED_FUNCTION_LAN;
+ gpios = <&gpio4 RK_PC1 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "netdev";
+ };
+
+ led-1 {
+ color = <LED_COLOR_ID_BLUE>;
+ function = LED_FUNCTION_WAN;
+ gpios = <&gpio4 RK_PC0 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "netdev";
+ };
+
+ led-2 {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio4 RK_PB7 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "default-on";
+ };
+ };
+
+ vdd_0v9: regulator-0v9-vdd {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_0v9";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ vcc_ddr: regulator-1v1-vcc-ddr {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_ddr";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ vcc_1v8: regulator-1v8-vcc {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vcc_3v3>;
+ };
+
+ vcc_3v3: regulator-3v3-vcc {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_3v3";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ vcc3v3_sd: regulator-3v3-vcc-sd {
+ compatible = "regulator-fixed";
+ gpios = <&gpio4 RK_PA1 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc_pwren_l>;
+ regulator-name = "vcc3v3_sd";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vcc_3v3>;
+ };
+
+ vcc5v0_sys: regulator-5v0-vcc-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ vccio_sd: regulator-vccio-sd {
+ compatible = "regulator-gpio";
+ gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc_vol_ctrl_h>;
+ regulator-name = "vccio_sd";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ states = <1800000 0x0>, <3300000 0x1>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ vdd_arm: regulator-vdd-arm {
+ compatible = "pwm-regulator";
+ pwms = <&pwm1 0 5000 PWM_POLARITY_INVERTED>;
+ pwm-supply = <&vcc5v0_sys>;
+ regulator-name = "vdd_arm";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <746000>;
+ regulator-max-microvolt = <1201000>;
+ regulator-settling-time-up-us = <250>;
+ };
+
+ vdd_logic: regulator-vdd-logic {
+ compatible = "pwm-regulator";
+ pwms = <&pwm2 0 5000 PWM_POLARITY_INVERTED>;
+ pwm-supply = <&vcc5v0_sys>;
+ regulator-name = "vdd_logic";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <705000>;
+ regulator-max-microvolt = <1006000>;
+ regulator-settling-time-up-us = <250>;
+ };
+};
+
+&combphy {
+ status = "okay";
+};
+
+&cpu0 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&cpu1 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&cpu2 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&cpu3 {
+ cpu-supply = <&vdd_arm>;
+};
+
+&gmac1 {
+ clock_in_out = "output";
+ phy-handle = <&rgmii_phy>;
+ phy-mode = "rgmii-id";
+ phy-supply = <&vcc_3v3>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_miim>,
+ <&rgmii_tx_bus2>,
+ <&rgmii_rx_bus2>,
+ <&rgmii_rgmii_clk>,
+ <&rgmii_rgmii_bus>;
+ status = "okay";
+};
+
+&gpu {
+ mali-supply = <&vdd_logic>;
+ status = "okay";
+};
+
+&mdio1 {
+ rgmii_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0x1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac1_rstn_l>;
+ reset-assert-us = <20000>;
+ reset-deassert-us = <100000>;
+ reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&pcie {
+ pinctrl-names = "default";
+ pinctrl-0 = <&rtl8111hs_isolateb_l>;
+ reset-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>;
+ vpcie3v3-supply = <&vcc_3v3>;
+ status = "okay";
+};
+
+&pinctrl {
+ gmac {
+ gmac1_rstn_l: gmac1-rstn-l {
+ rockchip,pins = <4 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ leds {
+ lan_led: lan-led {
+ rockchip,pins = <4 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ wan_led: wan-led {
+ rockchip,pins = <4 RK_PC0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ work_led: work-led {
+ rockchip,pins = <4 RK_PB7 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pcie {
+ rtl8111hs_isolateb_l: rtl8111hs-isolateb-l {
+ rockchip,pins = <4 RK_PA6 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ sdmmc {
+ sdmmc_pwren_l: sdmmc-pwren-l {
+ rockchip,pins = <4 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ sdmmc_vol_ctrl_h: sdmmc-vol-ctrl-h {
+ rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm1m0_pins>;
+ status = "okay";
+};
+
+&pwm2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm2m0_pins>;
+ status = "okay";
+};
+
+&saradc {
+ vref-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&sdhci {
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ mmc-hs200-1_8v;
+ non-removable;
+ vmmc-supply = <&vcc_3v3>;
+ vqmmc-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&sdmmc {
+ bus-width = <4>;
+ cap-sd-highspeed;
+ disable-wp;
+ sd-uhs-sdr104;
+ vmmc-supply = <&vcc3v3_sd>;
+ vqmmc-supply = <&vccio_sd>;
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0m0_xfer>;
+ status = "okay";
+};
+
+&usb2phy {
+ status = "okay";
+};
+
+&usb2phy_host {
+ phy-supply = <&vcc5v0_sys>;
+ status = "okay";
+};
+
+&usb_host0_ehci {
+ status = "okay";
+};
+
+&usb_host0_ohci {
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/2] arm64: dts: rockchip: Add HINLINK H28K
From: Chukun Pan @ 2026-06-10 10:00 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Rob Herring, Chukun Pan, Conor Dooley, Krzysztof Kozlowski,
linux-arm-kernel, linux-rockchip, linux-kernel, devicetree
The HINLINK H28K is a dual-gigabit SBC based on the RK3528 SoC.
There is a version that SeeedStudio distributes called LinkStar-H28K.
It's no different from the HINLINK H28K. The schematic can be found here:
https://www.hinlink.cn/wp-content/uploads/2024/03/20240428015024130824.pdf
https://files.seeedstudio.com/wiki/H28K/Open_source/H28K-SCH.zip
The U-Boot patch will be sent after the kernel device tree is merged.
Changes in v2:
- Add USB 2.0 support
- Remove MangoPi patches
- Improve commit messages
Chukun Pan (2):
dt-bindings: arm: rockchip: Add HINLINK H28K
arm64: dts: rockchip: Add HINLINK H28K
.../devicetree/bindings/arm/rockchip.yaml | 5 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3528-hinlink-h28k.dts | 318 ++++++++++++++++++
3 files changed, 324 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-hinlink-h28k.dts
--
2.34.1
^ 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