* [PATCH v8 1/3] dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible string
From: Jianhua Lin @ 2026-05-19 2:17 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
In-Reply-To: <20260519021726.19137-1-jianhua.lin@mediatek.com>
Add the compatible string for the JPEG decoder block found in the
MediaTek MT8189 SoC.
Compared to previous generation ICs, the MT8189 JPEG decoder requires
34-bit IOVA address space support and only needs a single clock
("jpgdec") instead of two. Therefore, it is added as a standalone
compatible string without falling back to older SoCs.
Update the binding schema to include the new compatible string and add
an `allOf` block with conditional checks. This enforces the single clock
requirement for MT8189 while preserving the two-clock requirement
("jpgdec-smi", "jpgdec") for older SoCs.
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../bindings/media/mediatek-jpeg-decoder.yaml | 44 +++++++++++++++----
1 file changed, 36 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
index a4aacd3eb189..a152c874b53b 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
@@ -15,10 +15,10 @@ description: |-
properties:
compatible:
oneOf:
- - items:
- - enum:
- - mediatek,mt8173-jpgdec
- - mediatek,mt2701-jpgdec
+ - enum:
+ - mediatek,mt2701-jpgdec
+ - mediatek,mt8173-jpgdec
+ - mediatek,mt8189-jpgdec
- items:
- enum:
- mediatek,mt7623-jpgdec
@@ -32,13 +32,16 @@ properties:
maxItems: 1
clocks:
+ minItems: 1
maxItems: 2
- minItems: 2
clock-names:
- items:
- - const: jpgdec-smi
- - const: jpgdec
+ oneOf:
+ - items:
+ - const: jpgdec
+ - items:
+ - const: jpgdec-smi
+ - const: jpgdec
power-domains:
maxItems: 1
@@ -51,6 +54,10 @@ properties:
Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details.
Ports are according to the HW.
+ mediatek,larb:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: A phandle to the smi_larb node.
+
required:
- compatible
- reg
@@ -60,6 +67,27 @@ required:
- power-domains
- iommus
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8189-jpgdec
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ maxItems: 1
+ required:
+ - mediatek,larb
+ else:
+ properties:
+ clocks:
+ minItems: 2
+ clock-names:
+ minItems: 2
+
additionalProperties: false
examples:
--
2.45.2
^ permalink raw reply related
* [PATCH v8 2/3] dt-bindings: media: mediatek-jpeg-encoder: add MT8189 compatible string
From: Jianhua Lin @ 2026-05-19 2:17 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
In-Reply-To: <20260519021726.19137-1-jianhua.lin@mediatek.com>
Add the compatible string for the JPEG encoder block found in the
MediaTek MT8189 SoC.
Unlike some previous SoCs, the MT8189 JPEG encoder requires 34-bit IOVA
address space support. Therefore, it is added as a standalone compatible
string without falling back to the generic "mediatek,mtk-jpgenc" to
ensure the driver applies the correct hardware-specific configurations.
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../bindings/media/mediatek-jpeg-encoder.yaml | 30 +++++++++++++++----
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
index 5b15f8977f67..f75871e72633 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
@@ -14,13 +14,17 @@ description: |-
properties:
compatible:
- items:
+ oneOf:
- enum:
- - mediatek,mt2701-jpgenc
- - mediatek,mt8183-jpgenc
- - mediatek,mt8186-jpgenc
- - mediatek,mt8188-jpgenc
- - const: mediatek,mtk-jpgenc
+ - mediatek,mt8189-jpgenc
+ - items:
+ - enum:
+ - mediatek,mt2701-jpgenc
+ - mediatek,mt8183-jpgenc
+ - mediatek,mt8186-jpgenc
+ - mediatek,mt8188-jpgenc
+ - const: mediatek,mtk-jpgenc
+
reg:
maxItems: 1
@@ -45,6 +49,10 @@ properties:
Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details.
Ports are according to the HW.
+ mediatek,larb:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: A phandle to the smi_larb node.
+
required:
- compatible
- reg
@@ -54,6 +62,16 @@ required:
- power-domains
- iommus
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8189-jpgenc
+ then:
+ required:
+ - mediatek,larb
+
additionalProperties: false
examples:
--
2.45.2
^ permalink raw reply related
* [PATCH v8 0/3] Mediatek MT8189 JPEG support
From: Jianhua Lin @ 2026-05-19 2:17 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
This series is based on linux-next tag next-20260508.
This series depends on commit 7560349ee0d9 ("media: mediatek: jpeg:
support 34bits"), which introduced the `support_34bit` field in struct
mtk_jpeg_variant. That commit has already been merged via the media
tree and is present in linux-next as of next-20260508.
Changes compared with v7:
- Patches 1/3 (dt-bindings: decoder):
- In the allOf constraints, only keep maxItems: 1 in the then
branch and minItems: 2 in the else branch; remove duplicated
constraints already defined at the top level
Changes compared with v6:
- Patches 1/3 (dt-bindings: decoder):
update the existing `allOf` condition for mediatek,mt8189-jpgdec to
make the 'mediatek,larb' property strictly required for MT8189 SoC.
- Patches 2/3 (dt-bindings: encoder):
Add an `allOf` condition to enforce that the `mediatek,larb` property
is strictly required when the compatible string contains
mediatek,mt8189-jpgenc.
Changes compared with v5:
- Patches 1/3 (dt-bindings: decoder):
- Drop top-level minItems/maxItems for clock-names per Krzysztof's
review.
- Refine allOf block to strictly enforce clock constraints.
Changes compared with v4:
- Refines the device tree bindings for JPEG decoder and encoder.
- Patches 1/3 (dt-bindings: decoder):
Moved the standalone compatible string mediatek,mt8189-jpgdec
into the first oneOf entry along with mt2701 and mt8173, as
suggested by Rob Herring. This correctly groups all independent
ICs and removes the redundant items wrapper.
- Patches 2/3 (dt-bindings: encoder):
Applied the same logic suggested by Rob Herring to the encoder
binding. Restructured the compatible property to clearly
distinguish between the standalone IC (mediatek,mt8189-jpgenc)
and the ICs that must fallback to mediatek,mtk-jpgenc.
Changes compared with v3:
- The v4 is resending the cover-letter, because the v3 cover-letter was
not sent successfully.
Changes compared with v2:
- Dropped the dts patch (arm64: dts: mt8188: update JPEG encoder/decoder
compatible) as it belongs to a different tree/series.
- Patches 1/3 (dt-bindings: decoder):
- Changed the MT8189 compatible to be a standalone `const` instead of
an `enum`.
- Added an `allOf` block with conditional checks to enforce the single
clock ("jpgdec") requirement for MT8189, while preserving the
two-clock requirement for older SoCs.
- Updated commit message to reflect the schema structure changes and
hardware differences.
- Patches 2/3 (dt-bindings: encoder):
- Changed the MT8189 compatible to be a standalone `const` instead of
an `enum` inside the `items` list, as it does not fallback to
"mediatek,mtk-jpgenc" due to 34-bit IOVA requirements.
- Updated commit message to explain the standalone compatible design.
- Patches 3/3 (media: mediatek: jpeg):
- Refined commit message for better clarity regarding 34-bit IOVA and
single clock configuration.
Changes compared with v1:
- Patches 1/4:
- Updating commit message
- Patches 2/4, 3/4:
- Updating commit message
- Adjusted property descriptions acorrding to hardware requirements
- Improved formatting for better readability and consistency
- Patches 4/4:
- Updating commit message
Jianhua Lin (3):
dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible
string
dt-bindings: media: mediatek-jpeg-encoder: add MT8189 compatible
string
media: mediatek: jpeg: add compatible for MT8189 SoC
.../bindings/media/mediatek-jpeg-decoder.yaml | 44 +++++++++++++++----
.../bindings/media/mediatek-jpeg-encoder.yaml | 30 ++++++++++---
.../platform/mediatek/jpeg/mtk_jpeg_core.c | 44 +++++++++++++++++++
3 files changed, 104 insertions(+), 14 deletions(-)
--
2.45.2
^ permalink raw reply
* [PATCH v8 3/3] media: mediatek: jpeg: add compatible for MT8189 SoC
From: Jianhua Lin @ 2026-05-19 2:17 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
In-Reply-To: <20260519021726.19137-1-jianhua.lin@mediatek.com>
Compared to the previous generation ICs, the MT8189 uses a 34-bit IOVA
address space (16GB) and requires a single clock configuration.
Therefore, add new compatible strings ("mediatek,mt8189-jpgenc" and
"mediatek,mt8189-jpgdec") along with their specific driver data to
support the JPEG encoder and decoder of the MT8189 SoC.
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../platform/mediatek/jpeg/mtk_jpeg_core.c | 44 +++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index d147ec483081..14f2991a4053 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1868,6 +1868,10 @@ static struct clk_bulk_data mt8173_jpeg_dec_clocks[] = {
{ .id = "jpgdec" },
};
+static struct clk_bulk_data mtk_jpeg_dec_clocks[] = {
+ { .id = "jpgdec" },
+};
+
static const struct mtk_jpeg_variant mt8173_jpeg_drvdata = {
.clks = mt8173_jpeg_dec_clocks,
.num_clks = ARRAY_SIZE(mt8173_jpeg_dec_clocks),
@@ -1899,6 +1903,38 @@ static const struct mtk_jpeg_variant mtk_jpeg_drvdata = {
.multi_core = false,
};
+static const struct mtk_jpeg_variant mtk8189_jpegenc_drvdata = {
+ .clks = mtk_jpeg_clocks,
+ .num_clks = ARRAY_SIZE(mtk_jpeg_clocks),
+ .formats = mtk_jpeg_enc_formats,
+ .num_formats = MTK_JPEG_ENC_NUM_FORMATS,
+ .qops = &mtk_jpeg_enc_qops,
+ .irq_handler = mtk_jpeg_enc_irq,
+ .hw_reset = mtk_jpeg_enc_reset,
+ .m2m_ops = &mtk_jpeg_enc_m2m_ops,
+ .dev_name = "mtk-jpeg-enc",
+ .ioctl_ops = &mtk_jpeg_enc_ioctl_ops,
+ .out_q_default_fourcc = V4L2_PIX_FMT_YUYV,
+ .cap_q_default_fourcc = V4L2_PIX_FMT_JPEG,
+ .support_34bit = true,
+};
+
+static const struct mtk_jpeg_variant mtk8189_jpegdec_drvdata = {
+ .clks = mtk_jpeg_dec_clocks,
+ .num_clks = ARRAY_SIZE(mtk_jpeg_dec_clocks),
+ .formats = mtk_jpeg_dec_formats,
+ .num_formats = MTK_JPEG_DEC_NUM_FORMATS,
+ .qops = &mtk_jpeg_dec_qops,
+ .irq_handler = mtk_jpeg_dec_irq,
+ .hw_reset = mtk_jpeg_dec_reset,
+ .m2m_ops = &mtk_jpeg_dec_m2m_ops,
+ .dev_name = "mtk-jpeg-dec",
+ .ioctl_ops = &mtk_jpeg_dec_ioctl_ops,
+ .out_q_default_fourcc = V4L2_PIX_FMT_JPEG,
+ .cap_q_default_fourcc = V4L2_PIX_FMT_YUV420M,
+ .support_34bit = true,
+};
+
static struct mtk_jpeg_variant mtk8195_jpegenc_drvdata = {
.formats = mtk_jpeg_enc_formats,
.num_formats = MTK_JPEG_ENC_NUM_FORMATS,
@@ -1938,6 +1974,14 @@ static const struct of_device_id mtk_jpeg_match[] = {
.compatible = "mediatek,mtk-jpgenc",
.data = &mtk_jpeg_drvdata,
},
+ {
+ .compatible = "mediatek,mt8189-jpgenc",
+ .data = &mtk8189_jpegenc_drvdata,
+ },
+ {
+ .compatible = "mediatek,mt8189-jpgdec",
+ .data = &mtk8189_jpegdec_drvdata,
+ },
{
.compatible = "mediatek,mt8195-jpgenc",
.data = &mtk8195_jpegenc_drvdata,
--
2.45.2
^ permalink raw reply related
* Re: [PATCH] media: mediatek: mdp: avoid double free on video register failure
From: kernel test robot @ 2026-05-19 0:21 UTC (permalink / raw)
To: Guangshuo Li, Minghsiu Tsai, Houlong Wei, Andrew-CT Chen,
Mauro Carvalho Chehab, Matthias Brugger,
AngeloGioacchino Del Regno, Hans Verkuil, linux-kernel,
linux-arm-kernel, linux-mediatek
Cc: llvm, oe-kbuild-all, linux-media, Guangshuo Li
In-Reply-To: <20260518125500.1000083-1-lgs201920130244@gmail.com>
Hi Guangshuo,
kernel test robot noticed the following build errors:
[auto build test ERROR on linuxtv-media-pending/master]
[also build test ERROR on media-tree/master linus/master v7.1-rc4 next-20260518]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Guangshuo-Li/media-mediatek-mdp-avoid-double-free-on-video-register-failure/20260518-211648
base: https://git.linuxtv.org/media-ci/media-pending.git master
patch link: https://lore.kernel.org/r/20260518125500.1000083-1-lgs201920130244%40gmail.com
patch subject: [PATCH] media: mediatek: mdp: avoid double free on video register failure
config: hexagon-allmodconfig (https://download.01.org/0day-ci/archive/20260519/202605190845.KlMSPp80-lkp@intel.com/config)
compiler: clang version 17.0.6 (https://github.com/llvm/llvm-project 6009708b4367171ccdbf4b5905cb6a803753fe18)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260519/202605190845.KlMSPp80-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605190845.KlMSPp80-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/media/platform/mediatek/mdp/mtk_mdp_m2m.c:1217:33: error: expected ';' after expression
1217 | video_device_release(mdp->vdev)
| ^
| ;
1 error generated.
vim +1217 drivers/media/platform/mediatek/mdp/mtk_mdp_m2m.c
1172
1173 int mtk_mdp_register_m2m_device(struct mtk_mdp_dev *mdp)
1174 {
1175 struct device *dev = &mdp->pdev->dev;
1176 int ret;
1177
1178 mdp->variant = &mtk_mdp_default_variant;
1179 mdp->vdev = video_device_alloc();
1180 if (!mdp->vdev) {
1181 dev_err(dev, "failed to allocate video device\n");
1182 ret = -ENOMEM;
1183 goto err_video_alloc;
1184 }
1185 mdp->vdev->device_caps = V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING;
1186 mdp->vdev->fops = &mtk_mdp_m2m_fops;
1187 mdp->vdev->ioctl_ops = &mtk_mdp_m2m_ioctl_ops;
1188 mdp->vdev->release = video_device_release_empty;
1189 mdp->vdev->lock = &mdp->lock;
1190 mdp->vdev->vfl_dir = VFL_DIR_M2M;
1191 mdp->vdev->v4l2_dev = &mdp->v4l2_dev;
1192 snprintf(mdp->vdev->name, sizeof(mdp->vdev->name), "%s:m2m",
1193 MTK_MDP_MODULE_NAME);
1194 video_set_drvdata(mdp->vdev, mdp);
1195
1196 mdp->m2m_dev = v4l2_m2m_init(&mtk_mdp_m2m_ops);
1197 if (IS_ERR(mdp->m2m_dev)) {
1198 dev_err(dev, "failed to initialize v4l2-m2m device\n");
1199 ret = PTR_ERR(mdp->m2m_dev);
1200 goto err_m2m_init;
1201 }
1202
1203 ret = video_register_device(mdp->vdev, VFL_TYPE_VIDEO, 2);
1204 if (ret) {
1205 dev_err(dev, "failed to register video device\n");
1206 goto err_vdev_register;
1207 }
1208 mdp->vdev->release = video_device_release;
1209
1210 v4l2_info(&mdp->v4l2_dev, "driver registered as /dev/video%d",
1211 mdp->vdev->num);
1212 return 0;
1213
1214 err_vdev_register:
1215 v4l2_m2m_release(mdp->m2m_dev);
1216 err_m2m_init:
> 1217 video_device_release(mdp->vdev)
1218 mdp->vdev = NULL;
1219 err_video_alloc:
1220
1221 return ret;
1222 }
1223
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH] ASoC: mediatek: mt2701: fix snprintf bounds
From: Rosen Penev @ 2026-05-19 1:04 UTC (permalink / raw)
To: linux-sound
Cc: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Matthias Brugger, AngeloGioacchino Del Regno,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
For whatever reason, GCC is unable to figure out that i2s_num is a
single digit number, with MT2701_BASE_CLK_NUM being the maximum value it
represents. Add a min() call to help it out and fix W=1 errors regarding
snprintf bounds.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c b/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
index 5a2bcf027b4f..43157f218409 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
@@ -25,6 +25,7 @@ static const char *const base_clks[] = {
int mt2701_init_clock(struct mtk_base_afe *afe)
{
struct mt2701_afe_private *afe_priv = afe->platform_priv;
+ int i2s_num;
int i;
for (i = 0; i < MT2701_BASE_CLK_NUM; i++) {
@@ -35,8 +36,9 @@ int mt2701_init_clock(struct mtk_base_afe *afe)
}
}
+ i2s_num = min(MT2701_BASE_CLK_NUM, afe_priv->soc->i2s_num);
/* Get I2S related clocks */
- for (i = 0; i < afe_priv->soc->i2s_num; i++) {
+ for (i = 0; i < i2s_num; i++) {
struct mt2701_i2s_path *i2s_path = &afe_priv->i2s_path[i];
struct clk *i2s_ck;
char name[13];
--
2.54.0
^ permalink raw reply related
* [PATCH] ASoC: mediatek: mt2701: allocate i2s_path with priv
From: Rosen Penev @ 2026-05-19 1:04 UTC (permalink / raw)
To: linux-sound
Cc: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Matthias Brugger, AngeloGioacchino Del Regno,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
Use a flexible array member to combine allocations.
Clean up surrounding code and allocate based on afe_priv and not
platform_priv which is a void pointer. struct_size needs a properly
typed pointer to work.
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
sound/soc/mediatek/mt2701/mt2701-afe-common.h | 2 +-
sound/soc/mediatek/mt2701/mt2701-afe-pcm.c | 21 ++++++++-----------
2 files changed, 10 insertions(+), 13 deletions(-)
diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-common.h b/sound/soc/mediatek/mt2701/mt2701-afe-common.h
index 8b6f3a200048..c9477bc24ee9 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-common.h
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-common.h
@@ -89,7 +89,6 @@ struct mt2701_soc_variants {
};
struct mt2701_afe_private {
- struct mt2701_i2s_path *i2s_path;
struct clk *base_ck[MT2701_BASE_CLK_NUM];
struct clk *mrgif_ck;
struct clk *hadds2pll_ck;
@@ -99,6 +98,7 @@ struct mt2701_afe_private {
bool mrg_enable[MTK_STREAM_NUM];
const struct mt2701_soc_variants *soc;
+ struct mt2701_i2s_path i2s_path[];
};
#endif
diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
index bb459faa6e05..d56b498e8c0c 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-pcm.c
@@ -1593,6 +1593,7 @@ static int mt2701_afe_runtime_resume(struct device *dev)
static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
{
+ const struct mt2701_soc_variants *soc;
struct mtk_base_afe *afe;
struct mt2701_afe_private *afe_priv;
struct device *dev;
@@ -1602,23 +1603,19 @@ static int mt2701_afe_pcm_dev_probe(struct platform_device *pdev)
if (!afe)
return -ENOMEM;
- afe->platform_priv = devm_kzalloc(&pdev->dev, sizeof(*afe_priv),
- GFP_KERNEL);
- if (!afe->platform_priv)
+ soc = of_device_get_match_data(&pdev->dev);
+ afe_priv = devm_kzalloc(&pdev->dev,
+ struct_size(afe_priv, i2s_path, soc->i2s_num),
+ GFP_KERNEL);
+ if (!afe_priv)
return -ENOMEM;
- afe_priv = afe->platform_priv;
- afe_priv->soc = of_device_get_match_data(&pdev->dev);
+ afe_priv->soc = soc;
+
+ afe->platform_priv = afe_priv;
afe->dev = &pdev->dev;
dev = afe->dev;
- afe_priv->i2s_path = devm_kcalloc(dev,
- afe_priv->soc->i2s_num,
- sizeof(struct mt2701_i2s_path),
- GFP_KERNEL);
- if (!afe_priv->i2s_path)
- return -ENOMEM;
-
irq_id = platform_get_irq_byname(pdev, "asys");
if (irq_id < 0)
return irq_id;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 4/8] drm/panthor: Add support for protected memory allocation in panthor
From: Chia-I Wu @ 2026-05-19 0:36 UTC (permalink / raw)
To: Boris Brezillon
Cc: Liviu Dudau, Marcin Ślusarz, Ketil Johnsen, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Jonathan Corbet, Shuah Khan, Sumit Semwal,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian König, Steven Price, Daniel Almeida, Alice Ryhl,
Matthias Brugger, AngeloGioacchino Del Regno, dri-devel,
linux-doc, linux-kernel, linux-media, linaro-mm-sig,
linux-arm-kernel, linux-mediatek, Florent Tomasin, nd
In-Reply-To: <20260518091650.5a7a4f4a@fedora>
On Mon, May 18, 2026 at 12:16 AM Boris Brezillon
<boris.brezillon@collabora.com> wrote:
>
> On Wed, 13 May 2026 12:31:32 -0700
> Chia-I Wu <olvaffe@gmail.com> wrote:
>
> > On Tue, May 12, 2026 at 8:39 AM Liviu Dudau <liviu.dudau@arm.com> wrote:
> > >
> > > On Tue, May 12, 2026 at 04:11:11PM +0200, Boris Brezillon wrote:
> > > > On Tue, 12 May 2026 14:47:27 +0100
> > > > Liviu Dudau <liviu.dudau@arm.com> wrote:
> > > >
> > > > > On Thu, May 07, 2026 at 01:53:56PM +0200, Boris Brezillon wrote:
> > > > > > On Thu, 7 May 2026 11:02:26 +0200
> > > > > > Marcin Ślusarz <marcin.slusarz@arm.com> wrote:
> > > > > >
> > > > > > > On Tue, May 05, 2026 at 06:15:23PM +0200, Boris Brezillon wrote:
> > > > > > > > > @@ -277,9 +286,21 @@ int panthor_device_init(struct panthor_device *ptdev)
> > > > > > > > > return ret;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > + /* If a protected heap name is specified but not found, defer the probe until created */
> > > > > > > > > + if (protected_heap_name && strlen(protected_heap_name)) {
> > > > > > > >
> > > > > > > > Do we really need this strlen() > 0? Won't dma_heap_find() fail is the
> > > > > > > > name is "" already?
> > > > > > >
> > > > > > > If dma_heap_find() will fail, then the whole probe with fail too.
> > > > > > > This check prevents that.
> > > > > >
> > > > > > Yeah, that's also a questionable design choice. I mean, we can
> > > > > > currently probe and boot the FW even though we never setup the
> > > > > > protected FW sections, so why should we defer the probe here? Can't we
> > > > > > just retry the next time a group with the protected bit is created and
> > > > > > fail if we can find a protected heap?
> > > > >
> > > > > The problem we have with the current firmware is that it does a number of setup steps at "boot"
> > > > > time only. One of the steps is preparing its internal structures for when it enters protected
> > > > > mode and it stores them in the buffer passed in at firmware loading. We cannot later run the
> > > > > process when we have a group with protected mode set.
> > > >
> > > > No, but we can force a full/slow reset and have that thing
> > > > re-initialized, can't we? I mean, that's basically what we do when a
> > > > fast reset fails: we re-initialize all the sections and reset again, at
> > > > which point the FW should start from a fresh state, and be able to
> > > > properly initialize the protected-related stuff if protected sections
> > > > are populated. Am I missing something?
> > >
> > > Right, we can do that. For some reason I keep associating the reset with the
> > > error handling and not with "normal" operations.
> > I kind of hope we end up with either
> >
> > - panthor knows the exact heap to use and fails with EPROBE_DEFER if
> > the heap is missing, or
> > - panthor gets a dma-buf from userspace and does the full reset
> > - userspace also needs to provide a dma-buf for each protected
> > group for the suspend buffer
> >
> > than something in-between. The latter is more ad-hoc and basically
> > kicks the issue to the userspace.
>
> Indeed, the second option is more ad-hoc, but when you think about it,
> userspace has to have this knowledge, because it needs to know the
> dma-heap to use for buffer allocation that cross a device boundary
> anyway. Think about frames produced by a video decoder, and composited
> by the GPU into a protected scanout buffer that's passed to the KMS
> device. Why would the GPU driver be source of truth when it comes to
> choosing the heap to use to allocate protected buffers for the video
> decoder or those used for the display?
I don't think the GPU driver is ever the source of truth. If the
system integrator wants to specify the source of truth (SoT) from
kernel space, they should use the device tree (or module params /
config options). If they want to specify the SoT in userspace, then we
don't really care how it is done other than providing an ioctl.
Panthor is always on the receiving end.
If we don't want to delay this functionality, but it takes time to
converge on SoT, maybe a solution that is not a long-term promise can
work? Of the options on the table (dt, module params, kconfig options,
ioctls), a kconfig option, potentially marked as experimental, seems
like a good candidate.
>
> >
> > For the former, expressing the relation in DT seems to be the best,
> > but only if possible :-). Otherwise, a kconfig option (instead of
> > module param) should be easier to work with.
> >
> > Looking at the userspace implementation, can we also have an panthor
> > ioctl to return the heap to userspace?
>
> Yes, it's something we can add, but again, I'm questioning the
> usefulness of this: how can we ensure the heap used by panthor to
> allocate its protected FW buffers is suitable for scanout buffers
> (buffers that can be used by display drivers). There needs to be a glue
> leaving in usersland and taking the decision, and I'm not too sure
> trusting any of the component in the chain (vdec, gpu, display) is the
> right thing to do.
The heap returned by panthor is only for panfrost/panvk. It says
nothing about compatibility with other components on the system.
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmtk: fix urb->setup_packet leak in error paths
From: patchwork-bot+bluetooth @ 2026-05-18 21:50 UTC (permalink / raw)
To: Jiajia Liu
Cc: marcel, luiz.dentz, matthias.bgg, angelogioacchino.delregno,
sean.wang, linux-bluetooth, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260518022402.20398-1-liujiajia@kylinos.cn>
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:
On Mon, 18 May 2026 10:24:02 +0800 you wrote:
> The setup_packet of control urb is not freed if usb_submit_urb fails or
> the submitted urb is killed. Add free in these two paths.
>
> Fixes: a1c49c434e150 ("Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices")
> Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
> ---
> drivers/bluetooth/btmtk.c | 2 ++
> 1 file changed, 2 insertions(+)
Here is the summary with links:
- Bluetooth: btmtk: fix urb->setup_packet leak in error paths
https://git.kernel.org/bluetooth/bluetooth-next/c/5daf96ab8398
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] media: mediatek: mdp: avoid double free on video register failure
From: kernel test robot @ 2026-05-18 20:30 UTC (permalink / raw)
To: Guangshuo Li, Minghsiu Tsai, Houlong Wei, Andrew-CT Chen,
Mauro Carvalho Chehab, Matthias Brugger,
AngeloGioacchino Del Regno, Hans Verkuil, linux-kernel,
linux-arm-kernel, linux-mediatek
Cc: oe-kbuild-all, linux-media, Guangshuo Li
In-Reply-To: <20260518125500.1000083-1-lgs201920130244@gmail.com>
Hi Guangshuo,
kernel test robot noticed the following build errors:
[auto build test ERROR on linuxtv-media-pending/master]
[also build test ERROR on media-tree/master linus/master v7.1-rc4 next-20260518]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Guangshuo-Li/media-mediatek-mdp-avoid-double-free-on-video-register-failure/20260518-211648
base: https://git.linuxtv.org/media-ci/media-pending.git master
patch link: https://lore.kernel.org/r/20260518125500.1000083-1-lgs201920130244%40gmail.com
patch subject: [PATCH] media: mediatek: mdp: avoid double free on video register failure
config: m68k-allmodconfig (https://download.01.org/0day-ci/archive/20260519/202605190406.bMshG7YY-lkp@intel.com/config)
compiler: m68k-linux-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260519/202605190406.bMshG7YY-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605190406.bMshG7YY-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/media/platform/mediatek/mdp/mtk_mdp_m2m.c: In function 'mtk_mdp_register_m2m_device':
>> drivers/media/platform/mediatek/mdp/mtk_mdp_m2m.c:1217:40: error: expected ';' before 'mdp'
1217 | video_device_release(mdp->vdev)
| ^
| ;
1218 | mdp->vdev = NULL;
| ~~~
vim +1217 drivers/media/platform/mediatek/mdp/mtk_mdp_m2m.c
1172
1173 int mtk_mdp_register_m2m_device(struct mtk_mdp_dev *mdp)
1174 {
1175 struct device *dev = &mdp->pdev->dev;
1176 int ret;
1177
1178 mdp->variant = &mtk_mdp_default_variant;
1179 mdp->vdev = video_device_alloc();
1180 if (!mdp->vdev) {
1181 dev_err(dev, "failed to allocate video device\n");
1182 ret = -ENOMEM;
1183 goto err_video_alloc;
1184 }
1185 mdp->vdev->device_caps = V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING;
1186 mdp->vdev->fops = &mtk_mdp_m2m_fops;
1187 mdp->vdev->ioctl_ops = &mtk_mdp_m2m_ioctl_ops;
1188 mdp->vdev->release = video_device_release_empty;
1189 mdp->vdev->lock = &mdp->lock;
1190 mdp->vdev->vfl_dir = VFL_DIR_M2M;
1191 mdp->vdev->v4l2_dev = &mdp->v4l2_dev;
1192 snprintf(mdp->vdev->name, sizeof(mdp->vdev->name), "%s:m2m",
1193 MTK_MDP_MODULE_NAME);
1194 video_set_drvdata(mdp->vdev, mdp);
1195
1196 mdp->m2m_dev = v4l2_m2m_init(&mtk_mdp_m2m_ops);
1197 if (IS_ERR(mdp->m2m_dev)) {
1198 dev_err(dev, "failed to initialize v4l2-m2m device\n");
1199 ret = PTR_ERR(mdp->m2m_dev);
1200 goto err_m2m_init;
1201 }
1202
1203 ret = video_register_device(mdp->vdev, VFL_TYPE_VIDEO, 2);
1204 if (ret) {
1205 dev_err(dev, "failed to register video device\n");
1206 goto err_vdev_register;
1207 }
1208 mdp->vdev->release = video_device_release;
1209
1210 v4l2_info(&mdp->v4l2_dev, "driver registered as /dev/video%d",
1211 mdp->vdev->num);
1212 return 0;
1213
1214 err_vdev_register:
1215 v4l2_m2m_release(mdp->m2m_dev);
1216 err_m2m_init:
> 1217 video_device_release(mdp->vdev)
1218 mdp->vdev = NULL;
1219 err_video_alloc:
1220
1221 return ret;
1222 }
1223
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH] mailbox: mtk-adsp: fix UAF during device teardown
From: Jassi Brar @ 2026-05-18 19:04 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Allen-KH Cheng,
YC Hung, Tzung-Bi Shih, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260428025614.1094085-1-senozhatsky@chromium.org>
On Mon, Apr 27, 2026 at 9:56 PM Sergey Senozhatsky
<senozhatsky@chromium.org> wrote:
>
> When the SOF audio driver fails to initialize (e.g. firmware boot
> timeout), its devres unwind frees the snd_sof_dev object that the
> mailbox client (mtk-adsp-ipc) reaches via chan->cl->rx_callback.
> The mtk-adsp-mailbox shutdown clears the mailbox command registers
> but leaves the IRQ line unmasked, so a late interrupt can still
> queue a threaded handler after mbox_free_channel() had cleared
> chan->cl, and mbox_chan_received_data() would then trigger UAF:
>
> BUG: KASAN: slab-use-after-free in sof_ipc3_validate_fw_version
> sof_ipc3_validate_fw_version
> sof_ipc3_do_rx_work
> sof_ipc3_rx_msg
> mt8196_dsp_handle_request
> mtk_adsp_ipc_recv
> mbox_chan_received_data
> mtk_adsp_mbox_isr
> irq_thread_fn
> Freed by task ...:
> kfree
> devres_release_all
> really_probe
> ... (sof-audio-of-mt8196 probe failure)
>
> The crash was observed roughly three seconds after the failed probe.
>
> disable_irq() in shutdown and enable_irq() in startup. disable_irq()
> also waits for any in-flight interrupts, so by the time
> mbox_free_channel() proceeds to clear chan->cl no rx_callback can run.
>
> In addition, request the IRQ with IRQF_NO_AUTOEN so it stays masked
> between probe and the first client bind — otherwise an early interrupt
> can crash on chan->cl == NULL in mbox_chan_received_data().
>
> Fixes: af2dfa96c52d ("mailbox: mediatek: add support for adsp mailbox controller")
> Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
> ---
> drivers/mailbox/mtk-adsp-mailbox.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mailbox/mtk-adsp-mailbox.c b/drivers/mailbox/mtk-adsp-mailbox.c
> index 91487aa4d7da..8bcecddee0eb 100644
> --- a/drivers/mailbox/mtk-adsp-mailbox.c
> +++ b/drivers/mailbox/mtk-adsp-mailbox.c
> @@ -19,6 +19,7 @@ struct mtk_adsp_mbox_priv {
> struct mbox_controller mbox;
> void __iomem *va_mboxreg;
> const struct mtk_adsp_mbox_cfg *cfg;
> + int irq;
> };
>
> struct mtk_adsp_mbox_cfg {
> @@ -67,6 +68,8 @@ static int mtk_adsp_mbox_startup(struct mbox_chan *chan)
> writel(0xFFFFFFFF, priv->va_mboxreg + priv->cfg->clr_in);
> writel(0xFFFFFFFF, priv->va_mboxreg + priv->cfg->clr_out);
>
> + enable_irq(priv->irq);
> +
> return 0;
> }
>
> @@ -74,6 +77,8 @@ static void mtk_adsp_mbox_shutdown(struct mbox_chan *chan)
> {
> struct mtk_adsp_mbox_priv *priv = get_mtk_adsp_mbox_priv(chan->mbox);
>
> + disable_irq(priv->irq);
> +
> /* Clear ADSP mbox command */
> writel(0xFFFFFFFF, priv->va_mboxreg + priv->cfg->clr_in);
> writel(0xFFFFFFFF, priv->va_mboxreg + priv->cfg->clr_out);
> @@ -139,8 +144,10 @@ static int mtk_adsp_mbox_probe(struct platform_device *pdev)
> if (irq < 0)
> return irq;
>
> + priv->irq = irq;
> ret = devm_request_threaded_irq(dev, irq, mtk_adsp_mbox_irq,
> - mtk_adsp_mbox_isr, IRQF_TRIGGER_NONE,
> + mtk_adsp_mbox_isr,
> + IRQF_TRIGGER_NONE | IRQF_NO_AUTOEN,
> dev_name(dev), mbox->chans);
> if (ret < 0)
> return ret;
> --
> 2.54.0.545.g6539524ca2-goog
>
Applied to mailbox/for-next
Thanks
Jassi
^ permalink raw reply
* Re: [PATCH] wifi: mt76: mt7996: avoid memset overwriting tx_info->control.flags
From: Roy Luo @ 2026-05-18 18:23 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Ryder Lee, Felix Fietkau, linux-mediatek, linux-wireless,
Shayne Chen, Roy Luo
In-Reply-To: <agsGiHKH6ly1afaf@lore-desk>
On Mon, May 18, 2026 at 5:31 AM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
>
> On May 15, Cheng Hao Luo wrote:
> > > struct ieee80211_tx_info {
> > > u32 flags; /* 0 4 */
> > > u32 band:3; /* 4: 0 4 */
> > > u32 status_data_idr:1; /* 4: 3 4 */
> > > u32 status_data:13; /* 4: 4 4 */
> > > u32 hw_queue:4; /* 4:17 4 */
> > > u32 tx_time_est:10; /* 4:21 4 */
> > >
> > > /* XXX 1 bit hole, try to pack */
> > >
> > > union {
> > > struct {
> > > union {
> > > struct {
> > > struct ieee80211_tx_rate rates[4]; /* 8 12 */
> > > s8 rts_cts_rate_idx; /* 20 1 */
> > > u8 use_rts:1; /* 21: 0 1 */
> > > u8 use_cts_prot:1; /* 21: 1 1 */
> > > u8 short_preamble:1; /* 21: 2 1 */
> > > u8 skip_table:1; /* 21: 3 1 */
> > > u8 antennas:2; /* 21: 4 1 */
> > > }; /* 8 14 */
> > > long unsigned int jiffies; /* 8 8 */
> > > }; /* 8 16 */
> > > struct ieee80211_vif * vif; /* 24 8 */
> > > struct ieee80211_key_conf * hw_key; /* 32 8 */
> > > u32 flags; /* 40 4 */
> > > codel_time_t enqueue_time; /* 44 4 */
> > > } control; /* 8 40 */
> > > struct {
> > > u64 cookie; /* 8 8 */
> > > } ack; /* 8 8 */
> > > struct {
> > > struct ieee80211_tx_rate rates[4]; /* 8 12 */
> > > s32 ack_signal; /* 20 4 */
> > > u8 ampdu_ack_len; /* 24 1 */
> > > u8 ampdu_len; /* 25 1 */
> > > u8 antenna; /* 26 1 */
> > > u8 pad; /* 27 1 */
> > > u16 tx_time; /* 28 2 */
> > > u8 flags; /* 30 1 */
> > > u8 pad2; /* 31 1 */
> > > void * status_driver_data[2]; /* 32 16 */
> > > } status; /* 8 40 */
> > > struct {
> > > struct ieee80211_tx_rate driver_rates[4]; /* 8 12 */
> > > u8 pad[4]; /* 20 4 */
> > > void * rate_driver_data[3]; /* 24 24 */
> > > }; /* 8 40 */
> > > void * driver_data[5]; /* 8 40 */
> > > }; /* 8 40 */
> > >
> > > /* size: 48, cachelines: 1, members: 7 */
> > > /* sum members: 44 */
> > > /* sum bitfield members: 31 bits, bit holes: 1, sum bit holes: 1 bits */
> > > /* last cacheline: 48 bytes */
> > > };
> > >
> > > According to pahole, the size of the control inner union is actually 16 bytes
> > > since the compiler adds 2 bytes of padding. Since mt76_tx_status_skb_add()
> > > meset to 0 just mt76_tx_cb size (that is 16 bytes) I can't see how
> > > control.flags is overwritten. Am I missing something?
> > >
> > > struct mt76_tx_cb {
> > > long unsigned int jiffies; /* 0 8 */
> > > u16 wcid; /* 8 2 */
> > > u8 pktid; /* 10 1 */
> > > u8 flags; /* 11 1 */
> > >
> > > /* size: 16, cachelines: 1, members: 4 */
> > > /* padding: 4 */
> > > /* last cacheline: 16 bytes */
> > > };
> >
> > Hi Lorenzo,
> >
> > The mt76_tx_cb is placed at status.status_driver_data (offset 32).
> > It overlaps with hw_key, flags and enqueue_time in the control union.
> >
> > static inline struct mt76_tx_cb *mt76_tx_skb_cb(struct sk_buff *skb)
> > {
> > BUILD_BUG_ON(sizeof(struct mt76_tx_cb) >
> > sizeof(IEEE80211_SKB_CB(skb)->status.status_driver_data));
> > return ((void *)IEEE80211_SKB_CB(skb)->status.status_driver_data);
> > }
>
> Hi Roy,
>
> I still do not understand since mt76_tx_status_skb_add() sets to 0 just sizeof
> of mt76_tx_cb, that according to pahole is 16 bytes, so it can't overwrite
> hw_key pointer (whose offset respect to the beginning of the control struct is
> 24, 32 - 8).
>
> Regards,
> Lorenzo
>
> >
> > Regards,
> > Roy Luo
Hi Lorenzo,
The mt76_tx_status_skb_add() memset zero the 16 bytes starting from
status.status_driver_data (please see the above inline function shared
in my last response) whose offset with respect to the beginning of
the control/status union is exactly 24 (32 - 8) instead of 0.
Regards,
Roy Luo
^ permalink raw reply
* Re: [PATCH v1] regulator: Use named initializers for arrays of i2c_device_data
From: Mark Brown @ 2026-05-18 17:13 UTC (permalink / raw)
To: Woody Douglass
Cc: Laurent Pinchart, Uwe Kleine-König (The Capable Hub),
Liam Girdwood, Markus Schneider-Pargmann, Michael Hennerich,
Support Opensource, Ivaylo Ivanov, Claudiu Beznea, Andrei Simion,
Saravanan Sekar, Matthias Brugger, AngeloGioacchino Del Regno,
Jagan Teki, Icenowy Zheng, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
In-Reply-To: <54168033-c968-4565-afe8-2f1f8547ddf0@carnegierobotics.com>
[-- Attachment #1: Type: text/plain, Size: 469 bytes --]
On Mon, May 18, 2026 at 05:07:46PM +0000, Woody Douglass wrote:
> On 5/15/26 08:28, Laurent Pinchart wrote:
> > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.
Please delete unneeded context from mails when replying. Doing this
makes it much easier to find your reply in the message, helping ensure
it won't be missed by people scrolling through the irrelevant quoted
material.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v1] regulator: Use named initializers for arrays of i2c_device_data
From: Woody Douglass @ 2026-05-18 17:07 UTC (permalink / raw)
To: Laurent Pinchart, Uwe Kleine-König (The Capable Hub)
Cc: Liam Girdwood, Mark Brown, Markus Schneider-Pargmann,
Michael Hennerich, Support Opensource, Ivaylo Ivanov,
Claudiu Beznea, Andrei Simion, Saravanan Sekar, Matthias Brugger,
AngeloGioacchino Del Regno, Jagan Teki, Icenowy Zheng,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
In-Reply-To: <20260515122816.GB52035@killaraus.ideasonboard.com>
On 5/15/26 08:28, Laurent Pinchart wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.
>
>
> Hi Uwe,
>
> Thank you for the patch.
>
> On Fri, May 15, 2026 at 12:31:50PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
>> While being less compact, using named initializers allows to more easily
>> see which members of the structs are assigned which value without having
>> to lookup the declaration of the struct. And it's also more robust
>> against changes to the struct definition.
>>
>> The mentioned robustness is relevant for a planned change to struct
>> i2c_device_id that replaces .driver_data by an anonymous union.
>>
>> While touching all these arrays, unify usage of whitespace and commas.
>>
>> This patch doesn't modify the compiled arrays, only their representation
>> in source form benefits. The former was confirmed with x86 and arm64
>> builds.
>>
>> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
>> ---
>> Hello,
>>
>> the mentioned change to i2c_device_id is the following:
>>
>> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
>> index 23ff24080dfd..aebd3a5e90af 100644
>> --- a/include/linux/mod_devicetable.h
>> +++ b/include/linux/mod_devicetable.h
>> @@ -477,7 +477,11 @@ struct rpmsg_device_id {
>>
>> struct i2c_device_id {
>> char name[I2C_NAME_SIZE];
>> - kernel_ulong_t driver_data; /* Data private to the driver */
>> + union {
>> + /* Data private to the driver */
>> + kernel_ulong_t driver_data;
>> + const void *driver_data_ptr;
>> + };
>> };
>>
>> /* pci_epf */
>>
>> and this requires that .driver_data is assigned via a named initializer
>> for static data. This requirement isn't a bad one because named
>> initializers are also much better readable than list initializers.
>>
>> The union added to struct i2c_device_id enables further cleanups like:
>>
>> diff --git a/drivers/regulator/ad5398.c b/drivers/regulator/ad5398.c
>> index 0123ca8157a8..dfb0b07500a7 100644
>> --- a/drivers/regulator/ad5398.c
>> +++ b/drivers/regulator/ad5398.c
>> @@ -207,8 +207,8 @@ struct ad5398_current_data_format {
>> static const struct ad5398_current_data_format df_10_4_120 = {10, 4, 0, 120000};
>>
>> static const struct i2c_device_id ad5398_id[] = {
>> - { .name = "ad5398", .driver_data = (kernel_ulong_t)&df_10_4_120 },
>> - { .name = "ad5821", .driver_data = (kernel_ulong_t)&df_10_4_120 },
>> + { .name = "ad5398", .driver_data_ptr = &df_10_4_120 },
>> + { .name = "ad5821", .driver_data_ptr = &df_10_4_120 },
>> { }
>> };
>> MODULE_DEVICE_TABLE(i2c, ad5398_id);
>> @@ -219,8 +219,7 @@ static int ad5398_probe(struct i2c_client *client)
>> struct regulator_init_data *init_data = dev_get_platdata(&client->dev);
>> struct regulator_config config = { };
>> struct ad5398_chip_info *chip;
>> - const struct ad5398_current_data_format *df =
>> - (struct ad5398_current_data_format *)id->driver_data;
>> + const struct ad5398_current_data_format *df = id->driver_data;
>>
>> chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
>> if (!chip)
>>
>> that are an improvement for readability (again!) and it keeps some
>> properties of the pointers (here: being const) without having to pay
>> attention for that.
>>
>> My additional motivation for this effort is CHERI[1]. This is a hardware
>> extension that uses 128 bit pointers but unsigned long is still 64 bit.
>> So with CHERI you cannot store pointers in unsigned long variables.
>>
>> Best regards
>> Uwe
>>
>> [1] https://cheri-alliance.org/discover-cheri/
>> https://lwn.net/Articles/1037974/
>>
>> drivers/regulator/88pg86x.c | 4 +--
>> drivers/regulator/ad5398.c | 4 +--
>> drivers/regulator/da9121-regulator.c | 20 +++++++--------
>> drivers/regulator/da9210-regulator.c | 4 +--
>> drivers/regulator/da9211-regulator.c | 18 +++++++-------
>> drivers/regulator/fan53880.c | 4 +--
>> drivers/regulator/isl9305.c | 4 +--
>> drivers/regulator/lp3971.c | 2 +-
>> drivers/regulator/lp3972.c | 2 +-
>> drivers/regulator/lp872x.c | 34 +++++++++++++-------------
>> drivers/regulator/lp8755.c | 4 +--
>> drivers/regulator/ltc3589.c | 6 ++---
>> drivers/regulator/ltc3676.c | 2 +-
>> drivers/regulator/max1586.c | 2 +-
>> drivers/regulator/max20086-regulator.c | 8 +++---
>> drivers/regulator/max20411-regulator.c | 2 +-
>> drivers/regulator/max77503-regulator.c | 2 +-
>> drivers/regulator/max77675-regulator.c | 2 +-
>> drivers/regulator/max77826-regulator.c | 2 +-
>> drivers/regulator/max77838-regulator.c | 2 +-
>> drivers/regulator/max77857-regulator.c | 8 +++---
>> drivers/regulator/max8649.c | 2 +-
>> drivers/regulator/max8893.c | 2 +-
>> drivers/regulator/max8952.c | 2 +-
>> drivers/regulator/mcp16502.c | 2 +-
>> drivers/regulator/mp5416.c | 6 ++---
>> drivers/regulator/mp8859.c | 4 +--
>> drivers/regulator/mp886x.c | 6 ++---
>> drivers/regulator/mpq7920.c | 4 +--
>> drivers/regulator/mt6311-regulator.c | 4 +--
>> drivers/regulator/pf530x-regulator.c | 8 +++---
>> drivers/regulator/pf8x00-regulator.c | 8 +++---
>> drivers/regulator/pv88060-regulator.c | 4 +--
>> drivers/regulator/pv88080-regulator.c | 8 +++---
>> drivers/regulator/pv88090-regulator.c | 4 +--
>> drivers/regulator/slg51000-regulator.c | 4 +--
>> drivers/regulator/sy8106a-regulator.c | 2 +-
>> drivers/regulator/sy8824x.c | 8 +++---
>> drivers/regulator/sy8827n.c | 4 +--
>> drivers/regulator/tps6286x-regulator.c | 10 ++++----
>> drivers/regulator/tps6287x-regulator.c | 10 ++++----
>> 41 files changed, 119 insertions(+), 119 deletions(-)
> [snip]
>
>> diff --git a/drivers/regulator/pf530x-regulator.c b/drivers/regulator/pf530x-regulator.c
>> index f789c4b6a499..e7b13d60106b 100644
>> --- a/drivers/regulator/pf530x-regulator.c
>> +++ b/drivers/regulator/pf530x-regulator.c
>> @@ -353,10 +353,10 @@ static const struct of_device_id pf530x_dt_ids[] = {
>> MODULE_DEVICE_TABLE(of, pf530x_dt_ids);
>>
>> static const struct i2c_device_id pf530x_i2c_id[] = {
>> - { "pf5300", 0 },
>> - { "pf5301", 0 },
>> - { "pf5302", 0 },
>> - {},
>> + { .name = "pf5300", .driver_data = 0 },
>> + { .name = "pf5301", .driver_data = 0 },
>> + { .name = "pf5302", .driver_data = 0 },
> I think you can drop driver_data here. It doesn't appear to be used by
> the driver.
I can confirm this, the pf530x driver does not use the driver_data
member. This is an improvement, thank you!
Reviewed-by: Woodrow Douglass <wdouglass@carnegierobotics.com>
> I like the result overall. With this small issue addressed,
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>
>> + { }
>> };
>> MODULE_DEVICE_TABLE(i2c, pf530x_i2c_id);
>>
> [snip]
>
> --
> Regards,
>
> Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmtk: accept too short WMT FUNC_CTRL events
From: Luiz Augusto von Dentz @ 2026-05-18 16:39 UTC (permalink / raw)
To: Artem S. Tashkinov; +Cc: pav, linux-bluetooth, linux-mediatek, mark-yw.chen
In-Reply-To: <79571779-316d-4d7b-bbca-554328ec7dd6@gmx.com>
Hi Artem,
On Mon, May 18, 2026 at 12:33 PM Artem S. Tashkinov <aros@gmx.com> wrote:
>
> Hello,
>
> The kernel bug tracker already has half a dozen bug reports in regard to
> this regression, yet almost a week later I still don't see the fix
> pushed to stable.
>
> Please do.
No offense, but I recommend checking the list before generating this
kind of response:
https://patchwork.kernel.org/project/bluetooth/patch/20260514172340.1515042-1-luiz.dentz@gmail.com/
PR is in progress and will be merged in the next RC.
> Regards,
> Artem
>
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmtk: accept too short WMT FUNC_CTRL events
From: Artem S. Tashkinov @ 2026-05-18 16:33 UTC (permalink / raw)
To: pav; +Cc: linux-bluetooth, linux-mediatek, mark-yw.chen
In-Reply-To: <770d36b07311bf88210c187923f243fb9f126f04.1777058551.git.pav@iki.fi>
Hello,
The kernel bug tracker already has half a dozen bug reports in regard to
this regression, yet almost a week later I still don't see the fix
pushed to stable.
Please do.
Regards,
Artem
^ permalink raw reply
* Re: [PATCH 0/4] drm/mediatek: fix sparse warnings
From: Chun-Kuang Hu @ 2026-05-18 14:26 UTC (permalink / raw)
To: Louis-Alexis Eyraud
Cc: Chun-Kuang Hu, Philipp Zabel, David Airlie, Simona Vetter,
Matthias Brugger, AngeloGioacchino Del Regno, CK Hu,
Alexandre Mergnat, kernel, dri-devel, linux-mediatek,
linux-kernel, linux-arm-kernel, kernel test robot
In-Reply-To: <20260429-mediatek-drm-fix-sparse-warnings-v1-0-d95c4d118b83@collabora.com>
Hi, Louis:
Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> 於 2026年4月29日週三 上午9:59寫道：
>
> This series fixes in the mediatek-drm driver the sparse warnings
> reported by [1] and two others introduced during v6.16 development
> cycle.
>
> The series has compile-tested and is based on linux-next (tag:
> next-2040428).
>
> [1]: https://lore.kernel.org/all/202604132044.fcYjEcU8-lkp@intel.com/
For this series, applied to mediatek-drm-fixes [1], thanks.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-fixes
Regards,
Chun-Kuang.
>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
> ---
> Louis-Alexis Eyraud (4):
> drm/mediatek: mtk_hdmi_ddc_v2: Fix non-static global variable
> drm/mediatek: mtk_hdmi_v2: Fix non-static global variable
> drm/mediatek: mtk_cec: Fix non-static global variable
> drm/mediatek: mtk_hdmi_ddc: Fix non-static global variable
>
> drivers/gpu/drm/mediatek/mtk_cec.c | 2 +-
> drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c | 2 +-
> drivers/gpu/drm/mediatek/mtk_hdmi_ddc_v2.c | 2 +-
> drivers/gpu/drm/mediatek/mtk_hdmi_v2.c | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
> ---
> base-commit: 0f3ef35b0747832b58b97171bad99011d084c6b1
> change-id: 20260424-mediatek-drm-fix-sparse-warnings-7404de18204c
>
> Best regards,
> --
> Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
>
^ permalink raw reply
* Re: [PATCH v4 2/2] drm/mediatek: dsi: Add compatible for mt8167-dsi
From: Chun-Kuang Hu @ 2026-05-18 14:11 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Chun-Kuang Hu,
Philipp Zabel, David Airlie, Simona Vetter, devicetree,
linux-kernel, linux-arm-kernel, dri-devel
In-Reply-To: <20260505214541.333657-3-l.scorcia@gmail.com>
Hi, Luca:
Luca Leonardo Scorcia <l.scorcia@gmail.com> 於 2026年5月5日週二 下午9:46寫道：
>
> The mt8167 DSI controller is fully compatible with the one found in
> mt2701. Unfortunately the device tree has a dedicated compatible for
> mt8167 since 2022 and it cannot be changed with a fallback nor removed at
> this point. The only way to get the device to work is to add the
> compatible to the driver.
Applied to mediatek-drm-next [1], thanks.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 5aa71fcdcfab..167e33fef025 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -1305,6 +1305,7 @@ static const struct mtk_dsi_driver_data mt8188_dsi_driver_data = {
>
> static const struct of_device_id mtk_dsi_of_match[] = {
> { .compatible = "mediatek,mt2701-dsi", .data = &mt2701_dsi_driver_data },
> + { .compatible = "mediatek,mt8167-dsi", .data = &mt2701_dsi_driver_data },
> { .compatible = "mediatek,mt8173-dsi", .data = &mt8173_dsi_driver_data },
> { .compatible = "mediatek,mt8183-dsi", .data = &mt8183_dsi_driver_data },
> { .compatible = "mediatek,mt8186-dsi", .data = &mt8186_dsi_driver_data },
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH] drm/mediatek: Convert legacy DRM logging to drm_* helpers in mtk_dsi.c
From: Chun-Kuang Hu @ 2026-05-18 13:39 UTC (permalink / raw)
To: Abhishek Rajput
Cc: chunkuang.hu, p.zabel, airlied, simona, matthias.bgg,
angelogioacchino.delregno, dri-devel, linux-mediatek,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260420052008.5417-1-abhiraj21put@gmail.com>
Hi, Abhishek:
Abhishek Rajput <abhiraj21put@gmail.com> 於 2026年4月20日週一 上午5:20寫道：
>
> Replace DRM_INFO(), DRM_WARN() and DRM_ERROR() calls in
> drivers/gpu/drm/mediatek/mtk_dsi.c with the corresponding
> drm_info(), drm_warn() and drm_err() helpers.
>
> The drm_*() logging helpers take a struct drm_device * argument,
> allowing the DRM core to prefix log messages with the correct device
> name and instance. This is required to correctly distinguish log
> messages on systems with multiple GPUs.
>
> This change aligns the radeon driver with the DRM TODO item:
> "Convert logging to drm_* functions with drm_device parameter".
Applied to mediatek-drm-next [1], thanks.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux.git/log/?h=mediatek-drm-next
Regards,
Chun-Kuang.
>
> Signed-off-by: Abhishek Rajput <abhiraj21put@gmail.com>
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 0e2bcd5f67b7..a67ad575f5f0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -510,6 +510,7 @@ static void mtk_dsi_config_vdo_timing_per_line_lp(struct mtk_dsi *dsi)
> u32 delta;
> struct mtk_phy_timing *timing = &dsi->phy_timing;
> struct videomode *vm = &dsi->vm;
> + struct drm_device *drm = dsi->bridge.dev;
>
> if (dsi->format == MIPI_DSI_FMT_RGB565)
> dsi_tmp_buf_bpp = 2;
> @@ -543,7 +544,7 @@ static void mtk_dsi_config_vdo_timing_per_line_lp(struct mtk_dsi *dsi)
> horizontal_backporch_byte /
> horizontal_front_back_byte;
> } else {
> - DRM_WARN("HFP + HBP less than d-phy, FPS will under 60Hz\n");
> + drm_warn(drm, "HFP + HBP less than d-phy, FPS will under 60Hz\n");
> }
>
> if ((dsi->mode_flags & MIPI_DSI_HS_PKT_END_ALIGNED) &&
> @@ -623,12 +624,13 @@ static s32 mtk_dsi_wait_for_irq_done(struct mtk_dsi *dsi, u32 irq_flag,
> {
> s32 ret = 0;
> unsigned long jiffies = msecs_to_jiffies(timeout);
> + struct drm_device *drm = dsi->bridge.dev;
>
> ret = wait_event_interruptible_timeout(dsi->irq_wait_queue,
> dsi->irq_data & irq_flag,
> jiffies);
> if (ret == 0) {
> - DRM_WARN("Wait DSI IRQ(0x%08x) Timeout\n", irq_flag);
> + drm_warn(drm, "Wait DSI IRQ(0x%08x) Timeout\n", irq_flag);
>
> mtk_dsi_enable(dsi);
> mtk_dsi_reset_engine(dsi);
> @@ -663,9 +665,10 @@ static s32 mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi, u8 irq_flag, u32 t)
> {
> mtk_dsi_irq_data_clear(dsi, irq_flag);
> mtk_dsi_set_cmd_mode(dsi);
> + struct drm_device *drm = dsi->bridge.dev;
>
> if (!mtk_dsi_wait_for_irq_done(dsi, irq_flag, t)) {
> - DRM_ERROR("failed to switch cmd mode\n");
> + drm_err(drm, "failed to switch cmd mode\n");
> return -ETIME;
> } else {
> return 0;
> @@ -849,11 +852,12 @@ static void mtk_dsi_bridge_atomic_pre_enable(struct drm_bridge *bridge,
> struct drm_atomic_state *state)
> {
> struct mtk_dsi *dsi = bridge_to_dsi(bridge);
> + struct drm_device *drm = bridge->dev;
> int ret;
>
> ret = mtk_dsi_poweron(dsi);
> if (ret < 0)
> - DRM_ERROR("failed to power on dsi\n");
> + drm_err(drm, "failed to power on dsi\n");
> }
>
> static void mtk_dsi_bridge_atomic_post_disable(struct drm_bridge *bridge,
> @@ -916,7 +920,7 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
> ret = drm_simple_encoder_init(drm, &dsi->encoder,
> DRM_MODE_ENCODER_DSI);
> if (ret) {
> - DRM_ERROR("Failed to encoder init to drm\n");
> + drm_err(drm, "Failed to encoder init to drm\n");
> return ret;
> }
>
> @@ -932,7 +936,7 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi)
>
> dsi->connector = drm_bridge_connector_init(drm, &dsi->encoder);
> if (IS_ERR(dsi->connector)) {
> - DRM_ERROR("Unable to create bridge connector\n");
> + drm_err(drm, "Unable to create bridge connector\n");
> ret = PTR_ERR(dsi->connector);
> goto err_cleanup_encoder;
> }
> @@ -985,6 +989,7 @@ static int mtk_dsi_host_attach(struct mipi_dsi_host *host,
> {
> struct mtk_dsi *dsi = host_to_dsi(host);
> struct device *dev = host->dev;
> + struct drm_device *drm = dsi->bridge.dev;
> int ret;
>
> dsi->lanes = device->lanes;
> @@ -1012,7 +1017,7 @@ static int mtk_dsi_host_attach(struct mipi_dsi_host *host,
>
> ret = component_add(host->dev, &mtk_dsi_component_ops);
> if (ret) {
> - DRM_ERROR("failed to add dsi_host component: %d\n", ret);
> + drm_err(drm, "failed to add dsi_host component: %d\n", ret);
> drm_bridge_remove(&dsi->bridge);
> return ret;
> }
> @@ -1034,11 +1039,12 @@ static void mtk_dsi_wait_for_idle(struct mtk_dsi *dsi)
> {
> int ret;
> u32 val;
> + struct drm_device *drm = dsi->bridge.dev;
>
> ret = readl_poll_timeout(dsi->regs + DSI_INTSTA, val, !(val & DSI_BUSY),
> 4, 2000000);
> if (ret) {
> - DRM_WARN("polling dsi wait not busy timeout!\n");
> + drm_warn(drm, "polling dsi wait not busy timeout!\n");
>
> mtk_dsi_enable(dsi);
> mtk_dsi_reset_engine(dsi);
> @@ -1123,6 +1129,7 @@ static ssize_t mtk_dsi_host_transfer(struct mipi_dsi_host *host,
> const struct mipi_dsi_msg *msg)
> {
> struct mtk_dsi *dsi = host_to_dsi(host);
> + struct drm_device *drm = dsi->bridge.dev;
> ssize_t recv_cnt;
> u8 read_data[16];
> void *src_addr;
> @@ -1153,7 +1160,7 @@ static ssize_t mtk_dsi_host_transfer(struct mipi_dsi_host *host,
> }
>
> if (!msg->rx_buf) {
> - DRM_ERROR("dsi receive buffer size may be NULL\n");
> + drm_err(drm, "dsi receive buffer size may be NULL\n");
> ret = -EINVAL;
> goto restore_dsi_mode;
> }
> @@ -1177,7 +1184,7 @@ static ssize_t mtk_dsi_host_transfer(struct mipi_dsi_host *host,
> if (recv_cnt)
> memcpy(msg->rx_buf, src_addr, recv_cnt);
>
> - DRM_INFO("dsi get %zd byte data from the panel address(0x%x)\n",
> + drm_info(drm, "dsi get %zd byte data from the panel address(0x%x)\n",
> recv_cnt, *((u8 *)(msg->tx_buf)));
>
> restore_dsi_mode:
> --
> 2.43.0
>
^ permalink raw reply
* [PATCH] media: mediatek: mdp: avoid double free on video register failure
From: Guangshuo Li @ 2026-05-18 12:55 UTC (permalink / raw)
To: Minghsiu Tsai, Houlong Wei, Andrew-CT Chen, Mauro Carvalho Chehab,
Matthias Brugger, AngeloGioacchino Del Regno, Hans Verkuil,
linux-media, linux-kernel, linux-arm-kernel, linux-mediatek
Cc: Guangshuo Li
mtk_mdp_register_m2m_device() allocates a video_device with
video_device_alloc() and releases it from the err_m2m_init error path if
video_register_device() fails.
This can double free the video_device when __video_register_device()
reaches device_register() and that call fails:
video_register_device()
-> __video_register_device()
-> device_register() fails
-> put_device(&vdev->dev)
-> v4l2_device_release()
-> vdev->release(vdev)
-> video_device_release(vdev)
mtk_mdp_register_m2m_device()
-> err_m2m_init
-> video_device_release(mdp->vdev)
Use video_device_release_empty() while registering the device so that
registration failure paths do not free mdp->vdev through vdev->release().
mtk_mdp_register_m2m_device() then releases mdp->vdev exactly once from
err_m2m_init. Restore video_device_release() after successful registration
so the registered device keeps its normal lifetime handling.
Clear mdp->vdev after releasing it on failure to avoid leaving a stale
pointer behind.
This issue was found by a static analysis tool I am developing.
Fixes: 7febb418a32a ("[media] mtk-mdp: allocate video_device dynamically")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/media/platform/mediatek/mdp/mtk_mdp_m2m.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/mediatek/mdp/mtk_mdp_m2m.c b/drivers/media/platform/mediatek/mdp/mtk_mdp_m2m.c
index d2813890cceb..5cc80a542eda 100644
--- a/drivers/media/platform/mediatek/mdp/mtk_mdp_m2m.c
+++ b/drivers/media/platform/mediatek/mdp/mtk_mdp_m2m.c
@@ -1185,7 +1185,7 @@ int mtk_mdp_register_m2m_device(struct mtk_mdp_dev *mdp)
mdp->vdev->device_caps = V4L2_CAP_VIDEO_M2M_MPLANE | V4L2_CAP_STREAMING;
mdp->vdev->fops = &mtk_mdp_m2m_fops;
mdp->vdev->ioctl_ops = &mtk_mdp_m2m_ioctl_ops;
- mdp->vdev->release = video_device_release;
+ mdp->vdev->release = video_device_release_empty;
mdp->vdev->lock = &mdp->lock;
mdp->vdev->vfl_dir = VFL_DIR_M2M;
mdp->vdev->v4l2_dev = &mdp->v4l2_dev;
@@ -1205,6 +1205,7 @@ int mtk_mdp_register_m2m_device(struct mtk_mdp_dev *mdp)
dev_err(dev, "failed to register video device\n");
goto err_vdev_register;
}
+ mdp->vdev->release = video_device_release;
v4l2_info(&mdp->v4l2_dev, "driver registered as /dev/video%d",
mdp->vdev->num);
@@ -1213,7 +1214,8 @@ int mtk_mdp_register_m2m_device(struct mtk_mdp_dev *mdp)
err_vdev_register:
v4l2_m2m_release(mdp->m2m_dev);
err_m2m_init:
- video_device_release(mdp->vdev);
+ video_device_release(mdp->vdev)
+ mdp->vdev = NULL;
err_video_alloc:
return ret;
--
2.43.0
^ permalink raw reply related
* [PATCH] media: mediatek: jpeg: avoid double free on video register failure
From: Guangshuo Li @ 2026-05-18 12:51 UTC (permalink / raw)
To: Bin Liu, Mauro Carvalho Chehab, Matthias Brugger,
AngeloGioacchino Del Regno, Tomasz Figa, Hans Verkuil, Xia Jiang,
linux-media, linux-kernel, linux-arm-kernel, linux-mediatek
Cc: Guangshuo Li
mtk_jpeg_probe() allocates a video_device with video_device_alloc() and
releases it from the err_vfd_jpeg_register error path if
video_register_device() fails.
This can double free the video_device when __video_register_device()
reaches device_register() and that call fails:
video_register_device()
-> __video_register_device()
-> device_register() fails
-> put_device(&vdev->dev)
-> v4l2_device_release()
-> vdev->release(vdev)
-> video_device_release(vdev)
mtk_jpeg_probe()
-> err_vfd_jpeg_register
-> video_device_release(jpeg->vdev)
Use video_device_release_empty() while registering the device so that
registration failure paths do not free jpeg->vdev through vdev->release().
mtk_jpeg_probe() then releases jpeg->vdev exactly once from
err_vfd_jpeg_register. Restore video_device_release() after successful
registration so the registered device keeps its normal lifetime handling.
This issue was found by a static analysis tool I am developing.
Fixes: 2ac8015f156b ("media: platform: Rename existing functions/defines/variables")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index c01124a349f6..9888ac8dd6e4 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1362,7 +1362,7 @@ static int mtk_jpeg_probe(struct platform_device *pdev)
jpeg->vdev->fops = &mtk_jpeg_fops;
jpeg->vdev->ioctl_ops = jpeg->variant->ioctl_ops;
jpeg->vdev->minor = -1;
- jpeg->vdev->release = video_device_release;
+ jpeg->vdev->release = video_device_release_empty;
jpeg->vdev->lock = &jpeg->lock;
jpeg->vdev->v4l2_dev = &jpeg->v4l2_dev;
jpeg->vdev->vfl_dir = VFL_DIR_M2M;
@@ -1374,6 +1374,7 @@ static int mtk_jpeg_probe(struct platform_device *pdev)
v4l2_err(&jpeg->v4l2_dev, "Failed to register video device\n");
goto err_vfd_jpeg_register;
}
+ jpeg->vdev->release = video_device_release;
video_set_drvdata(jpeg->vdev, jpeg);
v4l2_info(&jpeg->v4l2_dev,
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] wifi: mt76: mt7996: avoid memset overwriting tx_info->control.flags
From: Lorenzo Bianconi @ 2026-05-18 12:31 UTC (permalink / raw)
To: Cheng Hao Luo
Cc: Ryder Lee, Felix Fietkau, linux-mediatek, linux-wireless,
Shayne Chen, Roy Luo
In-Reply-To: <CAHoxojJX2BRRTLMuM_QcJqMMmshxS4EAwrB1VjU3rsZ+0k2PAg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5379 bytes --]
On May 15, Cheng Hao Luo wrote:
> > struct ieee80211_tx_info {
> > u32 flags; /* 0 4 */
> > u32 band:3; /* 4: 0 4 */
> > u32 status_data_idr:1; /* 4: 3 4 */
> > u32 status_data:13; /* 4: 4 4 */
> > u32 hw_queue:4; /* 4:17 4 */
> > u32 tx_time_est:10; /* 4:21 4 */
> >
> > /* XXX 1 bit hole, try to pack */
> >
> > union {
> > struct {
> > union {
> > struct {
> > struct ieee80211_tx_rate rates[4]; /* 8 12 */
> > s8 rts_cts_rate_idx; /* 20 1 */
> > u8 use_rts:1; /* 21: 0 1 */
> > u8 use_cts_prot:1; /* 21: 1 1 */
> > u8 short_preamble:1; /* 21: 2 1 */
> > u8 skip_table:1; /* 21: 3 1 */
> > u8 antennas:2; /* 21: 4 1 */
> > }; /* 8 14 */
> > long unsigned int jiffies; /* 8 8 */
> > }; /* 8 16 */
> > struct ieee80211_vif * vif; /* 24 8 */
> > struct ieee80211_key_conf * hw_key; /* 32 8 */
> > u32 flags; /* 40 4 */
> > codel_time_t enqueue_time; /* 44 4 */
> > } control; /* 8 40 */
> > struct {
> > u64 cookie; /* 8 8 */
> > } ack; /* 8 8 */
> > struct {
> > struct ieee80211_tx_rate rates[4]; /* 8 12 */
> > s32 ack_signal; /* 20 4 */
> > u8 ampdu_ack_len; /* 24 1 */
> > u8 ampdu_len; /* 25 1 */
> > u8 antenna; /* 26 1 */
> > u8 pad; /* 27 1 */
> > u16 tx_time; /* 28 2 */
> > u8 flags; /* 30 1 */
> > u8 pad2; /* 31 1 */
> > void * status_driver_data[2]; /* 32 16 */
> > } status; /* 8 40 */
> > struct {
> > struct ieee80211_tx_rate driver_rates[4]; /* 8 12 */
> > u8 pad[4]; /* 20 4 */
> > void * rate_driver_data[3]; /* 24 24 */
> > }; /* 8 40 */
> > void * driver_data[5]; /* 8 40 */
> > }; /* 8 40 */
> >
> > /* size: 48, cachelines: 1, members: 7 */
> > /* sum members: 44 */
> > /* sum bitfield members: 31 bits, bit holes: 1, sum bit holes: 1 bits */
> > /* last cacheline: 48 bytes */
> > };
> >
> > According to pahole, the size of the control inner union is actually 16 bytes
> > since the compiler adds 2 bytes of padding. Since mt76_tx_status_skb_add()
> > meset to 0 just mt76_tx_cb size (that is 16 bytes) I can't see how
> > control.flags is overwritten. Am I missing something?
> >
> > struct mt76_tx_cb {
> > long unsigned int jiffies; /* 0 8 */
> > u16 wcid; /* 8 2 */
> > u8 pktid; /* 10 1 */
> > u8 flags; /* 11 1 */
> >
> > /* size: 16, cachelines: 1, members: 4 */
> > /* padding: 4 */
> > /* last cacheline: 16 bytes */
> > };
>
> Hi Lorenzo,
>
> The mt76_tx_cb is placed at status.status_driver_data (offset 32).
> It overlaps with hw_key, flags and enqueue_time in the control union.
>
> static inline struct mt76_tx_cb *mt76_tx_skb_cb(struct sk_buff *skb)
> {
> BUILD_BUG_ON(sizeof(struct mt76_tx_cb) >
> sizeof(IEEE80211_SKB_CB(skb)->status.status_driver_data));
> return ((void *)IEEE80211_SKB_CB(skb)->status.status_driver_data);
> }
Hi Roy,
I still do not understand since mt76_tx_status_skb_add() sets to 0 just sizeof
of mt76_tx_cb, that according to pahole is 16 bytes, so it can't overwrite
hw_key pointer (whose offset respect to the beginning of the control struct is
24, 32 - 8).
Regards,
Lorenzo
>
> Regards,
> Roy Luo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] memory: mtk-smi: Add a flag skip_rpm
From: AngeloGioacchino Del Regno @ 2026-05-18 10:02 UTC (permalink / raw)
To: Xueqi Zhang (张雪琦), robh@kernel.org,
matthias.bgg@gmail.com, Yong Wu (吴勇),
krzk@kernel.org, conor+dt@kernel.org
Cc: Wendy-ST Lin (林詩庭),
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
Project_Global_Chrome_Upstream_Group, devicetree@vger.kernel.org
In-Reply-To: <198865fb3184926d0b1b4e4855b5f863ad0d6a20.camel@mediatek.com>
On 5/18/26 09:16, Xueqi Zhang (张雪琦) wrote:
> Hi Angelo,
>
> First of all, please accept my apologies for the delayed response. I
> have been deeply occupied with MT8196 Aluminium pKVM SMMU and SMI
> related tasks recently.
>
> Regarding your question, my previous description in the patch was not
> accurate enough and may have caused some confusion. In fact, not
> all SMI commons have their backup/restore handled by the RTFF
> hardware. The SMI commons are distributed across various subsystems
> (e.g., mminfra, venc, display, cam, etc.). Currently, only the SMI
> common under the mminfra subsystem is backed up and restored by
> the RTFF hardware.
>
> Therefore, I believe adding a specific 'skip_rpm' flag is more
> appropriate here. If we were to differentiate this based on a new
> MTK_SMI_GEN3 type, it would imply that all SMI common modules of
> that generation would skip the RPM operations, which is not the
> intended behavior.
>
> To make this clearer, I plan to update the commit message in the
> next version as follows:
>
> Subject: memory: mtk-smi: Add skip_rpm flag for certain MT8196 SMI
> commons
memory: mtk-smi: Allow no clocks for RTFF managed SMI commons
>
> Body:
> On MT8196, certain SMI commons are backed up and restored by the RTFF
> hardware rather than by software.
>
> For these specific SMI commons, software-controlled register backup
> and restore in the runtime callback is no longer necessary. Therefore,
> introduce a 'skip_rpm' flag to bypass these redundant RPMoperations
> for these SMI commons.
>
> What do you think about this approach?
>
That would be kind-of ok, but keep in mind: pm_runtime doesn't only manage clocks.
I think that the best option here would be to allow having no clocks instead,
and to still call pm_runtime_{en,dis}able() - as that would get a bit more
future-proof, should any other (newer, older, etc) SoC need to declare any power
domain but still no clocks.
So at this point, I think that just doing something like:
if (common->plat->has_gals) {
if (common->plat->rtff_managed) <--- not "skip_rpm"
clk_required = 0;
else if (common->plat->type == MTK_SMI_GEN2)
clk_required = MTK_SMI_COM_GALS_REQ_CLK_NR;
else if (common->plat->type == MTK_SMI_GEN2_SUB_COMM)
clk_required = MTK_SMI_SUB_COM_GALS_REQ_CLK_NR;
}
should be sufficient (and/or check zero required clocks in smi_dts_clk_init).
Cheers,
Angelo
> Thanks,
> Xueqi
>
> On Thu, 2025-03-20 at 13:11 +0100, AngeloGioacchino Del Regno wrote:
>> External email : Please do not click links or open attachments until
>> you have verified the sender or the content.
>>
>>
>> Il 20/03/25 08:36, Xueqi Zhang ha scritto:
>>> MT8196 SMI commons is backed up/restored by RTFF HW.
>>> It doesn't need SW control the register backup/store
>>> in the runtime callback.Therefore, add a flag skip_rpm
>>> to help skip RPM operations for SMI commons.
>>>
>>> Signed-off-by: Xueqi Zhang <xueqi.zhang@mediatek.com>
>>
>> So the MT8196 SMI common doesn't require any clocks?
>>
>> That's fine for me, but this looks bloody similar to MT6989's SMI
>> common, which
>> is SMI GEN3 and not GEN2....
>>
>> ....so, are you sure that you need a `skip_rpm` flag and not new
>> MTK_SMI_GEN3 and
>> MTK_SMI_GEN3_SUB_COMM types? :-)
>>
>> Regards,
>> Angelo
>>
>>> ---
>>> drivers/memory/mtk-smi.c | 11 ++++++++---
>>> 1 file changed, 8 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
>>> index a8f5467d6b31..b9affa3c3185 100644
>>> --- a/drivers/memory/mtk-smi.c
>>> +++ b/drivers/memory/mtk-smi.c
>>> @@ -123,6 +123,7 @@ static const char * const mtk_smi_common_clks[]
>>> = {"apb", "smi", "gals0", "gals1
>>> struct mtk_smi_common_plat {
>>> enum mtk_smi_type type;
>>> bool has_gals;
>>> + bool skip_rpm;
>>> u32 bus_sel; /* Balance some larbs to
>>> enter mmu0 or mmu1 */
>>>
>>> const struct mtk_smi_reg_pair *init;
>>> @@ -547,6 +548,9 @@ static int mtk_smi_dts_clk_init(struct device
>>> *dev, struct mtk_smi *smi,
>>> {
>>> int i, ret;
>>>
>>> + if (smi->plat->skip_rpm)
>>> + return 0;
>>> +
>>> for (i = 0; i < clk_nr_required; i++)
>>> smi->clks[i].id = clks[i];
>>> ret = devm_clk_bulk_get(dev, clk_nr_required, smi->clks);
>>> @@ -783,7 +787,7 @@ static int mtk_smi_common_probe(struct
>>> platform_device *pdev)
>>> common->dev = dev;
>>> common->plat = of_device_get_match_data(dev);
>>>
>>> - if (common->plat->has_gals) {
>>> + if (!common->plat->skip_rpm && common->plat->has_gals) {
>>> if (common->plat->type == MTK_SMI_GEN2)
>>> clk_required = MTK_SMI_COM_GALS_REQ_CLK_NR;
>>> else if (common->plat->type == MTK_SMI_GEN2_SUB_COMM)
>>> @@ -814,13 +818,14 @@ static int mtk_smi_common_probe(struct
>>> platform_device *pdev)
>>> }
>>>
>>> /* link its smi-common if this is smi-sub-common */
>>> - if (common->plat->type == MTK_SMI_GEN2_SUB_COMM) {
>>> + if (common->plat->type == MTK_SMI_GEN2_SUB_COMM && !common-
>>>> plat->skip_rpm) {
>>> ret = mtk_smi_device_link_common(dev, &common-
>>>> smi_common_dev);
>>> if (ret < 0)
>>> return ret;
>>> }
>>>
>>> - pm_runtime_enable(dev);
>>> + if (!common->plat->skip_rpm)
>>> + pm_runtime_enable(dev);
>>> platform_set_drvdata(pdev, common);
>>> return 0;
>>> }
>>
>>
^ permalink raw reply
* Re: [PATCH 0/4] arm64: dts: mediatek: random Chromebook cleanups
From: AngeloGioacchino Del Regno @ 2026-05-18 9:40 UTC (permalink / raw)
To: Matthias Brugger, Chen-Yu Tsai
Cc: linux-mediatek, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260514101254.2749300-1-wenst@chromium.org>
On Thu, 14 May 2026 18:12:48 +0800, Chen-Yu Tsai wrote:
> Here are some random DT cleanups that are not directly related to other
> topics I'm working on, but came up when checking for warnings.
>
> The regulator related changes overlap with my other "Regulator cleanup
> for Chromebooks" series [1].
>
> Please have a look.
>
> [...]
Applied to v7.1-next/dts64, thanks!
[1/4] arm64: dts: mediatek: mt8192-asurada: Fix SPI-NOR flash compatible
commit: 95937cbb6d51e0c6f8ac937bd043fb3b442391ec
[2/4] arm64: dts: mediatek: mt8192-asurada: Add (BT|WIFI)_KILL_1V8_L GPIO line names
commit: c42235145c52955ab20fcb648bb8c7818f58282b
[3/4] arm64: dts: mediatek: mt8195-cherry: Fix names for EC controlled regulators
commit: 2066ac078402301d9aa50026dee017182d316eac
[4/4] arm64: dts: mediatek: mt8195-cherry: Sort top level nodes correctly
commit: 559b8b1524760ad8dc18d52c4415d40ee24d02fc
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH RFC 05/12] usb: hub: Power on connected M.2 E-key connectors
From: Chen-Yu Tsai @ 2026-05-18 9:13 UTC (permalink / raw)
To: Alan Stern
Cc: Bartosz Golaszewski, Greg Kroah-Hartman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, linux-pm, linux-usb, devicetree,
linux-mediatek, linux-arm-kernel, linux-kernel,
Manivannan Sadhasivam
In-Reply-To: <41260a6d-46fa-4a45-9906-e1bc5e5dd83a@rowland.harvard.edu>
On Fri, May 15, 2026 at 10:39 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Fri, May 15, 2026 at 05:01:41PM +0800, Chen-Yu Tsai wrote:
> > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> > index 90ea597d42ae..4165f71e212b 100644
> > --- a/drivers/usb/core/hub.c
> > +++ b/drivers/usb/core/hub.c
> > @@ -31,7 +31,9 @@
> > #include <linux/minmax.h>
> > #include <linux/mutex.h>
> > #include <linux/random.h>
> > +#include <linux/of_graph.h>
> > #include <linux/pm_qos.h>
> > +#include <linux/pwrseq/consumer.h>
> > #include <linux/kobject.h>
> >
> > #include <linux/bitfield.h>
> > @@ -888,13 +890,25 @@ int usb_hub_set_port_power(struct usb_device *hdev, struct usb_hub *hub,
> > {
> > int ret;
> >
> > + if (set)
> > + ret = pwrseq_power_on(hub->ports[port1 - 1]->pwrseq);
> > + else
> > + ret = pwrseq_power_off(hub->ports[port1 - 1]->pwrseq);
> > + if (ret)
> > + return ret;
> > +
> > if (set)
> > ret = set_port_feature(hdev, port1, USB_PORT_FEAT_POWER);
> > else
> > ret = usb_clear_port_feature(hdev, port1, USB_PORT_FEAT_POWER);
> >
> > - if (ret)
> > + if (ret) {
> > + if (set)
> > + pwrseq_power_off(hub->ports[port1 - 1]->pwrseq);
> > + else
> > + pwrseq_power_on(hub->ports[port1 - 1]->pwrseq);
> > return ret;
> > + }
> >
> > if (set)
> > set_bit(port1, hub->power_bits);
> > @@ -1867,6 +1881,7 @@ static int hub_probe(struct usb_interface *intf, const struct usb_device_id *id)
> > struct usb_host_interface *desc;
> > struct usb_device *hdev;
> > struct usb_hub *hub;
> > + int ret;
> >
> > desc = intf->cur_altsetting;
> > hdev = interface_to_usbdev(intf);
>
> This change is totally useless. Didn't you get a warning from the
> compiler when you built it?
Apologies. This should have been part of the previous patch.
> > diff --git a/drivers/usb/core/hub.h b/drivers/usb/core/hub.h
> > index 9ebc5ef54a32..6039e5f5dcd7 100644
> > --- a/drivers/usb/core/hub.h
> > +++ b/drivers/usb/core/hub.h
> > @@ -85,6 +85,7 @@ struct usb_hub {
> > * @port_owner: port's owner
> > * @peer: related usb2 and usb3 ports (share the same connector)
> > * @connector: USB Type-C connector
> > + * @pwrseq: power sequencing descriptor for the port
> > * @req: default pm qos request for hubs without port power control
> > * @connect_type: port's connect type
> > * @state: device state of the usb device attached to the port
> > @@ -104,6 +105,7 @@ struct usb_port {
> > struct usb_dev_state *port_owner;
> > struct usb_port *peer;
> > struct typec_connector *connector;
> > + struct pwrseq_desc *pwrseq;
> > struct dev_pm_qos_request *req;
> > enum usb_port_connect_type connect_type;
> > enum usb_device_state state;
>
> The fact that hub.h uses struct pwrseq_desc indicates that it ought to
> #include <linux/pwrseq/consumer.h>, instead of making the .c files do
> so themselves. Then you wouldn't have to add the #include lines to
> hub.c and port.c.
I couldn't tell if the existing pattern in this file was to include
the headers or not, as it's missing a whole bunch.
Regardless of whether this header file includes linux/pwrseq/consumer.h
or has a forward declaration or nothing, I think that if the .c files
use the API, then they should include the corresponding header file
directly.
> > diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
> > index b1364f0c384c..2d09037fee93 100644
> > --- a/drivers/usb/core/port.c
> > +++ b/drivers/usb/core/port.c
> > @@ -7,11 +7,14 @@
> > * Author: Lan Tianyu <tianyu.lan@intel.com>
> > */
> >
> > +#include <linux/cleanup.h>
>
> Why is this needed?
For the __free() in usb_hub_port_pwrseq_get() below:
struct device_node *np __free(device_node) = NULL;
Thanks
ChenYu
> > #include <linux/kstrtox.h>
> > #include <linux/slab.h>
> > #include <linux/string_choices.h>
> > #include <linux/sysfs.h>
> > +#include <linux/of_graph.h>
> > #include <linux/pm_qos.h>
> > +#include <linux/pwrseq/consumer.h>
> > #include <linux/component.h>
> > #include <linux/usb/of.h>
> >
>
> Alan Stern
^ 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