* RE: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Yu-Chun Lin [林祐君] @ 2026-06-17 8:36 UTC (permalink / raw)
To: Michael Walle, Bartosz Golaszewski, Andy Shevchenko
Cc: linusw@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, afaerber@suse.com, wbg@kernel.org,
mathieu.dubois-briand@bootlin.com, lars@metafoo.de,
Michael.Hennerich@analog.com, jic23@kernel.org,
nuno.sa@analog.com, andy@kernel.org, dlechner@baylibre.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org, linux-iio@vger.kernel.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰]
In-Reply-To: <DJ3QVMZ6XLW9.1M9W541O92QWJ@kernel.org>
Hi Andy, Michael and Bartosz,
> Hi,
>
>On Mon Jun 8, 2026 at 4:10 PM CEST, Bartosz Golaszewski wrote:
>>> On Wed, 3 Jun 2026 02:34:40 +0200, Andy Shevchenko
>>> <andriy.shevchenko@intel.com> said:
>
>>> On Mon, May 25, 2026 at 12:04:09PM +0000, Yu-Chun Lin [林祐君] wrote:
>>>> > On Tue, May 12, 2026 at 11:33:12AM +0800, Yu-Chun Lin wrote:
>>>> > > Expose an accessor function to retrieve the gpio_chip pointer
>>>> > > from a gpio_regmap instance.
>>>> > >
>>>> > > This is needed by drivers that use gpio_regmap but also manage
>>>> > > their own irq_chip, where
>>>> > > gpiochip_enable_irq()/gpiochip_disable_irq() must be called with
>>>> > > the gpio_chip pointer.
>>>> > >
>>>> > > Add gpio_regmap_get_gpiochip() to allow drivers with complex
>>>> > > custom IRQ implementations.
>>>> >
>>>> > Hmm... Can't we rather add
>>>> > gpio_regmap_enable_irq()/gpio_regmap_disable_irq()
>>>> > that take regmap or GPIO regmap (whatever suits better for the
>>>> > purpose) and do the magic inside GPIO regmap library code?
>>>
>>>> Thanks for the review! I apologize for the misleading commit message.
>>>> The real reason I need the struct gpio_chip pointer is to properly
>>>> set up a custom IRQ domain. Our SoC GPIO controller is quite
>>>> complex. It routes different trigger types to multiple parent IRQs,
>>>> which doesn't fit the generic regmap_irq framework.
>>>> Therefore, we have to create our own irq_domain and pass it to
>>>> gpio_regmap_config.irq_domain.
>>>>
>>>> The core problem occurs inside our custom irq_domain_ops.map() callback:
>>>>
>>>> static int rtd1625_gpio_irq_map(struct irq_domain *domain, unsigned int irq,
>>>> irq_hw_number_t hwirq) {
>>>> struct rtd1625_gpio *data = domain->host_data;
>>>> struct gpio_chip *gc = data->gpio_chip;
>>>>
>>>> /*
>>>> * The second argument MUST be struct gpio_chip *.
>>>> * If we pass our custom data structure here, the kernel will panic later
>>>> * in gpiochip_irq_reqres() when it calls irq_data_get_irq_chip_data()
>>>> * and strictly expects it to be a gpio_chip.
>>>> */
>>>> irq_set_chip_data(irq, gc);
>>>>
>>>> irq_set_lockdep_class(irq, &rtd1625_gpio_irq_lock_class,
>>>> &rtd1625_gpio_irq_request_class);
>>>>
>>>> irq_set_chip_and_handler(irq, &rtd1625_iso_gpio_irq_chip, handle_bad_irq);
>>>> irq_set_noprobe(irq);
>>>>
>>>> return 0;
>>>> }
>>>>
>>>> Without an accessor like gpio_regmap_get_gpiochip(), we cannot
>>>> retrieve the gpio_chip instantiated inside gpio-regmap.c to fulfill
>>>> these requirements in our
>>>> map() function.
>
> Why is gpiochip_irq_reqres() called in the first place? Isn't that only
> called if the irq handling is set up via gc->irq.chip and not via
> gpiochip_irqchip_add_domain() like in gpio-regmap?
>
The panic was caused by my driver including 'GPIOCHIP_IRQ_RESOURCE_HELPERS',
which forced the call to 'gpiochip_irq_reqres()' and crashed.
>>> This is all good and needs to be depicted in the cover-letter and/or commit message.
Yes, I will do it.
>>>
>>>> Before I send a v4, I see 3 possible paths:
>>>>
>>>> Option 1: Keep the accessor (Current v3 approach) We keep
>>>> gpio_regmap_get_gpiochip() but I will completely rewrite the commit
>>>> message to explain the custom irq_domain_ops.map and lockdep requirements.
>>>>
>>>> Option 2: Let gpiolib create the irq_domain via gpio_regmap_config
>>>> Instead of creating the irq_domain in our driver, we add all
>>>> necessary IRQ fields (irq_chip, irq_handler, irq_parents, etc.) into
>>>> struct gpio_regmap_config. Then gpio-regmap.c populates the
>>>> gpio_irq_chip structure before calling gpiochip_add_data(). This
>>>> prevents an early return and allows the core gpiolib
>>>> (gpiochip_add_irqchip()) to automatically create the irq_domain for us.
>>>> Drawback: This adds a lot of fields to gpio_regmap_config and might
>>>> violate the original design philosophy of gpio-regmap.c (commit
>>>> ebe363197e52), which explicitly states that it does not implement
>>>> its own IRQ chip and delegates it to the parent driver.
>>>>
>>>> Option 3: Drop gpio-regmap entirely (Revert to v2 approach)
>>>> Currently, all drivers using gpio-regmap (mostly simple CPLDs and
>>>> external I/O cards) use regmap-irq to get their domain. Since our
>>>> SoC has a complex IRQ routing scheme with multiple parents, maybe
>>>> gpio-regmap is simply not the right tool for this hardware, and we
>>>> should just implement a standard GPIO driver directly using gpiolib.
>>>>
>>>> Which approach would you prefer upstream?
>>>
>>> This question to Bart, Linus, and poissibly gpio-regmap stakeholders.
>>> I'm not sure that my personal opinion will be the best fit here.
>>>
>>
>> My preference would be for #2 but I understand that this could risk
>> getting stuck in endless bikeshedding so I'm fine with going #3 with
>> potential for future refactoring if we have more similar users.
>
> Yeah, I'd like to keep that stuff out of gpio-regmap. But I'm on the same boat
> regarding the refactoring if we have more data and potential users.
>
> -michael
Got it. I will go with Option #3 in the upcoming v4 patch.
Therefore, I will drop the patches 2, 3 and 4 from this series, and address
Andy's feedback on patch 6.
Best-regards,
Yu Chun
^ permalink raw reply
* Re: [PATCH v3 3/3] arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
From: sashiko-bot @ 2026-06-17 8:34 UTC (permalink / raw)
To: Jun Yan; +Cc: devicetree, conor+dt, linux-amlogic, robh, neil.armstrong
In-Reply-To: <20260617082239.645562-4-jerrysteve1101@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Enabling `pcie_phy` on `meson-axg-s400.dts` is insufficient to support PCIe functionality because its hardware dependency `mipi_pcie_analog_dphy` remains disabled.
--
commit cd94d06969e9f9a23ea319f406b8e86e8ed9ec44
Author: Jun Yan <jerrysteve1101@gmail.com>
arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
This patch disables the pcie_phy node by default in the meson-axg dtsi file
to suppress deferred probe warnings on boards that do not use it. It then
explicitly enables pcie_phy in the meson-axg-s400 board device tree to
preserve its PCIe functionality.
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> index 285c6ac1dd613..7ba249cc3d569 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
[ ... ]
> @@ -448,6 +448,10 @@ &pcieB {
> status = "okay";
> };
>
> +&pcie_phy {
> + status = "okay";
> +};
[Severity: High]
This is a pre-existing issue, but is it sufficient to only enable pcie_phy
to restore PCIe functionality on the s400 board?
The pcie_phy node depends on the mipi_pcie_analog_dphy analog PHY via its
phys property. Looking at meson-axg.dtsi, mipi_pcie_analog_dphy is disabled
by default:
arch/arm64/boot/dts/amlogic/meson-axg.dtsi:
mipi_pcie_analog_dphy: phy {
compatible = "amlogic,axg-mipi-pcie-analog-phy";
#phy-cells = <0>;
status = "disabled";
};
If the analog PHY is not also overridden to "okay" here in meson-axg-s400.dts,
will the analog PHY driver fail to probe, causing devm_phy_get(dev, "analog")
in the pcie_phy driver to continually return -EPROBE_DEFER?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617082239.645562-1-jerrysteve1101@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH v2] spi: dt-bindings: microchip,pic32mzda-spi: Convert to DT schema
From: Uday Kiran @ 2026-06-17 8:28 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: tsbogend, robh, krzk+dt, conor+dt, skhan, me, linux-rtc,
devicetree, linux-kernel
In-Reply-To: <20260617-sturdy-silver-bison-bfb6ba@quoll>
> > Convert Microchip PIC32 SPI controller devicetree binding
> > from legacy text format to DT schema.
>
> Please mention here that you dropped requirement of 'cs-gpios' because
> it is not a mandatory in hardware design nor in current Linux driver...
> and then CHECK it actually against drivers, which will lead you to
> conclusion that maybe it is wrong decision...
Thank you Krzysztof
I rechecked the driver and found that it uses spi_get_csgpiod() for
chip-select handling and sets host->num_chipselect = 1. Therefore, dropping
the cs-gpios requirement during the conversion was not justified.
I'll restore cs-gpios as a required property and resend the series with an
updated changelog.
Regards,
Udaya Kiran Challa
^ permalink raw reply
* Re: [PATCH 1/3] PCI: rcar-gen4: Configure AXIINTC if iMSI-RX not used
From: Geert Uytterhoeven @ 2026-06-17 8:26 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Marc Zyngier, Rob Herring, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <20260617030008.154449-1-marek.vasut+renesas@mailbox.org>
Hi Marek,
On Wed, 17 Jun 2026 at 05:00, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> In case MSI are enabled, but DWC built-in iMSI-RX is not in use, the
> MSI are handled via GIC ITS. Configure all controller MSI registers
> fully.
>
> Set or clear MSI capability register MSICAP0 MSI enable MSIE bit and
> PCIe Interrupt Status 0 Enable register PCIEINTSTS0EN MSI interrupt
> enable MSI_CTRL_INT bit according to MSI enable state, set both bits
> if MSI are enabled, clear both bits if MSI are disabled.
>
> If MSI are disabled, or MSI are enabled and iMSI-RX is used, then
> deconfigure AXIINTCADDR and AXIINTCCONT to 0, which disables any
> pass through of MSI TLPs onto the AXI bus and then further into
> GIC ITS translation registers.
>
> If MSI are enabled and iMSI-RX is not used, the configure AXIINTCADDR
> with target address of GIC ITS translation registers, and configure
> AXIINTCCONT to enable MSI TLP pass through onto AXI bus and into the
> GIC ITS. This specific configuration allows handling of MSI via the
> GIC ITS instead of integrated iMSI-RX.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Thanks for your patch!
> --- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> +++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> @@ -31,6 +31,10 @@
> #define DEVICE_TYPE_RC BIT(4)
> #define BIFUR_MOD_SET_ON BIT(0)
>
> +/* MSI Capability */
> +#define MSICAP0 0x0050
> +#define MSICAP0_MSIE BIT(16)
> +
> /* PCIe Interrupt Status 0 */
> #define PCIEINTSTS0 0x0084
>
> @@ -55,6 +59,16 @@
> #define APP_HOLD_PHY_RST BIT(16)
> #define APP_LTSSM_ENABLE BIT(0)
>
> +/* INTC address */
> +#define AXIINTCADDR 0x0a00
> +/* GITS GIC ITS translation register */
> +#define AXIINTCADDR_VAL 0xf1050000
> +
> +/* INTC control & mask */
> +#define AXIINTCCONT 0x0a04
> +#define INTC_EN BIT(31)
> +#define INTC_MASK GENMASK(11, 2)
> +
> /* PCIe Power Management Control */
> #define PCIEPWRMNGCTRL 0x0070
> #define APP_CLK_REQ_N BIT(11)
> @@ -305,6 +319,39 @@ static struct rcar_gen4_pcie *rcar_gen4_pcie_alloc(struct platform_device *pdev)
> return rcar;
> }
>
> +static void rcar_gen4_pcie_host_msi_init(struct dw_pcie_rp *pp)
> +{
> + struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
> + struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
> + u32 val;
> +
> + /* Make sure MSICAP0 MSIE is configured. */
> + val = dw_pcie_readl_dbi(dw, MSICAP0);
> + if (pci_msi_enabled())
> + val |= MSICAP0_MSIE;
> + else
> + val &= ~MSICAP0_MSIE;
> + dw_pcie_writel_dbi(dw, MSICAP0, val);
> +
> + if (!pci_msi_enabled() || pp->use_imsi_rx) {
> + /* Clear AXIINTC mapping. */
> + writel(0, rcar->base + AXIINTCADDR);
> + writel(0, rcar->base + AXIINTCCONT);
> + } else {
> + /* Point AXIINTC to GIC ITS and enable. */
> + writel(AXIINTCADDR_VAL, rcar->base + AXIINTCADDR);
> + writel(INTC_EN | INTC_MASK, rcar->base + AXIINTCCONT);
> + }
> +
> + /* Configure MSI interrupt signal */
> + val = readl(rcar->base + PCIEINTSTS0EN);
> + if (pci_msi_enabled())
> + val |= MSI_CTRL_INT;
> + else
> + val &= ~MSI_CTRL_INT;
> + writel(val, rcar->base + PCIEINTSTS0EN);
> +}
> +
> static int rcar_gen4_pcie_enable_device(struct pci_host_bridge *bridge,
FTR, this has a contextual dependency on "[PATCH v2] PCI: rcar-gen4:
Limit Max_Read_Request_Size and Max_Payload_Size to 256 Bytes"
(https://lore.kernel.org/all/20260519195219.189323-1-marek.vasut+renesas@mailbox.org).
> struct pci_dev *dev)
> {
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v3 3/3] arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
From: Jun Yan @ 2026-06-17 8:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260617082239.645562-1-jerrysteve1101@gmail.com>
Set the pcie_phy node to "disabled" as it is not used on some boards
and should be enabled per-board when necessary.
This change suppresses the deferred probe warning:
platform ff644000.phy: deferred probe pending: (reason unknown)
The meson-axg dtsi now disables pcie_phy by default, so enable it
for the s400 board to support PCIe functionality.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 4 ++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 1 +
2 files changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
index 285c6ac1dd61..7ba249cc3d56 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
@@ -448,6 +448,10 @@ &pcieB {
status = "okay";
};
+&pcie_phy {
+ status = "okay";
+};
+
&pwm_ab {
status = "okay";
pinctrl-0 = <&pwm_a_x20_pins>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 8ca3ac09b306..5b8ef98f6d03 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -328,6 +328,7 @@ pcie_phy: phy@ff644000 {
phys = <&mipi_pcie_analog_dphy>;
phy-names = "analog";
#phy-cells = <0>;
+ status = "disabled";
};
pdm: audio-controller@ff632000 {
--
2.54.0
^ permalink raw reply related
* [PATCH v3 2/3] arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to nand_all_pins
From: Jun Yan @ 2026-06-17 8:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260617082239.645562-1-jerrysteve1101@gmail.com>
The nand_all_pins pinctrl node was missing the nand_rb0 (ready/busy)
pin description, which is required for NAND controller operation.
Add it to the pinmux list.
Fixes: be18d53c32b2 ("arm64: dts: amlogic: meson-axg: pinctrl node for NAND")
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index 6457667d974e..8ca3ac09b306 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -481,7 +481,8 @@ mux {
"nand_ale",
"nand_cle",
"nand_wen_clk",
- "nand_ren_wr";
+ "nand_ren_wr",
+ "nand_rb0";
function = "nand";
input-enable;
bias-pull-up;
--
2.54.0
^ permalink raw reply related
* [PATCH v3 1/3] arm64: dts: amlogic: meson-axg: Disable nfc node by default
From: Jun Yan @ 2026-06-17 8:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20260617082239.645562-1-jerrysteve1101@gmail.com>
nand_rb0 and emmc_ds share one pad. Before enabling nand_rb0 for nfc,
disable nfc nodes by default to resolve pinctrl resource contention.
No mainline AXG boards enable nfc currently thus no extra DTS adjustments
are needed.
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
index f1f53fd98ae2..6457667d974e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
@@ -1999,6 +1999,7 @@ nfc: nand-controller@7800 {
clocks = <&clkc CLKID_SD_EMMC_C>,
<&clkc CLKID_FCLK_DIV2>;
clock-names = "core", "device";
+ status = "disabled";
};
usb2_phy1: phy@9020 {
--
2.54.0
^ permalink raw reply related
* [PATCH v3 0/3] arm64: dts: amlogic: meson-axg: NAND fix and PCIe PHY adjustment
From: Jun Yan @ 2026-06-17 8:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: Jun Yan, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
- Disable nfc node by default ahead of nand_rb0 pin addition.
- Add missing nand_rb0 pin to fix incomplete NAND pinctrl.
- Disable pcie_phy by default to suppress probe warning.
- Re-enable pcie_phy on S400 board to preserve PCIe functionality.
Changes in v3:
- squash "disable pcie_phy node by default" and "enable pcie_phy in
meson-axg-s400" patches
- Link to v2:
https://lore.kernel.org/all/20260617071604.635627-1-jerrysteve1101@gmail.com/
Changes in v2:
- Add patch to disable nfc node by default.
- Link to v1:
https://lore.kernel.org/all/20260529140605.1070764-1-jerrysteve1101@gmail.com/
Jun Yan (3):
arm64: dts: amlogic: meson-axg: Disable nfc node by default
arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to
nand_all_pins
arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 4 ++++
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 5 ++++-
2 files changed, 8 insertions(+), 1 deletion(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH v5 14/14] video: leds: backlight: lm3533: Support getting LED sources from DT
From: sashiko-bot @ 2026-06-17 8:18 UTC (permalink / raw)
To: Svyatoslav Ryhel; +Cc: devicetree, conor+dt, dri-devel, robh
In-Reply-To: <20260617080031.99156-15-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Out-of-bounds bitmask shift causes regcache pollution and unnecessary I2C bus writes for LM3533_REG_OUTPUT_CONF1.
--
commit a74553be2d2b60a05a193e9dc35527d3d4a425da
Author: Svyatoslav Ryhel <clamor95@gmail.com>
video: leds: backlight: lm3533: Support getting LED sources from DT
This commit adds Control Bank to HVLED/LVLED muxing support based on
the led-sources defined in the device tree.
> diff --git a/drivers/leds/leds-lm3533.c b/drivers/leds/leds-lm3533.c
> index ed810c23f30f3..9e07953814fdd 100644
> --- a/drivers/leds/leds-lm3533.c
> +++ b/drivers/leds/leds-lm3533.c
[ ... ]
> @@ -623,8 +631,36 @@ static const struct attribute_group *lm3533_led_attribute_groups[] = {
>
> static int lm3533_led_setup(struct lm3533_led *led)
> {
> + u32 output_cfg_shift = 0;
> + u32 output_cfg_val = 0;
> + u32 output_cfg_mask = 0;
> int ret;
>
> + if (led->num_leds) {
> + for (int i = 0; i < led->num_leds; i++) {
> + if (led->leds[i] >= LM3533_LVCTRLBANK_MAX)
> + continue;
> +
> + output_cfg_shift = led->leds[i] * 2;
> + output_cfg_val |= led->id << output_cfg_shift;
> + output_cfg_mask |= OUTPUT_LVLED_MASK << output_cfg_shift;
> + }
> +
> + /* LVLED1, LVLED2 and LVLED3 */
> + ret = regmap_update_bits(led->regmap, LM3533_REG_OUTPUT_CONF1,
> + output_cfg_mask << OUTPUT_CONF1_SHIFT,
> + output_cfg_val << OUTPUT_CONF1_SHIFT);
[Severity: Low]
Can this shift cause bits to fall outside the 8-bit register width?
When led-sources specifies LVLED4 or LVLED5, output_cfg_mask accumulates
bits that, when shifted left by OUTPUT_CONF1_SHIFT (which is 2), will exceed
8 bits (for example, forming masks like 0x300 or 0xC00).
Because regmap_update_bits operates on unsigned int internally, these
out-of-bounds bits are applied to the cached register value. This causes
the internal comparison (tmp != orig) to incorrectly evaluate to true,
triggering an unnecessary I2C write.
Although the I2C subsystem harmlessly truncates the value to 8 bits so the
hardware state is not corrupted, does it make sense to apply an explicit
8-bit mask (e.g., & 0xFF) before passing the shifted mask and value to
regmap_update_bits() to prevent regcache pollution and redundant bus traffic?
> + if (ret)
> + return ret;
> +
> + /* LVLED4 and LVLED5 */
> + ret = regmap_update_bits(led->regmap, LM3533_REG_OUTPUT_CONF2,
> + output_cfg_mask >> OUTPUT_CONF2_SHIFT,
> + output_cfg_val >> OUTPUT_CONF2_SHIFT);
> + if (ret)
> + return ret;
> + }
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617080031.99156-1-clamor95@gmail.com?part=14
^ permalink raw reply
* Re: [PATCH v5 13/14] video: backlight: lm3533_bl: Implement backlight_scale property
From: sashiko-bot @ 2026-06-17 8:17 UTC (permalink / raw)
To: Svyatoslav Ryhel; +Cc: dri-devel, conor+dt, devicetree, robh
In-Reply-To: <20260617080031.99156-14-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Race condition in `store_linear` leading to hardware and software state mismatch.
--
commit 52a62eb2455ff3beba4492c4d5e3f63ad2e5e71d
Author: Svyatoslav Ryhel <clamor95@gmail.com>
video: backlight: lm3533_bl: Implement backlight_scale property
This commit implements the backlight_scale property for the lm3533_bl driver.
It describes whether the backlight operates in linear or non-linear mode
based on the device state.
> diff --git a/drivers/video/backlight/lm3533_bl.c b/drivers/video/backlight/lm3533_bl.c
> --- a/drivers/video/backlight/lm3533_bl.c
> +++ b/drivers/video/backlight/lm3533_bl.c
> @@ -142,6 +142,7 @@ static ssize_t store_linear(struct device *dev, struct device_attribute *attr,
> {
> struct lm3533_bl *bl = dev_get_drvdata(dev);
> int ctrlbank = lm3533_bl_get_ctrlbank_id(bl);
> + struct backlight_device *bd = bl->bd;
> unsigned long linear;
> int ret;
>
> @@ -153,6 +154,9 @@ static ssize_t store_linear(struct device *dev, struct device_attribute *attr,
> if (ret)
> return ret;
>
> + bd->props.scale = linear ? BACKLIGHT_SCALE_LINEAR :
> + BACKLIGHT_SCALE_NON_LINEAR;
[Severity: Medium]
Could this allow the hardware state and the software property to diverge
during concurrent writes?
Since kernfs does not serialize concurrent writes to sysfs files, if two
threads write contradictory values at the same time, the regmap updates and
the bd->props.scale updates could interleave. This might result in the
hardware being configured in one mode while bd->props.scale incorrectly
reports the opposite mode.
Would it make sense to protect this update sequence with a lock to ensure both
the hardware and software properties are updated atomically?
> +
> return len;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617080031.99156-1-clamor95@gmail.com?part=13
^ permalink raw reply
* Re: [PATCH v5 08/14] mfd: lm3533: Convert to use OF bindings
From: sashiko-bot @ 2026-06-17 8:16 UTC (permalink / raw)
To: Svyatoslav Ryhel; +Cc: robh, dri-devel, devicetree, conor+dt
In-Reply-To: <20260617080031.99156-9-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `default-brightness` property is read from the Device Tree as a `u32` without being clamped to `LM3533_BL_MAX_BRIGHTNESS` (255).
--
commit ea75baf449ff637e79d3393f0fdd68b3fcf947de
Author: Svyatoslav Ryhel <clamor95@gmail.com>
mfd: lm3533: Convert to use OF bindings
This commit removes platform data support and transitions the driver to use
Device Tree bindings for its configuration.
> diff --git a/drivers/video/backlight/lm3533_bl.c b/drivers/video/backlight/lm3533_bl.c
> index 9ef171d3aaeab..2c24647fc17a4 100644
> --- a/drivers/video/backlight/lm3533_bl.c
> +++ b/drivers/video/backlight/lm3533_bl.c
[ ... ]
> @@ -292,13 +291,21 @@ static int lm3533_bl_probe(struct platform_device *pdev)
> bl->cb.id = lm3533_bl_get_ctrlbank_id(bl);
> bl->cb.dev = NULL; /* until registered */
>
> + name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "%s-%d",
> + pdev->name, pdev->id);
> + if (!name)
> + return -ENOMEM;
> +
> + device_property_read_u32(&pdev->dev, "default-brightness",
> + &default_brightness);
> +
> memset(&props, 0, sizeof(props));
> props.type = BACKLIGHT_RAW;
> props.max_brightness = LM3533_BL_MAX_BRIGHTNESS;
> - props.brightness = pdata->default_brightness;
> + props.brightness = default_brightness;
[Severity: Medium]
Should default_brightness be clamped to LM3533_BL_MAX_BRIGHTNESS before being
assigned to props.brightness?
The transition to Device Tree bindings introduces reading default-brightness
as a u32. In the previous platform data implementation, default_brightness
was a u8, which inherently restricted it to a 0-255 range.
If a Device Tree provides a value greater than 255, it will be implicitly
truncated to an 8-bit unsigned integer when passed to the hardware writing
functions (for instance, 256 would wrap around to 0). This would cause the
backlight to turn off instead of setting it to the expected maximum brightness.
Does it make sense to clamp default_brightness similar to how led-max-microamp
is clamped later in this function?
> - bd = devm_backlight_device_register(&pdev->dev, pdata->name,
> - pdev->dev.parent, bl, &lm3533_bl_ops,
> - &props);
> +
> + bd = devm_backlight_device_register(&pdev->dev, name, &pdev->dev,
> + bl, &lm3533_bl_ops, &props);
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617080031.99156-1-clamor95@gmail.com?part=8
^ permalink raw reply
* Re: [PATCH v5 11/14] video: backlight: lm3533_bl: Improve logic of sysfs functions
From: sashiko-bot @ 2026-06-17 8:16 UTC (permalink / raw)
To: Svyatoslav Ryhel; +Cc: robh, devicetree, dri-devel, conor+dt
In-Reply-To: <20260617080031.99156-12-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Sysfs attributes were inadvertently moved from the backlight class device to the platform device, breaking userspace ABI.
--
commit b4eaddced56809e9f87ffe143724f151f0e7013e
Author: Svyatoslav Ryhel <clamor95@gmail.com>
mfd: lm3533: Use dev_groups in struct device_driver
This commit replaces manual sysfs attribute creation during probe and
removal in favor of using dev_groups in struct device_driver. The goal
is to let the core handle the creation and removal of these attributes
automatically.
> diff --git a/drivers/video/backlight/lm3533_bl.c b/drivers/video/backlight/lm3533_bl.c
> index 4d6f680334802..9ef171d3aaeab 100644
> --- a/drivers/video/backlight/lm3533_bl.c
> +++ b/drivers/video/backlight/lm3533_bl.c
[ ... ]
> @@ -304,28 +309,17 @@ static int lm3533_bl_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, bl);
>
> - ret = sysfs_create_group(&bd->dev.kobj, &lm3533_bl_attribute_group);
[Severity: Critical]
By removing this manual sysfs_create_group() call and moving it to the platform
driver's dev_groups, will this change the location of the sysfs attributes?
The original code registers the attributes on the backlight class device's
kobject (&bd->dev.kobj), meaning they appear under
/sys/class/backlight/<name>/.
> - if (ret < 0) {
> - dev_err(&pdev->dev, "failed to create sysfs attributes\n");
> - return ret;
> - }
> -
> backlight_update_status(bd);
[ ... ]
> @@ -377,6 +370,7 @@ static struct platform_driver lm3533_bl_driver = {
> .driver = {
> .name = "lm3533-backlight",
> .pm = &lm3533_bl_pm_ops,
> + .dev_groups = lm3533_bl_attribute_groups,
[Severity: Critical]
Does moving the attributes to the platform driver's dev_groups inadvertently
register them on the platform device instead of the backlight class device?
This means attributes like als_channel, als_en, and linear would now be exposed
under /sys/bus/platform/devices/lm3533-backlight.<id>/ instead of their
previous location.
Will this break backward compatibility for userspace tools relying on the
standard backlight path?
> },
> .probe = lm3533_bl_probe,
> .remove = lm3533_bl_remove,
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617080031.99156-1-clamor95@gmail.com?part=11
^ permalink raw reply
* Re: [PATCH v2 4/4] arm64: dts: amlogic: meson-axg-s400: Enable pcie_phy
From: Jun Yan @ 2026-06-17 8:15 UTC (permalink / raw)
To: neil.armstrong
Cc: avkrasnov, conor+dt, devicetree, jbrunet, jerrysteve1101, khilman,
krzk+dt, linux-amlogic, linux-arm-kernel, linux-kernel,
martin.blumenstingl, robh
In-Reply-To: <915e4524-d407-4b4b-9e61-e4a2274a6f6b@linaro.org>
> > The meson-axg dtsi now disables pcie_phy by default, so enable it
> > for the s400 board to support PCIe functionality.
> >
> > Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
> > ---
> > arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> > index 285c6ac1dd61..7ba249cc3d56 100644
> > --- a/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> > +++ b/arch/arm64/boot/dts/amlogic/meson-axg-s400.dts
> > @@ -448,6 +448,10 @@ &pcieB {
> > status = "okay";
> > };
> >
> > +&pcie_phy {
> > + status = "okay";
> > +};
> > +
> > &pwm_ab {
> > status = "okay";
> > pinctrl-0 = <&pwm_a_x20_pins>;
>
> Please squash this one with the previous patch
Sure, will squash with the prior patch in v3
>
> Thanks,
> Neil
>
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: interrupt-controller: qcom,pdc: Document Purwa PDC
From: Krzysztof Kozlowski @ 2026-06-17 8:14 UTC (permalink / raw)
To: Maulik Shah
Cc: Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, linux-arm-msm, linux-kernel,
devicetree, Konrad Dybcio
In-Reply-To: <20260616-purwa-pdc-v2-1-8dda7ef25ce5@oss.qualcomm.com>
On Tue, Jun 16, 2026 at 03:57:13PM +0530, Maulik Shah wrote:
> X1P42100 (Purwa) shares the X1E80100 (Hamoa) PDC device, but the hardware
> register bug addressed in commit e9a48ea4d90b ("irqchip/qcom-pdc:
> Workaround hardware register bug on X1E80100") is already fixed in
> X1P42100 silicon.
>
> X1E80100 compatible forces the software workaround. Add PDC compatible
> for purwa as "qcom,x1p42100-pdc" to remove the workaround from Purwa.
That is an excellent commit msg, really very good! Thank you.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 01/14] dt-bindings: leds: Document TI LM3533 LED controller
From: sashiko-bot @ 2026-06-17 8:13 UTC (permalink / raw)
To: Svyatoslav Ryhel; +Cc: conor+dt, dri-devel, devicetree, robh
In-Reply-To: <20260617080031.99156-2-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] DT Schema Validation Failure due to strict property restrictions.
- [Low] Ineffective Schema Constraints on `reg` property array.
--
commit 69694c121b5fef16f95b87bbf30e28ee4fb13044
Author: Svyatoslav Ryhel <clamor95@gmail.com>
dt-bindings: leds: Document TI LM3533 LED controller
Document the LM3533 - a complete power source for backlight, keypad and
indicator LEDs in smartphone handsets.
> diff --git a/Documentation/devicetree/bindings/leds/backlight/ti,lm3533-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/ti,lm3533-backlight.yaml
> new file mode 100644
> index 0000000000000..a25846e9b3752
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/backlight/ti,lm3533-backlight.yaml
[ ... ]
> +properties:
> + compatible:
> + const: ti,lm3533-backlight
> +
> + reg:
> + description: Control bank selection (0 = bank A, 1 = bank B).
> + maximum: 1
[Severity: Low]
Are these constraints effective? In Device Tree JSON representations, reg is
decoded as an array of arrays of integers (cells).
Numeric validation keywords like maximum are silently ignored when applied
directly to arrays instead of being nested under items.
[ ... ]
> diff --git a/Documentation/devicetree/bindings/leds/ti,lm3533-leds.yaml b/Documentation/devicetree/bindings/leds/ti,lm3533-leds.yaml
> new file mode 100644
> index 0000000000000..d8dbefef3323e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/ti,lm3533-leds.yaml
[ ... ]
> +properties:
> + compatible:
> + const: ti,lm3533-leds
> +
> + reg:
> + description:
> + Control bank selection (2 = bank C, 3 = bank D, 4 = bank E, 5 = bank F).
> + minimum: 2
> + maximum: 5
[Severity: Low]
Similar to the reg property in the backlight binding, should these numeric
constraints be nested under items? As written, they apply to the array itself
and will be ignored during schema validation.
[ ... ]
> diff --git a/Documentation/devicetree/bindings/leds/ti,lm3533.yaml b/Documentation/devicetree/bindings/leds/ti,lm3533.yaml
> new file mode 100644
> index 0000000000000..bdc05a9f3d663
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/ti,lm3533.yaml
[ ... ]
> + light-sensor:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + compatible:
> + const: ti,lm3533-als
[ ... ]
> +examples:
> + - |
[ ... ]
> + light-sensor {
> + compatible = "ti,lm3533-als";
> +
> + interrupt-parent = <&gpio>;
> + interrupts = <80 IRQ_TYPE_LEVEL_LOW>;
[Severity: Low]
Will this fail make dt_binding_check? The light-sensor definition uses
additionalProperties: false but doesn't explicitly list interrupt-parent
in its properties block.
Since the example uses interrupt-parent, it seems this will cause a schema
validation failure. Should the schema include interrupt-parent: true, or
perhaps drop additionalProperties: false?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617080031.99156-1-clamor95@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: rtc: Convert rtc-cmos binding to YAML
From: Krzysztof Kozlowski @ 2026-06-17 8:13 UTC (permalink / raw)
To: sashiko-reviews; +Cc: Teja Sai Charan B, robh, conor+dt, devicetree
In-Reply-To: <20260616090404.534451F000E9@smtp.kernel.org>
On Tue, Jun 16, 2026 at 09:04:03AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [Low] The node name in the YAML example uses a unit address that does not match its 'reg' property, which will cause a dtc warning and fail `make dt_binding_check`.
> - [Low] A stray file `result.txt` containing intermediate search and build output was accidentally included in the patch.
> - [Low] Important explanatory text about firmware initialization was dropped during the conversion to YAML.
Please address Sashiko reports as well.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: rtc: Convert rtc-cmos binding to YAML
From: Krzysztof Kozlowski @ 2026-06-17 8:12 UTC (permalink / raw)
To: Teja Sai Charan B
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-rtc, devicetree, linux-kernel
In-Reply-To: <20260616085659.12809-1-tejaasaye@gmail.com>
On Tue, Jun 16, 2026 at 02:26:58PM +0530, Teja Sai Charan B wrote:
> From: Teja Sai Charan Bellamkonda <tejaasaye@gmail.com>
>
> Convert the rtc-cmos devicetree bindings to dt schema.
Subject: s/YAML/DT schema/
>
> Signed-off-by: Teja Sai Charan Bellamkonda <tejaasaye@gmail.com>
>
> ---
>
> Changes in v2:
> - Allow intel,ce4100-rtc compatible used by existing DTS files
> ---
> .../devicetree/bindings/rtc/rtc-cmos.txt | 27 ---------
> .../devicetree/bindings/rtc/rtc-cmos.yaml | 60 +++++++++++++++++++
> result.txt | 17 ++++++
Stale file, please drop.
> 3 files changed, 77 insertions(+), 27 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/rtc/rtc-cmos.txt
> create mode 100644 Documentation/devicetree/bindings/rtc/rtc-cmos.yaml
> create mode 100644 result.txt
...
> diff --git a/Documentation/devicetree/bindings/rtc/rtc-cmos.yaml b/Documentation/devicetree/bindings/rtc/rtc-cmos.yaml
> new file mode 100644
> index 000000000000..ba4812778115
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/rtc-cmos.yaml
> @@ -0,0 +1,60 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/rtc/rtc-cmos.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Motorola mc146818 compatible RTC
> +
> +maintainers:
> + - Alexandre Belloni <alexandre.belloni@bootlin.com>
> +
> +properties:
> + compatible:
> + oneOf:
> + - const: motorola,mc146818
> +
> + - items:
> + - const: intel,ce4100-rtc
> + - const: motorola,mc146818
These were not in original binding, so you need to mention it in the
commit msg and explain why.
I understand there is not 'rtc-cmos' compatible, so basically the
filename should be set to this fallback compatible.
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 1
> +
> + ctrl-reg:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Initial value of the control register
> + (also known as Register B).
> +
> + freq-reg:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Initial value of the frequency register
> + (also known as Register A).
> +
> +required:
> + - compatible
> + - reg
> +
You should $ref the rtc.yaml schema and use "unevaluatedProperties:
false". Or explain in the commit msg why it is not applicable.
> +additionalProperties: false
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 07/14] mfd: lm3533: Use dev_groups in struct device_driver
From: sashiko-bot @ 2026-06-17 8:11 UTC (permalink / raw)
To: Svyatoslav Ryhel; +Cc: devicetree, dri-devel, conor+dt, robh
In-Reply-To: <20260617080031.99156-8-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Unintentional user-space ABI breakage by moving custom sysfs attributes from the backlight class device to the platform device.
--
commit b4eaddced56809e9f87ffe143724f151f0e7013e
Author: Svyatoslav Ryhel <clamor95@gmail.com>
mfd: lm3533: Use dev_groups in struct device_driver
Instead of creating and removing the device sysfs attributes directly
during probe and remove of the driver, respectively, use dev_groups in
struct device_driver to point to the attribute definitions and let the
core take care of creating and removing them.
No intentional functional impact.
> diff --git a/drivers/video/backlight/lm3533_bl.c b/drivers/video/backlight/lm3533_bl.c
> index 4d6f680334802..9ef171d3aaeab 100644
> --- a/drivers/video/backlight/lm3533_bl.c
> +++ b/drivers/video/backlight/lm3533_bl.c
[ ... ]
> @@ -304,28 +309,17 @@ static int lm3533_bl_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, bl);
>
> - ret = sysfs_create_group(&bd->dev.kobj, &lm3533_bl_attribute_group);
> - if (ret < 0) {
> - dev_err(&pdev->dev, "failed to create sysfs attributes\n");
> - return ret;
> - }
> -
> backlight_update_status(bd);
[ ... ]
> @@ -377,6 +370,7 @@ static struct platform_driver lm3533_bl_driver = {
> .driver = {
> .name = "lm3533-backlight",
> .pm = &lm3533_bl_pm_ops,
> + .dev_groups = lm3533_bl_attribute_groups,
[Severity: High]
Does moving these attributes to the platform driver break the userspace ABI?
The old code explicitly created custom sysfs attributes on the backlight
device's kobject (&bd->dev.kobj), placing them in the backlight class
directory, for example under /sys/class/backlight/<name>/.
By attaching the attribute groups to the platform driver via .dev_groups, the
driver core will now create these attributes on the parent platform device
instead.
Since the commit message states there is no intentional functional impact,
could this path change accidentally break userspace tools or udev rules
that expect to find these custom attributes inside the backlight class
directory?
> },
> .probe = lm3533_bl_probe,
> .remove = lm3533_bl_remove,
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617080031.99156-1-clamor95@gmail.com?part=7
^ permalink raw reply
* Re: [PATCH v2] hw_random: timeriomem-rng: add configurable read width and data mask
From: Krzysztof Kozlowski @ 2026-06-17 8:08 UTC (permalink / raw)
To: Jad Keskes
Cc: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Alexander Clouter, linux-crypto, devicetree,
linux-kernel
In-Reply-To: <20260615201339.1264676-1-inasj268@gmail.com>
On Mon, Jun 15, 2026 at 09:13:39PM +0100, Jad Keskes wrote:
> The TODO for supporting read sizes other than 32 bits and masking has
> been sitting in this driver since 2009. Implement it.
>
> Add width (8, 16, or 32 bits) and mask properties to the platform data
> and device tree bindings. The read loop dispatches on width using
> readb/readw/readl so a configured 8-bit access doesn't trigger a bus
> error on hardware that rejects 32-bit reads to that address. The mask
> is ANDed with the value before storing.
>
> These are platform properties, not runtime policy -- width depends on
> SoC integration, mask reflects which output bits carry entropy.
>
> The alignment check in probe is updated to verify the resource is
> aligned to the configured width instead of hardcoding 4-byte alignment.
>
> Signed-off-by: Jad Keskes <inasj268@gmail.com>
> ---
>
> v2:
> - Remove old timeriomem_rng.yaml to avoid dt_binding_check conflict
> - Use IS_ALIGNED() instead of modulo for 32-bit PAE safety
>
>
> .../bindings/rng/timeriomem-rng.yaml | 76 ++++++++++++++++++
> .../bindings/rng/timeriomem_rng.yaml | 48 ------------
I don't undetstand this diff... what are you doing exactly? And more
important WHY?
Please run scripts/checkpatch.pl on the patches and fix reported
warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
patches and (probably) fix more warnings. Some warnings can be ignored,
especially from --strict run, but the code here looks like it needs a
fix. Feel free to get in touch if the warning is not clear.
> drivers/char/hw_random/timeriomem-rng.c | 78 +++++++++++++++----
> include/linux/timeriomem-rng.h | 12 +++
> 4 files changed, 153 insertions(+), 61 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/rng/timeriomem-rng.yaml
> delete mode 100644 Documentation/devicetree/bindings/rng/timeriomem_rng.yaml
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] dt-bindings: arm: qcom: Document Hawi SoC and its reference boards
From: Mukesh Ojha @ 2026-06-17 8:01 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Mukesh Ojha
Document the Qualcomm Hawi SoC binding and the boards which use it.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 50cc18a6ec5e..bf6bdded81d6 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -371,6 +371,11 @@ properties:
- qcom,ipq9650-rdp488
- const: qcom,ipq9650
+ - items:
+ - enum:
+ - qcom,hawi-mtp
+ - const: qcom,hawi
+
- items:
- enum:
- qcom,kaanapali-mtp
--
2.53.0
^ permalink raw reply related
* [PATCH v5 14/14] video: leds: backlight: lm3533: Support getting LED sources from DT
From: Svyatoslav Ryhel @ 2026-06-17 8:00 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Svyatoslav Ryhel
Cc: Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <20260617080031.99156-1-clamor95@gmail.com>
Add Control Bank to HVLED/LVLED muxing support based on the led-sources
defined in the device tree.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/leds/leds-lm3533.c | 60 +++++++++++++++++++++++++++++
drivers/video/backlight/lm3533_bl.c | 45 ++++++++++++++++++++++
2 files changed, 105 insertions(+)
diff --git a/drivers/leds/leds-lm3533.c b/drivers/leds/leds-lm3533.c
index ed810c23f30f..9e07953814fd 100644
--- a/drivers/leds/leds-lm3533.c
+++ b/drivers/leds/leds-lm3533.c
@@ -27,6 +27,11 @@
#define LM3533_ALS_CHANNEL_LV_MIN 1
#define LM3533_ALS_CHANNEL_LV_MAX 2
+#define LM3533_REG_OUTPUT_CONF1 0x10
+#define OUTPUT_CONF1_SHIFT 2
+#define OUTPUT_LVLED_MASK 0x3
+#define LM3533_REG_OUTPUT_CONF2 0x11
+#define OUTPUT_CONF2_SHIFT 6
#define LM3533_REG_CTRLBANK_BCONF_BASE 0x1b
#define LM3533_REG_PATTERN_ENABLE 0x28
#define LM3533_REG_PATTERN_LOW_TIME_BASE 0x71
@@ -55,6 +60,9 @@ struct lm3533_led {
u32 max_current;
u32 pwm;
+ int num_leds;
+ u32 leds[LM3533_LVCTRLBANK_MAX];
+
bool have_als;
};
@@ -623,8 +631,36 @@ static const struct attribute_group *lm3533_led_attribute_groups[] = {
static int lm3533_led_setup(struct lm3533_led *led)
{
+ u32 output_cfg_shift = 0;
+ u32 output_cfg_val = 0;
+ u32 output_cfg_mask = 0;
int ret;
+ if (led->num_leds) {
+ for (int i = 0; i < led->num_leds; i++) {
+ if (led->leds[i] >= LM3533_LVCTRLBANK_MAX)
+ continue;
+
+ output_cfg_shift = led->leds[i] * 2;
+ output_cfg_val |= led->id << output_cfg_shift;
+ output_cfg_mask |= OUTPUT_LVLED_MASK << output_cfg_shift;
+ }
+
+ /* LVLED1, LVLED2 and LVLED3 */
+ ret = regmap_update_bits(led->regmap, LM3533_REG_OUTPUT_CONF1,
+ output_cfg_mask << OUTPUT_CONF1_SHIFT,
+ output_cfg_val << OUTPUT_CONF1_SHIFT);
+ if (ret)
+ return ret;
+
+ /* LVLED4 and LVLED5 */
+ ret = regmap_update_bits(led->regmap, LM3533_REG_OUTPUT_CONF2,
+ output_cfg_mask >> OUTPUT_CONF2_SHIFT,
+ output_cfg_val >> OUTPUT_CONF2_SHIFT);
+ if (ret)
+ return ret;
+ }
+
ret = lm3533_ctrlbank_set_max_current(&led->cb, led->max_current);
if (ret)
return ret;
@@ -699,6 +735,30 @@ static int lm3533_led_probe(struct platform_device *pdev)
device_property_read_u32(&pdev->dev, "ti,pwm-config-mask", &led->pwm);
+ /*
+ * If led-sources property is not set then either this Control Bank uses
+ * its default LVLED or is not linked to any LVLED at all.
+ */
+ led->num_leds = device_property_count_u32(&pdev->dev, "led-sources");
+ if (led->num_leds > LM3533_LVCTRLBANK_MAX) {
+ dev_err(&pdev->dev, "num of LED sources exceeds max %d: %d\n",
+ LM3533_LVCTRLBANK_MAX, led->num_leds);
+ ret = -EINVAL;
+ goto err_deregister;
+ }
+
+ if (led->num_leds < 0)
+ led->num_leds = 0;
+
+ if (led->num_leds > 0) {
+ ret = device_property_read_u32_array(&pdev->dev, "led-sources",
+ led->leds, led->num_leds);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to get led-sources\n");
+ goto err_deregister;
+ }
+ }
+
ret = lm3533_led_setup(led);
if (ret)
goto err_deregister;
diff --git a/drivers/video/backlight/lm3533_bl.c b/drivers/video/backlight/lm3533_bl.c
index c99fc68cb669..b3e5b3042d34 100644
--- a/drivers/video/backlight/lm3533_bl.c
+++ b/drivers/video/backlight/lm3533_bl.c
@@ -7,6 +7,7 @@
* Author: Johan Hovold <jhovold@gmail.com>
*/
+#include <linux/bits.h>
#include <linux/module.h>
#include <linux/init.h>
#include <linux/mod_devicetable.h>
@@ -22,6 +23,7 @@
#define LM3533_HVCTRLBANK_COUNT 2
#define LM3533_BL_MAX_BRIGHTNESS 255
+#define LM3533_REG_OUTPUT_CONF1 0x10
#define LM3533_REG_CTRLBANK_AB_BCONF 0x1a
#define CTRLBANK_AB_BCONF_ALS(n) BIT(2 * (n))
#define CTRLBANK_AB_BCONF_MODE(n) BIT(2 * (n) + 1)
@@ -36,6 +38,9 @@ struct lm3533_bl {
u32 max_current;
u32 pwm;
+ int num_leds;
+ u32 led_strings[LM3533_HVCTRLBANK_COUNT];
+
bool have_als;
bool linear;
};
@@ -237,6 +242,8 @@ static const struct attribute_group *lm3533_bl_attribute_groups[] = {
static int lm3533_bl_setup(struct lm3533_bl *bl)
{
int ctrlbank = lm3533_bl_get_ctrlbank_id(bl);
+ u32 output_cfg_val = 0;
+ u32 output_cfg_mask = 0;
int ret;
ret = regmap_assign_bits(bl->regmap, LM3533_REG_CTRLBANK_AB_BCONF,
@@ -244,6 +251,21 @@ static int lm3533_bl_setup(struct lm3533_bl *bl)
if (ret)
return ret;
+ if (bl->num_leds) {
+ for (int i = 0; i < bl->num_leds; i++) {
+ if (bl->led_strings[i] >= LM3533_HVCTRLBANK_COUNT)
+ continue;
+
+ output_cfg_val |= ctrlbank << bl->led_strings[i];
+ output_cfg_mask |= BIT(bl->led_strings[i]);
+ }
+
+ ret = regmap_update_bits(bl->regmap, LM3533_REG_OUTPUT_CONF1,
+ output_cfg_mask, output_cfg_val);
+ if (ret)
+ return ret;
+ }
+
ret = lm3533_ctrlbank_set_max_current(&bl->cb, bl->max_current);
if (ret)
return ret;
@@ -321,6 +343,29 @@ static int lm3533_bl_probe(struct platform_device *pdev)
device_property_read_u32(&pdev->dev, "ti,pwm-config-mask", &bl->pwm);
+ /*
+ * If led-sources property is not set then either this Control Bank uses
+ * its default HVLED or is not linked to any HVLED at all.
+ */
+ bl->num_leds = device_property_count_u32(&pdev->dev, "led-sources");
+ if (bl->num_leds > LM3533_HVCTRLBANK_COUNT) {
+ dev_err(&pdev->dev, "num of LED sources %d exceeds max %d\n",
+ bl->num_leds, LM3533_HVCTRLBANK_COUNT);
+ return -EINVAL;
+ }
+
+ if (bl->num_leds < 0)
+ bl->num_leds = 0;
+
+ if (bl->num_leds > 0) {
+ ret = device_property_read_u32_array(&pdev->dev, "led-sources",
+ bl->led_strings,
+ bl->num_leds);
+ if (ret)
+ return dev_err_probe(&pdev->dev, ret,
+ "failed to get led-sources\n");
+ }
+
ret = lm3533_bl_setup(bl);
if (ret)
return ret;
--
2.53.0
^ permalink raw reply related
* [PATCH v5 13/14] video: backlight: lm3533_bl: Implement backlight_scale property
From: Svyatoslav Ryhel @ 2026-06-17 8:00 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Svyatoslav Ryhel
Cc: Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <20260617080031.99156-1-clamor95@gmail.com>
Since the device supports linear and non-linear modes, implement the
backlight_scale property to describe this state.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
---
drivers/video/backlight/lm3533_bl.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/video/backlight/lm3533_bl.c b/drivers/video/backlight/lm3533_bl.c
index d003d5802508..c99fc68cb669 100644
--- a/drivers/video/backlight/lm3533_bl.c
+++ b/drivers/video/backlight/lm3533_bl.c
@@ -142,6 +142,7 @@ static ssize_t store_linear(struct device *dev, struct device_attribute *attr,
{
struct lm3533_bl *bl = dev_get_drvdata(dev);
int ctrlbank = lm3533_bl_get_ctrlbank_id(bl);
+ struct backlight_device *bd = bl->bd;
unsigned long linear;
int ret;
@@ -153,6 +154,9 @@ static ssize_t store_linear(struct device *dev, struct device_attribute *attr,
if (ret)
return ret;
+ bd->props.scale = linear ? BACKLIGHT_SCALE_LINEAR :
+ BACKLIGHT_SCALE_NON_LINEAR;
+
return len;
}
@@ -295,6 +299,8 @@ static int lm3533_bl_probe(struct platform_device *pdev)
bl->linear = device_property_read_bool(&pdev->dev,
"ti,linear-mapping-mode");
+ props.scale = bl->linear ? BACKLIGHT_SCALE_LINEAR :
+ BACKLIGHT_SCALE_NON_LINEAR;
bd = devm_backlight_device_register(&pdev->dev, name, &pdev->dev,
bl, &lm3533_bl_ops, &props);
--
2.53.0
^ permalink raw reply related
* [PATCH v5 12/14] video: backlight: lm3533_bl: Set initial mapping mode from DT
From: Svyatoslav Ryhel @ 2026-06-17 8:00 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Svyatoslav Ryhel
Cc: Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <20260617080031.99156-1-clamor95@gmail.com>
Add support to obtain the initial mapping mode from DT instead of leaving
it unconfigured.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
---
drivers/video/backlight/lm3533_bl.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/video/backlight/lm3533_bl.c b/drivers/video/backlight/lm3533_bl.c
index 9eb0db640948..d003d5802508 100644
--- a/drivers/video/backlight/lm3533_bl.c
+++ b/drivers/video/backlight/lm3533_bl.c
@@ -37,6 +37,7 @@ struct lm3533_bl {
u32 pwm;
bool have_als;
+ bool linear;
};
@@ -231,8 +232,14 @@ static const struct attribute_group *lm3533_bl_attribute_groups[] = {
static int lm3533_bl_setup(struct lm3533_bl *bl)
{
+ int ctrlbank = lm3533_bl_get_ctrlbank_id(bl);
int ret;
+ ret = regmap_assign_bits(bl->regmap, LM3533_REG_CTRLBANK_AB_BCONF,
+ CTRLBANK_AB_BCONF_MODE(ctrlbank), bl->linear);
+ if (ret)
+ return ret;
+
ret = lm3533_ctrlbank_set_max_current(&bl->cb, bl->max_current);
if (ret)
return ret;
@@ -286,6 +293,9 @@ static int lm3533_bl_probe(struct platform_device *pdev)
props.max_brightness = LM3533_BL_MAX_BRIGHTNESS;
props.brightness = default_brightness;
+ bl->linear = device_property_read_bool(&pdev->dev,
+ "ti,linear-mapping-mode");
+
bd = devm_backlight_device_register(&pdev->dev, name, &pdev->dev,
bl, &lm3533_bl_ops, &props);
if (IS_ERR(bd)) {
--
2.53.0
^ permalink raw reply related
* [PATCH v5 11/14] video: backlight: lm3533_bl: Improve logic of sysfs functions
From: Svyatoslav Ryhel @ 2026-06-17 8:00 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Svyatoslav Ryhel
Cc: Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <20260617080031.99156-1-clamor95@gmail.com>
Simplify the sysfs logic of properties by switching to macros and proper
regmap helpers.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org>
---
drivers/video/backlight/lm3533_bl.c | 62 ++++++++++-------------------
1 file changed, 22 insertions(+), 40 deletions(-)
diff --git a/drivers/video/backlight/lm3533_bl.c b/drivers/video/backlight/lm3533_bl.c
index 2c24647fc17a..9eb0db640948 100644
--- a/drivers/video/backlight/lm3533_bl.c
+++ b/drivers/video/backlight/lm3533_bl.c
@@ -23,6 +23,8 @@
#define LM3533_BL_MAX_BRIGHTNESS 255
#define LM3533_REG_CTRLBANK_AB_BCONF 0x1a
+#define CTRLBANK_AB_BCONF_ALS(n) BIT(2 * (n))
+#define CTRLBANK_AB_BCONF_MODE(n) BIT(2 * (n) + 1)
struct lm3533_bl {
@@ -85,88 +87,68 @@ static ssize_t show_als_channel(struct device *dev,
return scnprintf(buf, PAGE_SIZE, "%u\n", channel);
}
-static ssize_t show_als_en(struct device *dev,
- struct device_attribute *attr, char *buf)
+static ssize_t show_als_en(struct device *dev, struct device_attribute *attr,
+ char *buf)
{
struct lm3533_bl *bl = dev_get_drvdata(dev);
int ctrlbank = lm3533_bl_get_ctrlbank_id(bl);
- u32 val;
- u8 mask;
- bool enable;
int ret;
- ret = regmap_read(bl->regmap, LM3533_REG_CTRLBANK_AB_BCONF, &val);
- if (ret)
+ ret = regmap_test_bits(bl->regmap, LM3533_REG_CTRLBANK_AB_BCONF,
+ CTRLBANK_AB_BCONF_ALS(ctrlbank));
+ if (ret < 0)
return ret;
- mask = 1 << (2 * ctrlbank);
- enable = val & mask;
-
- return scnprintf(buf, PAGE_SIZE, "%d\n", enable);
+ return scnprintf(buf, PAGE_SIZE, "%d\n", ret);
}
-static ssize_t store_als_en(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t len)
+static ssize_t store_als_en(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t len)
{
struct lm3533_bl *bl = dev_get_drvdata(dev);
int ctrlbank = lm3533_bl_get_ctrlbank_id(bl);
int enable;
- u8 mask;
int ret;
if (kstrtoint(buf, 0, &enable))
return -EINVAL;
- mask = 1 << (2 * ctrlbank);
-
ret = regmap_assign_bits(bl->regmap, LM3533_REG_CTRLBANK_AB_BCONF,
- mask, enable);
+ CTRLBANK_AB_BCONF_ALS(ctrlbank), enable);
if (ret)
return ret;
return len;
}
-static ssize_t show_linear(struct device *dev,
- struct device_attribute *attr, char *buf)
+static ssize_t show_linear(struct device *dev, struct device_attribute *attr,
+ char *buf)
{
struct lm3533_bl *bl = dev_get_drvdata(dev);
- u32 val;
- u8 mask;
- int linear;
+ int ctrlbank = lm3533_bl_get_ctrlbank_id(bl);
int ret;
- ret = regmap_read(bl->regmap, LM3533_REG_CTRLBANK_AB_BCONF, &val);
- if (ret)
+ ret = regmap_test_bits(bl->regmap, LM3533_REG_CTRLBANK_AB_BCONF,
+ CTRLBANK_AB_BCONF_MODE(ctrlbank));
+ if (ret < 0)
return ret;
- mask = 1 << (2 * lm3533_bl_get_ctrlbank_id(bl) + 1);
-
- if (val & mask)
- linear = 1;
- else
- linear = 0;
-
- return scnprintf(buf, PAGE_SIZE, "%x\n", linear);
+ return scnprintf(buf, PAGE_SIZE, "%x\n", ret);
}
-static ssize_t store_linear(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t len)
+static ssize_t store_linear(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t len)
{
struct lm3533_bl *bl = dev_get_drvdata(dev);
+ int ctrlbank = lm3533_bl_get_ctrlbank_id(bl);
unsigned long linear;
- u8 mask;
int ret;
if (kstrtoul(buf, 0, &linear))
return -EINVAL;
- mask = 1 << (2 * lm3533_bl_get_ctrlbank_id(bl) + 1);
-
ret = regmap_assign_bits(bl->regmap, LM3533_REG_CTRLBANK_AB_BCONF,
- mask, linear);
+ CTRLBANK_AB_BCONF_MODE(ctrlbank), linear);
if (ret)
return ret;
--
2.53.0
^ permalink raw reply related
* [PATCH v5 10/14] mfd: lm3533: Set DMA mask
From: Svyatoslav Ryhel @ 2026-06-17 8:00 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Svyatoslav Ryhel
Cc: Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <20260617080031.99156-1-clamor95@gmail.com>
Missing coherent_dma_mask assigning triggers the following warning in
dmesg:
[ 3.287872] platform lm3533-backlight.0: DMA mask not set
Since this warning might be elevated to an error in the future, set
coherent_dma_mask to zero because both the core and cells do not utilize
DMA.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/mfd/lm3533-core.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/mfd/lm3533-core.c b/drivers/mfd/lm3533-core.c
index 4b5d94e9ed27..db8581d1b073 100644
--- a/drivers/mfd/lm3533-core.c
+++ b/drivers/mfd/lm3533-core.c
@@ -480,6 +480,10 @@ static int lm3533_i2c_probe(struct i2c_client *i2c)
LM3533_BOOST_FREQ_MAX);
lm3533->boost_freq = lm3533->boost_freq / (500 * KILO) - 1;
+ /* LM3533 and child devices do not use DMA */
+ i2c->dev.coherent_dma_mask = 0;
+ i2c->dev.dma_mask = &i2c->dev.coherent_dma_mask;
+
return lm3533_device_init(lm3533);
}
--
2.53.0
^ permalink raw reply related
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