* Re: [PATCH v4] dt-bindings: iio: proximity: move LIDAR-Lite out of trivial-devices
From: Jonathan Cameron @ 2026-07-19 22:41 UTC (permalink / raw)
To: David Lechner
Cc: Rodrigo Gobbi, nuno.sa, andy, robh, krzk+dt, conor+dt, mranostay,
~lkcamp/patches, linux-iio, devicetree, linux-kernel,
linux-kernel-mentees
In-Reply-To: <7b8973fd-385d-4532-8213-bb0a811081ae@baylibre.com>
> >
> > [1] https://lore.kernel.org/all/c39a2980-f5e5-44aa-9fd3-20e0658f62dc@gmail.com/
> >
> > Changelog:
> > v4: unify patches rather than using a series to keep the tree bisectable;
> > rewrite the commit msg, naming the devices explicitly;
>
> We lost the IIO driver patch though. The change adding a new compatible
> won't be accepted without it.
I think it is fully backwards compatible? If so we don't need to do
anything in the driver. We could tweak the name, but perhaps not worth
the bother in this case.
^ permalink raw reply
* Re: [PATCH v12 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: Bryan O'Donoghue @ 2026-07-19 22:30 UTC (permalink / raw)
To: sashiko-reviews
Cc: robh, media-ci, vkoul, conor+dt, devicetree, neil.armstrong,
linux-phy, olteanv
In-Reply-To: <20260719135920.2195A1F00A3A@smtp.kernel.org>
On 19/07/2026 14:59, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [High] Valid calculated settle_cnt of 0 is erroneously rejected as an error, causing PHY initialization to fail.
> - [High] Potential NULL pointer dereference in clock name comparison during probe when parsing malformed device trees.
> - [Medium] Missing PM_OPP Kconfig dependency causes unconditional runtime probe failures.
> --
>
> --- Patch [2]: [PATCH v12 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver ---
> commit 7fdedc509474184e47a62af468ae08b71f96dfd5
> Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> Subject: phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
>
> This commit adds a new MIPI CSI2 driver in DPHY mode. It imports existing
> CAMSS CSI PHY initialization sequences to support devices like the
> qcom,x1e80100-csi2-phy.
>
>> diff --git a/drivers/phy/qualcomm/Kconfig b/drivers/phy/qualcomm/Kconfig
>> index 60a0ead127fa9..779a3511ba852 100644
>> --- a/drivers/phy/qualcomm/Kconfig
>> +++ b/drivers/phy/qualcomm/Kconfig
>> @@ -28,6 +28,20 @@ config PHY_QCOM_EDP
>> Enable this driver to support the Qualcomm eDP PHY found in various
>> Qualcomm chipsets.
>>
>> +config PHY_QCOM_MIPI_CSI2
>> + tristate "Qualcomm MIPI CSI2 PHY driver"
>> + depends on ARCH_QCOM || COMPILE_TEST
>> + depends on OF
>> + depends on PM
>> + depends on COMMON_CLK
>> + select GENERIC_PHY
>> + select GENERIC_PHY_MIPI_DPHY
>
> [Severity: Medium]
> Should this Kconfig entry select or depend on PM_OPP?
>
> Without CONFIG_PM_OPP enabled, the stub for devm_pm_opp_of_add_table()
> used during probe will return -EOPNOTSUPP, causing the driver probe to
> unconditionally fail with an "invalid OPP table" error.
By design in fact as a result of a Sashiko review as I recall. Context
window between runs seems required for this tool.
>
>> diff --git a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
>> new file mode 100644
>> --- /dev/null
>> +++ b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c
>
> [ ... ]
>
>> +static int phy_qcom_mipi_csi2_lanes_enable(struct mipi_csi2phy_device *csi2phy,
>> + struct mipi_csi2phy_stream_cfg *cfg)
>> +{
>> + const struct mipi_csi2phy_device_regs *regs = csi2phy_dev_to_regs(csi2phy);
>> + struct mipi_csi2phy_lanes_cfg *lane_cfg = &cfg->lane_cfg;
>> + u8 settle_cnt;
>> + u8 val;
>> + int i;
>> +
>> + settle_cnt = phy_qcom_mipi_csi2_settle_cnt_calc(cfg->link_freq, csi2phy->timer_clk_rate);
>> + if (!settle_cnt)
>> + return -EINVAL;
>
> [Severity: High]
> Does this incorrectly reject a valid settle count of zero?
>
> Looking at the math in phy_qcom_mipi_csi2_settle_cnt_calc():
>
> phy_qcom_mipi_csi2_settle_cnt_calc() {
> ...
> settle_cnt = t_hs_settle_ps / timer_period_ps - 6;
> return settle_cnt;
> }
>
> If the link frequency and timer clock rate yield exactly 6 timer periods
> for t_hs_settle, the calculation results in 0. By rejecting 0 here,
> legitimate MIPI CSI2 configurations might fail to initialize.
Yeah, I guess a zero settle count should be legitimate.
>
>> diff --git a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c
>> new file mode 100644
>> --- /dev/null
>> +++ b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c
>
> [ ... ]
>
>> +static int phy_qcom_mipi_csi2_probe(struct platform_device *pdev)
>> +{
>
> [ ... ]
>
>> + ret = devm_clk_bulk_get_all(dev, &csi2phy->clks);
>> + if (ret < 0)
>> + return dev_err_probe(dev, ret, "Failed to get clocks\n");
>> +
>> + if (num_clk != ret) {
>> + return dev_err_probe(dev, -ENODEV, "clock count %d expected %d\n",
>> + ret, num_clk);
>> + }
>> +
>> + for (i = 0; i < num_clk; i++) {
>> + if (!strcmp(csi2phy->clks[i].id, "timer")) {
>
> [Severity: High]
> Could csi2phy->clks[i].id be NULL here?
>
> The clk_bulk_get_all() infrastructure can leave the .id field as NULL if
> the device tree node has a "clocks" property but is missing "clock-names".
> Calling strcmp() on a NULL pointer will cause a kernel panic during probe
> when parsing malformed device trees.
clock-names are required in the schema but sure I add a check for this.
This ping-pong with this tool is taking forever, I need to figure out
how to run this locally to stop wasting my own time.
>> + csi2phy->timer_clk = csi2phy->clks[i].clk;
>> + break;
>> + }
>> + }
>> + if (!csi2phy->timer_clk)
>> + return dev_err_probe(dev, -ENODEV, "no timer clock\n");
>
^ permalink raw reply
* Re: [PATCH v8 2/8] iio: dac: ad5686: missing NULL check on match data
From: Jonathan Cameron @ 2026-07-19 22:17 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Rodrigo Alencar, Michael Auchter, linux, linux-iio, devicetree,
linux-kernel, linux-hardening, Michael Hennerich, David Lechner,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Kees Cook, Gustavo A. R. Silva, sashiko-bot
In-Reply-To: <alyP8NlQzRpXnSq9@ashevche-desk.local>
On Sun, 19 Jul 2026 11:50:56 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Sun, Jul 19, 2026 at 12:55:44AM +0100, Jonathan Cameron wrote:
> > On Fri, 17 Jul 2026 13:28:52 +0300
> > Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
>
> ...
>
> > I applied the following rather than going for a v9 for just this:
>
> Thanks!
>
> > Shout if I messed it up.
>
> ...
>
> > + if (!chip_info)
> > + return -ENODEV;
>
> Perhaps stick with -ENODATA? (Maybe in a separate change, dunno...)
>
oops. I lost track on where we were with that. Updated.
^ permalink raw reply
* Re: [PATCH 3/4] iio: dac: ad5686: extend device support with new parts
From: Jonathan Cameron @ 2026-07-19 21:43 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay
Cc: rodrigo.alencar, Michael Auchter, linux, linux-iio, devicetree,
linux-kernel, Michael Hennerich, David Lechner, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20260719-ad5686-extend-dev-support-v1-3-841ec75cf5d8@analog.com>
On Sun, 19 Jul 2026 10:51:59 +0100
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> Add support for AD5313R, AD5317R, AD5674, AD5679, AD5687, AD5687R, AD5689,
> AD5689R to the AD5686 SPI driver. Also adding support for AD5316R, AD5675,
> AD5697R to the AD5696 I2C driver. AD5673R and AD5677R were missing from
> the of_match table.
Given I'm asking for a v2 anyway, please break out the missing of_match
table entries as a precursor.
> This includes the creation of seven chip info struct
> instances and reuse of existing ones.
>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH v1 3/4] clk: sunxi-ng: sun55i-a523: reparent GPU while pll-gpu changes rate
From: sashiko-bot @ 2026-07-19 21:35 UTC (permalink / raw)
To: Juan Manuel López Carrillo; +Cc: linux-sunxi, robh, conor+dt, devicetree
In-Reply-To: <20260719211319.982285-4-juanmanuellopezcarrillo@gmail.com>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
New issues:
- [High] The `pll_gpu_clk` retains the `CLK_SET_RATE_GATE` flag, which completely prevents the intended dynamic rate changes while the GPU is active.
- [High] Missing `clk_notifier_unregister()` on driver unbind/module unload leads to a Use-After-Free.
- [Medium] The return value of `ccu_mux_notifier_register()` is silently ignored.
Pre-existing issues:
- [High] Unhandled `ABORT_RATE_CHANGE` event in the mux notifier callback permanently parks the GPU on the bypass clock.
- [Medium] Out-of-bounds array read on `gpu_mux_table` via `ccu_mux_helper_set_parent()`.
--
--- Patch [3]: [PATCH v1 3/4] clk: sunxi-ng: sun55i-a523: reparent GPU while pll-gpu changes rate ---
commit faed0fa03ac4f89885fa0cb42878fa743f6eb4a4
Author: Juan Manuel López Carrillo <juanmanuellopezcarrillo@gmail.com>
clk: sunxi-ng: sun55i-a523: reparent GPU while pll-gpu changes rate
This commit registers a mux notifier on pll-gpu to park the GPU mod clock
on a fixed output while the PLL is being reprogrammed. This is intended to
allow glitch-free rate changes for higher speed-bin operating points.
> diff --git a/drivers/clk/sunxi-ng/ccu-sun55i-a523.c b/drivers/clk/sunxi-ng/ccu-sun55i-a523.c
> index 979e53e635228..4341eb66c0b75 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun55i-a523.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun55i-a523.c
[ ... ]
> @@ -1698,6 +1709,10 @@ static int sun55i_a523_ccu_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> + /* Reparent the GPU during pll-gpu rate changes */
> + ccu_mux_notifier_register(pll_gpu_clk.common.hw.clk,
> + &sun55i_a523_gpu_nb);
> +
[Severity: High]
Does pll_gpu_clk still have the CLK_SET_RATE_GATE flag set?
Looking at drivers/clk/sunxi-ng/ccu-sun55i-a523.c, pll_gpu_clk is defined
with:
.hw.init = CLK_HW_INIT_PARENTS_DATA("pll-gpu", osc24M,
&ccu_nkmp_ops,
CLK_SET_RATE_GATE),
The core clock framework enforces this in clk_core_set_rate_nolock():
if (clk_core_rate_is_protected(core))
return -EBUSY;
If the GPU driver calls clk_set_rate() while the clock is active, will the
core framework return -EBUSY and prevent the rate change from happening,
rendering this new notifier unused?
[Severity: Medium]
What happens if ccu_mux_notifier_register fails and returns an error?
If there is a low memory condition and clk_notifier_register returns
-ENOMEM, the registration will fail but the probe continues. Will this
leave the GPU clock without the mandatory glitch-free bypass protection
during rate changes?
[Severity: High]
Is it possible this introduces a use-after-free during module unload?
sun55i_a523_ccu_driver does not appear to have a .remove callback to
unregister this notifier.
If the module is unloaded (e.g. via rmmod), the statically allocated
sun55i_a523_gpu_nb is freed. If a clock rate change occurs on pll-gpu
afterwards, or if the global clock notifier list is traversed, could this
crash the system?
[Severity: High]
This is a pre-existing issue, but how does the notifier handle an aborted
rate change?
In drivers/clk/sunxi-ng/ccu_mux.c, ccu_mux_notifier_cb only handles
PRE_RATE_CHANGE and POST_RATE_CHANGE:
if (event == PRE_RATE_CHANGE) {
...
} else if (event == POST_RATE_CHANGE) {
...
If a clock rate change fails downstream after PRE_RATE_CHANGE, the core
emits ABORT_RATE_CHANGE. Since this event is dropped, will the GPU clock
remain permanently stuck at the bypass rate of 600MHz?
[Severity: Medium]
This is a pre-existing issue, but can ccu_mux_helper_set_parent read out of
bounds during POST_RATE_CHANGE?
If the bootloader leaves the hardware mux register with an unmapped value
like 6 or 7, ccu_mux_helper_get_parent returns this raw index. Later,
during the notifier callback, ccu_mux_helper_set_parent blindly uses it:
if (cm->table)
index = cm->table[index];
Since gpu_mux_table only has 5 elements:
static const u8 gpu_mux_table[] = { 0, 2, 3, 4, 5 };
Could this result in an out-of-bounds read and write junk back to the
hardware register?
> return 0;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260719211319.982285-1-juanmanuellopezcarrillo@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH 4/4] iio: dac: ad5686: update device list and file header comments
From: Jonathan Cameron @ 2026-07-19 21:30 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay
Cc: rodrigo.alencar, Michael Auchter, linux, linux-iio, devicetree,
linux-kernel, Michael Hennerich, David Lechner, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20260719-ad5686-extend-dev-support-v1-4-841ec75cf5d8@analog.com>
On Sun, 19 Jul 2026 10:52:00 +0100
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> Update device list entries in Kconfig and remove device description from
> file headers. One can rely on the ID table(s) to check for supported
> devices. Adjust comment header accordingly and update Copyright notice in
> comment file headers with the current year.
>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
> ---
Main comments here are about the patch break up. I think it needs
just enough modification for a v2 to be needed.
> drivers/iio/dac/Kconfig | 31 ++++++++++++++++++++++++-------
> drivers/iio/dac/ad5686-spi.c | 7 ++-----
> drivers/iio/dac/ad5686.c | 4 ++--
> drivers/iio/dac/ad5696-i2c.c | 6 ++----
> 4 files changed, 30 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> index d6d560c09e25..ba2065241af3 100644
> --- a/drivers/iio/dac/Kconfig
> +++ b/drivers/iio/dac/Kconfig
> @@ -251,9 +251,18 @@ config AD5686_SPI
> depends on SPI
> select AD5686
> help
> - Say yes here to build support for Analog Devices AD5672R, AD5674R,
> - AD5676, AD5676R, AD5679R, AD5684, AD5684R, AD5684R, AD5685R, AD5686,
> - AD5686R Voltage Output Digital to Analog Converter.
Given this is adding entrees that were in the previous patch, I'd have
preferred to see the more complex dance of a precursor patch before that
which did the reformat (and dropped the stuff form the c files)
That would then be followed the new stuff being added as part of the previous
patch.
Whilst the ends result is the same I think it is worth doing a v2 just
to clean that break down of patches up.
> + Say yes here to build support for Analog Devices Voltage Output
> + Digital to Analog Converters:
> + - Single-channel:
> + AD5310R, AD5681R, AD5682R, AD5683R, AD5683R
Eagle eyed Sashiko spotted last entry is a duplicate.
> + - Dual-channel:
> + AD5313R, AD5687, AD5687R, AD5689, AD5689R
> + - Quad-channel:
> + AD5317R, AD5684, AD5684R, AD5685R, AD5686, AD5686R
> + - 8-channel:
> + AD5672R, AD5676, AD5676R
> + - 16-channel:
> + AD5674, AD5674R, AD5679, AD5679R
>
> To compile this driver as a module, choose M here: the
> module will be called ad5686.
> @@ -263,10 +272,18 @@ config AD5696_I2C
> depends on I2C
> select AD5686
> help
> - Say yes here to build support for Analog Devices AD5311R, AD5337,
> - AD5338R, AD5671R, AD5673R, AD5675R, AD5677R, AD5691R, AD5692R, AD5693,
> - AD5693R, AD5694, AD5694R, AD5695R, AD5696, and AD5696R Digital to
> - Analog converters.
> + Say yes here to build support for Analog Devices Voltage Output
> + Digital to Analog Converters:
> + - Single-channel:
> + AD5311R, AD5691R, AD5692R, AD5693, AD5693R
> + - Dual-channel:
> + AD5338R, AD5697R
> + - Quad-channel:
> + AD5316R, AD5694, AD5694R, AD5695R, AD5696, AD5696R
> + - 8-channel:
> + AD5671R, AD5675, AD5675R
> + - 16-channel:
> + AD5673R, AD5677R
>
> To compile this driver as a module, choose M here: the module will be
> called ad5696.
> diff --git a/drivers/iio/dac/ad5686-spi.c b/drivers/iio/dac/ad5686-spi.c
> index 003541edb742..b4531b49cb22 100644
> --- a/drivers/iio/dac/ad5686-spi.c
> +++ b/drivers/iio/dac/ad5686-spi.c
> @@ -1,11 +1,8 @@
> // SPDX-License-Identifier: GPL-2.0
> /*
> - * AD5672R, AD5674R, AD5676, AD5676R, AD5679R,
> - * AD5681R, AD5682R, AD5683, AD5683R, AD5684,
> - * AD5684R, AD5685R, AD5686, AD5686R
> - * Digital to analog converters driver
> + * SPI driver for AD5686 and similar Digital to Analog Converters
> *
> - * Copyright 2018 Analog Devices Inc.
> + * Copyright 2018-2026 Analog Devices Inc.
That definitely belongs in the patch that made a real change, not one
that is just messing with comments.
> */
>
> #include <linux/array_size.h>
^ permalink raw reply
* Re: [PATCH v1 1/4] clk: sunxi-ng: add cycle-masking divider (maskdiv) clock type
From: sashiko-bot @ 2026-07-19 21:24 UTC (permalink / raw)
To: Juan Manuel López Carrillo; +Cc: linux-sunxi, robh, conor+dt, devicetree
In-Reply-To: <20260719211319.982285-2-juanmanuellopezcarrillo@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] ccu_maskdiv_determine_rate ignores the CLK_SET_RATE_PARENT flag, breaking rate propagation.
- [Medium] ccu_maskdiv_set_rate fails to apply CCU_FEATURE_UPDATE_BIT and CCU_FEATURE_KEY_FIELD, causing inconsistent state latching.
--
--- Patch [1]: [PATCH v1 1/4] clk: sunxi-ng: add cycle-masking divider (maskdiv) clock type ---
commit 07eec9d5dafd1fbf248e0e56bb3c42f8da46589d
Author: Juan Manuel López Carrillo <juanmanuellopezcarrillo@gmail.com>
clk: sunxi-ng: add cycle-masking divider (maskdiv) clock type
This commit introduces a cycle-masking divider clock type for sunxi-ng.
Instead of a linear divider, it masks M pulses out of every 2^width parent
cycles, which is used for hardware like the A523/T527 GPU clock.
> diff --git a/drivers/clk/sunxi-ng/ccu_maskdiv.c b/drivers/clk/sunxi-ng/ccu_maskdiv.c
> new file mode 100644
> index 0000000000000..2d3cccf081493
> --- /dev/null
> +++ b/drivers/clk/sunxi-ng/ccu_maskdiv.c
> @@ -0,0 +1,199 @@
[ ... ]
> +static int ccu_maskdiv_determine_rate(struct clk_hw *hw,
> + struct clk_rate_request *req)
> +{
> + struct ccu_maskdiv *cmd = hw_to_ccu_maskdiv(hw);
> + unsigned long best_rate = 0, best_parent_rate = 0;
> + struct clk_hw *best_parent = NULL;
> + unsigned int best_m = UINT_MAX;
> + unsigned int i;
> +
> + for (i = 0; i < clk_hw_get_num_parents(hw); i++) {
> + struct clk_hw *parent = clk_hw_get_parent_by_index(hw, i);
> + unsigned long parent_rate, new_rate;
> + unsigned int m;
> +
> + if (!parent)
> + continue;
> +
> + parent_rate = clk_hw_get_rate(parent);
> + m = ccu_maskdiv_find_m(parent_rate, req->rate, cmd->width);
> + new_rate = ccu_maskdiv_calc_rate(parent_rate, m, cmd->width);
[Severity: High]
Does this implementation ignore the CLK_SET_RATE_PARENT flag?
By using clk_hw_get_rate(parent) instead of clk_hw_round_rate(), this loop
only evaluates parents at their currently locked rates. It appears this
prevents the framework from adjusting the parent's rate (such as the
underlying pll-gpu).
Could this silently break Dynamic Voltage and Frequency Scaling (DVFS) by
locking the GPU to a masked fraction of the PLL's fixed boot rate?
> +
> + if (new_rate > req->rate)
> + continue;
[ ... ]
> +static int ccu_maskdiv_set_rate(struct clk_hw *hw, unsigned long rate,
> + unsigned long parent_rate)
> +{
> + struct ccu_maskdiv *cmd = hw_to_ccu_maskdiv(hw);
> + unsigned int m;
> + unsigned long flags;
> + u32 reg;
> +
> + m = ccu_maskdiv_find_m(parent_rate, rate, cmd->width);
> +
> + spin_lock_irqsave(cmd->common.lock, flags);
> +
> + reg = readl(cmd->common.base + cmd->common.reg);
> + reg &= ~GENMASK(cmd->shift + cmd->width - 1, cmd->shift);
> + writel(reg | (m << cmd->shift), cmd->common.base + cmd->common.reg);
[Severity: Medium]
Will hardware register updates fail to latch here if the clock requires the
CCU_SUNXI_UPDATE_BIT or CCU_FEATURE_KEY_FIELD?
The standard ccu_common framework relies on these feature bits to
synchronize hardware changes, which ccu_mux_helper_set_parent() applies
automatically.
Since this direct write ignores cmd->common.features, could rate changes
silently fail to apply for clocks that require the update bit?
> +
> + spin_unlock_irqrestore(cmd->common.lock, flags);
> +
> + return 0;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260719211319.982285-1-juanmanuellopezcarrillo@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: iio: dac: ad5696: extend device support
From: Jonathan Cameron @ 2026-07-19 21:18 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay
Cc: rodrigo.alencar, Michael Auchter, linux, linux-iio, devicetree,
linux-kernel, Michael Hennerich, David Lechner, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Conor Dooley
In-Reply-To: <20260719-ad5686-extend-dev-support-v1-1-841ec75cf5d8@analog.com>
On Sun, 19 Jul 2026 10:51:57 +0100
Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> Support for AD5316R, AD5673R, AD5675, AD5677R and AD5697R missing from the
I'd drop the 'missing' given I think until this series they weren't used.
If nothing else comes up I'll just make that change whilst applying.
> device-tree bindings documentation. These devices have different bit
> resolutions or different number of channels so no fallback compatibles
> are used.
>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
> ---
> Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml
> index e10f8596f9d3..835fa21c474e 100644
> --- a/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml
> +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml
> @@ -16,10 +16,14 @@ properties:
> compatible:
> enum:
> - adi,ad5311r
> + - adi,ad5316r
> - adi,ad5337r
> - adi,ad5338r
> - adi,ad5671r
> + - adi,ad5673r
> + - adi,ad5675
> - adi,ad5675r
> + - adi,ad5677r
> - adi,ad5691r
> - adi,ad5692r
> - adi,ad5693
> @@ -29,6 +33,7 @@ properties:
> - adi,ad5695r
> - adi,ad5696
> - adi,ad5696r
> + - adi,ad5697r
>
> reg:
> maxItems: 1
> @@ -84,6 +89,7 @@ allOf:
> compatible:
> contains:
> enum:
> + - adi,ad5675
> - adi,ad5693
> - adi,ad5694
> - adi,ad5696
>
^ permalink raw reply
* [PATCH v1 4/4] arm64: dts: allwinner: t527-orangepi-4a: add GPU OPP table
From: Juan Manuel López Carrillo @ 2026-07-19 21:13 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland
Cc: Brian Masney, Andre Przywara, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-clk, linux-sunxi, linux-arm-kernel,
devicetree, linux-kernel, Juan Manuel López Carrillo
In-Reply-To: <20260719211319.982285-1-juanmanuellopezcarrillo@gmail.com>
Add the Mali-G57 operating points from the vendor BSP universal table
(150/200/300/400/600 MHz) so panfrost devfreq can scale the GPU
instead of running at the boot clock.
All operating points use 920 mV: the BSP table specifies 900 mV for
every universal OPP, but on this board the GPU rail (AXP717 DCDC2,
vdd-gpu-sys) is a fixed 920 mV supply, so the OPP voltage states the
actual rail value and voltage transitions are no-ops. The higher
speed-bin points of the BSP (648-792 MHz) are not included: they are
gated by a SID efuse bin and need pll-gpu as a live parent.
Depends on the sun55i-a523 GPU clock divider fix (the OPP rates are
only produced correctly with the cycle-masking divider model);
validated on hardware with the Mali cycle counter: 149/199/300/399/597
MHz measured under load, thermal-emulation throttling included.
Signed-off-by: Juan Manuel López Carrillo <juanmanuellopezcarrillo@gmail.com>
---
.../dts/allwinner/sun55i-t527-orangepi-4a.dts | 30 +++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun55i-t527-orangepi-4a.dts b/arch/arm64/boot/dts/allwinner/sun55i-t527-orangepi-4a.dts
index 055be86e5..0fd73a1bb 100644
--- a/arch/arm64/boot/dts/allwinner/sun55i-t527-orangepi-4a.dts
+++ b/arch/arm64/boot/dts/allwinner/sun55i-t527-orangepi-4a.dts
@@ -30,6 +30,35 @@ ext_osc32k: ext-osc32k-clk {
clock-output-names = "ext_osc32k";
};
+ gpu_opp_table: opp-table-gpu {
+ compatible = "operating-points-v2";
+
+ opp-150000000 {
+ opp-hz = /bits/ 64 <150000000>;
+ opp-microvolt = <920000>;
+ };
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ opp-microvolt = <920000>;
+ };
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ opp-microvolt = <920000>;
+ };
+
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-microvolt = <920000>;
+ };
+
+ opp-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <920000>;
+ };
+ };
+
leds {
compatible = "gpio-leds";
@@ -116,6 +145,7 @@ &gmac1 {
&gpu {
mali-supply = <®_dcdc2>;
+ operating-points-v2 = <&gpu_opp_table>;
status = "okay";
};
--
2.47.3
^ permalink raw reply related
* [PATCH v1 3/4] clk: sunxi-ng: sun55i-a523: reparent GPU while pll-gpu changes rate
From: Juan Manuel López Carrillo @ 2026-07-19 21:13 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland
Cc: Brian Masney, Andre Przywara, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-clk, linux-sunxi, linux-arm-kernel,
devicetree, linux-kernel, Juan Manuel López Carrillo
In-Reply-To: <20260719211319.982285-1-juanmanuellopezcarrillo@gmail.com>
Register the existing sunxi-ng mux notifier on pll-gpu so the GPU mod
clock is parked on the fixed pll-periph0-600M output while the PLL is
being reprogrammed, and switched back once it has locked, following the
cpux precedent of other sunxi SoCs. The mux switch is glitch-free per
the T527 manual (GPU_CLK_REG, "The clock selection supports glitch-free
switch").
Nothing retunes pll-gpu at runtime today (the mux does not propagate
rate requests and all standard OPPs resolve to pll-periph0 outputs),
but the higher speed-bin operating points (648-792 MHz) will need
pll-gpu as a live parent, and any direct clk_set_rate() on the PLL is
now safe.
Signed-off-by: Juan Manuel López Carrillo <juanmanuellopezcarrillo@gmail.com>
---
drivers/clk/sunxi-ng/ccu-sun55i-a523.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu-sun55i-a523.c b/drivers/clk/sunxi-ng/ccu-sun55i-a523.c
index 979e53e63..4341eb66c 100644
--- a/drivers/clk/sunxi-ng/ccu-sun55i-a523.c
+++ b/drivers/clk/sunxi-ng/ccu-sun55i-a523.c
@@ -1667,6 +1667,17 @@ static const u32 pll_regs[] = {
SUN55I_A523_PLL_NPU_REG,
};
+/*
+ * Park the GPU on the fixed pll-periph0-600M output while pll-gpu
+ * changes rate; the mux switch is glitch-free (T527 manual, GPU_CLK_REG).
+ */
+static struct ccu_mux_nb sun55i_a523_gpu_nb = {
+ .common = &gpu_clk.common,
+ .cm = &gpu_clk.mux,
+ .delay_us = 1,
+ .bypass_index = 1, /* pll-periph0-600M */
+};
+
static int sun55i_a523_ccu_probe(struct platform_device *pdev)
{
void __iomem *reg;
@@ -1698,6 +1709,10 @@ static int sun55i_a523_ccu_probe(struct platform_device *pdev)
if (ret)
return ret;
+ /* Reparent the GPU during pll-gpu rate changes */
+ ccu_mux_notifier_register(pll_gpu_clk.common.hw.clk,
+ &sun55i_a523_gpu_nb);
+
return 0;
}
--
2.47.3
^ permalink raw reply related
* [PATCH v1 2/4] clk: sunxi-ng: sun55i-a523: GPU clock divider is fractional, not linear
From: Juan Manuel López Carrillo @ 2026-07-19 21:13 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland
Cc: Brian Masney, Andre Przywara, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-clk, linux-sunxi, linux-arm-kernel,
devicetree, linux-kernel, Juan Manuel López Carrillo
In-Reply-To: <20260719211319.982285-1-juanmanuellopezcarrillo@gmail.com>
The GPU mod clock (0x670) was modelled as a linear M+1 divider, but the
M factor of this register is a cycle-masking divider: GPU_CLK = Clock
Source * ((16-M)/16) (T527 user manual v0.92, section 2.7.6.58).
With the linear model every OPP that needed M > 0 silently ran the GPU
faster than requested. Measured on an Orange Pi 4A (T527) with the
Mali cycle counter against the programmed register:
OPP request programmed real rate
150 MHz 600M, M=3 487.5 MHz
200 MHz 800M, M=3 650 MHz
300 MHz 600M, M=1 562.5 MHz
400 MHz 800M, M=1 750 MHz
600 MHz 600M, M=0 600 MHz
i.e. the "400 MHz" OPP ran the GPU at 750 MHz, 25% above the vendor
ceiling of 600 MHz, at the low-OPP voltage. Thermal throttling to
"400 MHz" actually overclocked the GPU.
Switch the clock to the maskdiv type. With least-masking preference
the vendor OPP set now resolves to 600/400/300/200 MHz taken undivided
from their periph outputs and 150 MHz = pll-periph0-200M * 12/16, all
verified exact on hardware with the same cycle-counter method.
Drop pll-periph0-800M from the selectable parents (the mux table skips
hardware index 1): the vendor BSP removed it from its parent list with
the comment "If GPU use pll-peri0-800m, gpu will occur job fault", and
with the masking semantics every vendor OPP matches exactly from the
800M parent first, so it would otherwise always be chosen.
Also drop CLK_SET_RATE_PARENT: every OPP is reachable from the fixed
pll-periph0 outputs, and pll-gpu must never be reprogrammed through this
mux. Once the GPU moves off pll-gpu the PLL is no longer prepared, so
it loses the rate protection of CLK_SET_RATE_GATE; a propagated rate
request would then reprogram the PLL while its gate is off (the lock
bit never asserts, 70 ms poll timeout per transition) and switch the
running GPU onto it before it locks.
Fixes: 6702d17f54a8 ("clk: sunxi-ng: a523: add video mod clocks")
Signed-off-by: Juan Manuel López Carrillo <juanmanuellopezcarrillo@gmail.com>
---
drivers/clk/sunxi-ng/ccu-sun55i-a523.c | 32 +++++++++++++++++++++-----
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun55i-a523.c b/drivers/clk/sunxi-ng/ccu-sun55i-a523.c
index 20dad06b3..979e53e63 100644
--- a/drivers/clk/sunxi-ng/ccu-sun55i-a523.c
+++ b/drivers/clk/sunxi-ng/ccu-sun55i-a523.c
@@ -21,6 +21,7 @@
#include "ccu_div.h"
#include "ccu_gate.h"
+#include "ccu_maskdiv.h"
#include "ccu_mp.h"
#include "ccu_mult.h"
#include "ccu_nk.h"
@@ -442,18 +443,37 @@ static SUNXI_CCU_GATE_HWS(bus_g2d_clk, "bus-g2d", ahb_hws, 0x63c, BIT(0), 0);
static const struct clk_hw *gpu_parents[] = {
&pll_gpu_clk.common.hw,
- &pll_periph0_800M_clk.common.hw,
&pll_periph0_600M_clk.hw,
&pll_periph0_400M_clk.hw,
&pll_periph0_300M_clk.hw,
&pll_periph0_200M_clk.hw,
};
-static SUNXI_CCU_M_HW_WITH_MUX_GATE(gpu_clk, "gpu", gpu_parents, 0x670,
- 0, 4, /* M */
- 24, 3, /* mux */
- BIT(31), /* gate */
- CLK_SET_RATE_PARENT);
+/*
+ * Mux index 1 (pll-periph0-800M) is skipped: the vendor BSP removed it
+ * from the parent list ("If GPU use pll-peri0-800m, gpu will occur job
+ * fault"), and with the masking divider every OPP would match exactly
+ * from it first.
+ */
+static const u8 gpu_mux_table[] = { 0, 2, 3, 4, 5 };
+
+/*
+ * The M factor is a cycle-masking (fractional) divider, not a linear
+ * one: rate = source * (16 - M) / 16 (T527 manual, GPU_CLK_REG).
+ *
+ * No CLK_SET_RATE_PARENT: every GPU OPP is reachable from the fixed
+ * pll-periph0 outputs, and pll-gpu must never be reprogrammed through this mux.
+ * Once the GPU moves off pll-gpu the PLL is no longer prepared, so it loses
+ * the rate protection of CLK_SET_RATE_GATE; a propagated rate request would
+ * then reprogram the PLL while its gate is off (the lock bit never asserts,
+ * 70 ms timeout) and switch the running GPU onto it before it locks.
+ */
+static SUNXI_CCU_MASKDIV_HW_WITH_MUX_TABLE_GATE(gpu_clk, "gpu", gpu_parents,
+ gpu_mux_table, 0x670,
+ 0, 4, /* M */
+ 24, 3, /* mux */
+ BIT(31), /* gate */
+ 0);
static SUNXI_CCU_GATE_HWS(bus_gpu_clk, "bus-gpu", ahb_hws, 0x67c, BIT(0), 0);
--
2.47.3
^ permalink raw reply related
* [PATCH v1 1/4] clk: sunxi-ng: add cycle-masking divider (maskdiv) clock type
From: Juan Manuel López Carrillo @ 2026-07-19 21:13 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland
Cc: Brian Masney, Andre Przywara, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-clk, linux-sunxi, linux-arm-kernel,
devicetree, linux-kernel, Juan Manuel López Carrillo
In-Reply-To: <20260719211319.982285-1-juanmanuellopezcarrillo@gmail.com>
Some mod clocks do not divide their parent with a linear M+1 divider:
the M factor masks (swallows) M pulses out of every 2^width parent
cycles, so the average output rate is
rate = parent * (2^width - M) / 2^width
and the surviving pulses keep the parent period. The A523/T527 GPU
clock (GPU_CLK_REG, 0x670) is such a divider: "FACTOR_M: mask M cycles
at 16 cycles", GPU_CLK = Clock Source * ((16-M)/16) (T527 user manual
v0.92, section 2.7.6.58).
Modelling these registers with the linear ccu_div type programs a
faster clock than requested for every M > 0 (e.g. M=1 on a 800 MHz
parent yields 750 MHz, not 400 MHz).
Add a small ccu type implementing the masking semantics. Because the
masked output is not an even pulse train, determine_rate prefers, among
the parents that reach the requested rate, the one needing the least
masking. set_rate_and_parent follows the same ordering rule as
clk_composite_set_rate_and_parent() so no intermediate configuration
overshoots both the old and the new rate.
Signed-off-by: Juan Manuel López Carrillo <juanmanuellopezcarrillo@gmail.com>
---
drivers/clk/sunxi-ng/Makefile | 1 +
drivers/clk/sunxi-ng/ccu_maskdiv.c | 199 +++++++++++++++++++++++++++++
drivers/clk/sunxi-ng/ccu_maskdiv.h | 71 ++++++++++
3 files changed, 271 insertions(+)
create mode 100644 drivers/clk/sunxi-ng/ccu_maskdiv.c
create mode 100644 drivers/clk/sunxi-ng/ccu_maskdiv.h
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index a1c4087d7..26313083c 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -10,6 +10,7 @@ sunxi-ccu-y += ccu_reset.o
# Base clock types
sunxi-ccu-y += ccu_div.o
sunxi-ccu-y += ccu_frac.o
+sunxi-ccu-y += ccu_maskdiv.o
sunxi-ccu-y += ccu_gate.o
sunxi-ccu-y += ccu_mux.o
sunxi-ccu-y += ccu_mult.o
diff --git a/drivers/clk/sunxi-ng/ccu_maskdiv.c b/drivers/clk/sunxi-ng/ccu_maskdiv.c
new file mode 100644
index 000000000..2d3cccf08
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu_maskdiv.c
@@ -0,0 +1,199 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2026 Juan Manuel López Carrillo
+ *
+ * Cycle-masking divider: the M factor masks M pulses out of every
+ * 2^width parent cycles instead of dividing the parent rate, so
+ *
+ * rate = parent * (2^width - M) / 2^width
+ *
+ * The masked output is not an even pulse train: the surviving pulses
+ * keep the parent period. Rate selection therefore prefers, among the
+ * parents that reach the requested rate, the one needing the least
+ * masking.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/io.h>
+#include <linux/math64.h>
+
+#include "ccu_gate.h"
+#include "ccu_maskdiv.h"
+
+static unsigned long ccu_maskdiv_calc_rate(unsigned long parent_rate,
+ unsigned int m, unsigned int width)
+{
+ unsigned int n = 1 << width;
+
+ return div_u64((u64)parent_rate * (n - m), n);
+}
+
+/*
+ * Smallest M (least masking) whose output does not exceed the requested
+ * rate; masking everything (M == 2^width) is never returned.
+ */
+static unsigned int ccu_maskdiv_find_m(unsigned long parent_rate,
+ unsigned long rate, unsigned int width)
+{
+ unsigned int n = 1 << width;
+ u64 kept;
+
+ if (!parent_rate || rate >= parent_rate)
+ return 0;
+
+ kept = div64_ul((u64)rate * n, parent_rate);
+ if (!kept)
+ kept = 1;
+
+ return n - (unsigned int)kept;
+}
+
+static void ccu_maskdiv_disable(struct clk_hw *hw)
+{
+ struct ccu_maskdiv *cmd = hw_to_ccu_maskdiv(hw);
+
+ return ccu_gate_helper_disable(&cmd->common, cmd->enable);
+}
+
+static int ccu_maskdiv_enable(struct clk_hw *hw)
+{
+ struct ccu_maskdiv *cmd = hw_to_ccu_maskdiv(hw);
+
+ return ccu_gate_helper_enable(&cmd->common, cmd->enable);
+}
+
+static int ccu_maskdiv_is_enabled(struct clk_hw *hw)
+{
+ struct ccu_maskdiv *cmd = hw_to_ccu_maskdiv(hw);
+
+ return ccu_gate_helper_is_enabled(&cmd->common, cmd->enable);
+}
+
+static unsigned long ccu_maskdiv_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct ccu_maskdiv *cmd = hw_to_ccu_maskdiv(hw);
+ unsigned int m;
+ u32 reg;
+
+ reg = readl(cmd->common.base + cmd->common.reg);
+ m = (reg >> cmd->shift) & ((1 << cmd->width) - 1);
+
+ return ccu_maskdiv_calc_rate(parent_rate, m, cmd->width);
+}
+
+static int ccu_maskdiv_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
+{
+ struct ccu_maskdiv *cmd = hw_to_ccu_maskdiv(hw);
+ unsigned long best_rate = 0, best_parent_rate = 0;
+ struct clk_hw *best_parent = NULL;
+ unsigned int best_m = UINT_MAX;
+ unsigned int i;
+
+ for (i = 0; i < clk_hw_get_num_parents(hw); i++) {
+ struct clk_hw *parent = clk_hw_get_parent_by_index(hw, i);
+ unsigned long parent_rate, new_rate;
+ unsigned int m;
+
+ if (!parent)
+ continue;
+
+ parent_rate = clk_hw_get_rate(parent);
+ m = ccu_maskdiv_find_m(parent_rate, req->rate, cmd->width);
+ new_rate = ccu_maskdiv_calc_rate(parent_rate, m, cmd->width);
+
+ if (new_rate > req->rate)
+ continue;
+
+ /* Closest rate first; on ties, the least masking */
+ if (new_rate > best_rate ||
+ (new_rate == best_rate && m < best_m)) {
+ best_rate = new_rate;
+ best_parent_rate = parent_rate;
+ best_parent = parent;
+ best_m = m;
+ }
+ }
+
+ if (!best_parent)
+ return -EINVAL;
+
+ req->best_parent_hw = best_parent;
+ req->best_parent_rate = best_parent_rate;
+ req->rate = best_rate;
+
+ return 0;
+}
+
+static int ccu_maskdiv_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct ccu_maskdiv *cmd = hw_to_ccu_maskdiv(hw);
+ unsigned int m;
+ unsigned long flags;
+ u32 reg;
+
+ m = ccu_maskdiv_find_m(parent_rate, rate, cmd->width);
+
+ spin_lock_irqsave(cmd->common.lock, flags);
+
+ reg = readl(cmd->common.base + cmd->common.reg);
+ reg &= ~GENMASK(cmd->shift + cmd->width - 1, cmd->shift);
+ writel(reg | (m << cmd->shift), cmd->common.base + cmd->common.reg);
+
+ spin_unlock_irqrestore(cmd->common.lock, flags);
+
+ return 0;
+}
+
+static u8 ccu_maskdiv_get_parent(struct clk_hw *hw)
+{
+ struct ccu_maskdiv *cmd = hw_to_ccu_maskdiv(hw);
+
+ return ccu_mux_helper_get_parent(&cmd->common, &cmd->mux);
+}
+
+static int ccu_maskdiv_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct ccu_maskdiv *cmd = hw_to_ccu_maskdiv(hw);
+
+ return ccu_mux_helper_set_parent(&cmd->common, &cmd->mux, index);
+}
+
+static int ccu_maskdiv_set_rate_and_parent(struct clk_hw *hw,
+ unsigned long rate,
+ unsigned long parent_rate, u8 index)
+{
+ /*
+ * Same ordering rule as clk_composite_set_rate_and_parent(): if
+ * switching the mux with the current M would overshoot the
+ * requested rate, program the divider first, so the
+ * intermediate rate never exceeds both the old and the new
+ * rate.
+ */
+ if (ccu_maskdiv_recalc_rate(hw, parent_rate) > rate) {
+ ccu_maskdiv_set_rate(hw, rate, parent_rate);
+ ccu_maskdiv_set_parent(hw, index);
+ } else {
+ ccu_maskdiv_set_parent(hw, index);
+ ccu_maskdiv_set_rate(hw, rate, parent_rate);
+ }
+
+ return 0;
+}
+
+const struct clk_ops ccu_maskdiv_ops = {
+ .disable = ccu_maskdiv_disable,
+ .enable = ccu_maskdiv_enable,
+ .is_enabled = ccu_maskdiv_is_enabled,
+
+ .get_parent = ccu_maskdiv_get_parent,
+ .set_parent = ccu_maskdiv_set_parent,
+
+ .determine_rate = ccu_maskdiv_determine_rate,
+ .recalc_rate = ccu_maskdiv_recalc_rate,
+ .set_rate = ccu_maskdiv_set_rate,
+ .set_rate_and_parent = ccu_maskdiv_set_rate_and_parent,
+};
+EXPORT_SYMBOL_NS_GPL(ccu_maskdiv_ops, "SUNXI_CCU");
diff --git a/drivers/clk/sunxi-ng/ccu_maskdiv.h b/drivers/clk/sunxi-ng/ccu_maskdiv.h
new file mode 100644
index 000000000..3cbfce064
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu_maskdiv.h
@@ -0,0 +1,71 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2026 Juan Manuel López Carrillo
+ */
+
+#ifndef _CCU_MASKDIV_H_
+#define _CCU_MASKDIV_H_
+
+#include <linux/clk-provider.h>
+
+#include "ccu_common.h"
+#include "ccu_mux.h"
+
+/*
+ * struct ccu_maskdiv - cycle-masking ("fractional") divider
+ *
+ * This divider does not divide the parent clock: it masks (swallows) M
+ * pulses out of every 2^width parent cycles, so the average output rate
+ * is
+ *
+ * rate = parent * (2^width - M) / 2^width
+ *
+ * with the remaining pulses keeping the parent period. The A523/T527
+ * GPU clock (GPU_CLK_REG, 0x670) is such a divider: "FACTOR_M: mask M
+ * cycles at 16 cycles", GPU_CLK = Clock Source * ((16-M)/16) (T527 user
+ * manual v0.92, section 2.7.6.58).
+ *
+ * @shift: shift of the M field in the register
+ * @width: width of the M field; the mask window is 2^width cycles
+ */
+struct ccu_maskdiv {
+ u32 enable;
+
+ u8 shift;
+ u8 width;
+
+ struct ccu_mux_internal mux;
+ struct ccu_common common;
+};
+
+#define SUNXI_CCU_MASKDIV_HW_WITH_MUX_TABLE_GATE(_struct, _name, \
+ _parents, _table, \
+ _reg, \
+ _mshift, _mwidth, \
+ _muxshift, _muxwidth, \
+ _gate, _flags) \
+ struct ccu_maskdiv _struct = { \
+ .enable = _gate, \
+ .shift = _mshift, \
+ .width = _mwidth, \
+ .mux = _SUNXI_CCU_MUX_TABLE(_muxshift, _muxwidth, \
+ _table), \
+ .common = { \
+ .reg = _reg, \
+ .hw.init = CLK_HW_INIT_PARENTS_HW(_name, \
+ _parents, \
+ &ccu_maskdiv_ops, \
+ _flags), \
+ }, \
+ }
+
+static inline struct ccu_maskdiv *hw_to_ccu_maskdiv(struct clk_hw *hw)
+{
+ struct ccu_common *common = hw_to_ccu_common(hw);
+
+ return container_of(common, struct ccu_maskdiv, common);
+}
+
+extern const struct clk_ops ccu_maskdiv_ops;
+
+#endif /* _CCU_MASKDIV_H_ */
--
2.47.3
^ permalink raw reply related
* [PATCH v1 0/4] clk: sunxi-ng: fix the A523/T527 GPU clock model, enable GPU DVFS
From: Juan Manuel López Carrillo @ 2026-07-19 21:13 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland
Cc: Brian Masney, Andre Przywara, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-clk, linux-sunxi, linux-arm-kernel,
devicetree, linux-kernel, Juan Manuel López Carrillo
This series follows up on the discussion in [1], where Chen-Yu pointed
out that the A523/T527 GPU mod clock is not a standard divider but a
fractional one: GPU_CLK = Clock Source * ((16-M)/16), with M 0-15.
I checked this against the T527 user manual (v0.92, section 2.7.6.58,
"FACTOR_M: mask M cycles at 16 cycles") and verified it on hardware:
with the current linear model, forcing each OPP on an Orange Pi 4A and
measuring the real GPU frequency with the Mali cycle counter gives
OPP request programmed measured
150 MHz 600M, M=3 ~487 MHz
200 MHz 800M, M=3 648 MHz
300 MHz 600M, M=1 560 MHz
400 MHz 800M, M=1 749 MHz
600 MHz 600M, M=0 599 MHz
so every OPP below 600 MHz silently overclocks, up to 25% above the
vendor ceiling, and thermal throttling to "400 MHz" actually raises
the GPU frequency.
Patch 1 adds a small ccu type implementing the cycle-masking
semantics. Patch 2 switches the A523 GPU clock to it, drops
pll-periph0-800M from the selectable parents (the vendor BSP removed
it citing GPU job faults) and drops CLK_SET_RATE_PARENT (pll-gpu loses
its CLK_SET_RATE_GATE protection once the GPU runs from a periph
output). Patch 3 registers the existing sunxi-ng mux notifier so the
GPU is parked on pll-periph0-600M while pll-gpu changes rate, as
Chen-Yu suggested in the same thread. Patch 4 adds the BSP operating
points to the Orange Pi 4A DT, which enables panfrost devfreq.
With the series applied the same cycle-counter measurement reads
149/199/300/399/597 MHz for the five OPPs, all from the intended
parents, and devfreq scaling plus thermal throttling (emulated
temperature) behave correctly under load.
The higher speed-bin operating points of the BSP (648-792 MHz, gated
by a SID efuse bin, running from pll-gpu) are left for a follow-up.
[1] https://lore.kernel.org/linux-sunxi/20260719153122.892013-1-juanmanuellopezcarrillo@gmail.com/
Juan Manuel López Carrillo (4):
clk: sunxi-ng: add cycle-masking divider (maskdiv) clock type
clk: sunxi-ng: sun55i-a523: GPU clock divider is fractional, not
linear
clk: sunxi-ng: sun55i-a523: reparent GPU while pll-gpu changes rate
arm64: dts: allwinner: t527-orangepi-4a: add GPU OPP table
.../dts/allwinner/sun55i-t527-orangepi-4a.dts | 30 +++
drivers/clk/sunxi-ng/Makefile | 1 +
drivers/clk/sunxi-ng/ccu-sun55i-a523.c | 47 ++++-
drivers/clk/sunxi-ng/ccu_maskdiv.c | 199 ++++++++++++++++++
drivers/clk/sunxi-ng/ccu_maskdiv.h | 71 +++++++
5 files changed, 342 insertions(+), 6 deletions(-)
create mode 100644 drivers/clk/sunxi-ng/ccu_maskdiv.c
create mode 100644 drivers/clk/sunxi-ng/ccu_maskdiv.h
--
2.47.3
^ permalink raw reply
* [PATCH] dt-bindings: media: ti,am437x-vpfe: Convert to DT schema
From: Bhargav Joshi @ 2026-07-19 21:13 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Benoit Parrot
Cc: linux-media, devicetree, linux-kernel, goledhruva, m-chawdhry,
daniel.baluta, simona.toaca, j.bhargav.u
Convert Texas Instruments AM437x CAMERA Video Processing Front End
(VPFE) from legacy text to DT schema.
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
---
.../devicetree/bindings/media/ti,am437x-vpfe.yaml | 93 ++++++++++++++++++++++
.../devicetree/bindings/media/ti-am437x-vpfe.txt | 61 --------------
2 files changed, 93 insertions(+), 61 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/ti,am437x-vpfe.yaml b/Documentation/devicetree/bindings/media/ti,am437x-vpfe.yaml
new file mode 100644
index 000000000000..983e705ab1e8
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/ti,am437x-vpfe.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/ti,am437x-vpfe.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments AM437x CAMERA Video Processing Front End (VPFE)
+
+maintainers:
+ - Benoit Parrot <bparrot@ti.com>
+ - Bhargav Joshi <j.bhargav.u@gmail.com>
+
+description:
+ The Video Processing Front End (VPFE) is a key component for image capture
+ applications. The capture module provides the system interface and the
+ processing capability to connect RAW image-sensor modules and video decoders
+ to the AM437x device.
+
+properties:
+ compatible:
+ const: ti,am437x-vpfe
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ port:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ A single parallel input port connecting to an external image sensor or
+ video decoder. The VPFE supports only one input port per instance.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ ti,am437x-vpfe-interface:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3, 4]
+ description:
+ Selects the VPFE input interface type can be one of following
+ 0 - Raw Bayer (VPFE_RAW_BAYER)
+ 1 - BT.656 8-bit (VPFE_BT656)
+ 2 - BT.656 10-bit (VPFE_BT656_10BIT)
+ 3 - YCbCr 8-bit sync (VPFE_YCBCR_SYNC_8)
+ 4 - YCbCr 16-bit sync (VPFE_YCBCR_SYNC_16)
+
+ bus-width:
+ minimum: 8
+ maximum: 16
+
+ required:
+ - remote-endpoint
+ - ti,am437x-vpfe-interface
+ - bus-width
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - port
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ vpfe@48328000{
+ compatible = "ti,am437x-vpfe";
+ reg = <0x48328000 0x2000>;
+ interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&vpfe_pins_default>;
+ pinctrl-1 = <&vpfe_pins_sleep>;
+
+ port {
+ vpfe0_ep: endpoint {
+ remote-endpoint = <&ov2659_1>;
+ ti,am437x-vpfe-interface = <0>;
+ bus-width = <8>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/media/ti-am437x-vpfe.txt b/Documentation/devicetree/bindings/media/ti-am437x-vpfe.txt
deleted file mode 100644
index 3932e766553a..000000000000
--- a/Documentation/devicetree/bindings/media/ti-am437x-vpfe.txt
+++ /dev/null
@@ -1,61 +0,0 @@
-Texas Instruments AM437x CAMERA (VPFE)
---------------------------------------
-
-The Video Processing Front End (VPFE) is a key component for image capture
-applications. The capture module provides the system interface and the
-processing capability to connect RAW image-sensor modules and video decoders
-to the AM437x device.
-
-Required properties:
-- compatible: must be "ti,am437x-vpfe"
-- reg: physical base address and length of the registers set for the device;
-- interrupts: should contain IRQ line for the VPFE;
-- ti,am437x-vpfe-interface: can be one of the following,
- 0 - Raw Bayer Interface.
- 1 - 8 Bit BT656 Interface.
- 2 - 10 Bit BT656 Interface.
- 3 - YCbCr 8 Bit Interface.
- 4 - YCbCr 16 Bit Interface.
-
-VPFE supports a single port node with parallel bus. It should contain one
-'port' child node with child 'endpoint' node. Please refer to the bindings
-defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
-
-Example:
- vpfe: vpfe@f0034000 {
- compatible = "ti,am437x-vpfe";
- reg = <0x48328000 0x2000>;
- interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
-
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&vpfe_pins_default>;
- pinctrl-1 = <&vpfe_pins_sleep>;
-
- port {
- #address-cells = <1>;
- #size-cells = <0>;
-
- vpfe0_ep: endpoint {
- remote-endpoint = <&ov2659_1>;
- ti,am437x-vpfe-interface = <0>;
- bus-width = <8>;
- hsync-active = <0>;
- vsync-active = <0>;
- };
- };
- };
-
- i2c1: i2c@4802a000 {
-
- ov2659@30 {
- compatible = "ti,ov2659";
- reg = <0x30>;
-
- port {
- ov2659_1: endpoint {
- remote-endpoint = <&vpfe0_ep>;
- bus-width = <8>;
- mclk-frequency = <12000000>;
- };
- };
- };
---
base-commit: c6859eed755df351a3978b33cb92365f9b3e8f06
change-id: 20260720-ti-am437x-vpfe-739861b135ea
Best regards,
--
Bhargav
^ permalink raw reply related
* [PATCH V2] scsi: ufs: dt-bindings: Document the Maili UFS Controller
From: Nitin Rawat @ 2026-07-19 19:58 UTC (permalink / raw)
To: krzk+dt, robh, andersson, mani, alim.akhtar, bvanassche,
avri.altman, conor+dt
Cc: linux-arm-msm, linux-kernel, devicetree, linux-scsi, Nitin Rawat
Document the UFS Controller on Maili SoC.
Signed-off-by: Nitin Rawat <nitin.rawat@oss.qualcomm.com>
---
Change from v1:
1. Addressed Krzysztof's comment to update 'qcom,maili-ufshc'
to the allOf condition required for MCQ targets.
---
Documentation/devicetree/bindings/ufs/qcom,sm8650-ufshc.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/ufs/qcom,sm8650-ufshc.yaml b/Documentation/devicetree/bindings/ufs/qcom,sm8650-ufshc.yaml
index b441f0d26081..d03295806657 100644
--- a/Documentation/devicetree/bindings/ufs/qcom,sm8650-ufshc.yaml
+++ b/Documentation/devicetree/bindings/ufs/qcom,sm8650-ufshc.yaml
@@ -18,6 +18,7 @@ select:
- qcom,eliza-ufshc
- qcom,hawi-ufshc
- qcom,kaanapali-ufshc
+ - qcom,maili-ufshc
- qcom,nord-ufshc
- qcom,sm8650-ufshc
- qcom,sm8750-ufshc
@@ -31,6 +32,7 @@ properties:
- qcom,eliza-ufshc
- qcom,hawi-ufshc
- qcom,kaanapali-ufshc
+ - qcom,maili-ufshc
- qcom,nord-ufshc
- qcom,sm8650-ufshc
- qcom,sm8750-ufshc
@@ -78,6 +80,7 @@ allOf:
contains:
enum:
- qcom,eliza-ufshc
+ - qcom,maili-ufshc
- qcom,nord-ufshc
then:
properties:
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 2/2] ASoC: codecs: add TAS2557 mono smart amplifier driver
From: Mark Brown @ 2026-07-19 19:05 UTC (permalink / raw)
To: Gianluca Boiano
Cc: Liam Girdwood, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jaroslav Kysela, Takashi Iwai, Shenghao Ding, Kevin Lu, Baojun Xu,
Wang, Sen, linux-sound, devicetree, linux-kernel
In-Reply-To: <20260717233402.414326-3-morf3089@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3388 bytes --]
On Sat, Jul 18, 2026 at 01:34:00AM +0200, Gianluca Boiano wrote:
> The TAS2557 is a mono Class-D smart amplifier with an on-chip DSP for
> speaker protection. Audio is received over I2S/TDM (ASI) and processed
> by DSP firmware before reaching the Class-D output stage.
> +static const unsigned int tas2557_startup_data[] = {
> + TAS2557_GPI_PIN_REG, 0x15, /* enable DIN, MCLK, CCI */
> + TAS2557_GPIO1_PIN_REG, 0x01, /* enable BCLK (ASI1) */
> + TAS2557_GPIO2_PIN_REG, 0x01, /* enable WCLK (ASI1) */
> + /* ASI2 GPIO wiring; arm the BCLK source (GPIO5) before its dividers */
> + TAS2557_GPIO6_PIN_REG, 0x01, /* GPIO6 = ASI2 WCLK input */
> + TAS2557_GPIO8_PIN_REG, 0x02, /* GPIO8 = ASI2 DIN */
> + TAS2557_GPIO5_PIN_REG, 0x01, /* GPIO5 = ASI2 BCLK input */
This looks awfully board specific....
> +static int tas2557_dev_bulk_write(struct tas2557_priv *tas2557, unsigned int chn,
> + unsigned int reg, const u8 *data, size_t len)
> +{
> + int ret;
> +
> + /* The chip auto-increments past reg 0x7f into the page register */
> + if (TAS2557_PAGE_REG_ADDR(reg) + len > 128)
> + return -EINVAL;
I didn't check but is there room for sharing code with the other
multi-book TI devices?
> +static int fw_parse_header(struct tas2557_priv *tas2557,
> + struct tas2557_firmware *fw,
> + const u8 *data, size_t size)
> +{
> + fw->device = get_unaligned_be32(data); data += 4;
> + if (fw->device != TAS2557_FW_DEVICE_MONO &&
> + fw->device != TAS2557_FW_DEVICE_STEREO) {
> + dev_err(tas2557->dev,
> + "unsupported device %u in firmware (expected 2=mono or 3=stereo)\n",
> + fw->device);
> + return -EINVAL;
> + }
The tas2781 checks to see if there are one or two devices being
controlled by the driver and rejects a mismatch. Also, is there some
overlap in firmware formats here? Again I didn't actually check.
> +static int tas2557_set_program(struct tas2557_priv *tas2557,
> + unsigned int prog_idx, int config_idx)
> + /* Load PLL configuration for this config (firmware-driven) */
> + if (config->pll < fw->num_plls) {
> + ret = tas2557_load_pll(tas2557, config->pll);
> + if (ret < 0)
> + return ret;
> + }
Shouldn't an out of range value be an error?
> +static int tas2557_enable(struct tas2557_priv *tas2557, bool enable)
> +{
> + } else if (!enable && tas2557->powered) {
> + ret = tas2557_load_data_all(tas2557, tas2557_shutdown_data);
> + if (ret < 0)
> + dev_err(tas2557->dev, "shutdown failed: %d\n", ret);
> +
> + tas2557->powered = false;
> + tas2557->dac_muted = true;
> + tas2557->sense_muted = true;
> +
> + dev_dbg(tas2557->dev, "amplifier group powered off\n");
> + }
Does sense_muted get handled properly for suspend? The core mutes and
unmutes playback streams over suspend but not capture.
> +static int tas2557_hw_params(struct snd_pcm_substream *substream,
> + struct snd_pcm_hw_params *params,
> + struct snd_soc_dai *dai)
> + /* Commit cached stream state now the hardware writes have succeeded */
> + tas2557->sample_rate = rate;
> + tas2557->wordlength = wordlength;
This won't actually take effect if the device doesn't power down - you
should probably not set use_pmdown_time to force a power down/up, though
that's annoying when the configuration is the same.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v5 1/2] arm64: dts: qcom: sdm845-google: Add dual front IMX355 cameras
From: David Heidelberg @ 2026-07-19 18:57 UTC (permalink / raw)
To: sashiko-reviews; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260719182401.D720A1F000E9@smtp.kernel.org>
On 19/07/2026 20:24, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] Pinctrl for MCLK2 is attached to the camss consumer, causing a probe deadlock that breaks camera initialization.
> - [Medium] Incorrect pinctrl sleep state override for I2C bus causes power leakage and configuration conflict.
> --
>
> --- Patch [1]: [PATCH v5 1/2] arm64: dts: qcom: sdm845-google: Add dual front IMX355 cameras ---
> commit 650af867be78a11fabbd3346603a6fc8f7cb758f
> Author: David Heidelberg <david@ixit.cz>
>
> arm64: dts: qcom: sdm845-google: Add dual front IMX355 cameras
>
> The Pixel 3 features two front-facing Sony IMX355 sensors with different
> focal lengths (standard and wide-angle). Sensors are connected via CSIPHY
> port 1 and 2 and controlled over CCI I2C1, using MCLK2 as the clock source.
> This enables support for the dual front camera configuration.
>
>> diff --git a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
>> index 9368fd6b87515..cb5c261802bc9 100644
>> --- a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
>
> [ ... ]
>
>> @@ -351,6 +389,52 @@ vreg_s3c_0p6: smps3 {
>> };
>> };
>>
>> +&camss {
>> + vdda-phy-supply = <&vreg_l1a_0p875>;
>> + vdda-pll-supply = <&vreg_l26a_1p2>;
>> +
>> + /*
>> + * MCLK2 (GPIO15) is shared between both front camera sensors.
>> + * The clock is generated by CAMCC, therefore the pin is
>> + * configured here rather than in individual sensor nodes.
>> + */
>> + pinctrl-0 = <&cam_mclk2_default>;
>> + pinctrl-1 = <&cam_mclk2_sleep>;
>> + pinctrl-names = "default", "sleep";
>
> [Severity: High]
> Will this cause a probe deadlock that breaks camera initialization?
No
>
> Since fw_devlink parses the remote-endpoint properties, it establishes that
> camss depends on the imx355 sensors, meaning imx355 will probe first.
> During the imx355 probe, it requests and enables MCLK2.
>
> However, because the pinctrl for MCLK2 is attached to the camss consumer
> rather than the provider (camcc) or a dedicated gpio-gate-clock node, the
> physical pin (GPIO15) won't be configured to output the clock until camss
> probes.
>
> Without the clock active, will the imx355 sensor fail to respond to the I2C
> read for its CHIP_ID and fail to probe entirely?
Yes
>
> [ ... ]
>
>> +};
>> +
>> +&cci0_sleep {
>> + /* bus has external pull-up, don't pull down */
>> + bias-disable;
>> +};
>
> [Severity: Medium]
> Is this targeting the correct CCI bus?
Yes.
>
> The commit message states the cameras are controlled over CCI I2C1, which
> uses cci1_sleep. By overriding cci0_sleep instead, does this leave the
> I2C lines for the cameras pulled down against their external pull-ups
> during sleep, causing a continuous power leak?
>
> Additionally, without using /delete-property/ bias-pull-down;, won't
> cci0_sleep incorrectly contain both bias-disable and bias-pull-down
> conflicting settings?
>
--
David Heidelberg
^ permalink raw reply
* [PATCH v2] arm64: dts: rockchip: fix label of sys_led for nanopi-r4s
From: Vic B @ 2026-07-19 18:49 UTC (permalink / raw)
To: linux-kernel, linux-rockchip, devicetree, Heiko Stuebner,
Conor Dooley, Krzysztof Kozlowski, Rob Herring, Jensen Huang
In-Reply-To: <alz112qGhm77liqi@vicb.net>
This commit corrects the system LED configuration for the NanoPi R4S by
replacing the deprecated label property with color and function.
This changes the resulting label of mislabeled sys_led from red:power
to green:status, while the labels of the other two leds stay intact
(green:lan for lan_led and green:wan for wan_led).
Signed-off-by: Vic B <linux@vicb.net>
---
Changes in v2:
- use color and function instead of deprecated label as suggested
by Sashiko AI
---
arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi
index 4274d1b6e80a..4ad012a9bdc8 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi
@@ -14,6 +14,7 @@
/dts-v1/;
+#include <dt-bindings/leds/common.h>
#include "rk3399-nanopi4.dtsi"
/ {
@@ -25,19 +26,22 @@ gpio-leds {
/delete-node/ led-0;
lan_led: led-lan {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
gpios = <&gpio1 RK_PA1 GPIO_ACTIVE_HIGH>;
- label = "green:lan";
};
sys_led: led-sys {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
gpios = <&gpio0 RK_PB5 GPIO_ACTIVE_HIGH>;
- label = "red:power";
default-state = "on";
};
wan_led: led-wan {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_WAN;
gpios = <&gpio1 RK_PA0 GPIO_ACTIVE_HIGH>;
- label = "green:wan";
};
};
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v3] dt-bindings: pinctrl: microchip,pic32mzda-pinctrl: Convert to DT schema
From: sashiko-bot @ 2026-07-19 18:42 UTC (permalink / raw)
To: Udaya Kiran Challa; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260719183431.124061-1-challauday369@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The regular expressions used for matching pin configuration nodes contain invalid syntax (negative lookaheads unsupported by the RE2 engine) and overly restrictive patterns that reject standard Device Tree node naming conventions.
--
--- Patch [1]: [PATCH v3] dt-bindings: pinctrl: microchip,pic32mzda-pinctrl: Convert to DT schema ---
commit e4c63aad2379e3c473b66cca58b14faae98c368f
Author: Udaya Kiran Challa <challauday369@gmail.com>
dt-bindings: pinctrl: microchip,pic32mzda-pinctrl: Convert to DT schema
Convert Microchip PIC32 Pin Controller devicetree binding
from legacy text format to DT schema.
> diff --git a/Documentation/devicetree/bindings/pinctrl/microchip,pic32mzda-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/microchip,pic32mzda-pinctrl.yaml
> new file mode 100644
> index 0000000000000..7a36e5ff61ddf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/microchip,pic32mzda-pinctrl.yaml
> @@ -0,0 +1,153 @@
[ ... ]
> + '#size-cells':
> + const: 1
> +
> +patternProperties:
> + '^(?!pinctrl_)[a-z]+[0-9]*_[a-z0-9_]+$':
[Severity: Medium]
Will this negative lookahead cause a schema compilation error during
make dt_binding_check?
The dt-schema tool requires RE2-compatible regexes, which do not support
negative lookaheads. Additionally, strictly requiring an underscore in the
node name violates standard Device Tree node naming conventions.
> + type: object
> + $ref: pinmux-node.yaml#
[ ... ]
> + unevaluatedProperties: false
> +
> + '^pinctrl_[a-z0-9_-]+$|^[a-z]+[0-9]+-[0-9]+$':
[Severity: Medium]
Is this pattern too restrictive for container nodes?
By requiring a pinctrl_ prefix or strictly ending in a number, this pattern
rejects valid generic node names like uart-pins, which could break schema
validation for conformant device trees.
> + type: object
> + description: |
> + Container node for grouped pin configuration sub-nodes.
> +
> + patternProperties:
> + '^[a-z]+[0-9]+-[a-z]+$':
[Severity: Medium]
Does this child sub-node pattern improperly reject standard single-instance
interfaces?
The regex requires a number before a hyphen, which means valid generic names
like spi-mosi will fail to match.
> + type: object
> + $ref: pinmux-node.yaml#
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260719183431.124061-1-challauday369@gmail.com?part=1
^ permalink raw reply
* [PATCH v3] dt-bindings: pinctrl: microchip,pic32mzda-pinctrl: Convert to DT schema
From: Udaya Kiran Challa @ 2026-07-19 18:34 UTC (permalink / raw)
To: linusw, robh, krzk+dt, conor+dt
Cc: skhan, me, linux-gpio, devicetree, linux-kernel,
Udaya Kiran Challa
Convert Microchip PIC32 Pin Controller devicetree binding
from legacy text format to DT schema.
Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
---
Changelog:
Changes since v2:
- Add container node for grouped pin configuration sub-nodes
- Correct regex patterns of direct and nested child nodes
- Fix interrupts values in uart2 example
Link to v2:https://lore.kernel.org/all/20260707144223.120417-1-challauday369@gmail.com/
Changes since v1:
- Add interrupts and clocks to uart2 example to satisfy uart schema validation
- Corect regex patterns to accept standard DT node naming conventions
- Add function property to top-level pin configuration nodes
- Remove restrictive enum from function property to support all mux functions
Link to v1:https://lore.kernel.org/all/20260705132521.159522-1-challauday369@gmail.com/
---
.../pinctrl/microchip,pic32-pinctrl.txt | 60 -------
.../pinctrl/microchip,pic32mzda-pinctrl.yaml | 153 ++++++++++++++++++
2 files changed, 153 insertions(+), 60 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/pinctrl/microchip,pic32-pinctrl.txt
create mode 100644 Documentation/devicetree/bindings/pinctrl/microchip,pic32mzda-pinctrl.yaml
diff --git a/Documentation/devicetree/bindings/pinctrl/microchip,pic32-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/microchip,pic32-pinctrl.txt
deleted file mode 100644
index 51efd2085113..000000000000
--- a/Documentation/devicetree/bindings/pinctrl/microchip,pic32-pinctrl.txt
+++ /dev/null
@@ -1,60 +0,0 @@
-* Microchip PIC32 Pin Controller
-
-Please refer to pinctrl-bindings.txt, ../gpio/gpio.txt, and
-../interrupt-controller/interrupts.txt for generic information regarding
-pin controller, GPIO, and interrupt bindings.
-
-PIC32 'pin configuration node' is a node of a group of pins which can be
-used for a specific device or function. This node represents configurations of
-pins, optional function, and optional mux related configuration.
-
-Required properties for pin controller node:
- - compatible: "microchip,pic32mada-pinctrl"
- - reg: Address range of the pinctrl registers.
- - clocks: Clock specifier (see clock bindings for details)
-
-Required properties for pin configuration sub-nodes:
- - pins: List of pins to which the configuration applies.
-
-Optional properties for pin configuration sub-nodes:
-----------------------------------------------------
- - function: Mux function for the specified pins.
- - bias-pull-up: Enable weak pull-up.
- - bias-pull-down: Enable weak pull-down.
- - input-enable: Set the pin as an input.
- - output-low: Set the pin as an output level low.
- - output-high: Set the pin as an output level high.
- - microchip,digital: Enable digital I/O.
- - microchip,analog: Enable analog I/O.
-
-Example:
-
-pic32_pinctrl: pinctrl@1f801400{
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "microchip,pic32mzda-pinctrl";
- reg = <0x1f801400 0x400>;
- clocks = <&rootclk PB1CLK>;
-
- pinctrl_uart2: pinctrl_uart2 {
- uart2-tx {
- pins = "G9";
- function = "U2TX";
- microchip,digital;
- output-low;
- };
- uart2-rx {
- pins = "B0";
- function = "U2RX";
- microchip,digital;
- input-enable;
- };
- };
-};
-
-uart2: serial@1f822200 {
- compatible = "microchip,pic32mzda-uart";
- reg = <0x1f822200 0x50>;
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_uart2>;
-};
diff --git a/Documentation/devicetree/bindings/pinctrl/microchip,pic32mzda-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/microchip,pic32mzda-pinctrl.yaml
new file mode 100644
index 000000000000..7a36e5ff61dd
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/microchip,pic32mzda-pinctrl.yaml
@@ -0,0 +1,153 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/microchip,pic32mzda-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIC32 Pin Controller
+
+maintainers:
+ - Linus Walleij <linusw@kernel.org>
+
+description: |
+ PIC32 pin configuration node is a node of a group of pins which can be used
+ for a specific device or function. This node represents configurations of
+ pins, optional function, and optional mux related configuration.
+
+properties:
+ compatible:
+ const: microchip,pic32mzda-pinctrl
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+patternProperties:
+ '^(?!pinctrl_)[a-z]+[0-9]*_[a-z0-9_]+$':
+ type: object
+ $ref: pinmux-node.yaml#
+
+ properties:
+ pins:
+ description: |
+ List of pins to which the configuration applies.
+ items:
+ type: string
+ minItems: 1
+
+ function: true
+
+ bias-pull-up: true
+ bias-pull-down: true
+ input-enable: true
+ output-low: true
+ output-high: true
+
+ microchip,digital:
+ description: Enable digital I/O.
+ type: boolean
+
+ microchip,analog:
+ description: Enable analog I/O.
+ type: boolean
+
+ required:
+ - pins
+
+ unevaluatedProperties: false
+
+ '^pinctrl_[a-z0-9_-]+$|^[a-z]+[0-9]+-[0-9]+$':
+ type: object
+ description: |
+ Container node for grouped pin configuration sub-nodes.
+
+ patternProperties:
+ '^[a-z]+[0-9]+-[a-z]+$':
+ type: object
+ $ref: pinmux-node.yaml#
+
+ properties:
+ pins:
+ description: |
+ List of pins to which the configuration applies.
+ items:
+ type: string
+ minItems: 1
+
+ function: true
+
+ bias-pull-up: true
+ bias-pull-down: true
+ input-enable: true
+ output-low: true
+ output-high: true
+
+ microchip,digital:
+ description: Enable digital I/O.
+ type: boolean
+
+ microchip,analog:
+ description: Enable analog I/O.
+ type: boolean
+
+ required:
+ - pins
+
+ unevaluatedProperties: false
+
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/microchip,pic32-clock.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ pic32_pinctrl: pinctrl@1f801400 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "microchip,pic32mzda-pinctrl";
+ reg = <0x1f801400 0x400>;
+ clocks = <&rootclk PB1CLK>;
+
+ pinctrl_uart2: pinctrl_uart2 {
+ uart2-tx {
+ pins = "G9";
+ function = "U2TX";
+ microchip,digital;
+ output-low;
+ };
+
+ uart2-rx {
+ pins = "B0";
+ function = "U2RX";
+ microchip,digital;
+ input-enable;
+ };
+ };
+ };
+
+ uart2: serial@1f822200 {
+ compatible = "microchip,pic32mzda-uart";
+ reg = <0x1f822200 0x50>;
+ interrupts = <145 IRQ_TYPE_LEVEL_HIGH>,
+ <146 IRQ_TYPE_LEVEL_HIGH>,
+ <147 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&rootclk PB2CLK>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ };
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v5 1/2] arm64: dts: qcom: sdm845-google: Add dual front IMX355 cameras
From: sashiko-bot @ 2026-07-19 18:24 UTC (permalink / raw)
To: David Heidelberg; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260719-pixel3-camera-v5-1-99593f1bd8ec@ixit.cz>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Pinctrl for MCLK2 is attached to the camss consumer, causing a probe deadlock that breaks camera initialization.
- [Medium] Incorrect pinctrl sleep state override for I2C bus causes power leakage and configuration conflict.
--
--- Patch [1]: [PATCH v5 1/2] arm64: dts: qcom: sdm845-google: Add dual front IMX355 cameras ---
commit 650af867be78a11fabbd3346603a6fc8f7cb758f
Author: David Heidelberg <david@ixit.cz>
arm64: dts: qcom: sdm845-google: Add dual front IMX355 cameras
The Pixel 3 features two front-facing Sony IMX355 sensors with different
focal lengths (standard and wide-angle). Sensors are connected via CSIPHY
port 1 and 2 and controlled over CCI I2C1, using MCLK2 as the clock source.
This enables support for the dual front camera configuration.
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
> index 9368fd6b87515..cb5c261802bc9 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
[ ... ]
> @@ -351,6 +389,52 @@ vreg_s3c_0p6: smps3 {
> };
> };
>
> +&camss {
> + vdda-phy-supply = <&vreg_l1a_0p875>;
> + vdda-pll-supply = <&vreg_l26a_1p2>;
> +
> + /*
> + * MCLK2 (GPIO15) is shared between both front camera sensors.
> + * The clock is generated by CAMCC, therefore the pin is
> + * configured here rather than in individual sensor nodes.
> + */
> + pinctrl-0 = <&cam_mclk2_default>;
> + pinctrl-1 = <&cam_mclk2_sleep>;
> + pinctrl-names = "default", "sleep";
[Severity: High]
Will this cause a probe deadlock that breaks camera initialization?
Since fw_devlink parses the remote-endpoint properties, it establishes that
camss depends on the imx355 sensors, meaning imx355 will probe first.
During the imx355 probe, it requests and enables MCLK2.
However, because the pinctrl for MCLK2 is attached to the camss consumer
rather than the provider (camcc) or a dedicated gpio-gate-clock node, the
physical pin (GPIO15) won't be configured to output the clock until camss
probes.
Without the clock active, will the imx355 sensor fail to respond to the I2C
read for its CHIP_ID and fail to probe entirely?
[ ... ]
> +};
> +
> +&cci0_sleep {
> + /* bus has external pull-up, don't pull down */
> + bias-disable;
> +};
[Severity: Medium]
Is this targeting the correct CCI bus?
The commit message states the cameras are controlled over CCI I2C1, which
uses cci1_sleep. By overriding cci0_sleep instead, does this leave the
I2C lines for the cameras pulled down against their external pull-ups
during sleep, causing a continuous power leak?
Additionally, without using /delete-property/ bias-pull-down;, won't
cci0_sleep incorrectly contain both bias-disable and bias-pull-down
conflicting settings?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260719-pixel3-camera-v5-0-99593f1bd8ec@ixit.cz?part=1
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: qcom: lemans-evk: Add LVDS display overlay
From: sashiko-bot @ 2026-07-19 18:17 UTC (permalink / raw)
To: Vishnu Saini; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260719-lvds-support-v1-1-1f1aca3213ba@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The `lontium,lt9211c` compatible string has no matching driver or fallback, preventing the bridge from probing.
- [Low] The `panel-lvds` node violates the `panel-lvds.yaml` DT schema bindings regarding the compatible string and the use of the `ports` node.
--
--- Patch [1]: [PATCH 1/3] arm64: dts: qcom: lemans-evk: Add LVDS display overlay ---
commit 2607cce8051c05162f525ecd61797d0bdba55e07
Author: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
arm64: dts: qcom: lemans-evk: Add LVDS display overlay
This patch adds a DTBO overlay for the Lemans EVK IFP mezzanine to support
LVDS display output. It wires up a Lontium LT9211C DSI-to-LVDS bridge and a
BOE 1080p LVDS panel.
> diff --git a/arch/arm64/boot/dts/qcom/lemans-evk-lvds-boe,dv215fhm-r01.dtso b/arch/arm64/boot/dts/qcom/lemans-evk-lvds-boe,dv215fhm-r01.dtso
> new file mode 100644
> index 0000000000000..17c20e86e950b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/lemans-evk-lvds-boe,dv215fhm-r01.dtso
[ ... ]
> + panel_lvds: panel-lvds {
> + compatible = "boe,dv215fhm-r01", "panel-lvds";
[Severity: Low]
Will this cause dtbs_check validation failures? The panel-lvds.yaml schema
does not currently document the "boe,dv215fhm-r01" compatible string.
> + data-mapping = "vesa-24";
> + width-mm = <476>;
> + height-mm = <268>;
> + power-supply = <&lcd_disp_bias>;
> + status = "okay";
> +
> + panel-timing {
[ ... ]
> + };
> +
> + ports {
[Severity: Low]
Additionally, while the Linux DRM driver successfully parses the ports node
for dual-link LVDS at runtime, the panel-lvds.yaml schema restricts the
node to a strict single port. Will this trigger unevaluatedProperties warnings
during schema compilation?
> + #address-cells = <1>;
> + #size-cells = <0>;
[ ... ]
> +&i2c1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&qup_i2c1_default>;
> + status = "okay";
> +
> + lt9211c_codec: lvds-bridge@2d {
> + compatible = "lontium,lt9211c";
[Severity: High]
Is there a matching driver or fallback for this compatible string?
The existing driver in drivers/gpu/drm/bridge/lontium-lt9211.c only binds to
"lontium,lt9211". Without a valid fallback here, will the bridge fail to
probe and leave the LVDS display dead?
> + reg = <0x2d>;
> + reset-gpios = <&tlmm 37 GPIO_ACTIVE_HIGH>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260719-lvds-support-v1-0-1f1aca3213ba@oss.qualcomm.com?part=1
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: qcom: qcs6490-rb3gen2: Add LVDS display overlay
From: sashiko-bot @ 2026-07-19 18:17 UTC (permalink / raw)
To: Vishnu Saini; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260719-lvds-support-v1-3-1f1aca3213ba@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The LVDS bridge device tree node uses an unsupported `compatible` string (`"lontium,lt9211c"`), which will prevent the driver from matching and probing, and lacks a fallback compatible string.
- [Low] The compatible strings `"lontium,lt9211c"` and `"boe,dv215fhm-r01"` are used but not documented in any device tree bindings schema.
- [Low] The `panel-lvds` node defines multiple ports inside a `ports` container, violating the `panel-lvds` DT binding schema.
--
--- Patch [3]: [PATCH 3/3] arm64: dts: qcom: qcs6490-rb3gen2: Add LVDS display overlay ---
commit 8bcbc23969051c16954909a078c84444cd4362af
Author: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
arm64: dts: qcom: qcs6490-rb3gen2: Add LVDS display overlay
This commit adds a DTBO overlay for the QCS6490 RB3 Gen2 industrial mezzanine
to support LVDS display output via the Lontium LT9211C DSI-to-LVDS bridge.
It wires up the LT9211C bridge on I2C1 and adds a dual-channel panel-lvds node.
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine-lvds-boe,dv215fhm-r01.dtso b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine-lvds-boe,dv215fhm-r01.dtso
> new file mode 100644
> index 0000000000000..65af688503429
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine-lvds-boe,dv215fhm-r01.dtso
> @@ -0,0 +1,110 @@
[ ... ]
> + hdmi-connector {
> + status = "disabled";
> + };
> +
> + panel_lvds: panel-lvds {
> + compatible = "boe,dv215fhm-r01", "panel-lvds";
[Severity: Low]
Are these compatible strings documented in the device tree bindings?
A search of the tree reveals no schema definitions for boe,dv215fhm-r01
in the panel bindings. This will cause make dtbs_check validation to fail.
> + data-mapping = "vesa-24";
> + width-mm = <476>;
> + height-mm = <268>;
> +
> + status = "okay";
[ ... ]
> + panel-timing {
> + clock-frequency = <148500000>;
[ ... ]
> + de-active = <1>;
> + };
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
[Severity: Low]
Will this ports container cause a device tree validation failure?
This overlay matches the generic panel-lvds binding, which strictly requires
and only allows a single port property. Panels requiring dual LVDS ports
typically use dedicated schemas that explicitly support a ports container
instead of falling back to the strictly single-port panel-lvds.
> +
> + port@0 {
> + reg = <0>;
[ ... ]
> +&i2c1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + lvds_bridge: lvds-bridge@29 {
> + compatible = "lontium,lt9211c";
[Severity: High]
Will the display bridge driver successfully probe with this compatible string?
The upstream Lontium LT9211 driver and its match tables only support and match
the lontium,lt9211 compatible string. Because the overlay specifies
lontium,lt9211c without providing a supported fallback like:
compatible = "lontium,lt9211c", "lontium,lt9211";
the I2C subsystem might fail to bind the driver to the device,
resulting in a dead display output.
[Severity: Low]
Additionally, is the lontium,lt9211c compatible string documented?
It does not appear to be present in the lontium,lt9211.yaml schema,
which will also trigger dtbs_check warnings during device tree validation.
> + reg = <0x29>;
> + reset-gpios = <&tlmm 117 GPIO_ACTIVE_HIGH>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260719-lvds-support-v1-0-1f1aca3213ba@oss.qualcomm.com?part=3
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: qcom: monaco-evk: Add LVDS display overlay
From: sashiko-bot @ 2026-07-19 18:15 UTC (permalink / raw)
To: Vishnu Saini; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260719-lvds-support-v1-2-1f1aca3213ba@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The device tree overlay specifies an unsupported compatible string `lontium,lt9211c` for the LVDS bridge without a valid fallback, preventing the bridge from probing.
- [Low] The `panel-lvds` node defines a dual-port LVDS panel using the `ports` construct, which violates the strict `panel-lvds` generic schema requirements.
--
--- Patch [2]: [PATCH 2/3] arm64: dts: qcom: monaco-evk: Add LVDS display overlay ---
commit c66e770010c2090d7d3ca762b7283b36aac9f68f
Author: Vishnu Saini <vishnu.saini@oss.qualcomm.com>
arm64: dts: qcom: monaco-evk: Add LVDS display overlay
This commit adds a device tree overlay for the Monaco EVK IFP mezzanine to
support an LVDS display using the Lontium LT9211C bridge. It includes the
bridge node, panel timings, and necessary power routing.
> diff --git a/arch/arm64/boot/dts/qcom/monaco-evk-lvds-boe,dv215fhm-r01.dtso b/arch/arm64/boot/dts/qcom/monaco-evk-lvds-boe,dv215fhm-r01.dtso
> new file mode 100644
> index 0000000000000..d62f6baeca858
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/monaco-evk-lvds-boe,dv215fhm-r01.dtso
> @@ -0,0 +1,131 @@
> +// SPDX-License-Identifier: BSD-3-Clause
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include <dt-bindings/gpio/gpio.h>
> +
> +&{/} {
> + model = "Qualcomm Technologies, Inc. Monaco-EVK Mezzanine Lvds";
> +
> + panel_lvds: panel-lvds {
> + compatible = "boe,dv215fhm-r01", "panel-lvds";
> + data-mapping = "vesa-24";
> + width-mm = <476>;
> + height-mm = <268>;
> + power-supply = <&lcd_disp_bias>;
> +
> + status = "okay";
> +
> + panel-timing {
[ ... ]
> + };
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
[Severity: Low]
Will this ports construct fail device tree schema validation?
The panel-lvds.yaml schema generally mandates unevaluatedProperties: false
and only accepts a single port node, rejecting the ports container used for
dual-link mapping. Does this pass make dtbs_check?
> + dual-lvds-odd-pixels;
> + panel_in_lvds_odd: endpoint {
> + remote-endpoint = <<9211c_out_odd>;
> + };
> + };
[ ... ]
> +&i2c8 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&qup_i2c8_data_clk>;
> +
> + status = "okay";
> +
> + lt9211c_codec: lvds-bridge@2d {
> + compatible = "lontium,lt9211c";
> + reg = <0x2d>;
[Severity: High]
Will this bridge actually probe with this compatible string?
The string "lontium,lt9211c" appears to be unhandled by the kernel, lacking
a fallback (such as "lontium,lt9211"). Could this prevent the device from
binding to the driver and leave the display pipeline non-functional?
> + reset-gpios = <&tlmm 66 GPIO_ACTIVE_HIGH>;
> + vccio-supply = <&vreg_l5a>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260719-lvds-support-v1-0-1f1aca3213ba@oss.qualcomm.com?part=2
^ permalink raw reply
* Re: [PATCH v5 2/2] arm64: dts: qcom: sdm845-google: Enable PMI8998 camera flash LEDs
From: sashiko-bot @ 2026-07-19 18:12 UTC (permalink / raw)
To: David Heidelberg; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260719-pixel3-camera-v5-2-99593f1bd8ec@ixit.cz>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] A preexisting logical error in the teardown and error paths of `leds-qcom-flash.c` reads out-of-bounds of the `v4l2_flash` array, causing it to either leak successfully initialized V4L2 flash devices or trigger a kernel panic.
--
--- Patch [2]: [PATCH v5 2/2] arm64: dts: qcom: sdm845-google: Enable PMI8998 camera flash LEDs ---
commit 93ed1a73fa53c221bf41460abbfe7fe7c99737a0
Author: David Heidelberg <david@ixit.cz>
arm64: dts: qcom: sdm845-google: Enable PMI8998 camera flash LEDs
Enable the PMI8998 flash LED block and describe two white flash LEDs
used for the rear camera.
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
> --- a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
[ ... ]
> +&pmi8998_flash {
> + status = "okay";
> +
> + /* upper part */
> + led-0 {
> + function = LED_FUNCTION_FLASH;
> + color = <LED_COLOR_ID_WHITE>;
> + led-sources = <1>;
> + led-max-microamp = <500000>;
> + flash-max-microamp = <1500000>;
> + flash-max-timeout-us = <1280000>;
> + function-enumerator = <0>;
> + };
> +
> + /* bottom part */
> + led-1 {
> + function = LED_FUNCTION_FLASH;
> + color = <LED_COLOR_ID_WHITE>;
> + led-sources = <2>;
> + led-max-microamp = <500000>;
> + flash-max-microamp = <1500000>;
> + flash-max-timeout-us = <1280000>;
> + function-enumerator = <1>;
> + };
> +};
[Severity: High]
This is a pre-existing issue, but configuring multiple flash LEDs exposes an
out-of-bounds array access in the leds-qcom-flash driver.
During driver teardown in qcom_flash_led_remove(), the code attempts to
access the v4l2_flash array at index leds_count:
drivers/leds/flash/leds-qcom-flash.c:qcom_flash_led_remove() {
...
while (flash_data->v4l2_flash[flash_data->leds_count] &&
flash_data->leds_count)
v4l2_flash_release(flash_data->v4l2_flash[flash_data->leds_count--]);
...
}
If the probe is successful, leds_count equals the number of LEDs. Accessing
the array at that index reads past the end of the dynamically allocated
structure, potentially causing a panic or leaking resources if the
out-of-bounds memory happens to be NULL.
The probe error path in qcom_flash_led_probe() shares this logic. If probing
fails on the second LED, v4l2_flash at that index is NULL. The loop
evaluates to false immediately and terminates without freeing the
successfully initialized first LED.
Could we fix the array bounds check and release logic in the driver before
exposing it via this multi-LED device tree configuration?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260719-pixel3-camera-v5-0-99593f1bd8ec@ixit.cz?part=2
^ 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