* Re: [PATCH 2/3] dt-bindings: mfd: s2mu005-pmic: drop compatible property for multi-led node
From: Krzysztof Kozlowski @ 2026-06-16 4:15 UTC (permalink / raw)
To: Kaustabh Chakraborty, André Draszik, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Pavel Machek
Cc: linux-kernel, linux-samsung-soc, devicetree, linux-leds
In-Reply-To: <20260616-s2mu005-pmic-supplement-v1-2-41e84518b711@disroot.org>
On 15/06/2026 22:26, Kaustabh Chakraborty wrote:
> The multi-led node is very trivial in description and also has no
> sub-nodes. A compatible string property for such nodes is not preferred
> by upstream. Remove said node from the schema. While at it, also add a
> description following its other sibling nodes.
>
> Link: https://lore.kernel.org/all/d2f4cb7d-5c3e-4b9a-86ca-04262cbb9775@kernel.org
> Suggested-by: Krzysztof Kozlowski <krzk@kernel.org>
> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
> ---
> .../devicetree/bindings/mfd/samsung,s2mu005-pmic.yaml | 13 +++----------
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mfd/samsung,s2mu005-pmic.yaml b/Documentation/devicetree/bindings/mfd/samsung,s2mu005-pmic.yaml
> index 8354422e39b1e..f62fe7a05147e 100644
> --- a/Documentation/devicetree/bindings/mfd/samsung,s2mu005-pmic.yaml
> +++ b/Documentation/devicetree/bindings/mfd/samsung,s2mu005-pmic.yaml
> @@ -38,17 +38,10 @@ properties:
> Child node describing MUIC device.
>
> multi-led:
> - type: object
> + $ref: /schemas/leds/leds-class-multicolor.yaml#
>
> - allOf:
> - - $ref: /schemas/leds/leds-class-multicolor.yaml#
> -
> - properties:
> - compatible:
> - const: samsung,s2mu005-rgb
It's already accepted and used in two drivers, leave it.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: mfd: s2mu005-pmic: reorder reg and interrupts properties
From: Krzysztof Kozlowski @ 2026-06-16 4:14 UTC (permalink / raw)
To: Kaustabh Chakraborty, André Draszik, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Pavel Machek
Cc: linux-kernel, linux-samsung-soc, devicetree, linux-leds
In-Reply-To: <20260616-s2mu005-pmic-supplement-v1-1-41e84518b711@disroot.org>
On 15/06/2026 22:26, Kaustabh Chakraborty wrote:
> As per convention, and as also reiterated by maintainers [1], the
> properties in schema is to be ordered similar to how its done in
> devicetree sources; starting from compatible and reg. Re-order the
> properties in this schema accordingly.
>
> Link: https://lore.kernel.org/all/0240eb13-6c56-4879-8db7-b990a220a78f@kernel.org [1]
> Suggested-by: Krzysztof Kozlowski <krzk@kernel.org>
> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Honestly, nah... I commented on v6 so you change the patch. But you were
posting this huge patchset faster than we can review (v6 and v7 posted
on the same day!), so v7 got applied where you did not implement the
comments. One small posting per 24h. One big posting per 2-3 days, not
more often.
There is little benefit in fixing this single file.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] of: property: Fix of_fwnode_get_reference_args() with negative index
From: Krzysztof Kozlowski @ 2026-06-16 4:01 UTC (permalink / raw)
To: Alban Bedel
Cc: devicetree, Rob Herring, Saravana Kannan, driver-core,
linux-kernel, Tommaso Merciai
In-Reply-To: <20260615134747.3cdb9599@OMT-CWNXR4TFW5-LHT>
On 15/06/2026 13:47, Alban Bedel wrote:
> On Mon, 15 Jun 2026 11:54:01 +0200
> Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>> Indices larger than INT_MAX are valid in the fwnode API, so returning
>>> -EINVAL is not appropriate here.
>>>
>>
>> Then neither ENOENT are.
>>
>> But really, EINVAL is correct here. This is OF implementation, so this
>> implementation decides what is EINVAL and what is right. Not fwnode API.
>
> I think there is a missunderstanding here. The function we are talking
> about, of_fwnode_get_reference_args(), is the OF backed implementation
> of fwnode_property_get_reference_args(). As such it must follow the API
> documented by fwnode_property_get_reference_args() which list the
> following return values:
>
> * Return: %0 on success
> * %-ENOENT when the index is out of bounds, the index has an empty
> * reference or the property was not found
> * %-EINVAL on parse error
> * %-ENOTCONN when the remote firmware node exists but has not been
> * registered yet
>
> It is not explicitly documented what should be returned if the index is
> not representable in the backend, but considering it out of bound seems
> to be the most sensible thing to do.
>
I agree, I did not consider the docs for
fwnode_property_get_reference_args().
Please send v2 fixing the comment style and with:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v9 1/2] dt-bindings: ufs: Document static TX Equalization settings properties
From: Krzysztof Kozlowski @ 2026-06-16 3:54 UTC (permalink / raw)
To: Can Guo, bvanassche, beanhuo, peter.wang, martin.petersen, mani
Cc: linux-scsi, Alim Akhtar, Avri Altman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ram Kumar Dwivedi,
Zhaoming Luo,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20260615132834.2985346-2-can.guo@oss.qualcomm.com>
On 15/06/2026 15:28, Can Guo wrote:
> UFS v5.0/UFSHCI v5.0 adds HS-G6 support (46.6 Gbps/lane) via UniPro
> v3.0 and M-PHY v6.0. These specs define TX Equalization for all
> High-Speed Gears (not only HS-G6) to compensate channel loss and
> improve signal integrity at high speed.
>
> For HS-G6, M-PHY uses PAM4 1b1b line coding. Pre-Coding may also be
> required depending on channel characteristics.
>
> Document vendor-neutral properties in ufs-common.yaml:
> - txeq-preshoot-g[1-6]
> - txeq-deemphasis-g[1-6]
> - tx-precode-enable-g6
>
> Values are per-lane Host/Device tuples (2 values for x1, 4 values for
> x2). PreShoot/DeEmphasis range from 0..7, and Precode is 0/1.
>
> These are board-specific signal-integrity tuning values. They depend on
> channel SI/PHY characterization and validation (host PHY, device PHY,
> package, and board routing), and are determined by HW/PHY designers.
>
> Although UFSHCI v5.0 supports TX Equalization Training via UniPro v3.0,
> which allows host software to determine optimal TX Equalization at
> runtime, static board-specific TX Equalization settings in the Device
> Tree are still necessary because:
> - TX Equalization Training is not supported for HS-G3 and below
> - TX Equalization Training is disabled on some platforms
>
> Signed-off-by: Can Guo <can.guo@oss.qualcomm.com>
> ---
> .../devicetree/bindings/ufs/ufs-common.yaml | 58 +++++++++++++++++++
> 1 file changed, 58 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 7/8] dt-bindings: display: allwinner: Split H616 DE33 layer reg space
From: Krzysztof Kozlowski @ 2026-06-16 3:51 UTC (permalink / raw)
To: Jernej Škrabec, wens
Cc: samuel, mripard, maarten.lankhorst, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt, mturquette, sboyd, dri-devel, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel, linux-clk
In-Reply-To: <0r4us4OeRRWtJhxvps-bZw@gmail.com>
On 15/06/2026 17:47, Jernej Škrabec wrote:
> Dne ponedeljek, 15. junij 2026 ob 06:28:54 Srednjeevropski poletni čas je Krzysztof Kozlowski napisal(a):
>> On 14/06/2026 16:08, Jernej Škrabec wrote:
>>> Dne ponedeljek, 25. maj 2026 ob 14:10:38 Srednjeevropski poletni čas je Krzysztof Kozlowski napisal(a):
>>>> On 24/05/2026 23:33, Chen-Yu Tsai wrote:
>>>>> Hi,
>>>>>
>>>>> (resent from new email)
>>>>>
>>>>> On Thu, May 14, 2026 at 2:04 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>>>>
>>>>>> On Sat, May 09, 2026 at 09:00:14PM +0200, Jernej Skrabec wrote:
>>>>>>> From: Jernej Skrabec <jernej.skrabec@gmail.com>
>>>>>>>
>>>>>>> As it turns out, current H616 DE33 binding was written based on
>>>>>>> incomplete understanding of DE33 design. Namely, planes are shared
>>>>>>> resource and not tied to specific mixer, which was the case for previous
>>>>>>> generations of Display Engine (DE3 and earlier).
>>>>>>>
>>>>>>> This means that current DE33 binding doesn't properly reflect HW and
>>>>>>> using it would mean that second mixer (used for second display output)
>>>>>>> can't be supported.
>>>>>>>
>>>>>>> Remove layer register space, which will be represented with additional
>>>>>>> node, and replace it with phandle, which will point to that new, shared
>>>>>>> node. That way, all mixers can share same layers.
>>>>>>>
>>>>>>> There is no user of this binding yet, so changes can be made safely,
>>>>>>> without breaking any backward compatibility.
>>>>>>
>>>>>> There is user. git grep gives me:
>>>>>> drivers/gpu/drm/sun4i/sun8i_mixer.c
>>>>>>
>>>>>> which means this is a released ABI. As I understood, the old code was
>>>>>
>>>>> We held off on merging the DT changes so that we could rework this.
>>>>> I can't find the actual request though. It was probably over IRC.
>>>>>
>>>>>> working fine but just did not support all use cases. Why this cannot be
>>>>>> kept backwards compatible?
>>>>>
>>>>> AFAIK the "planes" block is shared between two display mixers. As the
>>>>> commit message explains, this prevents using the second mixer, since
>>>>> only one of them can claim and map the register space. And on the H700
>>>>> (which is the same die as the H616 discussed here but with more exposed
>>>>> interfaces), there could actually be a use case for the second mixer.
>>>>
>>>> It explains why you want to make the changes but not why you cannot keep
>>>> it backwards compatible.
>>>
>>> I guess it can be backward compatible, but I don't think it makes sense.
>>> Yes, original driver implemented original DT bindings, but there is no node
>>> which uses that binding. If there is no user of that, why would driver
>>
>> Did you check all out of tree users of the ABI? All vendor kernels,
>> forks and all of them for which the ABI was made for?
>
> Since when do we care about out of tree users? I understand that drivers
Since always? That is the meaning of ABI. Otherwise there is no point to
discuss ABI at all. Why would it exist if you had all DTS inside kernel
always matching the code?
> must support old device tree files. Once they work, compatibility must
> be carried forward. But that's not the case here.
>
> In any case, vendor kernels have completely different DT structure. This
> was developed independently from them. Take a look at [1] how BSP DT looks
> like, specifically Display Engine node.
>
> Of course there are some distros which grab WIP patches from mailing lists
> soon after they are available. For example, I know that Armbian carried old
> WIP patches which used old ABI. However, such distros generally don't care
> about exact solution and ditch patches as soon as proper solution is merged
> upstream or even when better WIP patches come around. DT files in such
> distros get updated alongside kernel, they are not hidden in firmware.
>
I am not talking about BSP. I am talking about out of tree users for
which we defined the ABI and called it that way.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: install DT overlays via dtbs_install
From: Krzysztof Kozlowski @ 2026-06-16 3:49 UTC (permalink / raw)
To: Vishwas Udupa
Cc: andersson, conor+dt, devicetree, kbajaj, konradybcio, krzk+dt,
linux-arm-msm, robh, snb, vudupa
In-Reply-To: <20260615162739.787779-1-vishwas.udupa@oss.qualcomm.com>
On 15/06/2026 18:27, Vishwas Udupa wrote:
> EL2 DTBOs are used at build time to construct DTBs corresponding to
> an EL2 (hypervisor-enabled) boot configuration. These DTBs are included in
> distributions [1] as complete boot configurations (e.g. EL1 and EL2).
>
> The EL2 configuration is not enabled by default and is typically selected
> after the initial boot by updating a UEFI runtime variable from userspace.
> Once set, firmware selects the prebuilt EL2 DTB on subsequent boots.
>
> Although EL2 DTBOs are not used directly at runtime during initial boot,
> they are required to generate and package the EL2 DTBs in the image so that
> firmware can switch to EL2 when the configuration variable is enabled. Hence, el2 dtbo's
> need to be retained.
>
> 1: https://github.com/qualcomm-linux/qcom-dtb-metadata/blob/main/qcom-next-fitimage.its#L273
You cut entire context making any discussion very difficult.
Anyway, comment stays. EL2 is not an overlay. If I need to repeat
myself, then let's do like:
NAK
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/2] dt-bindings: pinctrl: aspeed,ast2700-soc1: Add JTAGM1TRST group
From: Billy Tsai @ 2026-06-16 3:30 UTC (permalink / raw)
To: Andrew Jeffery, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley
Cc: linux-aspeed, openbmc, linux-gpio, devicetree, linux-arm-kernel,
linux-kernel, Billy Tsai
In-Reply-To: <20260616-pinctrl-fix-v1-0-621036e45c7c@aspeedtech.com>
The TRST signal of the JTAG master is optional and may not be wired on
every design, but it is only selectable as part of the JTAGM1 group,
which forces the D12 ball to be muxed whenever the JTAG master is used.
Add a separate JTAGM1TRST group so boards can enable TRST independently
of the other JTAG master signals.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
---
.../devicetree/bindings/pinctrl/aspeed,ast2700-soc1-pinctrl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2700-soc1-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2700-soc1-pinctrl.yaml
index 76944fd14e2c..fe7cef4fef6a 100644
--- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2700-soc1-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2700-soc1-pinctrl.yaml
@@ -356,6 +356,7 @@ patternProperties:
- I3C8
- I3C9
- JTAGM1
+ - JTAGM1TRST
- LPC0
- LPC1
- LTPI
--
2.34.1
^ permalink raw reply related
* [PATCH 2/2] pinctrl: aspeed: Split TRST out of the AST2700 SoC1 JTAGM1 group
From: Billy Tsai @ 2026-06-16 3:30 UTC (permalink / raw)
To: Andrew Jeffery, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley
Cc: linux-aspeed, openbmc, linux-gpio, devicetree, linux-arm-kernel,
linux-kernel, Billy Tsai
In-Reply-To: <20260616-pinctrl-fix-v1-0-621036e45c7c@aspeedtech.com>
The JTAGM1 group includes the D12 ball carrying the TRST signal, but
TRST is optional for a JTAG master and the ball may be needed for other
functions on designs that do not wire it. With TRST embedded in the
group, such designs cannot use the JTAG master at all.
Move D12 into a new JTAGM1TRST group under the same JTAGM1 function so
TRST is muxed only when a board requests it. Boards that do use TRST
now need to select both the JTAGM1 and JTAGM1TRST groups.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
---
drivers/pinctrl/aspeed/pinctrl-aspeed-g7-soc1.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g7-soc1.c b/drivers/pinctrl/aspeed/pinctrl-aspeed-g7-soc1.c
index 50027d69c342..f8b4066699ce 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g7-soc1.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g7-soc1.c
@@ -1018,7 +1018,8 @@ PIN_GROUP(I3C6, AA22, AB20);
PIN_GROUP(I3C7, AF18, AE19);
PIN_GROUP(I3C8, AD20, AC20);
PIN_GROUP(I3C9, AA21, AB21);
-PIN_GROUP(JTAGM1, D12, F10, E11, F11, F13);
+PIN_GROUP(JTAGM1, F10, E11, F11, F13);
+PIN_GROUP(JTAGM1TRST, D12);
PIN_GROUP(LPC0, AF26, AF25, B16, D14, B15, B14, C17, B13, E14, C15);
PIN_GROUP(LPC1, C16, C14, C11, D9, F14, D10, C12, C13, AE16, AE17);
PIN_GROUP(LTPI, U25, U26, Y26, AA24);
@@ -1263,6 +1264,7 @@ static const struct pingroup aspeed_g7_soc1_groups[] = {
GROUP(I3C8),
GROUP(I3C9),
GROUP(JTAGM1),
+ GROUP(JTAGM1TRST),
GROUP(LPC0),
GROUP(LPC1),
GROUP(LTPI),
@@ -1528,7 +1530,7 @@ static const struct aspeed_g7_soc1_function aspeed_g7_soc1_functions[] = {
FUNC(I3C7, (1), "I3C7"),
FUNC(I3C8, (1), "I3C8"),
FUNC(I3C9, (1), "I3C9"),
- FUNC(JTAGM1, (1), "JTAGM1"),
+ FUNC(JTAGM1, (1, 1), "JTAGM1", "JTAGM1TRST"),
FUNC(LPC0, (2), "LPC0"),
FUNC(LPC1, (2), "LPC1"),
FUNC(LTPI, (2), "LTPI"),
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] pinctrl: aspeed: Make AST2700 SoC1 JTAG master TRST optional
From: Billy Tsai @ 2026-06-16 3:30 UTC (permalink / raw)
To: Andrew Jeffery, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley
Cc: linux-aspeed, openbmc, linux-gpio, devicetree, linux-arm-kernel,
linux-kernel, Billy Tsai
The JTAGM1 pin group of the AST2700 SoC1 includes ball D12, which
carries the TRST signal. TRST is an optional signal for a JTAG master:
designs that do not wire it may need the D12 ball for other functions,
but with TRST embedded in the group they cannot use the JTAG master at
all.
Split D12 into a new JTAGM1TRST group under the existing JTAGM1
function, so TRST is only muxed when a board explicitly requests it.
Patch 1 adds the new group to the device tree binding and patch 2
splits the group in the driver.
Note that this changes the meaning of the existing JTAGM1 group: boards
that do use TRST now need to select both the JTAGM1 and JTAGM1TRST
groups.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
---
Billy Tsai (2):
dt-bindings: pinctrl: aspeed,ast2700-soc1: Add JTAGM1TRST group
pinctrl: aspeed: Split TRST out of the AST2700 SoC1 JTAGM1 group
.../devicetree/bindings/pinctrl/aspeed,ast2700-soc1-pinctrl.yaml | 1 +
drivers/pinctrl/aspeed/pinctrl-aspeed-g7-soc1.c | 6 ++++--
2 files changed, 5 insertions(+), 2 deletions(-)
---
base-commit: 761af93c9f1a100b8d9f71aa744b8f9abbbbbfb2
change-id: 20260612-pinctrl-fix-1c1e7c37261c
Best regards,
--
Billy Tsai <billy_tsai@aspeedtech.com>
^ permalink raw reply
* Re: [PATCH 1/2] power: sequencing: pcie-m2: Add PCI ID 0x1103 for WCN6855 Bluetooth
From: Wei Deng @ 2026-06-16 3:03 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Manivannan Sadhasivam, Bartosz Golaszewski,
linux-arm-msm, devicetree, linux-kernel, linux-pci, linux-pm,
quic_chezhou, cheng.jiang, shuai.zhang, jinwang.li, xiuzhuo.shang,
mengshi.wu
In-Reply-To: <hndyeomouu754rwevoigc2ai4ywtz5lhodizj4amjuyn4azjhq@f6ixgilydtg2>
Hi Dmitry,
On Tue, Jun 16, 2026 at 03:26:40AM +0300, Dmitry Baryshkov wrote:
> On Mon, Jun 08, 2026 at 02:47:01PM +0530, Wei Deng wrote:
>> WCN6855 is a Qualcomm Wi-Fi/BT combo chip that uses PCI device ID
>> 0x1103. Add it to pwrseq_m2_pci_ids[] alongside the existing 0x1107
>> (WCN7850) entry, so that the pwrseq-pcie-m2 driver creates a Bluetooth
>> serdev device for WCN6855 cards inserted into PCIe M.2 Key E connectors.
>>
>> Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
>> ---
>> drivers/power/sequencing/pwrseq-pcie-m2.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/power/sequencing/pwrseq-pcie-m2.c b/drivers/power/sequencing/pwrseq-pcie-m2.c
>> index efeb25ba9c79..b3af14464314 100644
>> --- a/drivers/power/sequencing/pwrseq-pcie-m2.c
>> +++ b/drivers/power/sequencing/pwrseq-pcie-m2.c
>> @@ -188,6 +188,8 @@ static int pwrseq_pcie_m2_match(struct pwrseq_device *pwrseq,
>> static const struct pci_device_id pwrseq_m2_pci_ids[] = {
>> { PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x1107),
>> .driver_data = (kernel_ulong_t)"qcom,wcn7850-bt" },
>> + { PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x1103),
>> + .driver_data = (kernel_ulong_t)"qcom,wcn6855-bt" },
>> { } /* Sentinel */
>
> Please keep the list sorted. I saw that Bartosz has applied the patch.
> Would you please send a followup?
Thanks for the feedback. I have sent a followup patch to sort the list:
<20260616025632.3697863-1-wei.deng@oss.qualcomm.com>
>> };
>>
>> --
>> 2.34.1
>>
--
Best Regards,
Wei Deng
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: lemans-evk: Describe the PCIe M.2 Key E connector
From: Wei Deng @ 2026-06-16 3:00 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: andersson, konradybcio, robh, krzk+dt, conor+dt, linux-arm-msm,
devicetree, linux-kernel, manivannan.sadhasivam,
bartosz.golaszewski, quic_chezhou, cheng.jiang, shuai.zhang,
jinwang.li, xiuzhuo.shang, mengshi.wu
In-Reply-To: <tspehw7yb6hrgek7rz6qghcoqr4v6cdpulbzpggii6qlmaatxk@gcb2tbb3qji2>
Hi Dmitry,
On Tue, Jun 16, 2026 at 03:28:11AM +0300, Dmitry Baryshkov wrote:
> On Mon, Jun 15, 2026 at 04:02:28PM +0530, Wei Deng wrote:
>> The lemans EVK has the PCIe M.2 Mechanical Key E connector to connect
>> wireless connectivity cards over PCIe and UART interfaces. Hence,
>> describe the connector node and link it with the PCIe 0 Root Port and
>> UART17 nodes through graph port/endpoint.
>>
>> Also add 'compatible = "pciclass,0604"' to the pcieport0 node in
>> lemans.dtsi to allow the PCI subsystem to associate the DT node with
>> the PCI-to-PCI bridge device.
>>
>> The M.2 Key E connector is powered by a 3.3V fixed regulator
>> (vreg_wcn_3p3) which is sourced from the board's 12V DC input rail
>> (vreg_dcin_12v). Both regulators are always-on and are required by the
>> pcie-m2-e-connector binding.
>>
>> Also add the serial1 = &uart17 alias, which is required for the
>> Bluetooth serdev device to be enumerated on the UART17 interface.
>>
>> Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
>> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>> ---
>> Changes in v2:
>> - Collected Reviewed-by tag and reorganized the patch
>
> Please don't send the patches as replies to the previous iterations.
> Each new revision should be in a separate thread.
Thanks for the feedback. I will make sure to start a new thread for
each new revision going forward.
>>
>> Link: https://lore.kernel.org/linux-arm-msm/20260608091702.3797437-2-wei.deng@oss.qualcomm.com/ [v1]
>>
>> arch/arm64/boot/dts/qcom/lemans-evk.dts | 75 +++++++++++++++++++++++++
>> arch/arm64/boot/dts/qcom/lemans.dtsi | 1 +
>> 2 files changed, 76 insertions(+)
>>
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>
>
> --
> With best wishes
> Dmitry
--
Best Regards,
Wei Deng
^ permalink raw reply
* RE: [PATCH v6 1/3] dt-bindings: imx6q-pcie: Add optional intr/aer/pme interrupts for i.MX95
From: Hongxing Zhu @ 2026-06-16 2:56 UTC (permalink / raw)
To: Rob Herring, Hongxing Zhu (OSS)
Cc: krzk+dt@kernel.org, conor+dt@kernel.org, bhelgaas@google.com,
Frank Li, l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-kernel@vger.kernel.org
In-Reply-To: <20260612151348.GA1040341-robh@kernel.org>
> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: Friday, June 12, 2026 11:14 PM
> To: Hongxing Zhu (OSS) <hongxing.zhu@oss.nxp.com>
> Cc: krzk+dt@kernel.org; conor+dt@kernel.org; bhelgaas@google.com; Frank Li
> <frank.li@nxp.com>; l.stach@pengutronix.de; lpieralisi@kernel.org;
> kwilczynski@kernel.org; mani@kernel.org; s.hauer@pengutronix.de;
> kernel@pengutronix.de; festevam@gmail.com; linux-pci@vger.kernel.org; linux-
> arm-kernel@lists.infradead.org; devicetree@vger.kernel.org;
> imx@lists.linux.dev; linux-kernel@vger.kernel.org; Hongxing Zhu
> <hongxing.zhu@nxp.com>
> Subject: Re: [PATCH v6 1/3] dt-bindings: imx6q-pcie: Add optional intr/aer/pme
> interrupts for i.MX95
>
> On Wed, Jun 03, 2026 at 02:25:08PM +0800, hongxing.zhu@oss.nxp.com wrote:
> > From: Richard Zhu <hongxing.zhu@nxp.com>
> >
> > The i.MX95 PCIe controller introduces three additional dedicated
> > hardware interrupt lines for specific events:
> > - intr: general controller events
> > - aer: Advanced Error Reporting events
> > - pme: Power Management Events
> >
> > These interrupts are optional on i.MX95. PCIe basic functionality
> > (enumeration, configuration, and data transfer) works correctly
> > without them, as the controller can operate using only the existing msi
> interrupt.
> >
> > Earlier i.MX PCIe variants (imx6q, imx6sx, imx6qp, imx7d, imx8mm,
> > imx8mp, imx8mq, imx8q) do not have these three dedicated interrupt lines.
> >
> > Update the binding to allow up to 5 interrupts for i.MX95, while
> > restricting earlier variants to a maximum of 2 interrupts using
> > conditional constraints (if/then schema). This ensures the schema
> > accurately reflects the hardware capabilities of each SoC variant.
> >
> > Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> > Reviewed-by: Frank Li <Frank.Li@nxp.com>
> > ---
> > .../bindings/pci/fsl,imx6q-pcie.yaml | 29 +++++++++++++++++++
> > 1 file changed, 29 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > index e8b8131f5f23..9b5d4e59dfff 100644
> > --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> > @@ -58,12 +58,18 @@ properties:
> > items:
> > - description: builtin MSI controller.
> > - description: builtin DMA controller.
> > + - description: PCIe event interrupt.
> > + - description: builtin AER SPI standalone interrupt line.
> > + - description: builtin PME SPI standalone interrupt line.
> >
> > interrupt-names:
> > minItems: 1
> > items:
> > - const: msi
> > - const: dma
> > + - const: intr
> > + - const: aer
> > + - const: pme
> >
> > reset-gpio:
> > deprecated: true
> > @@ -248,6 +254,29 @@ allOf:
> > - const: pcie_aux
> > - const: ref
> > - const: extref # Optional
> > + interrupts:
> > + maxItems: 5
> > + interrupt-names:
> > + maxItems: 5
>
> 5 is already the max.
Thank you for the review.
You're correct. These maxItems constraints are redundant and will be removed
later.
Best Regards
Richard Zhu
>
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + enum:
> > + - fsl,imx6q-pcie
> > + - fsl,imx6sx-pcie
> > + - fsl,imx6qp-pcie
> > + - fsl,imx7d-pcie
> > + - fsl,imx8mm-pcie
> > + - fsl,imx8mp-pcie
> > + - fsl,imx8mq-pcie
> > + - fsl,imx8q-pcie
> > + then:
> > + properties:
> > + interrupts:
> > + maxItems: 2
> > + interrupt-names:
> > + maxItems: 2
> >
> > unevaluatedProperties: false
> >
> > --
> > 2.34.1
> >
^ permalink raw reply
* Re: [PATCH RFC 1/2] dt-bindings: pinctl: amlogic,pinctrl-a4: Add gpio irq property
From: Xianwei Zhao @ 2026-06-16 2:56 UTC (permalink / raw)
To: Conor Dooley
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-amlogic, linux-gpio, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260615-ultra-pagan-84de490070e1@spud>
Hi Conor,
Thanks for your detailed review. I will drop this patch.
On 2026/6/16 00:52, Conor Dooley wrote:
> Subject:
> Re: [PATCH RFC 1/2] dt-bindings: pinctl: amlogic,pinctrl-a4: Add gpio
> irq property
> From:
> Conor Dooley <conor@kernel.org>
> Date:
> 2026/6/16 00:52
>
> To:
> xianwei.zhao@amlogic.com
> CC:
> Linus Walleij <linusw@kernel.org>, Rob Herring <robh@kernel.org>,
> Krzysztof Kozlowski <krzk+dt@kernel.org>, Conor Dooley
> <conor+dt@kernel.org>, Neil Armstrong <neil.armstrong@linaro.org>, Kevin
> Hilman <khilman@baylibre.com>, Jerome Brunet <jbrunet@baylibre.com>,
> Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
> linux-amlogic@lists.infradead.org, linux-gpio@vger.kernel.org,
> devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
> linux-arm-kernel@lists.infradead.org
>
>
> Given Linus' comments on the cover letter,
> pw-bot: changes-requested
>
> Thanks,
> Conor.
^ permalink raw reply
* Re: [PATCH RFC 1/2] dt-bindings: pinctl: amlogic,pinctrl-a4: Add gpio irq property
From: Xianwei Zhao @ 2026-06-16 2:54 UTC (permalink / raw)
To: Krzysztof Kozlowski, Conor Dooley
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-amlogic, linux-gpio, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <542ec217-1187-4fb2-8fd3-b90a6143b84d@kernel.org>
Hi Krzysztof,
Thanks for your detailed review. After considering the feedback, I
think this approach is not suitable, so I will drop this patch.
On 2026/6/15 13:32, Krzysztof Kozlowski wrote:
> On 15/06/2026 04:47, Xianwei Zhao wrote:
>> Hi Conor,
>> Thanks for your review.
>>
>> On 2026/6/12 01:39, Conor Dooley wrote:
>>> Subject:
>>> Re: [PATCH RFC 1/2] dt-bindings: pinctl: amlogic,pinctrl-a4: Add gpio
>>> irq property
>>> From:
>>> Conor Dooley<conor@kernel.org>
>>> Date:
>>> 2026/6/12 01:39
>>>
>>> To:
>>> xianwei.zhao@amlogic.com
>>> CC:
>>> Linus Walleij<linusw@kernel.org>, Rob Herring<robh@kernel.org>,
>>> Krzysztof Kozlowski<krzk+dt@kernel.org>, Conor Dooley
>>> <conor+dt@kernel.org>, Neil Armstrong<neil.armstrong@linaro.org>, Kevin
>>> Hilman<khilman@baylibre.com>, Jerome Brunet<jbrunet@baylibre.com>,
>>> Martin Blumenstingl<martin.blumenstingl@googlemail.com>,
>>> linux-amlogic@lists.infradead.org,linux-gpio@vger.kernel.org,
>>> devicetree@vger.kernel.org,linux-kernel@vger.kernel.org,
>>> linux-arm-kernel@lists.infradead.org
>>>
>>>
>>>
>>> On Thu, Jun 11, 2026 at 07:54:33AM +0000, Xianwei Zhao via B4 Relay wrote:
>>>> From: Xianwei Zhao<xianwei.zhao@amlogic.com>
>>>>
>>>> Add the hw-irq property for each GPIO bank and enable interrupt-parent
>>>> for pinctrl so that gpiod_to_irq() can translate GPIO lines to IRQs.
>>> Uhhhhh, what? Why can't you just use the normal interrupts property?
>>>
>> The interrupt cannot be used directly because the GPIO bank only
>> provides an IRQ base, which does not have a one-to-one mapping with the
>> actual hardware interrupts.
>>
>> On Amlogic SoCs, GPIO interrupts are handled through a mux. Multiple
>> GPIO pins are mapped to a limited number of real interrupt sources. The
>> implementation can be found here:
>>
>> https://github.com/torvalds/linux/blob/master/drivers/irqchip/irq-meson-gpio.c
>>
>> To use a GPIO interrupt, an unused hardware interrupt must first be
>> allocated, and then the corresponding mux register must be configured.
>> This allocation and mapping are already implemented in the existing driver.
>>
>> In that driver, the mapping is performed dynamically rather than simply
>> calculating:
>>
>> irq = irq_start + gpio_offset
>>
>> If the interrupt is used directly, only the GPIO index can be obtained.
>
> If it is performed dynamically, then it is not suitable for DT.
>
> You still did not explain what hardware aspect exactly is described by
> "hw-irq".
>
>
>
>> The real interrupt number cannot be derived by simply adding an offset,
>> because the hardware interrupt must be allocated first. Pre-allocating
>> all interrupts during initialization would prevent later GPIOs from
>> obtaining available interrupt sources.
>>
>> Perhaps other names would be more appropriate here, such as "irq_start".
>>
>>>> Signed-off-by: Xianwei Zhao<xianwei.zhao@amlogic.com>
>>>> ---
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH RFC 0/2] pinctrl: Add support gpiod_to_irq
From: Xianwei Zhao @ 2026-06-16 2:45 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, linux-amlogic,
linux-gpio, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <CAD++jLm9+8RSbBCi-k=8S98XvVJ7taYrK=kuBp3_RqxE_bcxbg@mail.gmail.com>
Hi Linus,
Understood. Thank you for your detailed explanation. I will drop
this patch.
On 2026/6/15 20:59, Linus Walleij wrote:
>>> Hi Xianwei,
>>>
>>> thanks for your patches!
>>>
>>> On Thu, Jun 11, 2026 at 9:54 AM Xianwei Zhao via B4 Relay
>>> <devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
>>>
>>>> Some users need to obtain an IRQ directly from a GPIO descriptor through gpiod_to_irq().
>>>> Add the required DT binding and implementation to support this use case.
>>>> Since this introduces a new DT property, the property is kept optional to
>>>> maintain compatibility with existing SoCs and DTS files.
>>> To me it looks like you have just re-implemented hierarchical
>>> irqs.
>>>
>>> Look into the section "Infrastructure helpers for GPIO irqchips"
>>> in Documentation/driver-api/gpio/driver.rst, especially towards
>>> the end.
>>>
>>> Solve this by using GPIOLIB_IRQCHIP and a custom
>>> child_to_parent_hwirq() callback to translate the GPIO into
>>> an IRQ.
>>>
>>> To just implement gpiod_to_irq() without any irqchip abstraction
>>> is also broken: you can't force all users to just use this way
>>> to get an IRQ it's excessively restricting.
>>>
>>> Add
>>>
>>> interrupt-controller: true
>>>
>>> "#interrupt-cells":
>>> const: 2
>>>
>>> to the pinctrl node as well so that DT users can simply request
>>> the IRQ from the irqchip inside of the pin controller. It will
>>> be hierarchical and lightweight but an irqchip nevertheless.
>>>
>>> The GPIOLIB_IRQCHIP approach will help you to get this
>>> right.
>>>
>> I read the document (Documentation/driver-api/gpio/driver.rst) you
>> pointed me to and found that the corresponding implementation has
>> already been added in this file:
>>
>> https://github.com/torvalds/linux/blob/master/drivers/irqchip/irq-meson-gpio.c
> That is the parent interrupt controller to the pinctrl+gpio isn't it.
>
> It will be even clearer once you use interrupts = <>; instead of
> the hwirq = <>; hack.
>
>> However, it is implemented as a standalone irqchip and is not integrated
>> with the GPIO controller.
> Right, so it is the parent. Of course it it stand alone.
>
>> In this patch, I implemented the GPIO-to-IRQ conversion through
>> gpiod_to_irq(). Users can still obtain the interrupt directly through
>> the interrupt property, for example:
>>
>> interrupts-extended = <&gpio_intc 16 1>;
>>
>> The purpose of this change is to make GPIO-to-IRQ conversion easier for
>> users who do not want to know the actual interrupt number. The interrupt
>> mapping is not fixed and varies between different SoCs, so users should
>> not need to handle the hardware interrupt allocation details.
> This is not why gpiod_to_irq() exists. It is not a convenience function
> that is voluntary to implement.
>
> If you implement gpiod_to_irq() you implement an entire
> irqchip otherwise it is a bug.
>
> If the pin control + GPIO driver should serve IRQ numbers in any
> shape or form, you need to go the whole way and provide a
> hierarchical irqchip.
>
> It doesn't matter if you don't need to set a single bit in the
> pinctrl + GPIO hardware for these IRQs, the fact that they are
> routed internally on the SoC out through the pin control and
> GPIO block by definition makes it hierarchical.
>
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: (subset) [PATCH v3 0/3] Add Hawi UFS PHY and Controller support
From: Martin K. Petersen @ 2026-06-16 2:26 UTC (permalink / raw)
To: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, mani, alim.akhtar,
bvanassche, andersson, dmitry.baryshkov, abel.vesa, luca.weiss,
palash.kambar
Cc: Martin K . Petersen, linux-arm-msm, linux-phy, devicetree,
linux-kernel, linux-scsi, nitin.rawat
In-Reply-To: <20260526090956.2340262-1-palash.kambar@oss.qualcomm.com>
On Tue, 26 May 2026 14:39:53 +0530, palash.kambar@oss.qualcomm.com wrote:
> This series introduces devicetree binding documentation and PHY
> initialization support required to enable UFS on this platform.
>
> 1. Devicetree binding documentation for the QMP UFS PHY
> used on Qualcomm Hawi.
> 2. Devicetree binding documentation for the UFS controller
> instance present on the Hawi platform.
> 3. Initialization sequence tables and configuration required
> for the QMP UFS PHY on Hawi SoC.
>
> [...]
Applied to 7.2/scsi-queue, thanks!
[2/3] scsi: ufs: qcom: dt-bindings: Document the Hawi UFS controller
https://git.kernel.org/mkp/scsi/c/63977ab3c6a0
--
Martin K. Petersen
^ permalink raw reply
* Re: [PATCH v5 09/16] media: iris: Add framework support for AR50_LITE video core
From: sashiko-bot @ 2026-06-16 2:17 UTC (permalink / raw)
To: Dmitry Baryshkov; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260616-iris-ar50lt-v5-9-583b42770b6a@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
Pre-existing issues:
- [High] pm_runtime_get_sync() leaks usage count on failure in iris_enable_power_domains().
- [High] iris_disable_power_domains() bails early on OPP failure, bypassing pm_runtime_put_sync() and leaking the PM reference.
- [High] 32-bit multiplication in VPU frequency calculations silently overflows, leading to drastic underclocking at high resolutions/framerates.
- [High] The function `iris_vpu_boot_firmware()` returns success (0) even when it detects a firmware boot error.
--
commit 7269410ec2faaa10691a53dc0ab6c6efcc23fc3e
Author: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
media: iris: Add framework support for AR50_LITE video core
Add power sequence for ar5lt core. Add register handling for ar50lt by
hooking up vpu op with ar50lt specific implemtation or resue from earlier
generation wherever feasible.
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_ar50lt.c b/drivers/media/platform/qcom/iris/iris_vpu_ar50lt.c
> new file mode 100644
> index 0000000000000..e084a5b49f2e3
> --- /dev/null
> +++ b/drivers/media/platform/qcom/iris/iris_vpu_ar50lt.c
[ ... ]
> +static int iris_vpu_ar50lt_power_on_controller(struct iris_core *core)
> +{
> + int ret;
> +
> + ret = iris_enable_power_domains(core, core->pmdomain_tbl->pd_devs[IRIS_CTRL_POWER_DOMAIN]);
[Severity: High]
This isn't a bug introduced by this patch, but do iris_enable_power_domains()
and iris_disable_power_domains() leak runtime PM references on failure?
In drivers/media/platform/qcom/iris/iris_resources.c,
iris_enable_power_domains() calls:
ret = pm_runtime_get_sync(pd_dev);
if (ret < 0)
return ret;
If the resume fails, it returns a negative error code but leaves the usage
count incremented without calling pm_runtime_put_noidle().
Similarly, iris_disable_power_domains() has an early return that bypasses
pm_runtime_put_sync():
ret = iris_opp_set_rate(core->dev, 0);
if (ret)
return ret;
pm_runtime_put_sync(pd_dev);
If iris_opp_set_rate() fails, the pm_runtime_put_sync() call is skipped,
permanently leaking the runtime PM reference and leaving the power domain
active.
[ ... ]
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_common.c b/drivers/media/platform/qcom/iris/iris_vpu_common.c
> index 41498f94480e8..d64e7745a63dc 100644
> --- a/drivers/media/platform/qcom/iris/iris_vpu_common.c
> +++ b/drivers/media/platform/qcom/iris/iris_vpu_common.c
> @@ -97,7 +97,8 @@ int iris_vpu_boot_firmware(struct iris_core *core)
> }
>
> writel(HOST2XTENSA_INTR_ENABLE, core->reg_base + CPU_CS_H2XSOFTINTEN);
> - writel(0x0, core->reg_base + CPU_CS_X2RPMH);
> + if (!core->iris_platform_data->no_rpmh)
> + writel(0x0, core->reg_base + CPU_CS_X2RPMH);
>
> return 0;
> }
[Severity: High]
This isn't a bug introduced by this patch, but does iris_vpu_boot_firmware()
return success even when it detects a firmware boot error?
Earlier in this function:
if ((ctrl_status & CTRL_ERROR_STATUS__M) == 0x4) {
dev_err(core->dev, "invalid setting for uc_region\n");
break;
}
Because the loop is exited early via break, the count does not reach
max_tries. This skips the subsequent timeout check (if (count >= max_tries)),
and the function incorrectly falls through to return 0.
Could this cause the caller to proceed assuming the firmware booted correctly,
leading to undefined behavior and hardware timeouts later?
[ ... ]
> @@ -422,6 +423,32 @@ void iris_vpu35_vpu4x_program_bootup_registers(struct iris_core *core)
> writel(0x1, core->reg_base + WRAPPER_IRIS_VCODEC_VPU_WRAPPER_SPARE_0);
> }
>
> +u64 iris_vpu2_calculate_frequency(struct iris_inst *inst, size_t data_size)
> +{
> + struct platform_inst_caps *caps = inst->core->iris_platform_data->inst_caps;
> + struct v4l2_format *inp_f = inst->fmt_src;
> + u32 mbs_per_second, mbpf, height, width;
> + unsigned long vpp_freq, vsp_freq;
> + u32 fps = inst->frame_rate;
> +
> + width = max(inp_f->fmt.pix_mp.width, inst->crop.width);
> + height = max(inp_f->fmt.pix_mp.height, inst->crop.height);
> +
> + mbpf = NUM_MBS_PER_FRAME(height, width);
> + mbs_per_second = mbpf * fps;
> +
> + vpp_freq = mbs_per_second * caps->mb_cycles_vpp;
[Severity: High]
This is a pre-existing issue, but does this 32-bit multiplication silently
overflow before assignment?
Both mbs_per_second and caps->mb_cycles_vpp are u32. For high resolutions
and framerates (like 8K at 240+ FPS), mbs_per_second can reach ~33M and
mb_cycles_vpp is ~200. This results in a product greater than 6.6 billion,
exceeding the u32 maximum.
The value wraps around before being cast to unsigned long, which might cause
the requested clock frequency to be set drastically lower than required.
The same multiplication overflow also exists in
iris_vpu3x_vpu4x_calculate_frequency() where mult_frac() internally executes a
u32 * u32 operation.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-iris-ar50lt-v5-0-583b42770b6a@oss.qualcomm.com?part=9
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: display: tegra: Changes to support Tegra264
From: Mikko Perttunen @ 2026-06-16 2:00 UTC (permalink / raw)
To: Conor Dooley
Cc: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-tegra, dri-devel,
devicetree, linux-kernel
In-Reply-To: <20260612-iphone-racing-c2f1934f3cf1@spud>
On Saturday, June 13, 2026 1:16 AM Conor Dooley wrote:
> On Fri, Jun 12, 2026 at 03:32:29PM +0900, Mikko Perttunen wrote:
> > Add nvidia,tegra264-host1x compatible string. The Tegra264 host1x is
> > similar to Tegra234, but with a different set of engines and layout.
> >
> > The engine register range is no longer continuous, so two range entries
> > are also needed.
>
> Please restrict the new ranges of 2 to only the new device.
Thank you, will fix.
Mikko
> pw-bot: changes-requested
>
>
> Thanks,
> Conor.
>
> >
> > Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> > ---
> > .../devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> > index 3563378a01af..5b0e3158aa5b 100644
> > --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> > +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> > @@ -25,6 +25,7 @@ properties:
> > - nvidia,tegra186-host1x
> > - nvidia,tegra194-host1x
> > - nvidia,tegra234-host1x
> > + - nvidia,tegra264-host1x
> >
> > - items:
> > - const: nvidia,tegra132-host1x
> > @@ -57,7 +58,8 @@ properties:
> > enum: [1, 2]
> >
> > ranges:
> > - maxItems: 1
> > + minItems: 1
> > + maxItems: 2
> >
> > clocks:
> > description: Must contain one entry, for the module clock. See
> > @@ -192,6 +194,7 @@ allOf:
> > contains:
> > enum:
> > - nvidia,tegra234-host1x
> > + - nvidia,tegra264-host1x
> > then:
> > properties:
> > reg-names:
> >
> > --
> > 2.53.0
> >
^ permalink raw reply
* Re: [PATCH net-next v5 0/4] net: dsa: mt7628 embedded switch initial support
From: Jakub Kicinski @ 2026-06-16 1:56 UTC (permalink / raw)
To: Joris Vaisvila
Cc: netdev, horms, pabeni, edumazet, davem, olteanv, Andrew Lunn,
devicetree, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Arınç ÜNAL, Landen Chao, DENG Qingfang, Sean Wang,
Daniel Golle
In-Reply-To: <20260613181845.111877-1-joey@tinyisr.com>
On Sat, 13 Jun 2026 21:18:41 +0300 Joris Vaisvila wrote:
> This patch series adds initial support for the MediaTek MT7628 Embedded
> Switch.
>
> The driver implements the basic functionality required to operate the
> switch using DSA. The hardware provides five internal Fast Ethernet user
> ports and one Gigabit port connected internally to the CPU MAC.
net-next has closed, and Linus W is reworking the tagger API in
parallel:
https://lore.kernel.org/all/20260616-dsa-fix-free-skb-v1-1-fd30b35dcf66@kernel.org/
Please repost after the merge window. See
https://netdev.bots.linux.dev/net-next.html
--
pw-bot: defer
^ permalink raw reply
* Re: [PATCH v11 2/2] leds: ltc3220: Add Support for LTC3220 18 channel LED Driver
From: sashiko-bot @ 2026-06-16 1:48 UTC (permalink / raw)
To: Edelweise Escala; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260616-ltc3220-driver-v11-2-6e51dd97ced6@analog.com>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] Typographical error in regmap_config uses an undefined enum value `REGCACHE_FLAT_S`, causing a build failure.
- [High] Aggregated mode (QUICK_WRITE) causes the regmap cache to desynchronize, breaking LEDs during regcache_sync().
- [Medium] regcache_sync() in the resume handler is a no-op because the regmap cache is never marked dirty.
- [Medium] User-provided brightness values in hardware patterns are incorrectly masked instead of clamped, causing wrap-around behavior.
- [Medium] The driver modifies the cached LED state (`uled_cfg->reg_value`) and hardware registers without driver-level synchronization, allowing concurrent operations to permanently desync the software cache from the hardware.
--
commit 531f73073c031952f85d8c75169d6129f992543c
Author: Edelweise Escala <edelweise.escala@analog.com>
leds: ltc3220: Add Support for LTC3220 18 channel LED Driver
Add driver for the LTC3220 18-channel LED driver with I2C interface,
individual brightness control, and hardware-assisted blink/gradation
features.
> diff --git a/drivers/leds/leds-ltc3220.c b/drivers/leds/leds-ltc3220.c
> new file mode 100644
> index 0000000000000..8bb06e50d3c6a
> --- /dev/null
> +++ b/drivers/leds/leds-ltc3220.c
[ ... ]
> +static const struct regmap_config ltc3220_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = LTC3220_GRAD_BLINK_REG,
> + .cache_type = REGCACHE_FLAT_S,
[Severity: High]
Does this cause a build failure?
The correct enum value defined by the kernel is REGCACHE_FLAT, but this uses
an undefined REGCACHE_FLAT_S.
> +};
[ ... ]
> +static int ltc3220_set_led_data(struct led_classdev *led_cdev,
> + enum led_brightness brightness)
> +{
> + struct ltc3220_uled_cfg *uled_cfg = container_of(led_cdev, struct ltc3220_uled_cfg,
> + led_cdev);
> + struct ltc3220 *ltc3220 = container_of(uled_cfg - uled_cfg->led_index, struct ltc3220,
> + uled_cfg[0]);
> + int ret;
> +
> + ret = regmap_write(ltc3220->regmap, LTC3220_ULED_REG(uled_cfg->led_index),
> + brightness);
[Severity: High]
When configured in aggregated mode, the hardware's QUICK_WRITE feature is
enabled, and a single write to LED 0 implicitly updates LEDs 1-17 in
hardware.
However, the driver doesn't update the regmap cache for registers 0x02
through 0x12, leaving them at 0.
When regcache_sync() runs during resume, will it write out the cached 0s and
inadvertently turn off LEDs 1-17?
Should the driver manually sync the cache for these implicitly updated
registers?
> + if (ret)
> + return ret;
> +
> + uled_cfg->reg_value = brightness;
[Severity: Medium]
Since the LED core does not strictly serialize asynchronous triggers against
all callback paths, is this unprotected assignment susceptible to a race
condition?
A concurrent call to ltc3220_set_led_data() or ltc3220_blink_set() could
cause the software reg_value to become permanently desynchronized from the
hardware register state.
Does this need a per-device or per-LED mutex to protect read-modify-write
operations?
> +
> + /*
> + * When aggregated LED mode is enabled, writing to LED 1 updates all
> + * LEDs simultaneously via quick-write mode. Update cached values for
[ ... ]
> +static int ltc3220_pattern_set(struct led_classdev *led_cdev,
> + struct led_pattern *pattern,
> + u32 len, int repeat)
> +{
[ ... ]
> + if (repeat != 1)
> + return -EOPNOTSUPP;
> +
> + start_brightness = pattern[0].brightness & LTC3220_LED_CURRENT_MASK;
> + end_brightness = pattern[1].brightness & LTC3220_LED_CURRENT_MASK;
[Severity: Medium]
Will this bitwise masking cause wrap-around behavior if a user provides a
brightness value greater than 63 via the sysfs hw_pattern interface?
For instance, a value of 64 would wrap to 0, unexpectedly turning the LED
off.
Would it be safer to use min_t() to clamp the input instead of a
bitwise mask?
> +
> + is_increasing = end_brightness > start_brightness;
[ ... ]
> +static int ltc3220_blink_set(struct led_classdev *led_cdev,
> + unsigned long *delay_on,
> + unsigned long *delay_off)
> +{
[ ... ]
> + ret = regmap_update_bits(ltc3220->regmap, LTC3220_GRAD_BLINK_REG,
> + LTC3220_BLINK_MASK, FIELD_PREP(LTC3220_BLINK_MASK, blink_mode));
> + if (ret)
> + return ret;
> +
> + /* Ensure LED has non-zero brightness before enabling blink mode */
> + if (uled_cfg->reg_value == 0)
> + uled_cfg->reg_value = led_cdev->max_brightness;
[Severity: Medium]
Could this rely on a stale reg_value if concurrent operations are
modifying the state without synchronization, as noted in
ltc3220_set_led_data() above?
> +
> + return regmap_write(ltc3220->regmap, LTC3220_ULED_REG(uled_cfg->led_index),
> + FIELD_PREP(LTC3220_LED_MODE_MASK, LTC3220_BLINK_MODE) |
> + uled_cfg->reg_value);
> +}
[ ... ]
> +static int ltc3220_suspend(struct device *dev)
> +{
> + struct ltc3220 *ltc3220 = i2c_get_clientdata(to_i2c_client(dev));
> +
> + for (int i = 0; i < LTC3220_NUM_LEDS; i++) {
> + if (ltc3220->uled_cfg[i].registered)
> + led_classdev_suspend(<c3220->uled_cfg[i].led_cdev);
> + }
> +
> + return regmap_update_bits(ltc3220->regmap, LTC3220_COMMAND_REG,
> + LTC3220_SHUTDOWN_MASK, LTC3220_SHUTDOWN_MASK);
> +}
[Severity: Medium]
Should regcache_mark_dirty(ltc3220->regmap) be called here or in resume?
Without marking the cache dirty, the regcache_sync() in ltc3220_resume()
will silently return without restoring any registers, resulting in the
permanent loss of the blink and gradation states upon resume.
> +
> +static int ltc3220_resume(struct device *dev)
> +{
> + struct ltc3220 *ltc3220 = i2c_get_clientdata(to_i2c_client(dev));
> + int ret;
> +
> + ret = regmap_update_bits(ltc3220->regmap, LTC3220_COMMAND_REG,
> + LTC3220_SHUTDOWN_MASK, 0);
> + if (ret)
> + return ret;
> +
> + ret = regcache_sync(ltc3220->regmap);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616-ltc3220-driver-v11-0-6e51dd97ced6@analog.com?part=2
^ permalink raw reply
* [PATCH v11 2/2] leds: ltc3220: Add Support for LTC3220 18 channel LED Driver
From: Edelweise Escala @ 2026-06-16 1:36 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-leds, devicetree, linux-kernel, Edelweise Escala
In-Reply-To: <20260616-ltc3220-driver-v11-0-6e51dd97ced6@analog.com>
Add driver for the LTC3220 18-channel LED driver
with I2C interface, individual brightness control, and hardware-assisted
blink/gradation features.
Signed-off-by: Edelweise Escala <edelweise.escala@analog.com>
---
MAINTAINERS | 1 +
drivers/leds/Kconfig | 13 ++
drivers/leds/Makefile | 1 +
drivers/leds/leds-ltc3220.c | 480 ++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 495 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index c8a242577d2f..0f553ada61d9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15229,6 +15229,7 @@ L: linux-leds@vger.kernel.org
S: Maintained
W: https://ez.analog.com/linux-software-drivers
F: Documentation/devicetree/bindings/leds/adi,ltc3220.yaml
+F: drivers/leds/leds-ltc3220.c
LTC4282 HARDWARE MONITOR DRIVER
M: Nuno Sa <nuno.sa@analog.com>
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index f4a0a3c8c870..31b1e3ff094c 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -1000,6 +1000,19 @@ config LEDS_ST1202
Say Y to enable support for LEDs connected to LED1202
LED driver chips accessed via the I2C bus.
+config LEDS_LTC3220
+ tristate "LED Driver for Analog Devices Inc. LTC3220"
+ depends on I2C && LEDS_CLASS
+ select REGMAP_I2C
+ help
+ Say Y to enable support for the Analog Devices LTC3220
+ 18-channel LED controller with I2C interface.
+ The driver supports individual LED brightness control (64 steps),
+ hardware-assisted blinking and gradation effects.
+
+ To compile this driver as a module, choose M here: the module will
+ be called leds-ltc3220.
+
config LEDS_TPS6105X
tristate "LED support for TI TPS6105X"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 7db3768912ca..a68244bd50fb 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_LEDS_LP8788) += leds-lp8788.o
obj-$(CONFIG_LEDS_LP8860) += leds-lp8860.o
obj-$(CONFIG_LEDS_LP8864) += leds-lp8864.o
obj-$(CONFIG_LEDS_LT3593) += leds-lt3593.o
+obj-$(CONFIG_LEDS_LTC3220) += leds-ltc3220.o
obj-$(CONFIG_LEDS_MAX5970) += leds-max5970.o
obj-$(CONFIG_LEDS_MAX77650) += leds-max77650.o
obj-$(CONFIG_LEDS_MAX77705) += leds-max77705.o
diff --git a/drivers/leds/leds-ltc3220.c b/drivers/leds/leds-ltc3220.c
new file mode 100644
index 000000000000..8bb06e50d3c6
--- /dev/null
+++ b/drivers/leds/leds-ltc3220.c
@@ -0,0 +1,480 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * LTC3220 18-Channel LED Driver
+ *
+ * Copyright 2026 Analog Devices Inc.
+ *
+ * Author: Edelweise Escala <edelweise.escala@analog.com>
+ */
+
+#include <linux/bitfield.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/leds.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/property.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+
+/* LTC3220 Registers */
+#define LTC3220_COMMAND_REG 0x00
+#define LTC3220_QUICK_WRITE_MASK BIT(0)
+#define LTC3220_SHUTDOWN_MASK BIT(3)
+
+#define LTC3220_ULED_REG(x) (0x01 + (x))
+#define LTC3220_LED_CURRENT_MASK GENMASK(5, 0)
+#define LTC3220_LED_MODE_MASK GENMASK(7, 6)
+
+#define LTC3220_GRAD_BLINK_REG 0x13
+#define LTC3220_GRADATION_MASK GENMASK(2, 0)
+#define LTC3220_GRADATION_DIRECTION_MASK BIT(0)
+#define LTC3220_GRADATION_PERIOD_MASK GENMASK(2, 1)
+#define LTC3220_BLINK_MASK GENMASK(4, 3)
+
+#define LTC3220_NUM_LEDS 18
+
+#define LTC3220_GRADATION_RAMP_TIME_240MS 240
+#define LTC3220_GRADATION_RAMP_TIME_480MS 480
+
+#define LTC3220_BLINK_ON_156MS 156
+#define LTC3220_BLINK_ON_625MS 625
+#define LTC3220_BLINK_PERIOD_1250MS 1250
+#define LTC3220_BLINK_PERIOD_2500MS 2500
+
+#define LTC3220_BLINK_SHORT_ON_TIME BIT(0)
+#define LTC3220_BLINK_LONG_PERIOD BIT(1)
+
+enum ltc3220_led_mode {
+ LTC3220_NORMAL_MODE,
+ LTC3220_BLINK_MODE,
+ LTC3220_GRADATION_MODE,
+};
+
+enum ltc3220_blink_mode {
+ LTC3220_BLINK_MODE_625MS_1250MS,
+ LTC3220_BLINK_MODE_156MS_1250MS,
+ LTC3220_BLINK_MODE_625MS_2500MS,
+ LTC3220_BLINK_MODE_156MS_2500MS
+};
+
+enum ltc3220_gradation_mode {
+ LTC3220_GRADATION_MODE_DISABLED,
+ LTC3220_GRADATION_MODE_240MS_RAMP_TIME,
+ LTC3220_GRADATION_MODE_480MS_RAMP_TIME,
+ LTC3220_GRADATION_MODE_960MS_RAMP_TIME
+};
+
+static const struct regmap_config ltc3220_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = LTC3220_GRAD_BLINK_REG,
+ .cache_type = REGCACHE_FLAT_S,
+};
+
+struct ltc3220_uled_cfg {
+ struct led_classdev led_cdev;
+ u8 reg_value;
+ u8 led_index;
+ bool registered;
+};
+
+struct ltc3220 {
+ struct ltc3220_uled_cfg uled_cfg[LTC3220_NUM_LEDS];
+ struct regmap *regmap;
+ bool is_aggregated;
+};
+
+/*
+ * Set LED brightness. Hardware supports 0-63 brightness levels.
+ * Mode switching (blink/gradation) is handled through dedicated callbacks.
+ */
+static int ltc3220_set_led_data(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ struct ltc3220_uled_cfg *uled_cfg = container_of(led_cdev, struct ltc3220_uled_cfg,
+ led_cdev);
+ struct ltc3220 *ltc3220 = container_of(uled_cfg - uled_cfg->led_index, struct ltc3220,
+ uled_cfg[0]);
+ int ret;
+
+ ret = regmap_write(ltc3220->regmap, LTC3220_ULED_REG(uled_cfg->led_index),
+ brightness);
+ if (ret)
+ return ret;
+
+ uled_cfg->reg_value = brightness;
+
+ /*
+ * When aggregated LED mode is enabled, writing to LED 1 updates all
+ * LEDs simultaneously via quick-write mode. Update cached values for
+ * all LEDs to reflect the synchronized state.
+ * See Documentation/devicetree/bindings/leds/adi,ltc3220.yaml for how
+ * to configure aggregated LED mode.
+ */
+ if (ltc3220->is_aggregated && uled_cfg->led_index == 0) {
+ for (int i = 0; i < LTC3220_NUM_LEDS; i++)
+ ltc3220->uled_cfg[i].reg_value = brightness;
+ }
+
+ return 0;
+}
+
+static enum led_brightness ltc3220_get_led_data(struct led_classdev *led_cdev)
+{
+ struct ltc3220_uled_cfg *uled_cfg = container_of(led_cdev, struct ltc3220_uled_cfg,
+ led_cdev);
+
+ return uled_cfg->reg_value;
+}
+
+/*
+ * LTC3220 pattern support for hardware-assisted breathing/gradation.
+ * The hardware supports 3 gradation ramp time 240ms, 480ms, 960ms)
+ * and can ramp up or down.
+ *
+ * Pattern array interpretation:
+ * pattern[0].brightness = start brightness (0-63)
+ * pattern[0].delta_t = ramp time in milliseconds
+ * pattern[1].brightness = end brightness (0-63)
+ * pattern[1].delta_t = (optional, can be 0 or same as pattern[0].delta_t)
+ */
+static int ltc3220_pattern_set(struct led_classdev *led_cdev,
+ struct led_pattern *pattern,
+ u32 len, int repeat)
+{
+ struct ltc3220_uled_cfg *uled_cfg = container_of(led_cdev, struct ltc3220_uled_cfg,
+ led_cdev);
+ struct ltc3220 *ltc3220 = container_of(uled_cfg - uled_cfg->led_index, struct ltc3220,
+ uled_cfg[0]);
+ u8 gradation_period;
+ u8 start_brightness;
+ u8 end_brightness;
+ u8 gradation_val;
+ bool is_increasing;
+ int ret;
+
+ if (len != 2)
+ return -EINVAL;
+
+ if (repeat != 1)
+ return -EOPNOTSUPP;
+
+ start_brightness = pattern[0].brightness & LTC3220_LED_CURRENT_MASK;
+ end_brightness = pattern[1].brightness & LTC3220_LED_CURRENT_MASK;
+
+ is_increasing = end_brightness > start_brightness;
+
+ if (pattern[0].delta_t == 0)
+ gradation_period = LTC3220_GRADATION_MODE_DISABLED;
+ else if (pattern[0].delta_t <= LTC3220_GRADATION_RAMP_TIME_240MS)
+ gradation_period = LTC3220_GRADATION_MODE_240MS_RAMP_TIME;
+ else if (pattern[0].delta_t <= LTC3220_GRADATION_RAMP_TIME_480MS)
+ gradation_period = LTC3220_GRADATION_MODE_480MS_RAMP_TIME;
+ else
+ gradation_period = LTC3220_GRADATION_MODE_960MS_RAMP_TIME;
+
+ gradation_val = FIELD_PREP(LTC3220_GRADATION_PERIOD_MASK, gradation_period);
+ gradation_val |= FIELD_PREP(LTC3220_GRADATION_DIRECTION_MASK, is_increasing);
+
+ ret = regmap_update_bits(ltc3220->regmap, LTC3220_GRAD_BLINK_REG,
+ LTC3220_GRADATION_MASK, gradation_val);
+ if (ret)
+ return ret;
+
+ ret = ltc3220_set_led_data(led_cdev, start_brightness);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(ltc3220->regmap, LTC3220_ULED_REG(uled_cfg->led_index),
+ FIELD_PREP(LTC3220_LED_MODE_MASK, LTC3220_GRADATION_MODE) |
+ end_brightness);
+ if (ret)
+ return ret;
+
+ uled_cfg->reg_value = end_brightness;
+
+ return 0;
+}
+
+static int ltc3220_pattern_clear(struct led_classdev *led_cdev)
+{
+ struct ltc3220_uled_cfg *uled_cfg = container_of(led_cdev, struct ltc3220_uled_cfg,
+ led_cdev);
+ struct ltc3220 *ltc3220 = container_of(uled_cfg - uled_cfg->led_index, struct ltc3220,
+ uled_cfg[0]);
+ int ret;
+
+ ret = regmap_update_bits(ltc3220->regmap, LTC3220_ULED_REG(uled_cfg->led_index),
+ LTC3220_LED_MODE_MASK, LTC3220_NORMAL_MODE);
+ if (ret)
+ return ret;
+
+ return ltc3220_set_led_data(led_cdev, LED_OFF);
+}
+
+/*
+ * LTC3220 has a global blink configuration that affects all LEDs.
+ * This implementation allows per-LED blink requests, but the blink timing
+ * will be shared across all LEDs. The delay values are mapped to the
+ * hardware's discrete blink rates.
+ */
+static int ltc3220_blink_set(struct led_classdev *led_cdev,
+ unsigned long *delay_on,
+ unsigned long *delay_off)
+{
+ struct ltc3220_uled_cfg *uled_cfg = container_of(led_cdev, struct ltc3220_uled_cfg,
+ led_cdev);
+ struct ltc3220 *ltc3220 = container_of(uled_cfg - uled_cfg->led_index, struct ltc3220,
+ uled_cfg[0]);
+ u8 blink_mode = 0;
+ int ret;
+
+ if (*delay_on <= LTC3220_BLINK_ON_156MS)
+ blink_mode = LTC3220_BLINK_SHORT_ON_TIME;
+
+ if (*delay_on + *delay_off > LTC3220_BLINK_PERIOD_1250MS)
+ blink_mode |= LTC3220_BLINK_LONG_PERIOD;
+
+ switch (blink_mode) {
+ case LTC3220_BLINK_MODE_625MS_1250MS:
+ *delay_on = LTC3220_BLINK_ON_625MS;
+ *delay_off = LTC3220_BLINK_PERIOD_1250MS - LTC3220_BLINK_ON_625MS;
+ break;
+ case LTC3220_BLINK_MODE_156MS_1250MS:
+ *delay_on = LTC3220_BLINK_ON_156MS;
+ *delay_off = LTC3220_BLINK_PERIOD_1250MS - LTC3220_BLINK_ON_156MS;
+ break;
+ case LTC3220_BLINK_MODE_625MS_2500MS:
+ *delay_on = LTC3220_BLINK_ON_625MS;
+ *delay_off = LTC3220_BLINK_PERIOD_2500MS - LTC3220_BLINK_ON_625MS;
+ break;
+ case LTC3220_BLINK_MODE_156MS_2500MS:
+ *delay_on = LTC3220_BLINK_ON_156MS;
+ *delay_off = LTC3220_BLINK_PERIOD_2500MS - LTC3220_BLINK_ON_156MS;
+ break;
+ }
+
+ ret = regmap_update_bits(ltc3220->regmap, LTC3220_GRAD_BLINK_REG,
+ LTC3220_BLINK_MASK, FIELD_PREP(LTC3220_BLINK_MASK, blink_mode));
+ if (ret)
+ return ret;
+
+ /* Ensure LED has non-zero brightness before enabling blink mode */
+ if (uled_cfg->reg_value == 0)
+ uled_cfg->reg_value = led_cdev->max_brightness;
+
+ return regmap_write(ltc3220->regmap, LTC3220_ULED_REG(uled_cfg->led_index),
+ FIELD_PREP(LTC3220_LED_MODE_MASK, LTC3220_BLINK_MODE) |
+ uled_cfg->reg_value);
+}
+
+static void ltc3220_reset_gpio_action(void *data)
+{
+ struct gpio_desc *reset_gpio = data;
+
+ gpiod_set_value_cansleep(reset_gpio, 1);
+}
+
+static int ltc3220_reset(struct ltc3220 *ltc3220, struct i2c_client *client)
+{
+ struct gpio_desc *reset_gpio;
+ int ret;
+
+ reset_gpio = devm_gpiod_get_optional(&client->dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(reset_gpio))
+ return dev_err_probe(&client->dev, PTR_ERR(reset_gpio), "Failed on reset GPIO\n");
+
+ if (reset_gpio) {
+ usleep_range(10000, 12000);
+ gpiod_set_value_cansleep(reset_gpio, 0);
+ usleep_range(10000, 12000);
+
+ ret = devm_add_action_or_reset(&client->dev, ltc3220_reset_gpio_action,
+ reset_gpio);
+ if (ret)
+ return ret;
+ }
+
+ ret = regmap_write(ltc3220->regmap, LTC3220_COMMAND_REG, 0);
+ if (ret)
+ return ret;
+
+ for (int i = 0; i < LTC3220_NUM_LEDS; i++) {
+ ret = regmap_write(ltc3220->regmap, LTC3220_ULED_REG(i), 0);
+ if (ret)
+ return ret;
+ }
+
+ return regmap_write(ltc3220->regmap, LTC3220_GRAD_BLINK_REG, 0);
+}
+
+static int ltc3220_suspend(struct device *dev)
+{
+ struct ltc3220 *ltc3220 = i2c_get_clientdata(to_i2c_client(dev));
+
+ for (int i = 0; i < LTC3220_NUM_LEDS; i++) {
+ if (ltc3220->uled_cfg[i].registered)
+ led_classdev_suspend(<c3220->uled_cfg[i].led_cdev);
+ }
+
+ return regmap_update_bits(ltc3220->regmap, LTC3220_COMMAND_REG,
+ LTC3220_SHUTDOWN_MASK, LTC3220_SHUTDOWN_MASK);
+}
+
+static int ltc3220_resume(struct device *dev)
+{
+ struct ltc3220 *ltc3220 = i2c_get_clientdata(to_i2c_client(dev));
+ int ret;
+
+ ret = regmap_update_bits(ltc3220->regmap, LTC3220_COMMAND_REG,
+ LTC3220_SHUTDOWN_MASK, 0);
+ if (ret)
+ return ret;
+
+ ret = regcache_sync(ltc3220->regmap);
+ if (ret)
+ return ret;
+
+ for (int i = 0; i < LTC3220_NUM_LEDS; i++) {
+ if (ltc3220->uled_cfg[i].registered)
+ led_classdev_resume(<c3220->uled_cfg[i].led_cdev);
+ }
+
+ return 0;
+}
+
+static DEFINE_SIMPLE_DEV_PM_OPS(ltc3220_pm_ops, ltc3220_suspend, ltc3220_resume);
+
+static int ltc3220_probe(struct i2c_client *client)
+{
+ struct ltc3220 *ltc3220;
+ bool aggregated_led_found = false;
+ int num_leds = 0;
+ u8 led_index = 0;
+ int ret;
+
+ ltc3220 = devm_kzalloc(&client->dev, sizeof(*ltc3220), GFP_KERNEL);
+ if (!ltc3220)
+ return -ENOMEM;
+
+ ltc3220->regmap = devm_regmap_init_i2c(client, <c3220_regmap_config);
+ if (IS_ERR(ltc3220->regmap))
+ return dev_err_probe(&client->dev, PTR_ERR(ltc3220->regmap),
+ "Failed to initialize regmap\n");
+
+ i2c_set_clientdata(client, ltc3220);
+
+ ret = ltc3220_reset(ltc3220, client);
+ if (ret)
+ return dev_err_probe(&client->dev, ret, "Failed to reset device\n");
+
+ /* First pass: validate configuration and set up LED structures */
+ device_for_each_child_node_scoped(&client->dev, child) {
+ struct ltc3220_uled_cfg *led;
+ u32 source;
+
+ ret = fwnode_property_read_u32(child, "reg", &source);
+ if (ret)
+ return dev_err_probe(&client->dev, ret, "Couldn't read LED address\n");
+
+ if (!source || source > LTC3220_NUM_LEDS)
+ return dev_err_probe(&client->dev, -EINVAL, "LED address out of range\n");
+
+ if (fwnode_property_present(child, "led-sources")) {
+ if (source != 1)
+ return dev_err_probe(&client->dev, -EINVAL,
+ "Aggregated LED out of range\n");
+
+ if (aggregated_led_found)
+ return dev_err_probe(&client->dev, -EINVAL,
+ "One Aggregated LED only\n");
+
+ aggregated_led_found = true;
+ ltc3220->is_aggregated = true;
+
+ ret = regmap_update_bits(ltc3220->regmap,
+ LTC3220_COMMAND_REG,
+ LTC3220_QUICK_WRITE_MASK,
+ LTC3220_QUICK_WRITE_MASK);
+ if (ret)
+ return dev_err_probe(&client->dev, ret,
+ "Failed to set quick write mode\n");
+ }
+
+ num_leds++;
+
+ /* LED node reg/index/address goes from 1 to 18 */
+ led_index = source - 1;
+ led = <c3220->uled_cfg[led_index];
+
+ if (led->registered)
+ return dev_err_probe(&client->dev, -EINVAL,
+ "Duplicate LED reg %u found", source);
+
+ led->registered = true;
+ led->led_index = led_index;
+ led->reg_value = 0;
+ led->led_cdev.brightness_set_blocking = ltc3220_set_led_data;
+ led->led_cdev.brightness_get = ltc3220_get_led_data;
+ led->led_cdev.max_brightness = 63;
+ led->led_cdev.blink_set = ltc3220_blink_set;
+ led->led_cdev.pattern_set = ltc3220_pattern_set;
+ led->led_cdev.pattern_clear = ltc3220_pattern_clear;
+ }
+
+ /*
+ * Aggregated LED mode uses hardware quick-write to control all 18 LEDs
+ * simultaneously. This is mutually exclusive with individual LED control.
+ * See Documentation/devicetree/bindings/leds/adi,ltc3220.yaml for details
+ * on how to configure aggregated LED mode.
+ */
+ if (aggregated_led_found && num_leds > 1)
+ return dev_err_probe(&client->dev, -EINVAL,
+ "Aggregated LED must be the only LED node\n");
+
+ /* Second pass: register LEDs after validation */
+ device_for_each_child_node_scoped(&client->dev, child) {
+ struct led_init_data init_data = {};
+ struct ltc3220_uled_cfg *led;
+ u32 source;
+
+ ret = fwnode_property_read_u32(child, "reg", &source);
+ if (ret)
+ return ret;
+
+ init_data.fwnode = child;
+ init_data.devicename = "ltc3220";
+
+ led_index = source - 1;
+ led = <c3220->uled_cfg[led_index];
+
+ ret = devm_led_classdev_register_ext(&client->dev, &led->led_cdev, &init_data);
+ if (ret)
+ return dev_err_probe(&client->dev, ret, "Failed to register LED class\n");
+ }
+
+ return 0;
+}
+
+static const struct of_device_id ltc3220_of_match[] = {
+ { .compatible = "adi,ltc3220" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ltc3220_of_match);
+
+static struct i2c_driver ltc3220_led_driver = {
+ .driver = {
+ .name = "ltc3220",
+ .of_match_table = ltc3220_of_match,
+ .pm = pm_sleep_ptr(<c3220_pm_ops),
+ },
+ .probe = ltc3220_probe,
+};
+module_i2c_driver(ltc3220_led_driver);
+
+MODULE_AUTHOR("Edelweise Escala <edelweise.escala@analog.com>");
+MODULE_DESCRIPTION("LED driver for LTC3220 controllers");
+MODULE_LICENSE("GPL");
--
2.43.0
^ permalink raw reply related
* [PATCH v11 1/2] dt-bindings: leds: Add LTC3220 18 channel LED Driver
From: Edelweise Escala @ 2026-06-16 1:36 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-leds, devicetree, linux-kernel, Edelweise Escala,
Conor Dooley
In-Reply-To: <20260616-ltc3220-driver-v11-0-6e51dd97ced6@analog.com>
LTC3220 is a multi-display LED driver with I2C interface.
The LTC3220 provides individual brightness control (64-step),
blinking, and gradation features for up to 18 LED outputs.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Edelweise Escala <edelweise.escala@analog.com>
---
.../devicetree/bindings/leds/adi,ltc3220.yaml | 131 +++++++++++++++++++++
MAINTAINERS | 7 ++
2 files changed, 138 insertions(+)
diff --git a/Documentation/devicetree/bindings/leds/adi,ltc3220.yaml b/Documentation/devicetree/bindings/leds/adi,ltc3220.yaml
new file mode 100644
index 000000000000..c859490e9108
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/adi,ltc3220.yaml
@@ -0,0 +1,131 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/adi,ltc3220.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices LTC3220 LED Driver
+
+maintainers:
+ - Edelweise Escala <edelweise.escala@analog.com>
+
+description: >
+ The LTC3220 is a multi-display LED driver, which contains a high-efficiency,
+ low-noise charge pump to provide power to up to 18 LED current sources.
+ The LEDs are individually configurable to 64-step linear brightness control,
+ blinking and gradation control via 2-wire I2C interface.
+
+ For more product information please see the link below
+ https://www.analog.com/en/products/ltc3220.html
+
+properties:
+ compatible:
+ const: adi,ltc3220
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ reset-gpios:
+ maxItems: 1
+
+patternProperties:
+ '^led@([1-9a-f]|1[0-2])$':
+ type: object
+ $ref: /schemas/leds/common.yaml#
+ unevaluatedProperties: false
+ properties:
+ reg:
+ description:
+ Output channel for the LED (1-18 maps to LED outputs D1-D18).
+ Unit-address must be in hexadecimal (1-12 hex = 1-18 decimal).
+ For aggregated LED control, define only one LED node with reg = <0x1>
+ and use led-sources to list all controlled outputs. Only reg 1 should
+ be present when using led-sources.
+ minimum: 1
+ maximum: 18
+
+ required:
+ - reg
+
+ if:
+ required:
+ - led-sources
+ then:
+ properties:
+ reg:
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - '#address-cells'
+ - '#size-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ // Independent LEDs
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@1c {
+ compatible = "adi,ltc3220";
+ reg = <0x1c>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reset-gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
+
+ led@1 {
+ reg = <0x1>;
+ function = LED_FUNCTION_INDICATOR;
+ function-enumerator = <1>;
+ };
+
+ led@2 {
+ reg = <0x2>;
+ function = LED_FUNCTION_INDICATOR;
+ function-enumerator = <2>;
+ };
+
+ led@3 {
+ reg = <0x3>;
+ function = LED_FUNCTION_INDICATOR;
+ function-enumerator = <3>;
+ };
+ };
+ };
+
+ - |
+ // Aggregated LED
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@1c {
+ compatible = "adi,ltc3220";
+ reg = <0x1c>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@1 {
+ reg = <0x1>;
+ led-sources = <0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 0x9 0xa 0xb 0xc 0xd 0xe 0xf 0x10 0x11 0x12>;
+ function = LED_FUNCTION_BACKLIGHT;
+ };
+ };
+ };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 2fb1c75afd16..c8a242577d2f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15223,6 +15223,13 @@ W: https://ez.analog.com/linux-software-drivers
F: Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
F: drivers/iio/temperature/ltc2983.c
+LTC3220 LED DRIVER
+M: Edelweise Escala <edelweise.escala@analog.com>
+L: linux-leds@vger.kernel.org
+S: Maintained
+W: https://ez.analog.com/linux-software-drivers
+F: Documentation/devicetree/bindings/leds/adi,ltc3220.yaml
+
LTC4282 HARDWARE MONITOR DRIVER
M: Nuno Sa <nuno.sa@analog.com>
L: linux-hwmon@vger.kernel.org
--
2.43.0
^ permalink raw reply related
* [PATCH v11 0/2] Add Support for LTC3220 18 Channel LED Driver
From: Edelweise Escala @ 2026-06-16 1:36 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-leds, devicetree, linux-kernel, Edelweise Escala,
Conor Dooley
The LTC3220/LTC3220-1 is a multi-display LED driver, which contains a
high-efficiency, low-noise charge pump to provide power to up to
18 LED current sources. The LEDs are individually configurable to
64-step linear brightness control, blinking and gradation control
via 2-wire I2C interface. The blinking and gradation configuration
is shared across all LED.
LTC3220 has a quick write function which allows changing the brightness
on all LEDS simultaneously when the brightness is changed on led 1.
For this leds are aggregated in the device tree and on probe we check
if led-sources exist to enable quick write.
We would like to know if this approach is alright?
Another way we might want to know is, is it alright to just make a
virtual led for the quick write function. Changing brightness on
the virtual led will change the brightness for all.
Signed-off-by: Edelweise Escala <edelweise.escala@analog.com>
---
Changes in v11:
- Add guards to check for double reg
- Add led_classdev_suspend/resume
- Return -EOPNOTSUPP for repeat request not 1
- Single write instead of write+read for blink
- Link to v10: https://lore.kernel.org/r/20260615-ltc3220-driver-v10-0-916562c88598@analog.com
Changes in v10:
- Remove volatile reg
- Add regacache_sync on resume
- Add delays on reset
- Remove early return and let software rset even if there is reset
- Set to max brightness before blink
- Two pass validation approach to avoid premature sysfs exposure
- Use pointer arithmetic for container_of
- Remove unused macros
- Add missing property header
- Link to v9: https://lore.kernel.org/r/20260528-ltc3220-driver-v9-0-69450fc213cb@analog.com
Changes in v9:
- Add address-cells and size-cells in required
- Restrict to reg 1 if led-sources is present
- Make set brightness only change brighntess for nomal mode,
blink and gradation is now handled only in its respective triggers.
- Fix blink to change mode on blink set
- Make pattern clear only change brightness and not change gradation
mode so it won't affect other leds.
- Add checks if ever there is duplicate reg in the bindings.
- Add REGMAP_I2C on Kconfig
- Rebase on Latest next
- Link to v8: https://lore.kernel.org/r/20260519-ltc3220-driver-v8-0-e1771c1733f7@analog.com
Changes in v8:
- Add '>' on descriptions with multiple paragraph
- Change led registers to hex
- Change cache type to REGCACHE_FLAT_S
- Link to v7: https://lore.kernel.org/r/20260508-ltc3220-driver-v7-0-0f092ba54f23@analog.com
Changes in v7:
- Add cahcetype on regmap
- Dropped struct ltc3220_state *ltc3220_state and use container_of()
- Rename ltc3220_state to ltc3220
- Dropped functions only used once and used inline instead.
- Loop variable changes
- Consistent decalaration for container_of
- Tabbing fixes
- Link to v6: https://lore.kernel.org/r/20260417-ltc3220-driver-v6-0-18157871eddd@analog.com
Changes in v6:
- Fix commit message
- Add manufacturer on Kconfig and improve description
- Rearrange register map and bitmask and improve naming
- Use regmap, also use update bits of regmap to avoid unnecessary
structs
- Alignment and spacing fixes
- Use Define for magic naumbers
- Fix blink calculation
- Add comments on aggregated LED
- Fix variable name to something more understandable like i to led_index
- Link to v5: https://lore.kernel.org/r/20260126-ltc3220-driver-v5-0-152a30e98ab7@analog.com
Changes in v5:
- Missed rename on bindings filename in MAINTAINERS file
- Link to v4: https://lore.kernel.org/linux-leds/20260126-ltc3220-driver-v4-0-c59517206c24@analog.com
Changes in v4:
- Rename leds-ltc3220.yaml to adi,ltc3220.yaml
- Add Reviewed-by: Conor Dooley <conor.dooley@microchip.com> on
adi,ltc3220.yaml
Other V1 comments I think already addressed
- Subject commit message was already changed to match hardware
- Fixed wrapping after description
- Dropped "Bindings for" in descriptions and improved description to match hardware
- Dropped adi,ltc3220-1
- Dropped redundant description on reset-gpios
- Dropped adi,force-cpo-level
- Dropped adi,quick-write in favor of aggregated LED
- Used consistent quotes ^led@([1-9]|1[0-8])$
- Fixed wrapping on error messages
- Link to v3: https://lore.kernel.org/r/20260120-ltc3220-driver-v3-0-fef612ec4faa@analog.com
Changes in v3:
- Dropped quick-write on bindings and added aggregated led instead.
- Add aggregated led example.
- Modify quick write to check if there is aggregated led, if there is
aggregated led enable quick write.
- Use DEFINE_SIMPLE_DEV_PM_OPS instead of SIMPLE_DEV_PM_OPS.
- Link to v2: https://lore.kernel.org/r/20260112-ltc3220-driver-v2-0-d043058fc4df@analog.com
Changes in v2:
leds-ltc3220.yaml changes
- Fix wrapping on description
- Improve description and commit messge to describe hardware
- Drop ltc3220-1
- Drop charge pump
ltc3220.c changes
- Fix wrapping
- Drop ltc3220-1
- Drop devname_mandatory
- Link to v1: https://lore.kernel.org/r/20260106-ltc3220-driver-v1-0-73601d6f1649@analog.com
---
Edelweise Escala (2):
dt-bindings: leds: Add LTC3220 18 channel LED Driver
leds: ltc3220: Add Support for LTC3220 18 channel LED Driver
.../devicetree/bindings/leds/adi,ltc3220.yaml | 131 ++++++
MAINTAINERS | 8 +
drivers/leds/Kconfig | 13 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-ltc3220.c | 480 +++++++++++++++++++++
5 files changed, 633 insertions(+)
---
base-commit: 25025253476a64c186592d952c27f24bc3490e42
change-id: 20260106-ltc3220-driver-f9ab6cc9d1e4
Best regards,
--
Edelweise Escala <edelweise.escala@analog.com>
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: media: qcom,sm8550-iris: Allow IOVA reservation memory-region
From: Dmitry Baryshkov @ 2026-06-16 0:57 UTC (permalink / raw)
To: Daniel J Blueman
Cc: Bryan O'Donoghue, Vikash Garodia, Abhinav Kumar,
Bjorn Andersson, Konrad Dybcio, Mauro Carvalho Chehab,
Stephan Gerhold, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-media, devicetree, linux-kernel, stable
In-Reply-To: <20260614145113.84243-1-daniel@quora.org>
On Sun, Jun 14, 2026 at 10:51:11PM +0800, Daniel J Blueman wrote:
> In addition to the firmware-loaded codec carveout, some Iris platforms
> need to declare an IOMMU IOVA reservation (a reserved-memory node with
> iommu-addresses) to keep DMA away from IOVA ranges that earlier
> firmware stages have already mapped through the SMMU.
>
> Permit a second memory-region phandle for this purpose, and describe
> the meaning of each entry so the ordering is unambiguous.
With no driver changes?
>
> Fixes: 9065340ac04d ("arm64: dts: qcom: x1e80100: Add IRIS video codec")
> Cc: stable@vger.kernel.org
> Signed-off-by: Daniel J Blueman <daniel@quora.org>
> ---
> v2:
> - drop redundant maxItems, keeping the items descriptions (Rob)
> - add Fixes tag and Cc stable for the backport dependency
> v1: https://lore.kernel.org/lkml/20260601041336.9497-1-daniel@quora.org/
>
> .../devicetree/bindings/media/qcom,sm8550-iris.yaml | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> index 9c4b760508b5..5abcaee4101c 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> @@ -80,7 +80,10 @@ properties:
> dma-coherent: true
>
> memory-region:
> - maxItems: 1
> + minItems: 1
> + items:
> + - description: Firmware-loaded codec carveout
> + - description: IOMMU IOVA reservation region
>
> operating-points-v2: true
>
> --
> 2.53.0
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/3] drm/msm/adreno: Add support for A704 GPU
From: Dmitry Baryshkov @ 2026-06-16 0:56 UTC (permalink / raw)
To: Akhil P Oommen
Cc: Rob Clark, Sean Paul, Konrad Dybcio, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Will Deacon, Robin Murphy, Joerg Roedel (AMD), Bibek Kumar Patro,
linux-arm-msm, dri-devel, freedreno, devicetree, linux-kernel,
linux-arm-kernel, iommu, Aditya Sherawat, Konrad Dybcio
In-Reply-To: <20260615-shikra-gpu-v2-2-2f2d1347c3fb@oss.qualcomm.com>
On Mon, Jun 15, 2026 at 03:02:58AM +0530, Akhil P Oommen wrote:
> From: Aditya Sherawat <asherawa@qti.qualcomm.com>
>
> Adreno A704 GPU found in Shikra is an IP reuse of A702 GPU with very
> minimal changes. The only KMD facing difference is the chipid and the
> zap firmware which is specified via devicetree.
>
> Just add the new chipid to enable support for A704 GPU in Shikra.
>
> Signed-off-by: Aditya Sherawat <asherawa@qti.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
> drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ 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