* Re: [PATCH] arm64: dts: imx{91,93}-phyboard-segin: Add peb-av-18 overlay
From: Florijan Plohl @ 2026-04-03 8:29 UTC (permalink / raw)
To: Frank Li
Cc: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, imx, linux-arm-kernel,
devicetree, linux-kernel, upstream
In-Reply-To: <ac50OHuEApM3tRHq@lizhi-Precision-Tower-5810>
Hello,
On 4/2/26 15:50, Frank Li wrote:
> On Thu, Apr 02, 2026 at 09:08:26AM +0200, Florijan Plohl wrote:
>> Add overlay for the PEB-AV-18 adapter on phyBOARD-Segin-i.MX91/93.
> what's means PEB-AV-18? Is it random board name?
The PEB-AV-18 is PHYTEC designation for Audio/Video adapter modules that can
be used to connect displays on their boards.
I will improve commit message to add more such information in v2.
>
>
>> The supported LCD is Powertip PH800480T032-ZHC19 panel (AC220).
>>
>> Signed-off-by: Florijan Plohl <florijan.plohl@norik.com>
>> ---
>> arch/arm64/boot/dts/freescale/Makefile | 4 +
>> .../imx91-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
>> .../imx93-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
> Any difference between 91 and 93, can use one overlay file?
>
> Frank
Can you suggest how to do so?
There are imx93-pinfunc.h and imx91-pinfunc.h which are not unified
between imx91 and imx93.
So we can only create common dtsi like so:
imx91-93-phyboard-segin-peb-av-18.dtsi
and still use separate dtsos:
imx91-phyboard-segin-peb-av-18.dtso
imx93-phyboard-segin-peb-av-18.dtso
Is that your idea?
BR,
Florijan Plohl
>> --
>> 2.43.0
>>
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: dsa: microchip: add KSZ low-loss cable errata properties
From: Fidelio LAWSON @ 2026-04-03 8:28 UTC (permalink / raw)
To: Andrew Lunn
Cc: Woojung Huh, UNGLinuxDriver, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Marek Vasut, Maxime Chevallier,
netdev, devicetree, linux-kernel, Fidelio Lawson
In-Reply-To: <521cf729-50d2-44c1-8c96-c1fba2127b9d@lunn.ch>
On 3/26/26 13:14, Andrew Lunn wrote:
> On Thu, Mar 26, 2026 at 10:10:21AM +0100, Fidelio Lawson wrote:
>> Microchip KSZ87xx switches are affected by the "Module 3: Equalizer fix
>> for short cables" erratum described in DS80000687C.
>> The embedded PHY receivers are tuned for long, high-loss cables,
>> which may cause signal distortion when operated with short or low-loss
>> cabling such as CAT5e or CAT6. In these cases,
>> the PHY may fail to establish a link due to internal over-amplification.
>>
>> Two workarounds are provided by Microchip, each configuring a different
>> indirect register value to adjust the PHY equalizer settings.
>>
>> This patch introduces two new device tree properties to enable and
>> select the appropriate workaround:
>>
>> - microchip,low-loss-errata-enable: boolean enabling the feature
>> - microchip,low-loss-errata: selects workaround 1 or 2 (default: 1)
>>
>> These properties allow board designers to opt into the errata fix
>> according to the targeted cable characteristics of their platform.
>
> Does the errata give any indication how the two different workarounds
> differ? How would a user decided which to use?
>
> I also question if this should be a DT property. The length of the
> cables is not a property of the board.
>
> A PHY tunable would better reflect the same board can be used with
> different cables, with different lengths/quality.
>
> Andrew
Hi Andrew,
Thanks for the review.
Regarding the difference between the two workarounds:
Microchip’s errata does provide some insight into how they behave and
when each should be used.
Workaround 1 modifies the PHY equalizer settings by adjusting an
indirect register (0x3c).
According to Microchip’s support article:
“The above register change makes the equalizer’s compensation range
wider, and therefore cables with various characteristics can be
tolerated. Adjust equalizer EQ training algorithm to cover a few type of
short cables issue. Also is appropriate for board‑to‑board connection
and port‑to‑port connection with the capacitor AC coupling mode.”
Microchip also explains that although the default value in register 0x3c
handles standard short Ethernet cables (CAT‑5/CAT‑5e), a more optimized
value (0x15) provides better tolerance for corner cases, especially very
short or board‑to‑board links:
“Based on tests, a more optimized equalizer adjustment value 0x15 is
better for all corner cases of the short cable and short distance
connection for port‑to‑port or board‑to‑board cases.”
So Workaround 1 primarily widens and optimizes the DSP equalizer EQ
compensation range, and is expected to solve most short/low‑loss cable
issues.
Workaround 2 is intended for the cases where Workaround 1 is not sufficient.
This one adjusts the receiver low‑pass filter bandwidth, effectively
reducing the high‑frequency component of the received signal:
“Based on the root cause above, adjust the receiver low pass filter to
reduce the high frequency component to keep the receive signal within a
reasonable range when using CAT‑5E and CAT‑6 cable.”
So Workaround 2 is a more aggressive filtering approach, applied only
when the EQ adjustment alone does not stabilize the link on CAT‑5e/CAT‑6
short cable scenarios.
Regarding the question of whether this should be exposed through a PHY
tunable:
I understand your concern. The erratum is indeed linked to cable
characteristics, not the board itself.
Since this patch modifies registers that belong to the DSA switch
itself, and not the PHY driver, I’m not entirely sure it would be
architecturally correct to expose these adjustments as PHY tunables. The
workarounds target internal receiver/equalizer settings inside the
KSZ87xx switch block, accessed via the switch’s indirect register
mechanism, not via a standard phy_device.
Given that, I’m unsure whether mapping these switch‑level registers into
the PHY tunables framework would be appropriate or even feasible.
What do you think?
Best regards,
Fidelio
^ permalink raw reply
* Re: [PATCH v4 net-next 5/5] net: pcs: pcs-mtk-lynxi: deprecate "mediatek,pnswap"
From: Frank Wunderlich @ 2026-04-03 8:23 UTC (permalink / raw)
To: Vladimir Oltean
Cc: netdev, devicetree, linux-kernel, linux-mediatek, Daniel Golle,
Horatiu Vultur, Bj√∏rn Mork, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Eric Woudstra, Alexander Couzens, Chester A. Unal, DENG Qingfang,
Sean Wang, Felix Fietkau
In-Reply-To: <20260402095300.hujib22ag6g5wkts@skbuf>
Am 2. April 2026 11:53:00 MESZ schrieb Vladimir Oltean <vladimir.oltean@nxp.com>:
>On Thu, Apr 02, 2026 at 05:50:33AM +0000, Frank Wunderlich wrote:
>> Hi,
>
>Hi,
>
>Please don't top-post :(
Sorry about that. Try to do better future :)
I keep context for now (not removing my findings from early mail),i hope it is ok.
Maybe daniel or mtk can respond if my understanding is wrong.
>> i tried using these properties in sgmiisys0 node (which should be mapped to mac0 and the mt7530 switch) without success [1].
>>
>> it looks like these properties are not read somewhere.
>
>Can you please clarify whether your problem is with the SerDes connected
>to a switch port or to a GMAC?
From my tests it looks like the issue is on switch side.
>Because if to a switch port, mt7531_create_sgmii() doesn't have any
>phandle to the SGMIISYS. That was from existing code.
>
> pcs = mtk_pcs_lynxi_create(priv->dev, NULL, regmap,
> MT7531_PHYA_CTRL_SIGNAL3);
>
>The LynxI PCS will be instantiated without a fwnode and only the
>defaults will apply.
This was a good hint, i had only seen the pcs call for mac.
>> the flow is
>>
>> mtk_probe (eth driver)
>>
>> if (MTK_HAS_CAPS(eth->soc->caps, MTK_SGMII)) {
>> err = mtk_sgmii_init(eth);
>>
>> and there calling mtk_pcs_lynxi_create with the sgmiisys-node (for each mac, so imho mac0=sgmiisys0)
>> but handling the sgmiisys only as syscon, not a "real" pcs node [2].
>>
>> but your new code calls phy_get_tx_polarity and should read out this properties, but from subnode "pcs", so next try was
>>
>> &sgmiisys0 {
>> pcs {
>> rx-polarity = <PHY_POL_NORMAL>;
>> tx-polarity = <PHY_POL_INVERT>;
>> };
>> };
>>
>> which results in completely strange behaviour (looks like sgmiisys1 is mapped to mac0, but based on code in mtk_sgmii_init 0=0 should be right):
>>
>> [ 2.765218] SGMSYS_QPHY_WRAP_CTRL = 0x501, will write 0x500
>> [ 9.143849] SGMSYS_QPHY_WRAP_CTRL = 0x500, will write 0x501
>>
>> but nevertheless i tried changing sgmiisys0 to sgmiisys1 and got the dame result as before
>>
>> [ 2.713644] SGMSYS_QPHY_WRAP_CTRL = 0x501, will write 0x500
>> [ 9.061509] SGMSYS_QPHY_WRAP_CTRL = 0x500, will write 0x500
>>
>> i can only change the second serdes with sgmiisys0, but not the first.
>
>I assume the second SerDes is mapped to a GMAC port which does
>instantiate the LynxI PCS with a fwnode, right? If so, the behaviour is
>consistent with the code. Only mtk-soc-eth uses mediatek,sgmiisys AFAICS.
>
>> mapping between mac and sgmiisys in dts in mt7986a.dtsi [3] are like this:
>>
>> eth: ethernet@15100000 {
>> compatible = "mediatek,mt7986-eth";
>> mediatek,sgmiisys = <&sgmiisys0>, <&sgmiisys1>;
>> ...
>> };
>>
>> ð {
>> status = "okay";
>>
>> gmac0: mac@0 {
>> compatible = "mediatek,eth-mac";
>> ...
>> };
>>
>> gmac1: mac@1 {
>> compatible = "mediatek,eth-mac";
>> ...
>> };
>> };
>>
>> maybe it is time to revive the PCS framework discussion ([4]-[6])?
>>
>> [1] https://github.com/frank-w/BPI-Router-Linux/commit/4846a7bb352fe5911136cba33813f099bac035fd
>> [2] https://elixir.bootlin.com/linux/v7.0-rc4/source/drivers/net/ethernet/mediatek/mtk_eth_soc.c#L5001
>> [3] https://elixir.bootlin.com/linux/v7.0-rc4/source/arch/arm64/boot/dts/mediatek/mt7986a.dtsi#L528
>>
>> [4] * https://patchwork.kernel.org/project/netdevbpf/patch/20250610233134.3588011-4-sean.anderson@linux.dev/ (v6)
>> > pcs-framework itself had not yet got a response from netdev maintainer (only other parts)
>> [5] * https://patchwork.kernel.org/project/netdevbpf/patch/20250511201250.3789083-4-ansuelsmth@gmail.com/ (v4)
>> > discussion: https://lore.kernel.org/netdev/20250511201250.3789083-1-ansuelsmth@gmail.com/
>> [6] * https://patchwork.kernel.org/project/netdevbpf/patch/ba4e359584a6b3bc4b3470822c42186d5b0856f9.1721910728.git.daniel@makrotopia.org/
>> > discussion: https://patchwork.kernel.org/project/netdevbpf/patch/8aa905080bdb6760875d62cb3b2b41258837f80e.1702352117.git.daniel@makrotopia.org/
>
>I'm not exactly sure how device+driver for the PCS devices would help in
>this case though? Because the LynxI PCS driver would just retrieve the
>fwnode on its own, rather than it being passed by the mtk_pcs_lynxi_create()
>caller?
Imho it could be more general and cleaner than calling "external" function in code. If pcs acts
as own device i would see which dtnode is assigned to it...here i guessed both calls were
from mac,but one was from mac and one from switch.
I tried adding prints before the lynxi call,but this does not make it clean from where it comes (i guess because of threading)...but this could be understanding issue on my side.
It looked like this:
root@bpi-r3:~# dmesg | grep 'SGMSYS_QPHY_WRAP_CTRL\|pcs'
[ 2.155221] mtk_soc_eth 15100000.ethernet: create sgmii pcs for mac #0
[ 2.168308] mtk_soc_eth 15100000.ethernet: create sgmii pcs for mac #1
[ 2.699744] mt7530-mdio mdio-bus:1f: add lynxi pcs for switch (port5)
[ 2.706773] mt7530-mdio mdio-bus:1f: add lynxi pcs for switch (port6)
[ 2.707881] SGMSYS_QPHY_WRAP_CTRL = 0x501, will write 0x501
[ 9.081259] SGMSYS_QPHY_WRAP_CTRL = 0x500, will write 0x500
>We need to have a very good model of what happens when the PCS provider
>goes away, especially in multi-port scenarios. It is a similar issue as
>to what happens when a phy_device goes away.
>https://lore.kernel.org/netdev/20260311153421.u454m3e4blkstymt@skbuf/
>
>I'm not saying "let's not do that", but we'd effectively introducing an
>issue that currently does not exist, with the PCS lifetime being managed
>by the consumer.
>
>Do you have any better idea by now why SGMSYS_QPHY_WRAP_CTRL is 0x501
>for SGMIISYS #0? Is that its out-of-reset value?
We guess that switch takes this value somehow from an efuse or similar.
I have 2 ways to fix this broken state:
1) to keep dts backward compatibility and due to undocumented behaviour i prefer this patch:
--- a/drivers/net/pcs/pcs-mtk-lynxi.c
+++ b/drivers/net/pcs/pcs-mtk-lynxi.c
@@ -129,6 +129,9 @@ static int mtk_pcs_config_polarity(struct mtk_pcs_lynxi *mpcs,
unsigned int val = 0, tmp;
int ret;
+ if (!fwnode)
+ return 0;
+
if (fwnode_property_read_bool(fwnode, "mediatek,pnswap"))
default_pol = PHY_POL_INVERT;
2) document pcs polarity (i'm still unsure if this is really correct as i cannot measure in hardware,just from software debugging...but not sure if the SGMSYS_QPHY_WRAP_CTRL offset is valid on switch regmap too) - it looks for me that by default is different between mac and switch side:
<https://github.com/frank-w/BPI-Router-Linux/commit/f693e2ed24287ce1e125d7f6202e14e263cc564d>
And add dts nodes like this:
<https://github.com/frank-w/BPI-Router-Linux/commit/4f7bce943dda614d24431d63adad65f1117a7f6d>
If i set same polarity to mac it is broken (thats why sgmiisys0 is disabled). I guess the pnswap property means "invert the default behaviour" and not "use inverted polarity compared to standard" and mac and switch use the same polarity with different values of the corresponding registers.
Based on my register documentation of mt7531 ("MT7531_Reference_Manual_for_Development_Board.pdf" page 729) i see
000050EC = QPHY_WRAP_CTRL
Bit 0
1'b1 : inversed TX_BIT_POLARITY TX bit polarity control (TX default inversed in MT7531)
Where bit 1 is only defined as "RX bit polarity control"
So my guess is that tx is inverted in hardware,but tx-bit is set in efuse to get the POL_NORMAL.
I did not find the register in my mt7986 register documentation...seems complete networking part is missing.
I do not expect that board changes polarity in hardware...
Regards Frank
^ permalink raw reply
* Re: [PATCH v4 3/4] Input: aw86938 - add driver for Awinic AW86938
From: Luca Weiss @ 2026-04-03 8:23 UTC (permalink / raw)
To: Dmitry Torokhov, Luca Weiss
Cc: Griffin Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, linux-input,
devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <ac1DclNOl3ZA5bUg@google.com>
On Wed Apr 1, 2026 at 6:11 PM CEST, Dmitry Torokhov wrote:
> On Wed, Apr 01, 2026 at 04:44:47PM +0200, Luca Weiss wrote:
>> Hi Dmitry,
>>
>> On Wed Mar 4, 2026 at 5:56 AM CET, Dmitry Torokhov wrote:
>> > On Mon, Mar 02, 2026 at 11:50:27AM +0100, Griffin Kroah-Hartman wrote:
>> >> Add support for the I2C-connected Awinic AW86938 LRA haptic driver.
>> >>
>> >> The AW86938 has a similar but slightly different register layout. In
>> >> particular, the boost mode register values.
>> >> The AW86938 also has some extra features that aren't implemented
>> >> in this driver yet.
>> >>
>> >> Signed-off-by: Griffin Kroah-Hartman <griffin.kroah@fairphone.com>
>> >
>> > Applied, thank you.
>>
>> I'm curious, where did you apply these patches? linux-next doesn't have
>> it and I don't see it in your kernel.org repo either.
>> https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git/
>>
>> Did this slip through the cracks or will these patches still appear
>> there?
>
> My bad, I think there was a conflict with Dan Carpenter's patch and as a
> result the series got stuck in my internal queue. My apologies.
>
> Should be out in 'next' branch now.
>
> Thanks.
Thanks, appreciate it!
Regards
Luca
^ permalink raw reply
* [PATCH v5] arm64: dts: qcom: milos-fairphone-fp6: Add vibrator support
From: Luca Weiss @ 2026-04-03 8:21 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel, Griffin Kroah-Hartman, Dmitry Baryshkov,
Konrad Dybcio, Luca Weiss
From: Griffin Kroah-Hartman <griffin.kroah@fairphone.com>
Add the required node for haptic playback (Awinic AW86938)
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Griffin Kroah-Hartman <griffin.kroah@fairphone.com>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Changes in v5:
- Rebase on -next, drop input patches
- Link to v4: https://lore.kernel.org/r/20260302-aw86938-driver-v4-0-92c865df9cca@fairphone.com
Changes in v4:
- Changed how vibration intensity was calculated, added a seperate patch
for it.
- Link to v3: https://lore.kernel.org/r/20260209-aw86938-driver-v3-0-5c79cff30492@fairphone.com
Changes in v3:
- Changed how compatibility was handled according to feedback
- Added reset gpio config for vibrator node
- Link to v2: https://lore.kernel.org/r/20260128-aw86938-driver-v2-0-b51ee086aaf5@fairphone.com
Changes in v2:
- Added AW86938 specific registers
- Added chip model enum to differentiate chips
- Link to v1: https://lore.kernel.org/r/20251204-aw86938-driver-v1-0-ebd71868df3a@fairphone.com
---
arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 26 +++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
index c1899db46e71..44d13966d6ff 100644
--- a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
+++ b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
@@ -687,7 +687,17 @@ vreg_l7p: ldo7 {
};
/* VL53L3 ToF @ 0x29 */
- /* AW86938FCR vibrator @ 0x5a */
+
+ vibrator@5a {
+ compatible = "awinic,aw86938", "awinic,aw86927";
+ reg = <0x5a>;
+
+ interrupts-extended = <&tlmm 80 IRQ_TYPE_EDGE_FALLING>;
+ reset-gpios = <&tlmm 78 GPIO_ACTIVE_LOW>;
+
+ pinctrl-0 = <&aw86938_int_default>, <&aw86938_reset_default>;
+ pinctrl-names = "default";
+ };
};
&pm8550vs_c {
@@ -824,6 +834,20 @@ hall_sensor_default: hall-sensor-default-state {
bias-disable;
};
+ aw86938_reset_default: aw86938-reset-default-state {
+ pins = "gpio78";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
+
+ aw86938_int_default: aw86938-int-default-state {
+ pins = "gpio80";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
pm8008_int_default: pm8008-int-default-state {
pins = "gpio125";
function = "gpio";
---
base-commit: 83acad05dee54a5cff0c98dd7962e55d4c6b145a
change-id: 20251113-aw86938-driver-b4fa0d3228a2
Best regards,
--
Luca Weiss <luca.weiss@fairphone.com>
^ permalink raw reply related
* Re: [PATCH 2/2] ARM: dts: imx25: remove empty clock-names for nand-controller@bb000000
From: Miquel Raynal @ 2026-04-03 8:20 UTC (permalink / raw)
To: Frank Li
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Shawn Guo, Daniel Baluta,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
In-Reply-To: <20260403074634.774234-2-Frank.Li@nxp.com>
On 03/04/2026 at 03:46:31 -04, Frank Li <Frank.Li@nxp.com> wrote:
> clock-names is empty in nand-controller@bb000000, which is wrong.
>
> Remove it to fix below CHECK_DTBS warings:
> arch/arm/boot/dts/nxp/imx/imx25-pdk.dtb: nand-controller@bb000000 (fsl,imx25-nand): Unevaluated properties are not allowed ('clock-names' was unexpected)
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: imx35: remove empty clock-names for nand-controller@bb000000
From: Miquel Raynal @ 2026-04-03 8:19 UTC (permalink / raw)
To: Frank Li
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Daniel Baluta, Shawn Guo,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
In-Reply-To: <20260403074634.774234-1-Frank.Li@nxp.com>
On 03/04/2026 at 03:46:30 -04, Frank Li <Frank.Li@nxp.com> wrote:
> clock-names is empty in nand-controller@bb000000, which is wrong.
>
> Remove it to fix below CHECK_DTBS warings:
> arch/arm/boot/dts/nxp/imx/imx35-pdk.dtb: nand-controller@bb000000 (fsl,imx35-nand): Unevaluated properties are not allowed ('clock-names' was unexpected)
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
^ permalink raw reply
* Re: [RFC v1 01/11] media: uapi: v4l2-isp: Add v4l2 ISP extensible statistics definitions
From: Jacopo Mondi @ 2026-04-03 8:19 UTC (permalink / raw)
To: Antoine Bouyer
Cc: julien.vuillaumier, alexi.birlinger, daniel.baluta, peng.fan,
frank.li, jacopo.mondi, laurent.pinchart, mchehab, robh, krzk+dt,
conor+dt, shawnguo, s.hauer, kernel, festevam, linux-kernel,
linux-media, devicetree, linux-arm-kernel, Jai Luthra, paul elder
In-Reply-To: <20260123080938.3367348-2-antoine.bouyer@nxp.com>
Hello Antoine
in cc Jai and Paul
Jai and Paul are working on upstreaming new ISP formats which would
benefit from usage of extensible stats.
No pressure of course, just wanted to check how things are progressing
on your side. Do you have an updated version of this patch which can
be taken in ? Should we sync and work on an updated version ?
Thanks!
j
On Fri, Jan 23, 2026 at 09:09:28AM +0100, Antoine Bouyer wrote:
> Extend the v4l2-isp extensible format introduced for isp parameters buffer
> to the statistics buffer as well.
>
> Like for ISP configuration purpose, that will help supporting various ISP
> hardware versions reporting different statistics data with less impact on
> userspace.
>
> The `v4l2_isp_stats_buffer` reuses the `v4l2_isp_params_buffer` container
> definitions, with similar header, versions and flags. V0 and V1 versions
> are provided to match with params versions. On the other side, ENABLE and
> DISABLE flags are not really meaningfull for statistics purpose. So VALID
> and INVALID flags are introduced. Purpose is to force ISP driver to
> validate a statistics buffer, before it is consumed by userspace.
>
> Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
> ---
> include/uapi/linux/media/v4l2-isp.h | 85 +++++++++++++++++++++++++++++
> 1 file changed, 85 insertions(+)
>
> diff --git a/include/uapi/linux/media/v4l2-isp.h b/include/uapi/linux/media/v4l2-isp.h
> index 779168f9058e..ed1279b86694 100644
> --- a/include/uapi/linux/media/v4l2-isp.h
> +++ b/include/uapi/linux/media/v4l2-isp.h
> @@ -99,4 +99,89 @@ struct v4l2_isp_params_buffer {
> __u8 data[] __counted_by(data_size);
> };
>
> +/**
> + * enum v4l2_isp_stats_version - V4L2 ISP statistics versioning
> + *
> + * @V4L2_ISP_STATS_VERSION_V0: First version of the V4L2 ISP statistics format
> + * (for compatibility)
> + * @V4L2_ISP_STATS_VERSION_V1: First version of the V4L2 ISP statistics format
> + *
> + * V0 and V1 are identical, and comply with V4l2 ISP parameters versions. So
> + * both V0 and V1 refers to the first version of the V4L2 ISP statistics
> + * format.
> + *
> + * Future revisions of the V4L2 ISP statistics format should start from the
> + * value of 2.
> + */
> +enum v4l2_isp_stats_version {
> + V4L2_ISP_STATS_VERSION_V0 = 0,
> + V4L2_ISP_STATS_VERSION_V1,
> +};
> +
> +#define V4L2_ISP_PARAMS_FL_BLOCK_VALID (1U << 0)
> +#define V4L2_ISP_PARAMS_FL_BLOCK_INVALID (1U << 1)
> +
> +/*
> + * Reserve the first 8 bits for V4L2_ISP_STATS_FL_* flag.
> + *
> + * Driver-specific flags should be defined as:
> + * #define DRIVER_SPECIFIC_FLAG0 ((1U << V4L2_ISP_STATS_FL_DRIVER_FLAGS(0))
> + * #define DRIVER_SPECIFIC_FLAG1 ((1U << V4L2_ISP_STATS_FL_DRIVER_FLAGS(1))
> + */
> +#define V4L2_ISP_STATS_FL_DRIVER_FLAGS(n) ((n) + 8)
> +
> +/**
> + * struct v4l2_isp_stats_block_header - V4L2 extensible statistics block header
> + * @type: The statistics block type (driver-specific)
> + * @flags: A bitmask of block flags (driver-specific)
> + * @size: Size (in bytes) of the statistics block, including this header
> + *
> + * This structure represents the common part of all the ISP statistics blocks.
> + * Each statistics block shall embed an instance of this structure type as its
> + * first member, followed by the block-specific statistics data.
> + *
> + * The @type field is an ISP driver-specific value that identifies the block
> + * type. The @size field specifies the size of the parameters block.
> + *
> + * The @flags field is a bitmask of per-block flags V4L2_STATS_ISP_FL_* and
> + * driver-specific flags specified by the driver header.
> + */
> +struct v4l2_isp_stats_block_header {
> + __u16 type;
> + __u16 flags;
> + __u32 size;
> +} __attribute__((aligned(8)));
> +
> +/**
> + * struct v4l2_isp_stats_buffer - V4L2 extensible statistics data
> + * @version: The statistics buffer version (driver-specific)
> + * @data_size: The statistics data effective size, excluding this header
> + * @data: The statistics data
> + *
> + * This structure contains the statistics information of the ISP hardware,
> + * serialized for userspace into a data buffer. Each statistics block is
> + * represented by a block-specific structure which contains a
> + * :c:type:`v4l2_isp_stats_block_header` entry as first member. Driver
> + * populates the @data buffer with statistics information of the ISP blocks it
> + * intends to share to userspace. As a consequence, the data buffer effective
> + * size changes according to the number of ISP blocks that driver intends to
> + * provide and is set by the driver in the @data_size field.
> + *
> + * The statistics buffer is versioned by the @version field to allow modifying
> + * and extending its definition. Driver shall populate the @version field to
> + * inform the userpsace about the version it intends to use. The userspace will
> + * parse and handle the @data buffer according to the data layout specific to
> + * the indicated version.
> + *
> + * For each ISP block that driver wants to report, a block-specific structure
> + * is appended to the @data buffer, one after the other without gaps in
> + * between. Driver shall populate the @data_size field with the effective
> + * size, in bytes, of the @data buffer.
> + */
> +struct v4l2_isp_stats_buffer {
> + __u32 version;
> + __u32 data_size;
> + __u8 data[] __counted_by(data_size);
> +};
> +
> #endif /* _UAPI_V4L2_ISP_H_ */
> --
> 2.52.0
>
^ permalink raw reply
* Re: [PATCH v12 2/7] qcom-tgu: Add TGU driver
From: Songwei.Chai @ 2026-04-02 2:04 UTC (permalink / raw)
To: Jie Gan, andersson, alexander.shishkin, mike.leach, konrad.dybcio,
suzuki.poulose, james.clark, krzk+dt, conor+dt
Cc: linux-kernel, linux-arm-kernel, linux-arm-msm, coresight,
devicetree, gregkh
In-Reply-To: <a0a9fa9d-5438-48e0-b3de-def97d4214bf@oss.qualcomm.com>
On 3/27/2026 10:16 AM, Jie Gan wrote:
>
>
> On 3/17/2026 11:26 AM, Songwei Chai wrote:
>> Add driver to support device TGU (Trigger Generation Unit).
>> TGU is a Data Engine which can be utilized to sense a plurality of
>> signals and create a trigger into the CTI or generate interrupts to
>> processors. Add probe/enable/disable functions for tgu.
>>
>> Signed-off-by: Songwei Chai <songwei.chai@oss.qualcomm.com>
>> ---
>> .../ABI/testing/sysfs-bus-amba-devices-tgu | 9 +
>> drivers/Makefile | 1 +
>> drivers/hwtracing/Kconfig | 2 +
>> drivers/hwtracing/qcom/Kconfig | 18 ++
>> drivers/hwtracing/qcom/Makefile | 3 +
>> drivers/hwtracing/qcom/tgu.c | 183 ++++++++++++++++++
>> drivers/hwtracing/qcom/tgu.h | 51 +++++
>> 7 files changed, 267 insertions(+)
>> create mode 100644
>> Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
>> create mode 100644 drivers/hwtracing/qcom/Kconfig
>> create mode 100644 drivers/hwtracing/qcom/Makefile
>> create mode 100644 drivers/hwtracing/qcom/tgu.c
>> create mode 100644 drivers/hwtracing/qcom/tgu.h
>>
>> diff --git a/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
>> b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
>> new file mode 100644
>> index 000000000000..ead237bb7d89
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
>> @@ -0,0 +1,9 @@
>> +What: /sys/bus/amba/devices/<tgu-name>/enable_tgu
>> +Date: March 2026
>> +KernelVersion 7.1
>> +Contact: Jinlong Mao <jinlong.mao@oss.qualcomm.com>, Songwei Chai
>> <songwei.chai@oss.qualcomm.com>
>> +Description:
>> + (RW) Set/Get the enable/disable status of TGU
>> + Accepts only one of the 2 values - 0 or 1.
>> + 0 : disable TGU.
>> + 1 : enable TGU.
>> diff --git a/drivers/Makefile b/drivers/Makefile
>> index 53fbd2e0acdd..82b712a12a26 100644
>> --- a/drivers/Makefile
>> +++ b/drivers/Makefile
>> @@ -177,6 +177,7 @@ obj-$(CONFIG_RAS) += ras/
>> obj-$(CONFIG_USB4) += thunderbolt/
>> obj-$(CONFIG_CORESIGHT) += hwtracing/coresight/
>> obj-y += hwtracing/intel_th/
>> +obj-y += hwtracing/qcom/
>> obj-$(CONFIG_STM) += hwtracing/stm/
>> obj-$(CONFIG_HISI_PTT) += hwtracing/ptt/
>> obj-y += android/
>> diff --git a/drivers/hwtracing/Kconfig b/drivers/hwtracing/Kconfig
>> index 911ee977103c..8a640218eed8 100644
>> --- a/drivers/hwtracing/Kconfig
>> +++ b/drivers/hwtracing/Kconfig
>> @@ -7,4 +7,6 @@ source "drivers/hwtracing/intel_th/Kconfig"
>> source "drivers/hwtracing/ptt/Kconfig"
>> +source "drivers/hwtracing/qcom/Kconfig"
>> +
>> endmenu
>> diff --git a/drivers/hwtracing/qcom/Kconfig
>> b/drivers/hwtracing/qcom/Kconfig
>> new file mode 100644
>> index 000000000000..d6f6d4b0f28e
>> --- /dev/null
>> +++ b/drivers/hwtracing/qcom/Kconfig
>> @@ -0,0 +1,18 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +#
>> +# QCOM specific hwtracing drivers
>> +#
>> +menu "Qualcomm specific hwtracing drivers"
>> +
>> +config QCOM_TGU
>> + tristate "QCOM Trigger Generation Unit driver"
>> + help
>> + This driver provides support for Trigger Generation Unit that is
>> + used to detect patterns or sequences on a given set of signals.
>> + TGU is used to monitor a particular bus within a given region to
>> + detect illegal transaction sequences or slave responses. It is
>> also
>> + used to monitor a data stream to detect protocol violations
>> and to
>> + provide a trigger point for centering data around a specific
>> event
>> + within the trace data buffer.
>> +
>> +endmenu
>> diff --git a/drivers/hwtracing/qcom/Makefile
>> b/drivers/hwtracing/qcom/Makefile
>> new file mode 100644
>> index 000000000000..5a0a868c1ea0
>> --- /dev/null
>> +++ b/drivers/hwtracing/qcom/Makefile
>> @@ -0,0 +1,3 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +
>> +obj-$(CONFIG_QCOM_TGU) += tgu.o
>> diff --git a/drivers/hwtracing/qcom/tgu.c b/drivers/hwtracing/qcom/tgu.c
>> new file mode 100644
>> index 000000000000..58c19f12f3d7
>> --- /dev/null
>> +++ b/drivers/hwtracing/qcom/tgu.c
>> @@ -0,0 +1,183 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
>> + */
>> +
>> +#include <linux/amba/bus.h>
>> +#include <linux/device.h>
>> +#include <linux/err.h>
>> +#include <linux/io.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/pm_runtime.h>
>> +
>> +#include "tgu.h"
>> +
>> +static void tgu_write_all_hw_regs(struct tgu_drvdata *drvdata)
>> +{
>> + TGU_UNLOCK(drvdata->base);
>> + /* Enable TGU to program the triggers */
>> + writel(1, drvdata->base + TGU_CONTROL);
>> + TGU_LOCK(drvdata->base);
>> +}
>> +
>> +static int tgu_enable(struct device *dev)
>> +{
>> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
>> +
>> + guard(spinlock)(&drvdata->lock);
>> + if (drvdata->enabled)
>> + return -EBUSY;
>> +
>> + tgu_write_all_hw_regs(drvdata);
>> + drvdata->enabled = true;
>> +
>> + return 0;
>> +}
>> +
>> +static void tgu_do_disable(struct tgu_drvdata *drvdata)
>> +{
>> + TGU_UNLOCK(drvdata->base);
>> + writel(0, drvdata->base + TGU_CONTROL);
>> + TGU_LOCK(drvdata->base);
>> +
>> + drvdata->enabled = false;
>> +}
>> +
>> +static void tgu_disable(struct device *dev)
>> +{
>> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
>> +
>> + guard(spinlock)(&drvdata->lock);
>> + if (!drvdata->enabled)
>> + return;
>> +
>> + tgu_do_disable(drvdata);
>> +}
>> +
>> +static ssize_t enable_tgu_show(struct device *dev,
>> + struct device_attribute *attr, char *buf)
>> +{
>> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
>> + bool enabled;
>> +
>> + guard(spinlock)(&drvdata->lock);
>> + enabled = drvdata->enabled;
>> +
>> + return sysfs_emit(buf, "%d\n", !!enabled);
>> +}
>> +
>> +/* enable_tgu_store - Configure Trace and Gating Unit (TGU)
>> triggers. */
>> +static ssize_t enable_tgu_store(struct device *dev,
>> + struct device_attribute *attr,
>> + const char *buf,
>> + size_t size)
>> +{
>> + unsigned long val;
>> + int ret;
>> +
>> + ret = kstrtoul(buf, 0, &val);
>> + if (ret || val > 1)
>> + return -EINVAL;
>> +
>> + if (val) {
>> + ret = pm_runtime_resume_and_get(dev);
>> + if (ret)
>> + return ret;
>> + ret = tgu_enable(dev);
>> + if (ret) {
>> + pm_runtime_put(dev);
>> + return ret;
>> + }
>> + } else {
>> + tgu_disable(dev);
>> + pm_runtime_put(dev);
>
> Sorry I didnt observe this issue with my previous check.
>
> echo 0 to the disabled device will result in the pm_runtime reference
> number goes to negative. We dont need pm_runtime_put(dev) when we try
> to disable a diabled device.
>
> Thanks,
> Jie
Thanks for your careful catch here, Jie.
"pm_runtime_put(dev);" will be removed here in next version.
>
>> + }
>> +
>> + return size;
>> +}
>> +static DEVICE_ATTR_RW(enable_tgu);
>> +
>> +static struct attribute *tgu_common_attrs[] = {
>> + &dev_attr_enable_tgu.attr,
>> + NULL,
>> +};
>> +
>> +static const struct attribute_group tgu_common_grp = {
>> + .attrs = tgu_common_attrs,
>> + NULL,
>> +};
>> +
>> +static const struct attribute_group *tgu_attr_groups[] = {
>> + &tgu_common_grp,
>> + NULL,
>> +};
>> +
>> +static int tgu_probe(struct amba_device *adev, const struct amba_id
>> *id)
>> +{
>> + struct device *dev = &adev->dev;
>> + struct tgu_drvdata *drvdata;
>> + int ret;
>> +
>> + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
>> + if (!drvdata)
>> + return -ENOMEM;
>> +
>> + drvdata->dev = &adev->dev;
>> + dev_set_drvdata(dev, drvdata);
>> +
>> + drvdata->base = devm_ioremap_resource(dev, &adev->res);
>> + if (IS_ERR(drvdata->base))
>> + return PTR_ERR(drvdata->base);
>> +
>> + spin_lock_init(&drvdata->lock);
>> +
>> + ret = sysfs_create_groups(&dev->kobj, tgu_attr_groups);
>> + if (ret) {
>> + dev_err(dev, "failed to create sysfs groups: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + drvdata->enabled = false;
>> +
>> + pm_runtime_put(&adev->dev);
>> +
>> + return 0;
>> +}
>> +
>> +static void tgu_remove(struct amba_device *adev)
>> +{
>> + struct device *dev = &adev->dev;
>> +
>> + sysfs_remove_groups(&dev->kobj, tgu_attr_groups);
>> +
>> + tgu_disable(dev);
>> +}
>> +
>> +static const struct amba_id tgu_ids[] = {
>> + {
>> + .id = 0x000f0e00,
>> + .mask = 0x000fffff,
>> + },
>> + { 0, 0, NULL },
>> +};
>> +
>> +MODULE_DEVICE_TABLE(amba, tgu_ids);
>> +
>> +static struct amba_driver tgu_driver = {
>> + .drv = {
>> + .name = "qcom-tgu",
>> + .suppress_bind_attrs = true,
>> + },
>> + .probe = tgu_probe,
>> + .remove = tgu_remove,
>> + .id_table = tgu_ids,
>> +};
>> +
>> +module_amba_driver(tgu_driver);
>> +
>> +MODULE_AUTHOR("Songwei Chai <songwei.chai@oss.qualcomm.com>");
>> +MODULE_AUTHOR("Jinlong Mao <jinlong.mao@oss.qualcomm.com>");
>> +MODULE_DESCRIPTION("Qualcomm Trigger Generation Unit driver");
>> +MODULE_LICENSE("GPL");
>> diff --git a/drivers/hwtracing/qcom/tgu.h b/drivers/hwtracing/qcom/tgu.h
>> new file mode 100644
>> index 000000000000..dd7533b9d735
>> --- /dev/null
>> +++ b/drivers/hwtracing/qcom/tgu.h
>> @@ -0,0 +1,51 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
>> + */
>> +
>> +#ifndef _QCOM_TGU_H
>> +#define _QCOM_TGU_H
>> +
>> +/* Register addresses */
>> +#define TGU_CONTROL 0x0000
>> +#define TGU_LAR 0xfb0
>> +#define TGU_UNLOCK_OFFSET 0xc5acce55
>> +
>> +static inline void TGU_LOCK(void __iomem *addr)
>> +{
>> + do {
>> + /* Wait for things to settle */
>> + mb();
>> + writel_relaxed(0x0, addr + TGU_LAR);
>> + } while (0);
>> +}
>> +
>> +static inline void TGU_UNLOCK(void __iomem *addr)
>> +{
>> + do {
>> + writel_relaxed(TGU_UNLOCK_OFFSET, addr + TGU_LAR);
>> + /* Make sure everyone has seen this */
>> + mb();
>> + } while (0);
>> +}
>> +
>> +/**
>> + * struct tgu_drvdata - Data structure for a TGU (Trigger Generator
>> Unit)
>> + * @base: Memory-mapped base address of the TGU device
>> + * @dev: Pointer to the associated device structure
>> + * @lock: Spinlock for handling concurrent access to private data
>> + * @enabled: Flag indicating whether the TGU device is enabled
>> + *
>> + * This structure defines the data associated with a TGU device,
>> + * including its base address, device pointers, clock, spinlock for
>> + * synchronization, trigger data pointers, maximum limits for various
>> + * trigger-related parameters, and enable status.
>> + */
>> +struct tgu_drvdata {
>> + void __iomem *base;
>> + struct device *dev;
>> + spinlock_t lock;
>> + bool enabled;
>> +};
>> +
>> +#endif
>
^ permalink raw reply
* Re: [PATCH v12 2/7] qcom-tgu: Add TGU driver
From: Songwei.Chai @ 2026-04-02 2:03 UTC (permalink / raw)
To: Jie Gan, andersson, alexander.shishkin, mike.leach, konrad.dybcio,
suzuki.poulose, james.clark, krzk+dt, conor+dt
Cc: linux-kernel, linux-arm-kernel, linux-arm-msm, coresight,
devicetree, gregkh
In-Reply-To: <2ff7aed6-72c0-492e-96d7-f8c30f331a01@oss.qualcomm.com>
On 3/27/2026 10:35 AM, Jie Gan wrote:
>
>
> On 3/17/2026 11:26 AM, Songwei Chai wrote:
>> Add driver to support device TGU (Trigger Generation Unit).
>> TGU is a Data Engine which can be utilized to sense a plurality of
>> signals and create a trigger into the CTI or generate interrupts to
>> processors. Add probe/enable/disable functions for tgu.
>>
>> Signed-off-by: Songwei Chai <songwei.chai@oss.qualcomm.com>
>> ---
>> .../ABI/testing/sysfs-bus-amba-devices-tgu | 9 +
>> drivers/Makefile | 1 +
>> drivers/hwtracing/Kconfig | 2 +
>> drivers/hwtracing/qcom/Kconfig | 18 ++
>> drivers/hwtracing/qcom/Makefile | 3 +
>> drivers/hwtracing/qcom/tgu.c | 183 ++++++++++++++++++
>> drivers/hwtracing/qcom/tgu.h | 51 +++++
>> 7 files changed, 267 insertions(+)
>> create mode 100644
>> Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
>> create mode 100644 drivers/hwtracing/qcom/Kconfig
>> create mode 100644 drivers/hwtracing/qcom/Makefile
>> create mode 100644 drivers/hwtracing/qcom/tgu.c
>> create mode 100644 drivers/hwtracing/qcom/tgu.h
>>
>> diff --git a/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
>> b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
>> new file mode 100644
>> index 000000000000..ead237bb7d89
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
>> @@ -0,0 +1,9 @@
>> +What: /sys/bus/amba/devices/<tgu-name>/enable_tgu
>> +Date: March 2026
>> +KernelVersion 7.1
>
> missed ":" in all patches.
Thanks Jie, it will be updated in next version.
> Thanks,
> Jie
>
>> +Contact: Jinlong Mao <jinlong.mao@oss.qualcomm.com>, Songwei Chai
>> <songwei.chai@oss.qualcomm.com>
>> +Description:
>> + (RW) Set/Get the enable/disable status of TGU
>> + Accepts only one of the 2 values - 0 or 1.
>> + 0 : disable TGU.
>> + 1 : enable TGU.
>> diff --git a/drivers/Makefile b/drivers/Makefile
>> index 53fbd2e0acdd..82b712a12a26 100644
>> --- a/drivers/Makefile
>> +++ b/drivers/Makefile
>> @@ -177,6 +177,7 @@ obj-$(CONFIG_RAS) += ras/
>> obj-$(CONFIG_USB4) += thunderbolt/
>> obj-$(CONFIG_CORESIGHT) += hwtracing/coresight/
>> obj-y += hwtracing/intel_th/
>> +obj-y += hwtracing/qcom/
>> obj-$(CONFIG_STM) += hwtracing/stm/
>> obj-$(CONFIG_HISI_PTT) += hwtracing/ptt/
>> obj-y += android/
>> diff --git a/drivers/hwtracing/Kconfig b/drivers/hwtracing/Kconfig
>> index 911ee977103c..8a640218eed8 100644
>> --- a/drivers/hwtracing/Kconfig
>> +++ b/drivers/hwtracing/Kconfig
>> @@ -7,4 +7,6 @@ source "drivers/hwtracing/intel_th/Kconfig"
>> source "drivers/hwtracing/ptt/Kconfig"
>> +source "drivers/hwtracing/qcom/Kconfig"
>> +
>> endmenu
>> diff --git a/drivers/hwtracing/qcom/Kconfig
>> b/drivers/hwtracing/qcom/Kconfig
>> new file mode 100644
>> index 000000000000..d6f6d4b0f28e
>> --- /dev/null
>> +++ b/drivers/hwtracing/qcom/Kconfig
>> @@ -0,0 +1,18 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +#
>> +# QCOM specific hwtracing drivers
>> +#
>> +menu "Qualcomm specific hwtracing drivers"
>> +
>> +config QCOM_TGU
>> + tristate "QCOM Trigger Generation Unit driver"
>> + help
>> + This driver provides support for Trigger Generation Unit that is
>> + used to detect patterns or sequences on a given set of signals.
>> + TGU is used to monitor a particular bus within a given region to
>> + detect illegal transaction sequences or slave responses. It is
>> also
>> + used to monitor a data stream to detect protocol violations
>> and to
>> + provide a trigger point for centering data around a specific
>> event
>> + within the trace data buffer.
>> +
>> +endmenu
>> diff --git a/drivers/hwtracing/qcom/Makefile
>> b/drivers/hwtracing/qcom/Makefile
>> new file mode 100644
>> index 000000000000..5a0a868c1ea0
>> --- /dev/null
>> +++ b/drivers/hwtracing/qcom/Makefile
>> @@ -0,0 +1,3 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +
>> +obj-$(CONFIG_QCOM_TGU) += tgu.o
>> diff --git a/drivers/hwtracing/qcom/tgu.c b/drivers/hwtracing/qcom/tgu.c
>> new file mode 100644
>> index 000000000000..58c19f12f3d7
>> --- /dev/null
>> +++ b/drivers/hwtracing/qcom/tgu.c
>> @@ -0,0 +1,183 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
>> + */
>> +
>> +#include <linux/amba/bus.h>
>> +#include <linux/device.h>
>> +#include <linux/err.h>
>> +#include <linux/io.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/pm_runtime.h>
>> +
>> +#include "tgu.h"
>> +
>> +static void tgu_write_all_hw_regs(struct tgu_drvdata *drvdata)
>> +{
>> + TGU_UNLOCK(drvdata->base);
>> + /* Enable TGU to program the triggers */
>> + writel(1, drvdata->base + TGU_CONTROL);
>> + TGU_LOCK(drvdata->base);
>> +}
>> +
>> +static int tgu_enable(struct device *dev)
>> +{
>> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
>> +
>> + guard(spinlock)(&drvdata->lock);
>> + if (drvdata->enabled)
>> + return -EBUSY;
>> +
>> + tgu_write_all_hw_regs(drvdata);
>> + drvdata->enabled = true;
>> +
>> + return 0;
>> +}
>> +
>> +static void tgu_do_disable(struct tgu_drvdata *drvdata)
>> +{
>> + TGU_UNLOCK(drvdata->base);
>> + writel(0, drvdata->base + TGU_CONTROL);
>> + TGU_LOCK(drvdata->base);
>> +
>> + drvdata->enabled = false;
>> +}
>> +
>> +static void tgu_disable(struct device *dev)
>> +{
>> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
>> +
>> + guard(spinlock)(&drvdata->lock);
>> + if (!drvdata->enabled)
>> + return;
>> +
>> + tgu_do_disable(drvdata);
>> +}
>> +
>> +static ssize_t enable_tgu_show(struct device *dev,
>> + struct device_attribute *attr, char *buf)
>> +{
>> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
>> + bool enabled;
>> +
>> + guard(spinlock)(&drvdata->lock);
>> + enabled = drvdata->enabled;
>> +
>> + return sysfs_emit(buf, "%d\n", !!enabled);
>> +}
>> +
>> +/* enable_tgu_store - Configure Trace and Gating Unit (TGU)
>> triggers. */
>> +static ssize_t enable_tgu_store(struct device *dev,
>> + struct device_attribute *attr,
>> + const char *buf,
>> + size_t size)
>> +{
>> + unsigned long val;
>> + int ret;
>> +
>> + ret = kstrtoul(buf, 0, &val);
>> + if (ret || val > 1)
>> + return -EINVAL;
>> +
>> + if (val) {
>> + ret = pm_runtime_resume_and_get(dev);
>> + if (ret)
>> + return ret;
>> + ret = tgu_enable(dev);
>> + if (ret) {
>> + pm_runtime_put(dev);
>> + return ret;
>> + }
>> + } else {
>> + tgu_disable(dev);
>> + pm_runtime_put(dev);
>> + }
>> +
>> + return size;
>> +}
>> +static DEVICE_ATTR_RW(enable_tgu);
>> +
>> +static struct attribute *tgu_common_attrs[] = {
>> + &dev_attr_enable_tgu.attr,
>> + NULL,
>> +};
>> +
>> +static const struct attribute_group tgu_common_grp = {
>> + .attrs = tgu_common_attrs,
>> + NULL,
>> +};
>> +
>> +static const struct attribute_group *tgu_attr_groups[] = {
>> + &tgu_common_grp,
>> + NULL,
>> +};
>> +
>> +static int tgu_probe(struct amba_device *adev, const struct amba_id
>> *id)
>> +{
>> + struct device *dev = &adev->dev;
>> + struct tgu_drvdata *drvdata;
>> + int ret;
>> +
>> + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
>> + if (!drvdata)
>> + return -ENOMEM;
>> +
>> + drvdata->dev = &adev->dev;
>> + dev_set_drvdata(dev, drvdata);
>> +
>> + drvdata->base = devm_ioremap_resource(dev, &adev->res);
>> + if (IS_ERR(drvdata->base))
>> + return PTR_ERR(drvdata->base);
>> +
>> + spin_lock_init(&drvdata->lock);
>> +
>> + ret = sysfs_create_groups(&dev->kobj, tgu_attr_groups);
>> + if (ret) {
>> + dev_err(dev, "failed to create sysfs groups: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + drvdata->enabled = false;
>> +
>> + pm_runtime_put(&adev->dev);
>> +
>> + return 0;
>> +}
>> +
>> +static void tgu_remove(struct amba_device *adev)
>> +{
>> + struct device *dev = &adev->dev;
>> +
>> + sysfs_remove_groups(&dev->kobj, tgu_attr_groups);
>> +
>> + tgu_disable(dev);
>> +}
>> +
>> +static const struct amba_id tgu_ids[] = {
>> + {
>> + .id = 0x000f0e00,
>> + .mask = 0x000fffff,
>> + },
>> + { 0, 0, NULL },
>> +};
>> +
>> +MODULE_DEVICE_TABLE(amba, tgu_ids);
>> +
>> +static struct amba_driver tgu_driver = {
>> + .drv = {
>> + .name = "qcom-tgu",
>> + .suppress_bind_attrs = true,
>> + },
>> + .probe = tgu_probe,
>> + .remove = tgu_remove,
>> + .id_table = tgu_ids,
>> +};
>> +
>> +module_amba_driver(tgu_driver);
>> +
>> +MODULE_AUTHOR("Songwei Chai <songwei.chai@oss.qualcomm.com>");
>> +MODULE_AUTHOR("Jinlong Mao <jinlong.mao@oss.qualcomm.com>");
>> +MODULE_DESCRIPTION("Qualcomm Trigger Generation Unit driver");
>> +MODULE_LICENSE("GPL");
>> diff --git a/drivers/hwtracing/qcom/tgu.h b/drivers/hwtracing/qcom/tgu.h
>> new file mode 100644
>> index 000000000000..dd7533b9d735
>> --- /dev/null
>> +++ b/drivers/hwtracing/qcom/tgu.h
>> @@ -0,0 +1,51 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
>> + */
>> +
>> +#ifndef _QCOM_TGU_H
>> +#define _QCOM_TGU_H
>> +
>> +/* Register addresses */
>> +#define TGU_CONTROL 0x0000
>> +#define TGU_LAR 0xfb0
>> +#define TGU_UNLOCK_OFFSET 0xc5acce55
>> +
>> +static inline void TGU_LOCK(void __iomem *addr)
>> +{
>> + do {
>> + /* Wait for things to settle */
>> + mb();
>> + writel_relaxed(0x0, addr + TGU_LAR);
>> + } while (0);
>> +}
>> +
>> +static inline void TGU_UNLOCK(void __iomem *addr)
>> +{
>> + do {
>> + writel_relaxed(TGU_UNLOCK_OFFSET, addr + TGU_LAR);
>> + /* Make sure everyone has seen this */
>> + mb();
>> + } while (0);
>> +}
>> +
>> +/**
>> + * struct tgu_drvdata - Data structure for a TGU (Trigger Generator
>> Unit)
>> + * @base: Memory-mapped base address of the TGU device
>> + * @dev: Pointer to the associated device structure
>> + * @lock: Spinlock for handling concurrent access to private data
>> + * @enabled: Flag indicating whether the TGU device is enabled
>> + *
>> + * This structure defines the data associated with a TGU device,
>> + * including its base address, device pointers, clock, spinlock for
>> + * synchronization, trigger data pointers, maximum limits for various
>> + * trigger-related parameters, and enable status.
>> + */
>> +struct tgu_drvdata {
>> + void __iomem *base;
>> + struct device *dev;
>> + spinlock_t lock;
>> + bool enabled;
>> +};
>> +
>> +#endif
>
^ permalink raw reply
* Re: [PATCH 1/1] dt-bindings: timer: fsl,imxgpt: add compatible string fsl,imx25-epit
From: Daniel Lezcano @ 2026-04-03 8:15 UTC (permalink / raw)
To: Frank Li, Mark Brown
Cc: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, open list:CLOCKSOURCE, CLOCKEVENT DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Stephen Rothwell
In-Reply-To: <ac9ztfwZMrZZgTeP@lizhi-Precision-Tower-5810>
On 4/3/26 10:00, Frank Li wrote:
> On Wed, Mar 04, 2026 at 08:31:01PM +0100, Daniel Lezcano wrote:
>> On Wed, Feb 11, 2026 at 04:49:47PM -0500, Frank Li wrote:
>>> Add compatible string fsl,imx25-epit to fix below CHECK_DTBS warnings:
>>> arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dtb: /soc/bus@53f00000/timer@53f94000: failed to match any schema with compatible: ['fsl,imx25-epit']
>>>
>>> Signed-off-by: Frank Li <Frank.Li@nxp.com>
>>
>> Applied, thanks
> Daniel Lezcano:
>
> Can't find it at linux-next master branch, anything wrong!
The patch is in timer/next but may be linux-next disabled my branch
^ permalink raw reply
* [PATCH v2] dt-bindings: arm-smmu: qcom: Add compatible for Hawi SoC
From: Mukesh Ojha @ 2026-04-03 8:09 UTC (permalink / raw)
To: Will Deacon, Joerg Roedel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robin Murphy
Cc: Robin Murphy, linux-arm-kernel, iommu, devicetree, linux-kernel,
Mukesh Ojha
Qualcomm Hawi SoC include apps smmu that implements arm,mmu-500, which
is used to translate device-visible virtual addresses to physical
addresses. Add compatible for these items.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
Changes in v2:
- Added qcom in the subject as Hawi is a Qualcomm SoC.
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index 27d25bc98cbe..06fb5c8e7547 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -93,6 +93,7 @@ properties:
items:
- enum:
- qcom,glymur-smmu-500
+ - qcom,hawi-smmu-500
- qcom,kaanapali-smmu-500
- qcom,milos-smmu-500
- qcom,qcm2290-smmu-500
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v4 0/3] Add CAMSS support for SM6350
From: Luca Weiss @ 2026-04-03 8:09 UTC (permalink / raw)
To: Vladimir Zapolskiy, Luca Weiss
Cc: Bryan O'Donoghue, Konrad Dybcio, Bryan O'Donoghue,
Conor Dooley, Robert Foss, ~postmarketos/upstreaming, phone-devel,
linux-arm-msm, linux-media, devicetree, linux-kernel,
Krzysztof Kozlowski, Todor Tomov, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Bjorn Andersson
In-Reply-To: <2a108976-374a-46e1-968d-7befa4369a74@linaro.org>
Hi Vladimir,
On Tue Mar 31, 2026 at 12:49 AM CEST, Vladimir Zapolskiy wrote:
> Hi Luca,
>
> On 2/16/26 10:54, Luca Weiss wrote:
>> Add bindings, driver and dts to support the Camera Subsystem on the
>> SM6350 SoC.
>>
>> These patches were tested on a Fairphone 4 smartphone with WIP sensor
>> drivers (Sony IMX576 and IMX582), the camera pipeline works properly as
>> far as I can tell.
>>
>> Though when stopping the camera stream, the following clock warning
>> appears in dmesg. But it does not interfere with any functionality,
>> starting and stopping the stream works and debugcc is showing 426.4 MHz
>> while the clock is on, and 'off' while it's off.
>>
>> Any suggestion how to fix this, is appreciated.
>
> I've looked at CAMCC recently, and I do notice that SM6350 CAMCC does not
> set '.use_rpm = true' flag for whatever reason.
>
> If you find a free minute, can you test the change below?..
Unfortunately that change does not resolve the "gcc_camera_axi_clk
status stuck at 'on'" warning.
fairphone-fp4:~$ cat /sys/bus/platform/drivers/sm6350-camcc/ad00000.clock-controller/power/runtime_status
active
fairphone-fp4:~$ cat /sys/bus/platform/drivers/sm6350-camcc/ad00000.clock-controller/power/runtime_status
suspended
>
> ----8<----
> diff --git a/drivers/clk/qcom/camcc-sm6350.c b/drivers/clk/qcom/camcc-sm6350.c
> index 7df12c1311c6..ba880e4edcaf 100644
> --- a/drivers/clk/qcom/camcc-sm6350.c
> +++ b/drivers/clk/qcom/camcc-sm6350.c
> @@ -1880,6 +1880,7 @@ static const struct qcom_cc_desc camcc_sm6350_desc = {
> .num_clks = ARRAY_SIZE(camcc_sm6350_clocks),
> .gdscs = camcc_sm6350_gdscs,
> .num_gdscs = ARRAY_SIZE(camcc_sm6350_gdscs),
> + .use_rpm = true,
> };
>
> static const struct of_device_id camcc_sm6350_match_table[] = {
> ----8<----
>
> This change could be considered to be included in any case, I believe.
I guess this change is now the way to enable pm_runtime, I had this
series 3 years ago in February 2023:
https://lore.kernel.org/linux-arm-msm/20230213-sm6350-camcc-runtime_pm-v3-0-d35e0d833cc4@fairphone.com/
But I never followed up due to me not understanding pm_runtime well and
no direct need for it.
But I guess reviving that with use_rpm = true, add power-domains &
required-opps to dt-bindings and sm6350.dtsi should be a good idea?
Regards
Luca
>
>> [ 5738.590980] ------------[ cut here ]------------
>> [ 5738.591009] gcc_camera_axi_clk status stuck at 'on'
>> [ 5738.591049] WARNING: CPU: 0 PID: 6918 at drivers/clk/qcom/clk-branch.c:87 clk_branch_toggle+0x170/0x190
>> [ 5738.591081] Modules linked in:
>> [ 5738.591099] CPU: 0 UID: 10000 PID: 6918 Comm: plasma-camera Tainted: G W 6.17.0-00057-ge6b67db49622 #71 NONE
>> [ 5738.591118] Tainted: [W]=WARN
>> [ 5738.591126] Hardware name: Fairphone 4 (DT)
>> [ 5738.591136] pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>> [ 5738.591150] pc : clk_branch_toggle+0x170/0x190
>> [ 5738.591164] lr : clk_branch_toggle+0x170/0x190
>> [ 5738.591177] sp : ffff800086ed3980
>> [ 5738.591184] x29: ffff800086ed3990 x28: 0000000000000001 x27: ffff800086ed3cd8
>> [ 5738.591208] x26: 0000000000000000 x25: ffffda14fcfbd250 x24: 0000000000000000
>> [ 5738.591230] x23: 0000000000000000 x22: ffffda14fc38bce0 x21: 0000000000000000
>> [ 5738.591252] x20: ffffda14fd33e618 x19: 0000000000000000 x18: 00000000000064c8
>> [ 5738.591274] x17: 0000000000000000 x16: 00001ae003667e9e x15: ffffda14fd2a07b0
>> [ 5738.591295] x14: 0000000000000000 x13: 6f27207461206b63 x12: 7574732073757461
>> [ 5738.591317] x11: 0000000000000058 x10: 0000000000000018 x9 : ffffda14fd2a0838
>> [ 5738.591338] x8 : 0000000000057fa8 x7 : 0000000000000a16 x6 : ffffda14fd2f8838
>> [ 5738.591360] x5 : ffff0001f6f59788 x4 : 0000000000000a15 x3 : ffff25ecf9d7e000
>> [ 5738.591381] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000baf5c100
>> [ 5738.591403] Call trace:
>> [ 5738.591412] clk_branch_toggle+0x170/0x190 (P)
>> [ 5738.591429] clk_branch2_disable+0x1c/0x30
>> [ 5738.591445] clk_core_disable+0x5c/0xb4
>> [ 5738.591462] clk_disable+0x38/0x60
>> [ 5738.591478] camss_disable_clocks+0x44/0x78
>> [ 5738.591496] vfe_put+0x7c/0xc0
>> [ 5738.591512] vfe_set_power+0x40/0x50
>> [ 5738.591528] pipeline_pm_power_one+0x14c/0x150
>> [ 5738.591546] pipeline_pm_power+0x74/0xf4
>> [ 5738.591561] v4l2_pipeline_pm_use+0x54/0x9c
>> [ 5738.591577] v4l2_pipeline_pm_put+0x14/0x40
>> [ 5738.591592] video_unprepare_streaming+0x18/0x24
>> [ 5738.591608] __vb2_queue_cancel+0x4c/0x314
>> [ 5738.591626] vb2_core_streamoff+0x24/0xc8
>> [ 5738.591643] vb2_ioctl_streamoff+0x58/0x98
>> [ 5738.591657] v4l_streamoff+0x24/0x30
>> [ 5738.591672] __video_do_ioctl+0x430/0x4a8
>> [ 5738.591689] video_usercopy+0x2ac/0x680
>> [ 5738.591705] video_ioctl2+0x18/0x40
>> [ 5738.591720] v4l2_ioctl+0x40/0x60
>> [ 5738.591734] __arm64_sys_ioctl+0x90/0xf0
>> [ 5738.591750] invoke_syscall.constprop.0+0x40/0xf0
>> [ 5738.591769] el0_svc_common.constprop.0+0x38/0xd8
>> [ 5738.591785] do_el0_svc+0x1c/0x28
>> [ 5738.591801] el0_svc+0x34/0xe8
>> [ 5738.591820] el0t_64_sync_handler+0xa0/0xe4
>> [ 5738.591838] el0t_64_sync+0x198/0x19c
>> [ 5738.591854] ---[ end trace 0000000000000000 ]---
>>
>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>> ---
>> Changes in v4:
>> - Update power-domain-names order (Krzysztof)
>> - Make hex numbers lower case in init seq (David)
>> - Pick up tags
>> - Link to v3: https://lore.kernel.org/r/20260213-sm6350-camss-v3-0-30a845b0b7cc@fairphone.com
>
> Should find some time myself to issue RBs, sorry for the delay.
>
>> Changes in v3:
>> - Update dt-bindings to include everything related to camss
>> - Update regulator names
>> - Remove slow_ahb_src
>> - Link to v2: https://lore.kernel.org/r/20251114-sm6350-camss-v2-0-d1ff67da33b6@fairphone.com
>>
>> Changes in v2:
>> - Remove prefix from interconnect-names
>> - Move 'top' power-domain to the top of list
>> - Update regulator supply names
>> - Link to v1: https://lore.kernel.org/r/20251024-sm6350-camss-v1-0-63d626638add@fairphone.com
>>
>> ---
>> Luca Weiss (3):
>> dt-bindings: media: camss: Add qcom,sm6350-camss
>> media: qcom: camss: Add SM6350 support
>> arm64: dts: qcom: sm6350: Add CAMSS node
>>
>> .../bindings/media/qcom,sm6350-camss.yaml | 471 +++++++++++++++++++++
>> arch/arm64/boot/dts/qcom/sm6350.dtsi | 233 ++++++++++
>> .../platform/qcom/camss/camss-csiphy-3ph-1-0.c | 125 ++++++
>> drivers/media/platform/qcom/camss/camss-vfe.c | 2 +
>> drivers/media/platform/qcom/camss/camss.c | 261 ++++++++++++
>> drivers/media/platform/qcom/camss/camss.h | 1 +
>> 6 files changed, 1093 insertions(+)
>> ---
>> base-commit: 3daf23347bb5f4a375d0101ed29c97ce1a99721b
>> change-id: 20251024-sm6350-camss-9c404bf9cfdd
>>
>> Best regards,
^ permalink raw reply
* Re: [PATCH 1/1] dt-bindings: timer: fsl,imxgpt: add compatible string fsl,imx25-epit
From: Frank Li @ 2026-04-03 8:00 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Daniel Lezcano, Thomas Gleixner, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, open list:CLOCKSOURCE, CLOCKEVENT DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <aaiIdS0zRPBY81aE@mai.linaro.org>
On Wed, Mar 04, 2026 at 08:31:01PM +0100, Daniel Lezcano wrote:
> On Wed, Feb 11, 2026 at 04:49:47PM -0500, Frank Li wrote:
> > Add compatible string fsl,imx25-epit to fix below CHECK_DTBS warnings:
> > arch/arm/boot/dts/nxp/imx/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dtb: /soc/bus@53f00000/timer@53f94000: failed to match any schema with compatible: ['fsl,imx25-epit']
> >
> > Signed-off-by: Frank Li <Frank.Li@nxp.com>
>
> Applied, thanks
Daniel Lezcano:
Can't find it at linux-next master branch, anything wrong!
Frank
^ permalink raw reply
* [PATCH 1/2] drivers/of: validate live-tree string properties before string use
From: Pengpeng Hou @ 2026-04-03 7:32 UTC (permalink / raw)
To: Rob Herring, Saravana Kannan; +Cc: devicetree, linux-kernel, pengpeng
`populate_properties()` stores live-tree property values as raw byte
sequences plus a separate `length`. They are not globally guaranteed to
be NUL-terminated.
`of_prop_next_string()` currently advances through string-list
properties with `strlen()`, `__of_node_is_type()` compares raw
`device_type` bytes with `strcmp()`, `__of_device_is_status()` compares
raw `status` bytes with `strcmp()`/`strncmp()`, and
`of_alias_from_compatible()` treats the first `compatible` entry as a
NUL-terminated string.
Validate these strings within their property bounds before treating
them as C strings. In particular, reject malformed string-list entries
whose next string is not terminated before `of_prop_next_string()`
returns it.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/of/base.c | 39 +++++++++++++++++++++++----------------
drivers/of/property.c | 30 +++++++++++++++++++++++++-----
2 files changed, 48 insertions(+), 21 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 57420806c1a2..3c6af4051ad3 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -82,7 +82,14 @@ EXPORT_SYMBOL(of_node_name_prefix);
static bool __of_node_is_type(const struct device_node *np, const char *type)
{
- const char *match = __of_get_property(np, "device_type", NULL);
+ const char *match;
+ int matchlen;
+
+ match = __of_get_property(np, "device_type", &matchlen);
+ if (!match || matchlen <= 0)
+ return false;
+ if (strnlen(match, matchlen) >= matchlen)
+ return false;
return np && match && type && !strcmp(match, type);
}
@@ -491,22 +498,22 @@ static bool __of_device_is_status(const struct device_node *device,
return false;
status = __of_get_property(device, "status", &statlen);
- if (status == NULL)
+ if (!status || statlen <= 0)
+ return false;
+ if (strnlen(status, statlen) >= statlen)
return false;
- if (statlen > 0) {
- while (*strings) {
- unsigned int len = strlen(*strings);
+ while (*strings) {
+ unsigned int len = strlen(*strings);
- if ((*strings)[len - 1] == '-') {
- if (!strncmp(status, *strings, len))
- return true;
- } else {
- if (!strcmp(status, *strings))
- return true;
- }
- strings++;
+ if ((*strings)[len - 1] == '-') {
+ if (!strncmp(status, *strings, len))
+ return true;
+ } else {
+ if (!strcmp(status, *strings))
+ return true;
}
+ strings++;
}
return false;
@@ -1217,10 +1224,10 @@ EXPORT_SYMBOL(of_find_matching_node_and_match);
int of_alias_from_compatible(const struct device_node *node, char *alias, int len)
{
const char *compatible, *p;
- int cplen;
+ int ret;
- compatible = of_get_property(node, "compatible", &cplen);
- if (!compatible || strlen(compatible) > cplen)
+ ret = of_property_read_string_index(node, "compatible", 0, &compatible);
+ if (ret)
return -ENODEV;
p = strchr(compatible, ',');
strscpy(alias, p ? p + 1 : compatible, len);
diff --git a/drivers/of/property.c b/drivers/of/property.c
index 50d95d512bf5..edbc7a95aa4c 100644
--- a/drivers/of/property.c
+++ b/drivers/of/property.c
@@ -648,16 +648,36 @@ EXPORT_SYMBOL_GPL(of_prop_next_u32);
const char *of_prop_next_string(const struct property *prop, const char *cur)
{
- const void *curv = cur;
+ const char *curv = cur;
+ const char *end;
+ size_t len;
- if (!prop)
+ if (!prop || !prop->value || !prop->length)
return NULL;
- if (!cur)
+ end = prop->value + prop->length;
+
+ if (!cur) {
+ len = strnlen(prop->value, prop->length);
+ if (len >= prop->length)
+ return NULL;
+
return prop->value;
+ }
- curv += strlen(cur) + 1;
- if (curv >= prop->value + prop->length)
+ if (cur < (const char *)prop->value || cur >= end)
+ return NULL;
+
+ len = strnlen(cur, end - cur);
+ if (len >= end - cur)
+ return NULL;
+
+ curv += len + 1;
+ if (curv >= end)
+ return NULL;
+
+ len = strnlen(curv, end - curv);
+ if (len >= end - curv)
return NULL;
return curv;
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH 2/2] drivers/of: validate status properties in reconfig state changes
From: Pengpeng Hou @ 2026-04-03 7:33 UTC (permalink / raw)
To: Rob Herring, Saravana Kannan; +Cc: devicetree, linux-kernel, pengpeng
In-Reply-To: <20260403183501.1-drivers-of-live-tree-pengpeng@iscas.ac.cn>
Live-tree reconfiguration properties also carry raw values plus explicit
lengths. `of_reconfig_get_state_change()` currently treats `status`
property values as NUL-terminated strings and feeds them straight into
`strcmp()`.
Factor the `"okay"` / `"ok"` check out into a helper that first verifies
that the property contains a bounded C string within `prop->length`.
Malformed `status` updates should be treated as not enabling the node.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/of/dynamic.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index 1a06175def37..efee59ed371a 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -74,6 +74,20 @@ static const char *action_names[] = {
[OF_RECONFIG_UPDATE_PROPERTY] = "UPDATE_PROPERTY",
};
+static bool of_property_status_ok(const struct property *prop)
+{
+ const char *status;
+
+ if (!prop || !prop->value || prop->length <= 0)
+ return false;
+
+ status = prop->value;
+ if (strnlen(status, prop->length) >= prop->length)
+ return false;
+
+ return !strcmp(status, "okay") || !strcmp(status, "ok");
+}
+
#define _do_print(func, prefix, action, node, prop, ...) ({ \
func("changeset: " prefix "%-15s %pOF%s%s\n", \
##__VA_ARGS__, action_names[action], node, \
@@ -135,11 +149,9 @@ int of_reconfig_get_state_change(unsigned long action, struct of_reconfig_data *
if (prop && !strcmp(prop->name, "status")) {
is_status = 1;
- status_state = !strcmp(prop->value, "okay") ||
- !strcmp(prop->value, "ok");
+ status_state = of_property_status_ok(prop);
if (old_prop)
- old_status_state = !strcmp(old_prop->value, "okay") ||
- !strcmp(old_prop->value, "ok");
+ old_status_state = of_property_status_ok(old_prop);
}
switch (action) {
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: imx25: remove empty clock-names for nand-controller@bb000000
From: Frank Li @ 2026-04-03 7:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Daniel Baluta,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
Cc: imx, miquel.raynal
In-Reply-To: <20260403074634.774234-1-Frank.Li@nxp.com>
clock-names is empty in nand-controller@bb000000, which is wrong.
Remove it to fix below CHECK_DTBS warings:
arch/arm/boot/dts/nxp/imx/imx25-pdk.dtb: nand-controller@bb000000 (fsl,imx25-nand): Unevaluated properties are not allowed ('clock-names' was unexpected)
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx25.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx25.dtsi b/arch/arm/boot/dts/nxp/imx/imx25.dtsi
index 94dbcef63b8cd..160533b037940 100644
--- a/arch/arm/boot/dts/nxp/imx/imx25.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx25.dtsi
@@ -618,7 +618,6 @@ nfc: nand-controller@bb000000 {
compatible = "fsl,imx25-nand";
reg = <0xbb000000 0x2000>;
clocks = <&clks 50>;
- clock-names = "";
interrupts = <33>;
status = "disabled";
};
--
2.43.0
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: imx35: remove empty clock-names for nand-controller@bb000000
From: Frank Li @ 2026-04-03 7:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Daniel Baluta, Shawn Guo,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
Cc: imx, miquel.raynal
clock-names is empty in nand-controller@bb000000, which is wrong.
Remove it to fix below CHECK_DTBS warings:
arch/arm/boot/dts/nxp/imx/imx35-pdk.dtb: nand-controller@bb000000 (fsl,imx35-nand): Unevaluated properties are not allowed ('clock-names' was unexpected)
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm/boot/dts/nxp/imx/imx35.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx35.dtsi b/arch/arm/boot/dts/nxp/imx/imx35.dtsi
index ab7b646399894..314c4f4845288 100644
--- a/arch/arm/boot/dts/nxp/imx/imx35.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx35.dtsi
@@ -369,7 +369,6 @@ nfc: nand-controller@bb000000 {
compatible = "fsl,imx35-nand", "fsl,imx25-nand";
reg = <0xbb000000 0x2000>;
clocks = <&clks 29>;
- clock-names = "";
interrupts = <33>;
status = "disabled";
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCh v3 09/14] ASoC: rsnd: Add ADG reset support for RZ/G3E
From: Geert Uytterhoeven @ 2026-04-03 7:36 UTC (permalink / raw)
To: John Madieu
Cc: Kuninori Morimoto, Mark Brown, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai,
Magnus Damm, Philipp Zabel, Claudiu Beznea, Biju Das, john.madieu,
linux-sound, linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <20260402162436.12059-10-john.madieu.xa@bp.renesas.com>
Hi John,
On Thu, 2 Apr 2026 at 18:53, John Madieu <john.madieu.xa@bp.renesas.com> wrote:
> RZ/G3E requires the ADG reset line to be deasserted for the audio
> subsystem to operate. The ADG module clock is already managed via
> rsnd_adg_clk_enable/disable() through adg->adg, so no additional
> clock handling is needed.
>
> Add support for the optional "adg" reset control on Renesas RZ/G3E SoC.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
Thanks for your patch!
> --- a/sound/soc/renesas/rcar/adg.c
> +++ b/sound/soc/renesas/rcar/adg.c
> @@ -771,6 +771,7 @@ void rsnd_adg_clk_dbg_info(struct rsnd_priv *priv, struct seq_file *m)
>
> int rsnd_adg_probe(struct rsnd_priv *priv)
> {
> + struct reset_control *rstc;
> struct rsnd_adg *adg;
> struct device *dev = rsnd_priv_to_dev(priv);
> int ret;
> @@ -779,8 +780,13 @@ int rsnd_adg_probe(struct rsnd_priv *priv)
> if (!adg)
> return -ENOMEM;
>
> + rstc = devm_reset_control_get_optional_exclusive(dev, "adg");
> + if (IS_ERR(rstc))
> + return dev_err_probe(dev, PTR_ERR(rstc),
> + "failed to get adg reset\n");
Given this file already uses lines longer than 80 characters, the
above statement would fit on a single line.
> +
> ret = rsnd_mod_init(priv, &adg->mod, &adg_ops,
> - NULL, NULL, 0, 0);
> + NULL, rstc, 0, 0);
This one fits for sure.
> if (ret)
> return ret;
>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 3/6] dt-bindings: phy: realtek,usb2phy.yaml: extend for resets and RTL9607C support
From: Krzysztof Kozlowski @ 2026-04-03 7:28 UTC (permalink / raw)
To: Rustam Adilov
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stanley Chang, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260402154414.196012-4-adilov@disroot.org>
On Thu, Apr 02, 2026 at 08:44:11PM +0500, Rustam Adilov wrote:
> Add the "realtek,rtl9607-usb2phy" compatible for USB2 PHY on the RTL9607C
> SoC series.
>
> Add a resets property to properties to describe the usb2phy reset line.
>
> In RTL9607C, USB2 PHY reset line is from "IP Enable controller" which is
> multipurpose and handle activating various SoC peripherals.
>
> It is unclear whether RTD SoCs have something similar to that so set
> the resets to false for these devices.
>
> RTL9607C requires the "resets" to be specified so add the corresponding
> if check for the "realtek,rtl9607-usb2phy" compatible.
>
> Signed-off-by: Rustam Adilov <adilov@disroot.org>
> ---
> .../bindings/phy/realtek,usb2phy.yaml | 25 ++++++++++++++++++-
> 1 file changed, 24 insertions(+), 1 deletion(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: pwm: dwc: add reset optional
From: Krzysztof Kozlowski @ 2026-04-03 7:27 UTC (permalink / raw)
To: dongxuyang
Cc: ukleinek, robh, krzk+dt, conor+dt, ben-linux, ben.dooks, p.zabel,
linux-pwm, devicetree, linux-kernel, ningyu, linmin, xuxiang,
wangguosheng, pinkesh.vaghela
In-Reply-To: <20260402091854.1666-1-dongxuyang@eswincomputing.com>
On Thu, Apr 02, 2026 at 05:18:54PM +0800, dongxuyang@eswincomputing.com wrote:
> From: Xuyang Dong <dongxuyang@eswincomputing.com>
>
> The DesignWare PWM controller provides separate reset signals for each
So one controller has signals. Plural, right? Then why do you define
only one reset signal?
> clock domain, as specified in the hardware documentation. Without
> asserting and deasserting these resets during probe, PWM outputs may
> remain in an undefined state after system reboot.
>
> To address this, the driver now supports an optional 'resets' property.
This is binding change, not driver.
> A full reset is performed only when no PWM channel is enabled, as
> determined by reading the enable bit in each channel's control register.
Do you describe hardware or driver behavior? This is not a change about
driver. Describe the hardware here - what is expected with that reset.
> This allows safe coexistence with bootloaders that have already
> configured active PWM channels.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: odroid-m2: Enable DisplayPort Alt Mode over USB-C
From: Clemens Malten @ 2026-04-03 7:25 UTC (permalink / raw)
To: heiko
Cc: robh, krzk+dt, conor+dt, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, Clemens Malten
Enable USB-C DisplayPort Alt Mode on the ODROID-M2 board (RK3588S) by
adding the necessary DTS changes:
- Enable dp0 controller (dw-dp driver)
- Add VOP2 video pipeline endpoints: vp2 -> dp0 -> usbdp_phy0
- Fix try-power-role from 'source' to 'sink' to allow the board to
receive power and trigger correct PD negotiation
- Add altmodes block to the USB-C connector with DP SVID (0xff01) and
VDO. Note: svid must be declared as a 16-bit value (/bits/ 16) as
required by the typec class driver (fwnode_property_read_u16)
Tested on ODROID-M2 (RK3588S) with a UGreen CM654 USB-C DP adapter
under mainline Linux 6.19-rc.
This patch depends on Andy Yan's RK3588 DisplayPort Controller series:
Link: https://lore.kernel.org/all/20250822063959.692098-1-andyshrk@163.com/
Signed-off-by: Clemens Malten <c.malten@proton.me>
---
.../boot/dts/rockchip/rk3588s-odroid-m2.dts | 29 ++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-odroid-m2.dts b/arch/arm64/boot/dts/rockchip/rk3588s-odroid-m2.dts
index a72063c55..dbc62f032 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-odroid-m2.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-odroid-m2.dts
@@ -352,7 +352,17 @@ connector {
power-role = "dual";
sink-pdos = <PDO_FIXED(5000, 1000, PDO_FIXED_USB_COMM)>;
source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
- try-power-role = "source";
+ try-power-role = "sink";
+
+ altmodes {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ altmode@0 {
+ reg = <0>;
+ svid = /bits/ 16 <0xff01>;
+ vdo = <0xffffffff>;
+ };
+ };
ports {
#address-cells = <1>;
@@ -952,3 +962,20 @@ vp0_out_hdmi0: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
remote-endpoint = <&hdmi0_in_vp0>;
};
};
+
+&dp0 {
+ status = "okay";
+};
+
+&dp0_in {
+ dp0_in_vp2: endpoint {
+ remote-endpoint = <&vp2_out_dp0>;
+ };
+};
+
+&vp2 {
+ vp2_out_dp0: endpoint@a {
+ reg = <ROCKCHIP_VOP2_EP_DP0>;
+ remote-endpoint = <&dp0_in_vp2>;
+ };
+};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 1/4] ASoC: dt-bindings: Add ti,tas67524
From: Krzysztof Kozlowski @ 2026-04-03 7:20 UTC (permalink / raw)
To: Sen Wang, linux-sound
Cc: broonie, lgirdwood, robh, krzk+dt, conor+dt, devicetree, perex,
tiwai, shenghao-ding, kevin-lu, baojun.xu, niranjan.hy,
l-badrinarayanan, devarsht, v-singh1, linux-kernel
In-Reply-To: <20260403050627.635591-2-sen@ti.com>
On 03/04/2026 07:06, Sen Wang wrote:
> Add device tree binding for the Texas Instruments TAS67524 family
> of four-channel Class-D audio amplifiers with integrated DSP.
>
> Signed-off-by: Sen Wang <sen@ti.com>
> ---
> Changes in v3:
> - Renamed ti,tas675x to ti,tas67524.yaml
> - Removed tas6754 compatible instance
> - Changed pd-gpios to powerdown-gpios
> - Cleanup unnessary "|" formatting
>
> Changes in v2:
> - None
>
> .../bindings/sound/ti,tas67524.yaml | 277 ++++++++++++++++++
> 1 file changed, 277 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/ti,tas67524.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/ti,tas67524.yaml b/Documentation/devicetree/bindings/sound/ti,tas67524.yaml
> new file mode 100644
> index 000000000000..b8da1360e698
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/ti,tas67524.yaml
> @@ -0,0 +1,277 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/ti,tas67524.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Texas Instruments TAS67524 Audio Amplifier
> +
> +maintainers:
> + - Sen Wang <sen@ti.com>
> +
> +description:
> + The TAS67524 is a four-channel, digital-input, automotive
> + Class-D audio amplifier with load diagnostics and an integrated
> + DSP for audio processing.
> +
> +allOf:
> + - $ref: dai-common.yaml#
> +
> +properties:
> + compatible:
> + enum:
> + - ti,tas67524
And where did you give me chance to answer to your comment? You answered
2:40 AM of my time and four hours later - 7 AM my time - you send v3.
No, read again the feedback. I am not reviewing the rest.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: sound: Add ti,tas675x
From: Krzysztof Kozlowski @ 2026-04-03 7:19 UTC (permalink / raw)
To: Sen Wang
Cc: linux-sound, broonie, lgirdwood, robh, krzk+dt, conor+dt,
devicetree, perex, tiwai, shenghao-ding, kevin-lu, baojun.xu,
niranjan.hy, l-badrinarayanan, devarsht, v-singh1, linux-kernel
In-Reply-To: <b35904a2-0913-456f-b89a-f9f45e6a686a@ti.com>
On 03/04/2026 02:40, Sen Wang wrote:
>>> diff --git a/Documentation/devicetree/bindings/sound/ti,tas675x.yaml b/Documentation/devicetree/bindings/sound/ti,tas675x.yaml
>>> new file mode 100644
>>> index 000000000000..23e4cc77b4ae
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/sound/ti,tas675x.yaml
>>> @@ -0,0 +1,278 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/sound/ti,tas675x.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Texas Instruments TAS675x Audio Amplifier
>>> +
>>> +maintainers:
>>> + - Sen Wang <sen@ti.com>
>>> +
>>> +description: |
>>
>> Do not need '|' unless you need to preserve formatting.
>>
>>> + The TAS675x family (TAS6754, TAS67524) are four-channel, digital-input,
>>
>> And devices are not compatible?
>>
>
> They're compatible, and I didn't have any differentiators for this
> initial driver. So I should only keep one.
> And also rename ti,tas675x.yaml to ti,tas67524.yaml.
No, you should express compatibility. See writing bindings, writing
schema, example schema docs or DTS101 talk.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 2/3] dt-bindings: media: mediatek-jpeg-encoder: add MT8189 compatible string
From: Krzysztof Kozlowski @ 2026-04-03 7:15 UTC (permalink / raw)
To: Jianhua Lin, 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
In-Reply-To: <20260403064912.17259-3-jianhua.lin@mediatek.com>
On 03/04/2026 08:49, Jianhua Lin wrote:
> 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.
>
> Suggested-by: Krzysztof Kozlowski <krzk@kernel.org>
Not true.
> Suggested-by: Rob Herring <robh@kernel.org>
Is this some sort of joke of us?
You received no comments at v5 but "suggested-by" me appeared.
You received comments in v4 but you ignored them completely.
NAK, I am really getting fed up how absolutely terrible contributions
from Mediatek are. Mediatek doesn't follow the process, doesn't read the
documents describing the process, sends code which often fails basic
build testing.
Best regards,
Krzysztof
^ 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