* [PATCH v2 0/4] arm64: dts: amlogic: meson-axg: NAND fix and PCIe PHY adjustment
From: Jun Yan @ 2026-06-17 7:15 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 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 (4):
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
arm64: dts: amlogic: meson-axg-s400: Enable pcie_phy
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
* [PATCH v2 1/4] arm64: dts: amlogic: meson-axg: Disable nfc node by default
From: Jun Yan @ 2026-06-17 7:15 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: <20260617071604.635627-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 v2 2/4] arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to nand_all_pins
From: Jun Yan @ 2026-06-17 7:15 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: <20260617071604.635627-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 v2 3/4] arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
From: Jun Yan @ 2026-06-17 7:15 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: <20260617071604.635627-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)
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 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 v2 4/4] arm64: dts: amlogic: meson-axg-s400: Enable pcie_phy
From: Jun Yan @ 2026-06-17 7:15 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: <20260617071604.635627-1-jerrysteve1101@gmail.com>
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>;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v5 2/7] dt-bindings: display: bridge: Document Renesas R-Car V4H DSC bindings
From: Geert Uytterhoeven @ 2026-06-17 7:16 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Michael Turquette, Stephen Boyd, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Magnus Damm, Marek Vasut, Laurent Pinchart, Kieran Bingham,
Philipp Zabel, linux-renesas-soc, linux-clk, linux-kernel,
dri-devel, devicetree, Conor Dooley
In-Reply-To: <20260615-rcar-du-dsc-v5-2-aed1a28610e4@ideasonboard.com>
On Mon, 15 Jun 2026 at 15:12, Tomi Valkeinen
<tomi.valkeinen+renesas@ideasonboard.com> wrote:
> From: Marek Vasut <marek.vasut+renesas@mailbox.org>
>
> The Renesas DSC Display Stream Compression is a bridge embedded in the
> Renesas R-Car V4H SoC. The bridge performs VESA DSC encoding of up to
> 8k or 400 Mpixel/s .
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> [tomi.valkeinen: fix the example]
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v6 2/2] Input: isa1200 - new driver for Imagis ISA1200
From: sashiko-bot @ 2026-06-17 7:18 UTC (permalink / raw)
To: Svyatoslav Ryhel; +Cc: robh, devicetree, linux-input, conor+dt, dmitry.torokhov
In-Reply-To: <20260617070528.35006-3-clamor95@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Critical] The `ff-memless` timer and input device can outlive the devres-managed driver state upon device unbind, leading to a Use-After-Free (UAF).
- [High] The worker `isa1200_play_work` silently drops force feedback events if it fails to acquire `input->mutex`, potentially leaving the vibrator stuck.
- [Medium] Concurrent access to `isa->level` across different locking contexts causes a data race that can schedule work after the device is closed.
--
commit 2ea8a9b82f2921004386e7307e4e382941aa5611
Author: Linus Walleij <linusw@kernel.org>
Input: isa1200 - new driver for Imagis ISA1200
The ISA1200 is a haptic feedback unit from Imagis Technology using two
motors for haptic feedback in mobile phones. Used in many mobile devices
c. 2012 including Samsung Galxy S Advance GT-I9070 (Janice), Samsung Beam
GT-I8350 (Gavini), LG Optimus 4X P880 and LG Optimus Vu P895.
> diff --git a/drivers/input/misc/isa1200.c b/drivers/input/misc/isa1200.c
> new file mode 100644
> index 0000000000000..f8c4da4a0e088
> --- /dev/null
> +++ b/drivers/input/misc/isa1200.c
[ ... ]
> +static void isa1200_play_work(struct work_struct *work)
> +{
> + struct isa1200 *isa = container_of(work, struct isa1200, play_work);
> + struct input_dev *input = isa->input;
> +
> + scoped_guard(mutex_try, &input->mutex) {
[Severity: High]
Can this cause force feedback events to be silently dropped?
The worker uses scoped_guard(mutex_try, &input->mutex) to acquire the lock.
However, input->mutex is frequently held by the input core for normal
operations like input_open_device, input_close_device, and ioctls
(e.g., EVIOCGABS).
If this worker runs concurrently with any of these operations, the mutex_try
will fail and the worker will exit without updating the hardware. Because
isa->level was already updated locklessly in isa1200_vibrator_play_effect(),
future identical effect updates will be skipped, which could leave the
vibrator stuck in its current state.
> + if (!isa->suspended) {
> + if (isa->level)
> + isa1200_start(isa);
> + else
> + isa1200_stop(isa);
> + }
> + }
> +}
[ ... ]
> +static void isa1200_vibrator_close(struct input_dev *input)
> +{
> + struct isa1200 *isa = input_get_drvdata(input);
> +
> + cancel_work_sync(&isa->play_work);
> + isa1200_stop(isa);
> + isa->level = 0;
[Severity: Medium]
Does this concurrent modification of isa->level create a data race that
can restart the vibrator after the device is closed?
The state variable isa->level is updated in isa1200_vibrator_play_effect()
under the input core's event_lock (timer context). Concurrently, it is reset
to 0 here in isa1200_vibrator_close() under input->mutex, without acquiring
event_lock.
Because the ff-memless timer is not explicitly stopped during close, the
timer can fire concurrently with or immediately after close. If it fires
after cancel_work_sync(&isa->play_work) completes, it can overwrite
isa->level to a non-zero value and re-schedule isa->play_work. This could
re-enable the motor indefinitely.
> +}
[ ... ]
> +static int isa1200_probe(struct i2c_client *client)
> +{
> + struct isa1200 *isa;
> + struct device *dev = &client->dev;
> + int err;
> +
> + isa = devm_kzalloc(dev, sizeof(*isa), GFP_KERNEL);
[Severity: Critical]
Is there a use-after-free risk here during device unbind?
The private isa structure is allocated with devm_kzalloc(), meaning it is
freed immediately when the device unbinds. However, the input device itself
is managed by devm_input_allocate_device(), which keeps the memory alive
as long as userspace holds an open file descriptor.
Because the ff-memless timer (ml_effect_timer) is tied to the input_dev
lifecycle, the timer can continue to fire even after unbind if an effect
was playing. When it fires, isa1200_vibrator_play_effect() retrieves the
freed isa structure via input_get_drvdata() and accesses corrupted memory
to schedule the workqueue.
Additionally, there doesn't appear to be a devm action added to explicitly
cancel isa->play_work on unbind.
> + if (!isa)
> + return -ENOMEM;
> +
> + isa->input = devm_input_allocate_device(dev);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617070528.35006-1-clamor95@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH 06/12] rtc: rzn1: Sort headers alphabetically
From: Geert Uytterhoeven @ 2026-06-17 7:22 UTC (permalink / raw)
To: Prabhakar
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Wolfram Sang,
linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-7-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Mon, 15 Jun 2026 at 17:48, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Sorting headers alphabetically helps locating duplicates, and make it
> easier to figure out where to insert new headers.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> --- a/drivers/rtc/rtc-rzn1.c
> +++ b/drivers/rtc/rtc-rzn1.c
> @@ -15,8 +15,8 @@
> #include <linux/clk.h>
> #include <linux/init.h>
> #include <linux/iopoll.h>
> -#include <linux/module.h>
> #include <linux/mod_devicetable.h>
> +#include <linux/module.h>
Sorting of special characters w.r.t. alphanumericals is always
a bit fuzzy...
> #include <linux/platform_device.h>
> #include <linux/pm_runtime.h>
> #include <linux/rtc.h>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 10/12] rtc: rzn1: Consistently use dev_err_probe()
From: Geert Uytterhoeven @ 2026-06-17 7:24 UTC (permalink / raw)
To: Prabhakar
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Wolfram Sang,
linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-11-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Mon, 15 Jun 2026 at 17:48, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Use dev_err_probe() in the IRQ request error path to make error handling
> consistent with the rest of rzn1_rtc_probe().
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/3] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Marc Zyngier @ 2026-06-17 7:24 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,
Rob Herring, devicetree, linux-arm-kernel, linux-doc,
linux-kernel, linux-renesas-soc
In-Reply-To: <20260617030008.154449-2-marek.vasut+renesas@mailbox.org>
On Wed, 17 Jun 2026 03:59:45 +0100,
Marek Vasut <marek.vasut+renesas@mailbox.org> wrote:
>
> Renesas R-Car S4/V4H/V4M GIC600 integration has address width for AXI
> or APB interface configured to 32 bit, it can therefore access only
> the first 4 GiB of physical address space. This information comes from
> R-Car V4H Interface Specification sheet, there is currently no technical
> update number assigned to this limitation. Further input from hardware
> engineer indicates that this limitation also applies to R-Car S4 and V4M.
> Name the limitation GEN4GICITS1, and add a driver quirk to mitigate this
> limitation.
>
> Note that the 0x0201743b GIC600 ID is not Renesas-specific, it is
> common for many ARM GICv3 implementations. Therefore, add an extra
Not quite. It designates GIC600 unambiguously. It is just that GIC600
is integrated in zillions of SoCs, most of which don't have this
problem (the machine I'm typing this from has a GIC600 *and* 96GB of
RAM).
> of_machine_is_compatible() check.
>
> The GIC600 implementation in R-Car S4/V4H/V4M is r1p6.
Is this relevant?
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> ---
> NOTE: This would not be possible without prior work from Shimoda-san
> https://lore.kernel.org/all/20240214052050.1966439-1-yoshihiro.shimoda.uh@renesas.com/
> ---
> Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: Manivannan Sadhasivam <mani@kernel.org>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-doc@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-pci@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> Documentation/arch/arm64/silicon-errata.rst | 1 +
> arch/arm64/Kconfig | 9 +++++++++
> drivers/irqchip/irq-gic-v3-its.c | 20 ++++++++++++++++++++
> 3 files changed, 30 insertions(+)
>
> diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
> index 014aa1c215a16..b0c68b64f5ac2 100644
> --- a/Documentation/arch/arm64/silicon-errata.rst
> +++ b/Documentation/arch/arm64/silicon-errata.rst
> @@ -352,6 +352,7 @@ stable kernels.
> +----------------+-----------------+-----------------+-----------------------------+
> | Qualcomm Tech. | Kryo4xx Gold | N/A | ARM64_ERRATUM_1286807 |
> +----------------+-----------------+-----------------+-----------------------------+
> +| Renesas | S4/V4H/V4M | N/A | RENESAS_ERRATUM_GEN4GICITS1 |
> +----------------+-----------------+-----------------+-----------------------------+
> | Rockchip | RK3588 | #3588001 | ROCKCHIP_ERRATUM_3588001 |
> +----------------+-----------------+-----------------+-----------------------------+
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index b3afe0688919b..b9e17ce475e61 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -1382,6 +1382,15 @@ config NVIDIA_CARMEL_CNP_ERRATUM
>
> If unsure, say Y.
>
> +config RENESAS_ERRATUM_GEN4GICITS1
> + bool "Renesas R-Car Gen4: GIC600 can not access physical addresses above 4 GiB"
> + default y
> + help
> + The Renesas R-Car Gen4 S4/V4H/V4M GIC600 SoC integrations have AXI
> + addressing limited to the first 32-bit of physical address space.
> +
> + If unsure, say Y.
> +
> config ROCKCHIP_ERRATUM_3568002
> bool "Rockchip 3568002: GIC600 can not access physical addresses higher than 4GB"
> default y
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index b57d81ad33a0a..ec3756f29cf1a 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -4901,6 +4901,18 @@ static bool __maybe_unused its_enable_rk3568002(void *data)
> return true;
> }
>
> +static bool __maybe_unused its_enable_renesas_gen4(void *data)
> +{
> + if (!of_machine_is_compatible("renesas,r8a779f0") &&
> + !of_machine_is_compatible("renesas,r8a779g0") &&
> + !of_machine_is_compatible("renesas,r8a779h0"))
> + return false;
> +
> + gfp_flags_quirk |= GFP_DMA32;
> +
> + return true;
> +}
> +
> static const struct gic_quirk its_quirks[] = {
> #ifdef CONFIG_CAVIUM_ERRATUM_22375
> {
> @@ -4975,6 +4987,14 @@ static const struct gic_quirk its_quirks[] = {
> .mask = 0xffffffff,
> .init = its_enable_rk3568002,
> },
> +#endif
> +#ifdef CONFIG_RENESAS_ERRATUM_GEN4GICITS1
> + {
> + .desc = "ITS: Renesas R-Car Gen4 GIC600 32-bit limit",
> + .iidr = 0x0201743b,
> + .mask = 0xffffffff,
> + .init = its_enable_renesas_gen4,
> + },
> #endif
> {
> }
Honestly, that's a bit too much copy-paste for my taste. Just refactor
the erratum handling to be more generic, something like this:
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 291d7668cc8da..380c4758647d2 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -4894,10 +4894,17 @@ static bool __maybe_unused its_enable_quirk_hip09_162100801(void *data)
return true;
}
-static bool __maybe_unused its_enable_rk3568002(void *data)
+static const char * const dma_impaired_platforms[] = {
+#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
+ "rockchip,rk3566",
+ "rockchip,rk3568",
+#endif
+ NULL,
+};
+
+static bool __maybe_unused its_enable_dma32(void *data)
{
- if (!of_machine_is_compatible("rockchip,rk3566") &&
- !of_machine_is_compatible("rockchip,rk3568"))
+ if (!of_machine_compatible_match(dma_impaired_platforms))
return false;
gfp_flags_quirk |= GFP_DMA32;
@@ -4972,14 +4979,12 @@ static const struct gic_quirk its_quirks[] = {
.property = "dma-noncoherent",
.init = its_set_non_coherent,
},
-#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
{
- .desc = "ITS: Rockchip erratum RK3568002",
+ .desc = "ITS: Broken GIC600 integration limited to 32bit PA",
.iidr = 0x0201743b,
.mask = 0xffffffff,
- .init = its_enable_rk3568002,
+ .init = its_enable_dma32,
},
-#endif
{
}
};
Then add the two lines you need in a separate patch.
In the future, please provide a cover letter when you have more than a
single patch (git will happily generate one for you).
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply related
* Re: [PATCH v2 3/4] arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
From: sashiko-bot @ 2026-06-17 7:25 UTC (permalink / raw)
To: Jun Yan; +Cc: linux-amlogic, neil.armstrong, conor+dt, devicetree, robh
In-Reply-To: <20260617071604.635627-4-jerrysteve1101@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The S400 board fails to enable the underlying `mipi_pcie_analog_dphy` required by `pcie_phy`, leaving PCIe broken and the deferred probe warning unresolved on this board.
--
commit 8447bc6097444b6a9914b09671ffb788547cd0fd
Author: Jun Yan <jerrysteve1101@gmail.com>
arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
This commit disables the pcie_phy node by default in the meson-axg base
devicetree to suppress a deferred probe warning on boards that do not use it.
> diff --git a/arch/arm64/boot/dts/amlogic/meson-axg.dtsi b/arch/arm64/boot/dts/amlogic/meson-axg.dtsi
> --- 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";
> };
[Severity: High]
This isn't a bug introduced by this patch, but does the S400 board fail to
enable the underlying mipi_pcie_analog_dphy required by pcie_phy?
Looking at arch/arm64/boot/dts/amlogic/meson-axg-s400.dts, the pcie_phy is
enabled:
&pcie_phy {
status = "okay";
};
However, the analog PHY it depends on (mipi_pcie_analog_dphy) is disabled by
default in 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";
};
Since mipi_pcie_analog_dphy is never set to "okay" in the s400 board file,
won't pcie_phy continue to indefinitely defer its probe waiting for the
analog PHY, leaving PCIe broken on the S400 board?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617071604.635627-1-jerrysteve1101@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH 03/12] rtc: rzn1: Fix malformed MODULE_AUTHOR string
From: Geert Uytterhoeven @ 2026-06-17 7:19 UTC (permalink / raw)
To: Prabhakar
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Wolfram Sang, linux-rtc, linux-renesas-soc,
devicetree, linux-kernel, Biju Das, Fabrizio Castro,
Lad Prabhakar
In-Reply-To: <20260615154805.1619693-4-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Mon, 15 Jun 2026 at 17:48, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> Fix a malformed MODULE_AUTHOR macro in the rtc-rzn1 driver where a missing
> closing angle bracket on the second author entry creates an invalid format.
> Correct it to the standard "Name <email>" format.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 4/4] arm64: dts: amlogic: meson-axg-s400: Enable pcie_phy
From: sashiko-bot @ 2026-06-17 7:27 UTC (permalink / raw)
To: Jun Yan; +Cc: devicetree, conor+dt, robh, linux-amlogic, neil.armstrong
In-Reply-To: <20260617071604.635627-5-jerrysteve1101@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Incomplete feature enablement causing permanent probe deferral for PCIe functionality.
--
commit 202349024b583dc874155ce812fb658ddbab6228
Author: Jun Yan <jerrysteve1101@gmail.com>
arm64: dts: amlogic: meson-axg-s400: Enable pcie_phy
This commit enables the pcie_phy node for the Amlogic meson-axg s400 board
device tree to support 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 does this incomplete enablement cause a
permanent probe deferral?
The amlogic,axg-pcie-phy driver unconditionally calls devm_phy_get(dev,
"analog") during probe. This maps to the mipi_pcie_analog_dphy node in
meson-axg.dtsi, which is set to 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";
};
Since mipi_pcie_analog_dphy is not also overridden to "okay" here in
meson-axg-s400.dts, won't devm_phy_get() permanently return -EPROBE_DEFER,
preventing pcie_phy and the dependent pcieA/pcieB nodes from initializing?
> +
> &pwm_ab {
> status = "okay";
> pinctrl-0 = <&pwm_a_x20_pins>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260617071604.635627-1-jerrysteve1101@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH 1/3] PCI: rcar-gen4: Configure AXIINTC if iMSI-RX not used
From: Marc Zyngier @ 2026-06-17 7:28 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,
Rob Herring, devicetree, linux-arm-kernel, linux-doc,
linux-kernel, linux-renesas-soc
In-Reply-To: <20260617030008.154449-1-marek.vasut+renesas@mailbox.org>
On Wed, 17 Jun 2026 03:59:44 +0100,
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>
> ---
> NOTE: This would not be possible without prior work from Shimoda-san
> ---
> Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: Manivannan Sadhasivam <mani@kernel.org>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-doc@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-pci@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> drivers/pci/controller/dwc/pcie-rcar-gen4.c | 53 +++++++++++++++++++--
> 1 file changed, 48 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> index 485cfa8bd9692..ba6e3bedd6d0a 100644
> --- 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
Wouldn't it be preferable to source the address from the device tree,
rather than hardcoding this?
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v2 4/4] arm64: dts: amlogic: meson-axg-s400: Enable pcie_phy
From: Neil Armstrong @ 2026-06-17 7:30 UTC (permalink / raw)
To: Jun Yan, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <20260617071604.635627-5-jerrysteve1101@gmail.com>
On 6/17/26 09:15, Jun Yan wrote:
> 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
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v3 4/4] Revert "dt-bindings: display: panel: panel-simple: Add lg,sw49410 compatible"
From: Neil Armstrong @ 2026-06-17 7:34 UTC (permalink / raw)
To: Maxime Ripard, Paul Sajna
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Sam Ravnborg, Jessica Zhang, linux-kernel, dri-devel, devicetree,
David Heidelberg, phone-devel, Amir Dahan
In-Reply-To: <20260615-amigurumi-kagu-of-prestige-ecae6c@houat>
On 6/15/26 11:17, Maxime Ripard wrote:
> On Sun, Jun 14, 2026 at 05:08:01PM -0700, Paul Sajna wrote:
>> This reverts commit a74c2e55ab66519ffa2069ac9ae83cd937bff4c4.
>>
>> It isn't actually panel-simple-compatible, and we knew as much by the
>> time this merged, but I guess maintainers needed something to prevent
>> the dt-bindings error going off while I was working on these patches.
>
> I had a look at the patch and discussion that commit was from, and I
> didn't see anyone bringing up that it wasn't actually panel-simple
> compatible.
I wonder why rob applied this one, I clearly requested a v3...
Neil
>
> If you knew as much back then, why wasn't this brought up?
>
> Maxime
^ permalink raw reply
* Re: [PATCH 07/12] rtc: rzn1: fix alarm range check truncation on 32-bit systems
From: Geert Uytterhoeven @ 2026-06-17 7:29 UTC (permalink / raw)
To: Prabhakar
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Wolfram Sang,
linux-rtc, linux-renesas-soc, devicetree, linux-kernel, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-8-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Mon, 15 Jun 2026 at 17:48, Prabhakar <prabhakar.csengg@gmail.com> wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> alarm and farest were declared as unsigned long, but
> rtc_tm_to_time64() returns time64_t (s64). On 32-bit systems where
> unsigned long is 32 bits, the assignment silently truncates the upper
> 32 bits of the timestamp.
>
> Fix by declaring alarm and farest as time64_t and replacing
> time_after() with a direct signed comparison, which is correct for
> time64_t values that will never realistically overflow.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 0/4] Add DRM driver for LG LH609QH1 Panel with SiliconWorks SW49410 DDIC
From: Neil Armstrong @ 2026-06-17 7:35 UTC (permalink / raw)
To: Maxime Ripard, Paul Sajna
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Sam Ravnborg, Jessica Zhang, linux-kernel, dri-devel, devicetree,
David Heidelberg, phone-devel, Amir Dahan
In-Reply-To: <20260615-celadon-pug-of-teaching-f1eb0a@houat>
On 6/15/26 11:19, Maxime Ripard wrote:
> Hi,
>
> On Sun, Jun 14, 2026 at 05:07:57PM -0700, Paul Sajna wrote:
>> This patch series adds a drm panel driver for the LG SW49410 panel found
>> in the LG G7 ThinQ (codename judyln).
>>
>> The basic driver skeleton was generated by
>> https://github.com/msm8916-mainline/linux-mdss-dsi-panel-driver-generator from the vendor
>> device-tree.
>>
>> There seems to still be some power supply issues, the bottom-left
>> corner of the screen is dark, and the rest of the screen develops
>> shadow-y burn-in-like patterns when resumed after being left off for a
>> while. https://i.imgur.com/oJZSHzE.jpeg
>
> If it's not reliable, why should we merge it, especially if it can lead
> to ABI-breaking changes like it happened already.
If the patchset is not ready to be merged but you need comments to go forward, please append RFC to your patches.
Neil
>
> Maxime
^ permalink raw reply
* Re: [PATCH v2] spi: dt-bindings: microchip,pic32mzda-spi: Convert to DT schema
From: Krzysztof Kozlowski @ 2026-06-17 7:35 UTC (permalink / raw)
To: Udaya Kiran Challa
Cc: tsbogend, robh, krzk+dt, conor+dt, skhan, me, linux-rtc,
devicetree, linux-kernel
In-Reply-To: <20260615115311.515404-1-challauday369@gmail.com>
On Mon, Jun 15, 2026 at 05:23:11PM +0530, Udaya Kiran Challa wrote:
> 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...
>
> Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
> ---
> Changelog:
> Changes since v1:
> - Rename schema file to microchip,pic32mzda-spi.yaml
> - Update subject prefix to match SPI DT binding conventions
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: arm: xen: Convert to DT schema
From: Krzysztof Kozlowski @ 2026-06-17 7:42 UTC (permalink / raw)
To: Tejas; +Cc: devicetree, robh, krzk+dt, conor+dt, sstabellini
In-Reply-To: <20260615130928.10198-1-tejasmutalikdesai@gmail.com>
On Mon, Jun 15, 2026 at 06:39:28PM +0530, Tejas wrote:
> Convert the Xen ARM device tree binding documentation from the legacy
> plain-text format (Documentation/devicetree/bindings/arm/xen.txt) to
> the YAML schema format, as required by the modern DT binding process.
There is no YAML schema. It's DT schema.
Your SoB does not match author (see submitting patches document).
Do not attach (thread) your patchsets to some other threads (unrelated
or older versions). This buries them deep in the mailbox and might
interfere with applying entire sets. See also:
https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/submitting-patches.rst#L830
> The old xen.txt is removed as the YAML schema is now the authoritative
> source.
>
> The YAML schema:
> - Uses the preferred dual license (GPL-2.0-only OR BSD-2-Clause)
> - Validates compatible string format as "xen,xen-<major>.<minor>"
> followed by the generic "xen,xen" string
> - Documents reg as accepting 1..N regions (region 0 mandatory for
> grant table mapping; regions 1..N optional extended regions)
> - Documents the uefi subnode with correct types:
> * xen,uefi-system-table: uint64 (guest PA of UEFI System Table)
> * xen,uefi-mmap-start: uint64 (guest PA of UEFI memory map)
> * xen,uefi-mmap-size: uint32 (size of UEFI memory map)
> * xen,uefi-mmap-desc-size: uint32 (size of each mmap entry)
> * xen,uefi-mmap-desc-ver: uint32 (mmap descriptor format version)
> - Marks all five xen,uefi-* properties as required within the uefi
> subnode; the source table lists all of them as unconditionally
> populated by Xen when UEFI is supported
> - 64-bit properties use /bits/ 64 <value> in the example, consistent
> with other bindings carrying uint64 properties (e.g. opp-v2.yaml,
> arm/mali-bifrost.yaml)
I don't understand the purpose of above paragraphs. Are you explaining
the changes done to the binding during conversion? Or explaining the
code? You are not suppose to explain the latter - code tells that. There
is no single point in repeating the diff in commit msg.
>
> The uefi subnode was originally introduced through a multi-version review
> series (v2..v7); the mistakes caught during those reviews (typos,
> duplicated UEFI spec content, insufficient description of Xen-specific
> hypercall semantics) are avoided with deliberate caution here.
What does it mean? What mistakes? What is avoided? How did you avoid it?
>
> Note: the example emits a dtc warning (unit_address_vs_reg) for the
You cannot have such warning, please fix the node.
> /hypervisor node. Both the normative text in xen.txt ("Xen ARM virtual
> platforms shall have a top-level 'hypervisor' node") and the example
> in xen.txt mandate this exact node name — the $nodename: const:
Example cannot mandate that.
> hypervisor in the schema is a direct encoding of that pre-existing
> requirement. A unit address is therefore impossible despite the presence
> of reg. This warning is pre-existing and not introduced by this
> conversion.
It is possible. The previous text did not forbid unit address. It only
said node name and the name is stuff before @. Look at DT spec:
"node-name@unit-address
The node-name component specifies the name of the node. It shall be 1
to 31 characters in length and consist solely of characters from the set
of characters in Table 2.1."
>
> Signed-off-by: Tejas Mutalikdesai <tejasmutalikdesai@gmail.com>
> ---
...
> +title: Xen hypervisor
> +
> +maintainers:
> + - Stefano Stabellini <sstabellini@kernel.org>
> +
> +description: |
Do not need '|' unless you need to preserve formatting.
> + Xen ARM virtual platforms shall have a top-level "hypervisor" node with
> + the properties defined below.
> +
> +properties:
> + $nodename:
> + const: hypervisor
> +
> + compatible:
> + description: |
Drop |
> + Specifies the Xen hypervisor. The version of the Xen ABI is encoded
> + in the first item as "xen,xen-<version>", followed by the generic
> + "xen,xen" string.
> + items:
> + - pattern: "^xen,xen-[0-9]+\\.[0-9]+$"
> + - const: xen,xen
> +
> + reg:
> + description: |
> + Base physical address and size of the regions in memory where special
> + resources should be mapped to, using a HYPERVISOR_memory_op hypercall.
> +
> + Region 0 is reserved for mapping the grant table and must always be
> + present. The memory region must be large enough to map the whole grant
> + table (it is larger or equal to gnttab_max_grant_frames()).
> +
> + Regions 1...N are extended regions (unused address space) for mapping
> + foreign GFNs and grants. They might be absent if there is nothing to
> + expose.
> + minItems: 1
> +
> + interrupts:
> + description: |
> + The interrupt used by Xen to inject event notifications.
> + A GIC node is also required.
> + maxItems: 1
...
> + / {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + gic: interrupt-controller {
> + #interrupt-cells = <3>;
> + interrupt-controller;
> + };
Drop everything above.
> +
> + hypervisor {
> + compatible = "xen,xen-4.3", "xen,xen";
> + reg = <0 0xb0000000 0 0x20000>;
> + interrupt-parent = <&gic>;
> + interrupts = <1 15 0xf08>;
> +
> + uefi {
> + xen,uefi-system-table = /bits/ 64 <0x1301415>;
> + xen,uefi-mmap-start = /bits/ 64 <0x7591400>;
> + xen,uefi-mmap-size = <0x1800>;
> + xen,uefi-mmap-desc-size = <0x30>;
> + xen,uefi-mmap-desc-ver = <1>;
> + };
> + };
> + };
> +...
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH v5 2/3] counter: add GPIO-based counter driver
From: William Breathitt Gray @ 2026-06-17 7:49 UTC (permalink / raw)
To: Wadim Mueller
Cc: William Breathitt Gray, krzk+dt, robh, conor+dt, linux-iio,
devicetree, linux-kernel, Oleksij Rempel, kernel
In-Reply-To: <20260524193846.19216-3-wafgo01@gmail.com>
On Sun, May 24, 2026 at 09:38:45PM +0200, Wadim Mueller wrote:
> Add a platform driver that turns plain GPIOs into a counter device.
> Edge interrupts on the signal-a, signal-b (and optional index) lines
> are decoded in software using a 2-bit Gray-code parity trick for the
> quadrature X4 mode and direct edge checks for the other modes.
>
> Supports COUNTER_FUNCTION_QUADRATURE_X1_{A,B} / X2_{A,B} / X4,
> PULSE_DIRECTION, INCREASE and DECREASE. Sleepable GPIO providers
> (I2C/SPI expanders) are rejected at probe time becouse the ISRs run
> in hardirq context.
>
> Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
Hello Wadim,
Because this is a novel module, I want to make sure we get it right lest
we merge something incorrect and end up needing to support a broken
design for many years onward.
One change I consider is whether to make Signal B optional. If a device
only has a single GPIO line available, it could still be used with only
Signal A as a counter in increase/decrease counter function mode.
However, I wonder whether this is substantially different enough from
simply using the interrupt-cnt module on the respective IRQ? I'm CCing
Oleksij and the Pengutronix team in case they wish to comment.
Regardless, the Counter subsystem is capable of interfacing with the two
Signals (A and B) independently, so users should be given the capability
of counting pulses on those two signals independently if so desired. In
the Generic Counter paradigm, an arbitrary number of Counts can be
associated to the same Signals -- it's just a matter of defining each
Count's Synapses.
In such a configuration, we would have two Counts: Count 1 is the count
you currently have implemented (supports all the counter functions),
while Count 2 supports only increase/decrease modes with a Synapse for
Signal B.
In theory, we could have Count 2 support the same modes as Count 1, but
we'll start with just increase/decrease modes to keep thing simple for
this introductory patch; new features may be added in future patches.
We should also allow each Count to have its own Index signal so the
counts may be preset independent from each other.
> +struct gpio_counter_priv {
> + struct gpio_desc *gpio_a;
> + struct gpio_desc *gpio_b;
> + struct gpio_desc *gpio_index;
> +
> + int irq_a;
> + int irq_b;
> + int irq_index;
> +
> + spinlock_t lock; /* protects count, ceiling, preset, function, direction, enabled */
> +
> + u64 count;
> + u64 ceiling;
> + u64 preset;
> + bool preset_enabled;
> + bool enabled;
> + enum counter_count_direction direction;
> + enum counter_function function;
> +
> + int prev_a;
> + int prev_b;
> +
> + struct counter_count cnts[1];
> + struct counter_signal signals[3];
> + struct counter_synapse synapses[3];
> +};
You'll need to add another set of some of these members to support a
second count (e.g. count, ceiling, enabled, etc.). I believe a member
structure is a good way to implement this as it'll make future updates
and changes simpler than modifying several independent arrays:
struct gpio_counter_count_priv{
u64 value;
u64 ceiling;
u64 preset;
...
};
struct gpio_counter_priv{
...
struct gpio_counter_count_priv count_priv[2];
...
};
If someone wishes to add some new feature in a future patch (e.g. floor)
they just add it to struct gpio_counter_count_priv and it's ready to go.
> +static int gpio_counter_a_delta(struct gpio_counter_priv *priv, int a, int b,
> + int prev_a, int prev_b)
> +{
> + enum counter_count_direction dir;
> +
> + switch (priv->function) {
> + case COUNTER_FUNCTION_QUADRATURE_X4:
> + if (!GPIO_COUNTER_STATE_CHANGED(prev_a, prev_b, a, b))
> + return 0;
> + dir = GPIO_COUNTER_GET_DIRECTION(prev_b, a);
> + return (dir == COUNTER_COUNT_DIRECTION_FORWARD) ? 1 : -1;
> +
> + case COUNTER_FUNCTION_QUADRATURE_X2_A:
> + return (a == b) ? -1 : 1;
> +
> + case COUNTER_FUNCTION_QUADRATURE_X1_A:
> + if (a && priv->direction == COUNTER_COUNT_DIRECTION_FORWARD)
> + return 1;
> + if (!a && priv->direction == COUNTER_COUNT_DIRECTION_BACKWARD)
> + return -1;
> + return 0;
Wouldn't all quadrature counter function modes require a
GPIO_COUNTER_STATE_CHANGED() check? If the quadrature encoding is not
valid then the count should not change.
I believe both Quadrature X4 and X2 can use the same logic, with
Quadrature X1 being similar:
case COUNTER_FUNCTION_QUADRATURE_X4:
case COUNTER_FUNCTION_QUADRATURE_X2_A:
if (!GPIO_COUNTER_STATE_CHANGED(prev_a, prev_b, a, b))
return 0;
dir = GPIO_COUNTER_GET_DIRECTION(prev_b, a);
return (dir == COUNTER_COUNT_DIRECTION_FORWARD) ? 1 : -1;
case COUNTER_FUNCTION_QUADRATURE_X1_A:
if (!GPIO_COUNTER_STATE_CHANGED(prev_a, prev_b, a, b))
return 0;
dir = GPIO_COUNTER_GET_DIRECTION(prev_b, a);
if (a && dir == COUNTER_COUNT_DIRECTION_FORWARD)
return 1;
if (!a && dir == COUNTER_COUNT_DIRECTION_BACKWARD)
return -1;
return 0;
In fact, you could even spin this off to a dedicated function:
static int gpio_counter_quadrature_a_delta(enum counter_function function, int a, int b, int prev_a, int prev_b)
{
enum counter_count_direction dir;
if (!GPIO_COUNTER_STATE_CHANGED(prev_a, prev_b, a, b))
return 0;
dir = GPIO_COUNTER_GET_DIRECTION(prev_b, a);
if (function == COUNTER_FUNCTION_QUADRATURE_X1_A) {
if (a && dir == COUNTER_COUNT_DIRECTION_FORWARD)
return 1;
if (!a && dir == COUNTER_COUNT_DIRECTION_BACKWARD)
return -1;
return 0;
}
return (dir == COUNTER_COUNT_DIRECTION_FORWARD) ? 1 : -1;
}
...
static int gpio_counter_a_delta(struct gpio_counter_priv *priv, int a, int b, int prev_a, int prev_b)
{
switch (priv->function) {
case COUNTER_FUNCTION_QUADRATURE_X4:
case COUNTER_FUNCTION_QUADRATURE_X2_A:
case COUNTER_FUNCTION_QUADRATURE_X1_A:
return gpio_counter_quadrature_a_delta(priv->function, a, b, prev_a, prev_b);
...
However, there may be a simpler solution possible without the use of
delta values. I'll discuss the idea further down in the ISR callback
review.
> +
> + case COUNTER_FUNCTION_PULSE_DIRECTION:
> + if (!prev_a && a)
> + return b ? -1 : 1;
> + return 0;
There's no need to check prev_a because the ISR only executes when
there's a change in state. That means, checking the current a level is
enough to determine if the edge was rising or falling.
> +
> + case COUNTER_FUNCTION_INCREASE:
> + if (!prev_a && a)
> + return 1;
> + return 0;
> +
> + case COUNTER_FUNCTION_DECREASE:
> + if (!prev_a && a)
> + return -1;
> + return 0;
Increase/decrease modes aren't restricted to rising edges and may be
handled on both edges. Therefore, you may eliminate the if statements
and simply return 1 or -1 directly.
Ideally, we should allow the user to choose the Synapse action mode
(rising, falling, or both edges) via the action_write() callback, but
we can postpone that to a future feature improvement patch for the sake
of keeping this introductory driver patch simpler.
> +static irqreturn_t gpio_counter_a_isr(int irq, void *dev_id)
> +{
> + struct counter_device *counter = dev_id;
> + struct gpio_counter_priv *priv = counter_priv(counter);
> + unsigned long flags;
> + int a, b, delta;
> +
> + /* !! normalises away negative gpiod_get_value() errors. */
> + a = !!gpiod_get_value(priv->gpio_a);
> + b = !!gpiod_get_value(priv->gpio_b);
> +
> + spin_lock_irqsave(&priv->lock, flags);
> +
> + delta = gpio_counter_a_delta(priv, a, b, priv->prev_a, priv->prev_b);
> + gpio_counter_update(priv, delta);
We could get rid of delta entirely. Doing so allows us to eliminate all
the delta code and replace the gpio_counter_update() call with something
like the following:
switch (priv->function) {
case COUNTER_FUNCTION_QUADRATURE_X4:
case COUNTER_FUNCTION_QUADRATURE_X2_A:
case COUNTER_FUNCTION_QUADRATURE_X1_A:
if (!GPIO_COUNTER_STATE_CHANGED(priv->prev_a, priv->prev_b, a, b))
break;
priv->direction = GPIO_COUNTER_GET_DIRECTION(priv->prev_b, a);
if (priv->function == COUNTER_FUNCTION_QUADRATURE_X1_A)
gpio_counter_quadrature_x1_update(priv, a);
else
gpio_counter_count_value_update(priv);
break;
case COUNTER_FUNCTION_PULSE_DIRECTION:
if (a)
gpio_counter_count_value_update(priv);
break;
case COUNTER_FUNCTION_INCREASE:
case COUNTER_FUNCTION_DECREASE:
gpio_counter_count_value_update(priv);
break;
default:
break;
}
And a couple simple helper functions to handle ceiling/floor and
Quadrature X1 mode:
static void gpio_counter_count_value_update(struct gpio_counter_priv *priv)
{
if (priv->direction == COUNTER_COUNT_DIRECTION_FORWARD)
if (priv->count < priv->ceiling)
priv->count++;
else if (priv->count > 0)
priv->count--;
}
static void gpio_counter_quadrature_x1_update(struct gpio_counter_priv *priv, int level)
{
if (level && priv->direction == COUNTER_COUNT_DIRECTION_FORWARD)
gpio_counter_count_value_update(priv);
else if (!level && priv->direction == COUNTER_COUNT_DIRECTION_BACKWARD)
gpio_counter_count_value_update(priv);
}
In this design, priv->direction is set in function_write() when a
user selects an increase or decrease counter function. In
pulse-direction mode on the other hand, priv->direction is updated in
the ISR callback for Signal B.
> +
> + priv->prev_a = a;
> + priv->prev_b = b;
> +
> + spin_unlock_irqrestore(&priv->lock, flags);
> +
> + counter_push_event(counter, COUNTER_EVENT_CHANGE_OF_STATE, 0);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t gpio_counter_b_isr(int irq, void *dev_id)
> +{
> + struct counter_device *counter = dev_id;
> + struct gpio_counter_priv *priv = counter_priv(counter);
> + unsigned long flags;
> + int a, b, delta;
> +
> + a = !!gpiod_get_value(priv->gpio_a);
> + b = !!gpiod_get_value(priv->gpio_b);
> +
> + spin_lock_irqsave(&priv->lock, flags);
> +
> + delta = gpio_counter_b_delta(priv, a, b, priv->prev_a, priv->prev_b);
> + gpio_counter_update(priv, delta);
> +
> + priv->prev_a = a;
> + priv->prev_b = b;
> +
> + spin_unlock_irqrestore(&priv->lock, flags);
> +
> + counter_push_event(counter, COUNTER_EVENT_CHANGE_OF_STATE, 0);
> +
> + return IRQ_HANDLED;
> +}
The B ISR would be updated in similar manner as the changes made to the
A ISR.
For the pulse-direction mode case, you will also need to update
priv->direction; Signal B represents direction, so a change in state
means a change in direction.
Remember to update Count 2's count value here too: increment if Count
2's priv->function is increase mode, and decrement if not.
> +static const enum counter_function gpio_counter_functions[] = {
> + COUNTER_FUNCTION_INCREASE, COUNTER_FUNCTION_DECREASE,
> + COUNTER_FUNCTION_PULSE_DIRECTION, COUNTER_FUNCTION_QUADRATURE_X1_A,
> + COUNTER_FUNCTION_QUADRATURE_X1_B, COUNTER_FUNCTION_QUADRATURE_X2_A,
> + COUNTER_FUNCTION_QUADRATURE_X2_B, COUNTER_FUNCTION_QUADRATURE_X4,
> +};
Count 2 will need its own counter functions list without the
pulse-direction and quadrature modes; only increase/decrease modes will
be supported at first.
> +static int gpio_counter_function_write(struct counter_device *counter,
> + struct counter_count *count,
> + enum counter_function function)
> +{
> + struct gpio_counter_priv *priv = counter_priv(counter);
> + unsigned long flags;
> +
> + spin_lock_irqsave(&priv->lock, flags);
> + priv->function = function;
> + spin_unlock_irqrestore(&priv->lock, flags);
> +
> + return 0;
> +}
Given the suggested changes to the ISR callbacks, priv->direction should
be set here when the user selects the increase/decrease modes. You can
also set an initial priv->direction for pulse-direction mode by reading
the state of Signal B.
> +static int gpio_counter_action_read(struct counter_device *counter,
> + struct counter_count *count,
> + struct counter_synapse *synapse,
> + enum counter_synapse_action *action)
> +{
> + struct gpio_counter_priv *priv = counter_priv(counter);
> + enum gpio_counter_signal_id signal_id = synapse->signal->id;
> + enum counter_function function;
> + enum counter_count_direction direction;
> + unsigned long flags;
> +
> + if (signal_id == GPIO_COUNTER_SIGNAL_INDEX) {
> + *action = COUNTER_SYNAPSE_ACTION_RISING_EDGE;
> + return 0;
> + }
> +
> + spin_lock_irqsave(&priv->lock, flags);
> + function = priv->function;
> + direction = priv->direction;
> + spin_unlock_irqrestore(&priv->lock, flags);
> +
> + *action = COUNTER_SYNAPSE_ACTION_NONE;
> +
> + switch (function) {
> + case COUNTER_FUNCTION_QUADRATURE_X4:
> + *action = COUNTER_SYNAPSE_ACTION_BOTH_EDGES;
> + return 0;
> +
> + case COUNTER_FUNCTION_QUADRATURE_X2_A:
> + if (signal_id == GPIO_COUNTER_SIGNAL_A)
> + *action = COUNTER_SYNAPSE_ACTION_BOTH_EDGES;
> + return 0;
> +
> + case COUNTER_FUNCTION_QUADRATURE_X2_B:
> + if (signal_id == GPIO_COUNTER_SIGNAL_B)
> + *action = COUNTER_SYNAPSE_ACTION_BOTH_EDGES;
> + return 0;
> +
> + case COUNTER_FUNCTION_QUADRATURE_X1_A:
> + if (signal_id == GPIO_COUNTER_SIGNAL_A) {
> + if (direction == COUNTER_COUNT_DIRECTION_FORWARD)
> + *action = COUNTER_SYNAPSE_ACTION_RISING_EDGE;
> + else
> + *action = COUNTER_SYNAPSE_ACTION_FALLING_EDGE;
> + }
> + return 0;
> +
> + case COUNTER_FUNCTION_QUADRATURE_X1_B:
> + if (signal_id == GPIO_COUNTER_SIGNAL_B) {
> + if (direction == COUNTER_COUNT_DIRECTION_FORWARD)
> + *action = COUNTER_SYNAPSE_ACTION_RISING_EDGE;
> + else
> + *action = COUNTER_SYNAPSE_ACTION_FALLING_EDGE;
> + }
> + return 0;
> +
> + case COUNTER_FUNCTION_PULSE_DIRECTION:
> + case COUNTER_FUNCTION_INCREASE:
> + case COUNTER_FUNCTION_DECREASE:
> + if (signal_id == GPIO_COUNTER_SIGNAL_A)
> + *action = COUNTER_SYNAPSE_ACTION_RISING_EDGE;
> + return 0;
Increase/decrease modes don't need to be restricted to rising edge so
make them both edges.
> +static int gpio_counter_ceiling_write(struct counter_device *counter,
> + struct counter_count *count, u64 val)
> +{
> + struct gpio_counter_priv *priv = counter_priv(counter);
> + unsigned long flags;
> +
> + /* Leave count untouched on shrink; matches intel-qep / ti-eqep / stm32-timer-cnt. */
You can remove this comment; the code makes it obvious enough that the
current count value is not modified.
> +static int gpio_counter_enable_write(struct counter_device *counter,
> + struct counter_count *count, u8 enable)
> +{
> + struct gpio_counter_priv *priv = counter_priv(counter);
> + unsigned long flags;
> + bool want = enable;
The Counter subsystem will ensure the enable argument is a boolean value
so you can use it directly in your code (or rename the parameter to
"want" if you prefer).
> + bool changed;
> +
> + spin_lock_irqsave(&priv->lock, flags);
> + changed = priv->enabled != want;
> + if (changed)
> + priv->enabled = want;
> + spin_unlock_irqrestore(&priv->lock, flags);
> +
> + if (!changed)
> + return 0;
Breaking out the negative case obscures the intent of the code more than
just unlocking the spinlock immediately on exit. Despite the additional
spin_unlock_irqrestore(), I consider this version below a lot easier to
grok:
spin_lock_irqsave(&priv->lock, flags);
if (priv->enabled == want) {
spin_unlock_irqrestore(&priv->lock, flags);
return 0;
}
priv->enabled = want;
spin_unlock_irqrestore(&priv->lock, flags);
> +
> + if (want) {
> + enable_irq(priv->irq_a);
> + enable_irq(priv->irq_b);
> + if (priv->irq_index)
> + enable_irq(priv->irq_index);
> + } else {
> + disable_irq(priv->irq_a);
> + disable_irq(priv->irq_b);
> + if (priv->irq_index)
> + disable_irq(priv->irq_index);
> + }
Hmm, is it a problem that priv->enabled is changed to a false state
before the IRQs are actually disabled? Do any issues arise if an IRQ is
handled during that brief period of time?
William Breathitt Gray
^ permalink raw reply
* Re: [PATCH v9 2/2] arm64: dts: qcom: Add Xiaomi 12 Lite 5G (taoyao) DTS
From: Stanislav Zaikin @ 2026-06-17 7:55 UTC (permalink / raw)
To: Konrad Dybcio, devicetree
Cc: linux-arm-msm, andersson, konradybcio, robh, krzk+dt, conor+dt,
linux-kernel, dmitry.baryshkov
In-Reply-To: <8b8fe93b-3df4-4dd4-acd6-3e87401071f9@oss.qualcomm.com>
On 6/16/26 12:01 PM, Konrad Dybcio wrote:
> On 6/8/26 4:33 PM, Stanislav Zaikin wrote:
>> Xiaomi 12 Lite 5G is a handset released in 2022
>>
>> This commit has the following features working:
>> - Display (with simple fb)
>> - Touchscreen
>> - UFS
>> - Power and volume buttons
>> - Pinctrl
>> - RPM Regulators
>> - Remoteprocs - wifi, bluetooth
>> - USB (Device Mode)
>>
>> Signed-off-by: Stanislav Zaikin <zstaseg@gmail.com>
>> ---
>
> [...]
>
>> +&ipa {
>> + firmware-name = "qcom/sm7325/xiaomi/taoyao/ipa_fws.mbn";
>> +
>> + status = "okay";
>> +};
>
> From make dtbs_check:
>
> qcom/sm7325-xiaomi-taoyao.dtb: ipa@1e40000 (qcom,sc7280-ipa): 'memory-region' is a required property
>
> Please fix that (or disable IPA)
>
> Otherwise:
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> Konrad
Thank you for the review.
This patch depends on [0]. With [0] patch applied, dtbs_check passes w/o
warnings.
[0]
https://lore.kernel.org/all/20260517-ipa-loader-v1-6-3c3764c1b4a3@oss.qualcomm.com/
--
Best regards,
Stanislav
^ permalink raw reply
* [PATCH v5 00/14] mfd: lm3533: convert to OF bindings, improve support
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
Convert LM3533 to OF bindings, add missing VIN supply, add support for
setting mapping mode and LED sources based on device tree.
---
Changes in v2:
schema
- maximum led sources for leds set to 4
- anyOf > oneOf in ALS
- improved ALS descriptions
- adjusted example
drivers
- dropped devm convertion of irq and mfd helpers
- all als configuration moved into lm3533_als_setup
- added regulator/consumer.h
- lm3533_bl_setup set before sysfs_create_group in backlight
- added check if LVLED is valid
- LM3533_REG_OUTPUT_CONF1 > LM3533_REG_OUTPUT_CONF2 for LVLED4 and LVLED5
Changes in v3:
- ohm -> ohms
- added default PWM mask to schema
- added commit removing driver regmap wrappers
- added commits which flatten pdata helpers
- adjusted check if als->irq > 0 since als->irq can be negative if error/missing
- added count for children defined in device tree and mfd_cell is allocated
via devm_kcalloc to be able to contain all of them
- fixed backlight boundary check
- fixed count increased unconditionally
- dev_err returns node name instead of reg value
- LM3533_MAX_CURRENT_* defines moved to common header since they are used to clamp
current values read from the tree
- mapping mode commit splitted into 2 (sysfs logic improvement > mode from DT)
- backlight mode configuration set before sysfs group is created
- fixed LVLED check on LEDs setup
- added check if HVLED is valid
- fixed wrong err_sysfs_remove goto in lm3533_bl
- added commit implementing backlight_scale property
Changes in v4:
- fixed regmap_update_bits val and mask swap in lm3533_als_set_int_mode
- fixed als->irq check in store_thresh_either_en
- removed clamping of r_select in als driver
- added use_of_reg and of_reg for backlight and leds registration
- added intermediate step in asigning props.brightness
- fixed HVLED/LVLED configuration overwriting
- added bounds check for num_leds in leds and backlight driver
- switched to regmap_clean/set/assign/test_bits helpers where appropriate
- dropped extern from header function declartions
- switched lm3533 pointer in cell structures to regmap
- sysfs_create_group > device_add_group
- changes in backlight sysfs were expanded to all properties
Changes in v5:
- aligned driver helpers to use u32
- child nodes parsing linked with 'else if' to ensure there is one call per node
- removed redundant pwm var init for leds
- fixed regmap_test_bits return check
- fixed leds and backlight counting handling
- iterator variables made scoped
- lm3533_als_setup() set to exit after mode set if m0de is pwm
---
Svyatoslav Ryhel (14):
dt-bindings: leds: Document TI LM3533 LED controller
mfd: lm3533: Remove driver specific regmap wrappers
mfd: lm3533: Remove extern from shared functions in the header
mfd: lm3533: Pass only regmap and light sensor presence to child
devices
iio: light: lm3533-als: Remove redundant pdata helpers
mfd: lm3533-core: Remove redundant pdata helpers
mfd: lm3533: Use dev_groups in struct device_driver
mfd: lm3533: Convert to use OF bindings
mfd: lm3533: Add support for VIN power supply
mfd: lm3533: Set DMA mask
video: backlight: lm3533_bl: Improve logic of sysfs functions
video: backlight: lm3533_bl: Set initial mapping mode from DT
video: backlight: lm3533_bl: Implement backlight_scale property
video: leds: backlight: lm3533: Support getting LED sources from DT
.../leds/backlight/ti,lm3533-backlight.yaml | 69 ++++
.../bindings/leds/ti,lm3533-leds.yaml | 67 ++++
.../devicetree/bindings/leds/ti,lm3533.yaml | 169 ++++++++
drivers/iio/light/lm3533-als.c | 180 ++++-----
drivers/leds/leds-lm3533.c | 184 ++++++---
drivers/mfd/lm3533-core.c | 375 +++++++-----------
drivers/mfd/lm3533-ctrlbank.c | 33 +-
drivers/video/backlight/lm3533_bl.c | 232 ++++++-----
include/linux/mfd/lm3533.h | 75 +---
9 files changed, 821 insertions(+), 563 deletions(-)
create mode 100644 Documentation/devicetree/bindings/leds/backlight/ti,lm3533-backlight.yaml
create mode 100644 Documentation/devicetree/bindings/leds/ti,lm3533-leds.yaml
create mode 100644 Documentation/devicetree/bindings/leds/ti,lm3533.yaml
--
2.53.0
^ permalink raw reply
* [PATCH v5 01/14] dt-bindings: leds: Document TI LM3533 LED controller
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>
Document the LM3533 - a complete power source for backlight, keypad and
indicator LEDs in smartphone handsets. The high-voltage inductive boost
converter provides the power for two series LED strings display backlight
and keypad functions.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Jonathan Cameron <jic23@kernel.org> #for light sensor
Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org> #for backlight
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
---
.../leds/backlight/ti,lm3533-backlight.yaml | 69 +++++++
.../bindings/leds/ti,lm3533-leds.yaml | 67 +++++++
.../devicetree/bindings/leds/ti,lm3533.yaml | 169 ++++++++++++++++++
3 files changed, 305 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/backlight/ti,lm3533-backlight.yaml
create mode 100644 Documentation/devicetree/bindings/leds/ti,lm3533-leds.yaml
create mode 100644 Documentation/devicetree/bindings/leds/ti,lm3533.yaml
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 000000000000..a25846e9b375
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/ti,lm3533-backlight.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/ti,lm3533-backlight.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI LM3533 high voltage series LED strings
+
+description:
+ This is part of the TI LM3533 MFD device. It represents two high voltage series
+ LED strings for display backlight controlled by the TI LM3533.
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+allOf:
+ - $ref: /schemas/leds/backlight/common.yaml#
+
+properties:
+ compatible:
+ const: ti,lm3533-backlight
+
+ reg:
+ description: Control bank selection (0 = bank A, 1 = bank B).
+ maximum: 1
+
+ led-max-microamp:
+ description: maximum current in uA with a 800 uA step.
+ minimum: 5000
+ maximum: 29800
+ default: 5000
+
+ led-sources:
+ description: |
+ HVLED strings associated with this control bank:
+ 0 - HVLED1
+ 1 - HVLED2
+ minItems: 1
+ maxItems: 2
+ items:
+ maximum: 1
+
+ ti,pwm-config-mask:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Control Bank PWM Configuration Register mask that allows to configure
+ PWM input in Zones 0-4
+ BIT(0) - PWM Input is enabled
+ BIT(1) - PWM Input is enabled in Zone 0
+ BIT(2) - PWM Input is enabled in Zone 1
+ BIT(3) - PWM Input is enabled in Zone 2
+ BIT(4) - PWM Input is enabled in Zone 3
+ BIT(5) - PWM Input is enabled in Zone 4
+ default: 0
+
+ ti,linear-mapping-mode:
+ description:
+ Enable linear mapping mode. If disabled, then it will use exponential
+ mapping mode in which the ramp up/down appears to have a more uniform
+ transition to the human eye.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+# see ti,lm3533.yaml for an example
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 000000000000..d8dbefef3323
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/ti,lm3533-leds.yaml
@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/ti,lm3533-leds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI LM3533 low voltage control banks for individual LEDs
+
+description:
+ This is part of the TI LM3533 MFD device. It represents four low voltage
+ control banks for individual LEDs provided by the TI LM3533.
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+allOf:
+ - $ref: /schemas/leds/common.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
+
+ led-max-microamp:
+ description: maximum current in uA with a 800 uA step.
+ minimum: 5000
+ maximum: 29800
+ default: 5000
+
+ led-sources:
+ description: |
+ LVLED associated with this control bank. May be more than 1 source per bank.
+ 0 - LVLED1
+ 1 - LVLED2
+ 2 - LVLED3
+ 3 - LVLED4
+ 4 - LVLED5
+ minItems: 1
+ maxItems: 5
+ items:
+ maximum: 4
+
+ ti,pwm-config-mask:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Control Bank PWM Configuration Register mask that allows to configure
+ PWM input in Zones 0-4
+ BIT(0) - PWM Input is enabled
+ BIT(1) - PWM Input is enabled in Zone 0
+ BIT(2) - PWM Input is enabled in Zone 1
+ BIT(3) - PWM Input is enabled in Zone 2
+ BIT(4) - PWM Input is enabled in Zone 3
+ BIT(5) - PWM Input is enabled in Zone 4
+ default: 0
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+# see ti,lm3533.yaml for an example
diff --git a/Documentation/devicetree/bindings/leds/ti,lm3533.yaml b/Documentation/devicetree/bindings/leds/ti,lm3533.yaml
new file mode 100644
index 000000000000..bdc05a9f3d66
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/ti,lm3533.yaml
@@ -0,0 +1,169 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/ti,lm3533.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI LM3533 Complete Lighting Power Solution
+
+description: >
+ The LM3533 is a complete power source for backlight, keypad, and indicator LEDs
+ in smartphone handsets. The high-voltage inductive boost converter provides the
+ power for two high voltage series LED strings for display backlight and four low
+ voltage control banks for individual LEDs. Additionally, LM3533 features an
+ interface for an external light sensor.
+
+ https://www.ti.com/product/LM3533
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+properties:
+ compatible:
+ const: ti,lm3533
+
+ reg:
+ maxItems: 1
+
+ enable-gpios:
+ description: GPIO connected to the HWEN pin.
+ maxItems: 1
+
+ vin-supply:
+ description: Supply connected to the IN line (2.7 V to 5.5 V).
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ ti,boost-ovp-microvolt:
+ description: boost OVP select (16V, 24V, 32V, 40V)
+ enum: [ 16000000, 24000000, 32000000, 40000000 ]
+ default: 16000000
+
+ ti,boost-freq-hz:
+ description: boost frequency select (500KHz or 1MHz)
+ enum: [ 500000, 1000000 ]
+ default: 500000
+
+ light-sensor:
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ const: ti,lm3533-als
+
+ interrupts:
+ maxItems: 1
+
+ ti,resistor-ohms:
+ description:
+ Internal configuration resistor value when light sensor is in
+ Analog Sensor mode and PWM mode is disabled. The expectation is
+ the input is a current from the external analog light sensor and
+ this is used to convert it to a voltage within the target range.
+ minimum: 1575
+ maximum: 200000
+
+ ti,pwm-mode:
+ type: boolean
+ description:
+ Switch for mode in which light sensor interface is running. If
+ this property is set then the light sensor interface is running
+ in PWM mode, internal resistor value is set to high-impedance (0)
+ and ti,resistor-ohms property is ignored.
+
+ required:
+ - compatible
+
+ oneOf:
+ - required:
+ - ti,resistor-ohms
+ - required:
+ - ti,pwm-mode
+
+patternProperties:
+ "^backlight@[01]$":
+ $ref: /schemas/leds/backlight/ti,lm3533-backlight.yaml#
+
+ "^led@[2-5]$":
+ $ref: /schemas/leds/ti,lm3533-leds.yaml#
+
+required:
+ - compatible
+ - reg
+ - '#address-cells'
+ - '#size-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@36 {
+ compatible = "ti,lm3533";
+ reg = <0x36>;
+
+ enable-gpios = <&gpio 110 GPIO_ACTIVE_HIGH>;
+ vin-supply = <&vdd_3v3_bat>;
+
+ ti,boost-ovp-microvolt = <24000000>;
+ ti,boost-freq-hz = <500000>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ backlight@0 {
+ compatible = "ti,lm3533-backlight";
+ reg = <0>;
+
+ default-brightness = <113>;
+
+ led-max-microamp = <23400>;
+ led-sources = <0 1>;
+ };
+
+ led@2 {
+ compatible = "ti,lm3533-leds";
+ reg = <2>;
+
+ led-max-microamp = <23400>;
+ led-sources = <0 1>;
+ };
+
+ led@4 {
+ compatible = "ti,lm3533-leds";
+ reg = <4>;
+
+ led-max-microamp = <23400>;
+ led-sources = <2>;
+ };
+
+ led@5 {
+ compatible = "ti,lm3533-leds";
+ reg = <5>;
+
+ led-max-microamp = <23400>;
+ led-sources = <3 4>;
+ };
+
+ light-sensor {
+ compatible = "ti,lm3533-als";
+
+ interrupt-parent = <&gpio>;
+ interrupts = <80 IRQ_TYPE_LEVEL_LOW>;
+
+ ti,pwm-mode;
+ };
+ };
+ };
+...
--
2.53.0
^ permalink raw reply related
* [PATCH v5 02/14] mfd: lm3533: Remove driver specific regmap wrappers
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>
Remove driver-specific regmap wrappers in favor of using regmap helpers
directly.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/iio/light/lm3533-als.c | 79 +++++++++++++----------------
drivers/leds/leds-lm3533.c | 62 ++++++++--------------
drivers/mfd/lm3533-core.c | 73 ++++----------------------
drivers/mfd/lm3533-ctrlbank.c | 28 +++++-----
drivers/video/backlight/lm3533_bl.c | 37 +++++---------
include/linux/mfd/lm3533.h | 15 ++----
6 files changed, 100 insertions(+), 194 deletions(-)
diff --git a/drivers/iio/light/lm3533-als.c b/drivers/iio/light/lm3533-als.c
index 99f0b903018c..44b104c2d77f 100644
--- a/drivers/iio/light/lm3533-als.c
+++ b/drivers/iio/light/lm3533-als.c
@@ -17,6 +17,7 @@
#include <linux/mutex.h>
#include <linux/mfd/core.h>
#include <linux/platform_device.h>
+#include <linux/regmap.h>
#include <linux/slab.h>
#include <linux/uaccess.h>
@@ -64,7 +65,7 @@ static int lm3533_als_get_adc(struct iio_dev *indio_dev, bool average,
{
struct lm3533_als *als = iio_priv(indio_dev);
u8 reg;
- u8 val;
+ u32 val;
int ret;
if (average)
@@ -72,7 +73,7 @@ static int lm3533_als_get_adc(struct iio_dev *indio_dev, bool average,
else
reg = LM3533_REG_ALS_READ_ADC_RAW;
- ret = lm3533_read(als->lm3533, reg, &val);
+ ret = regmap_read(als->lm3533->regmap, reg, &val);
if (ret) {
dev_err(&indio_dev->dev, "failed to read adc\n");
return ret;
@@ -86,10 +87,10 @@ static int lm3533_als_get_adc(struct iio_dev *indio_dev, bool average,
static int _lm3533_als_get_zone(struct iio_dev *indio_dev, u8 *zone)
{
struct lm3533_als *als = iio_priv(indio_dev);
- u8 val;
+ u32 val;
int ret;
- ret = lm3533_read(als->lm3533, LM3533_REG_ALS_ZONE_INFO, &val);
+ ret = regmap_read(als->lm3533->regmap, LM3533_REG_ALS_ZONE_INFO, &val);
if (ret) {
dev_err(&indio_dev->dev, "failed to read zone\n");
return ret;
@@ -127,7 +128,7 @@ static inline u8 lm3533_als_get_target_reg(unsigned channel, unsigned zone)
}
static int lm3533_als_get_target(struct iio_dev *indio_dev, unsigned channel,
- unsigned zone, u8 *val)
+ unsigned zone, u32 *val)
{
struct lm3533_als *als = iio_priv(indio_dev);
u8 reg;
@@ -140,7 +141,7 @@ static int lm3533_als_get_target(struct iio_dev *indio_dev, unsigned channel,
return -EINVAL;
reg = lm3533_als_get_target_reg(channel, zone);
- ret = lm3533_read(als->lm3533, reg, val);
+ ret = regmap_read(als->lm3533->regmap, reg, val);
if (ret)
dev_err(&indio_dev->dev, "failed to get target current\n");
@@ -161,7 +162,7 @@ static int lm3533_als_set_target(struct iio_dev *indio_dev, unsigned channel,
return -EINVAL;
reg = lm3533_als_get_target_reg(channel, zone);
- ret = lm3533_write(als->lm3533, reg, val);
+ ret = regmap_write(als->lm3533->regmap, reg, val);
if (ret)
dev_err(&indio_dev->dev, "failed to set target current\n");
@@ -171,8 +172,8 @@ static int lm3533_als_set_target(struct iio_dev *indio_dev, unsigned channel,
static int lm3533_als_get_current(struct iio_dev *indio_dev, unsigned channel,
int *val)
{
+ u32 target;
u8 zone;
- u8 target;
int ret;
ret = lm3533_als_get_zone(indio_dev, &zone);
@@ -271,16 +272,10 @@ static irqreturn_t lm3533_als_isr(int irq, void *dev_id)
static int lm3533_als_set_int_mode(struct iio_dev *indio_dev, int enable)
{
struct lm3533_als *als = iio_priv(indio_dev);
- u8 mask = LM3533_ALS_INT_ENABLE_MASK;
- u8 val;
int ret;
- if (enable)
- val = mask;
- else
- val = 0;
-
- ret = lm3533_update(als->lm3533, LM3533_REG_ALS_ZONE_INFO, val, mask);
+ ret = regmap_assign_bits(als->lm3533->regmap, LM3533_REG_ALS_ZONE_INFO,
+ LM3533_ALS_INT_ENABLE_MASK, enable);
if (ret) {
dev_err(&indio_dev->dev, "failed to set int mode %d\n",
enable);
@@ -293,17 +288,16 @@ static int lm3533_als_set_int_mode(struct iio_dev *indio_dev, int enable)
static int lm3533_als_get_int_mode(struct iio_dev *indio_dev, int *enable)
{
struct lm3533_als *als = iio_priv(indio_dev);
- u8 mask = LM3533_ALS_INT_ENABLE_MASK;
- u8 val;
int ret;
- ret = lm3533_read(als->lm3533, LM3533_REG_ALS_ZONE_INFO, &val);
- if (ret) {
+ ret = regmap_test_bits(als->lm3533->regmap, LM3533_REG_ALS_ZONE_INFO,
+ LM3533_ALS_INT_ENABLE_MASK);
+ if (ret < 0) {
dev_err(&indio_dev->dev, "failed to get int mode\n");
return ret;
}
- *enable = !!(val & mask);
+ *enable = ret;
return 0;
}
@@ -316,7 +310,7 @@ static inline u8 lm3533_als_get_threshold_reg(unsigned nr, bool raising)
}
static int lm3533_als_get_threshold(struct iio_dev *indio_dev, unsigned nr,
- bool raising, u8 *val)
+ bool raising, u32 *val)
{
struct lm3533_als *als = iio_priv(indio_dev);
u8 reg;
@@ -326,7 +320,7 @@ static int lm3533_als_get_threshold(struct iio_dev *indio_dev, unsigned nr,
return -EINVAL;
reg = lm3533_als_get_threshold_reg(nr, raising);
- ret = lm3533_read(als->lm3533, reg, val);
+ ret = regmap_read(als->lm3533->regmap, reg, val);
if (ret)
dev_err(&indio_dev->dev, "failed to get threshold\n");
@@ -337,8 +331,8 @@ static int lm3533_als_set_threshold(struct iio_dev *indio_dev, unsigned nr,
bool raising, u8 val)
{
struct lm3533_als *als = iio_priv(indio_dev);
- u8 val2;
u8 reg, reg2;
+ u32 val2;
int ret;
if (nr > LM3533_ALS_THRESH_MAX)
@@ -348,7 +342,7 @@ static int lm3533_als_set_threshold(struct iio_dev *indio_dev, unsigned nr,
reg2 = lm3533_als_get_threshold_reg(nr, !raising);
mutex_lock(&als->thresh_mutex);
- ret = lm3533_read(als->lm3533, reg2, &val2);
+ ret = regmap_read(als->lm3533->regmap, reg2, &val2);
if (ret) {
dev_err(&indio_dev->dev, "failed to get threshold\n");
goto out;
@@ -363,7 +357,7 @@ static int lm3533_als_set_threshold(struct iio_dev *indio_dev, unsigned nr,
goto out;
}
- ret = lm3533_write(als->lm3533, reg, val);
+ ret = regmap_write(als->lm3533->regmap, reg, val);
if (ret) {
dev_err(&indio_dev->dev, "failed to set threshold\n");
goto out;
@@ -375,11 +369,11 @@ static int lm3533_als_set_threshold(struct iio_dev *indio_dev, unsigned nr,
}
static int lm3533_als_get_hysteresis(struct iio_dev *indio_dev, unsigned nr,
- u8 *val)
+ u32 *val)
{
struct lm3533_als *als = iio_priv(indio_dev);
- u8 falling;
- u8 raising;
+ u32 falling;
+ u32 raising;
int ret;
if (nr > LM3533_ALS_THRESH_MAX)
@@ -503,7 +497,7 @@ static ssize_t show_als_attr(struct device *dev,
{
struct iio_dev *indio_dev = dev_to_iio_dev(dev);
struct lm3533_als_attribute *als_attr = to_lm3533_als_attr(attr);
- u8 val;
+ u32 val;
int ret;
switch (als_attr->type) {
@@ -716,16 +710,10 @@ static const struct attribute_group lm3533_als_attribute_group = {
static int lm3533_als_set_input_mode(struct lm3533_als *als, bool pwm_mode)
{
- u8 mask = LM3533_ALS_INPUT_MODE_MASK;
- u8 val;
int ret;
- if (pwm_mode)
- val = mask; /* pwm input */
- else
- val = 0; /* analog input */
-
- ret = lm3533_update(als->lm3533, LM3533_REG_ALS_CONF, val, mask);
+ ret = regmap_assign_bits(als->lm3533->regmap, LM3533_REG_ALS_CONF,
+ LM3533_ALS_INPUT_MODE_MASK, pwm_mode);
if (ret) {
dev_err(&als->pdev->dev, "failed to set input mode %d\n",
pwm_mode);
@@ -744,7 +732,8 @@ static int lm3533_als_set_resistor(struct lm3533_als *als, u8 val)
return -EINVAL;
}
- ret = lm3533_write(als->lm3533, LM3533_REG_ALS_RESISTOR_SELECT, val);
+ ret = regmap_write(als->lm3533->regmap, LM3533_REG_ALS_RESISTOR_SELECT,
+ val);
if (ret) {
dev_err(&als->pdev->dev, "failed to set resistor\n");
return ret;
@@ -774,11 +763,11 @@ static int lm3533_als_setup(struct lm3533_als *als,
static int lm3533_als_setup_irq(struct lm3533_als *als, void *dev)
{
- u8 mask = LM3533_ALS_INT_ENABLE_MASK;
int ret;
/* Make sure interrupts are disabled. */
- ret = lm3533_update(als->lm3533, LM3533_REG_ALS_ZONE_INFO, 0, mask);
+ ret = regmap_clear_bits(als->lm3533->regmap, LM3533_REG_ALS_ZONE_INFO,
+ LM3533_ALS_INT_ENABLE_MASK);
if (ret) {
dev_err(&als->pdev->dev, "failed to disable interrupts\n");
return ret;
@@ -798,10 +787,10 @@ static int lm3533_als_setup_irq(struct lm3533_als *als, void *dev)
static int lm3533_als_enable(struct lm3533_als *als)
{
- u8 mask = LM3533_ALS_ENABLE_MASK;
int ret;
- ret = lm3533_update(als->lm3533, LM3533_REG_ALS_CONF, mask, mask);
+ ret = regmap_set_bits(als->lm3533->regmap, LM3533_REG_ALS_CONF,
+ LM3533_ALS_ENABLE_MASK);
if (ret)
dev_err(&als->pdev->dev, "failed to enable ALS\n");
@@ -810,10 +799,10 @@ static int lm3533_als_enable(struct lm3533_als *als)
static int lm3533_als_disable(struct lm3533_als *als)
{
- u8 mask = LM3533_ALS_ENABLE_MASK;
int ret;
- ret = lm3533_update(als->lm3533, LM3533_REG_ALS_CONF, 0, mask);
+ ret = regmap_clear_bits(als->lm3533->regmap, LM3533_REG_ALS_CONF,
+ LM3533_ALS_ENABLE_MASK);
if (ret)
dev_err(&als->pdev->dev, "failed to disable ALS\n");
diff --git a/drivers/leds/leds-lm3533.c b/drivers/leds/leds-lm3533.c
index 45795f2a1042..335c758071f3 100644
--- a/drivers/leds/leds-lm3533.c
+++ b/drivers/leds/leds-lm3533.c
@@ -12,6 +12,7 @@
#include <linux/mfd/core.h>
#include <linux/mutex.h>
#include <linux/platform_device.h>
+#include <linux/regmap.h>
#include <linux/slab.h>
#include <linux/mfd/lm3533.h>
@@ -80,7 +81,6 @@ static inline u8 lm3533_led_get_pattern_reg(struct lm3533_led *led,
static int lm3533_led_pattern_enable(struct lm3533_led *led, int enable)
{
u8 mask;
- u8 val;
int pattern;
int state;
int ret = 0;
@@ -96,12 +96,8 @@ static int lm3533_led_pattern_enable(struct lm3533_led *led, int enable)
pattern = lm3533_led_get_pattern(led);
mask = 1 << (2 * pattern);
- if (enable)
- val = mask;
- else
- val = 0;
-
- ret = lm3533_update(led->lm3533, LM3533_REG_PATTERN_ENABLE, val, mask);
+ ret = regmap_assign_bits(led->lm3533->regmap,
+ LM3533_REG_PATTERN_ENABLE, mask, enable);
if (ret) {
dev_err(led->cdev.dev, "failed to enable pattern %d (%d)\n",
pattern, enable);
@@ -131,7 +127,7 @@ static int lm3533_led_set(struct led_classdev *cdev,
static enum led_brightness lm3533_led_get(struct led_classdev *cdev)
{
struct lm3533_led *led = to_lm3533_led(cdev);
- u8 val;
+ u32 val;
int ret;
ret = lm3533_ctrlbank_get_brightness(&led->cb, &val);
@@ -259,7 +255,7 @@ static u8 lm3533_led_delay_set(struct lm3533_led *led, u8 base,
dev_dbg(led->cdev.dev, "%s - %lu: %u (0x%02x)\n", __func__,
*delay, t, val);
reg = lm3533_led_get_pattern_reg(led, base);
- ret = lm3533_write(led->lm3533, reg, val);
+ ret = regmap_write(led->lm3533->regmap, reg, val);
if (ret)
dev_err(led->cdev.dev, "failed to set delay (%02x)\n", reg);
@@ -337,10 +333,10 @@ static ssize_t show_risefalltime(struct device *dev,
struct lm3533_led *led = to_lm3533_led(led_cdev);
ssize_t ret;
u8 reg;
- u8 val;
+ u32 val;
reg = lm3533_led_get_pattern_reg(led, base);
- ret = lm3533_read(led->lm3533, reg, &val);
+ ret = regmap_read(led->lm3533->regmap, reg, &val);
if (ret)
return ret;
@@ -375,7 +371,7 @@ static ssize_t store_risefalltime(struct device *dev,
return -EINVAL;
reg = lm3533_led_get_pattern_reg(led, base);
- ret = lm3533_write(led->lm3533, reg, val);
+ ret = regmap_write(led->lm3533->regmap, reg, val);
if (ret)
return ret;
@@ -405,11 +401,11 @@ static ssize_t show_als_channel(struct device *dev,
struct lm3533_led *led = to_lm3533_led(led_cdev);
unsigned channel;
u8 reg;
- u8 val;
+ u32 val;
int ret;
reg = lm3533_led_get_lv_reg(led, LM3533_REG_CTRLBANK_BCONF_BASE);
- ret = lm3533_read(led->lm3533, reg, &val);
+ ret = regmap_read(led->lm3533->regmap, reg, &val);
if (ret)
return ret;
@@ -441,7 +437,7 @@ static ssize_t store_als_channel(struct device *dev,
mask = LM3533_REG_CTRLBANK_BCONF_ALS_CHANNEL_MASK;
val = channel - 1;
- ret = lm3533_update(led->lm3533, reg, val, mask);
+ ret = regmap_update_bits(led->lm3533->regmap, reg, mask, val);
if (ret)
return ret;
@@ -455,11 +451,11 @@ static ssize_t show_als_en(struct device *dev,
struct lm3533_led *led = to_lm3533_led(led_cdev);
bool enable;
u8 reg;
- u8 val;
+ u32 val;
int ret;
reg = lm3533_led_get_lv_reg(led, LM3533_REG_CTRLBANK_BCONF_BASE);
- ret = lm3533_read(led->lm3533, reg, &val);
+ ret = regmap_read(led->lm3533->regmap, reg, &val);
if (ret)
return ret;
@@ -476,22 +472,15 @@ static ssize_t store_als_en(struct device *dev,
struct lm3533_led *led = to_lm3533_led(led_cdev);
unsigned enable;
u8 reg;
- u8 mask;
- u8 val;
int ret;
if (kstrtouint(buf, 0, &enable))
return -EINVAL;
reg = lm3533_led_get_lv_reg(led, LM3533_REG_CTRLBANK_BCONF_BASE);
- mask = LM3533_REG_CTRLBANK_BCONF_ALS_EN_MASK;
- if (enable)
- val = mask;
- else
- val = 0;
-
- ret = lm3533_update(led->lm3533, reg, val, mask);
+ ret = regmap_assign_bits(led->lm3533->regmap, reg,
+ LM3533_REG_CTRLBANK_BCONF_ALS_EN_MASK, enable);
if (ret)
return ret;
@@ -504,12 +493,12 @@ static ssize_t show_linear(struct device *dev,
struct led_classdev *led_cdev = dev_get_drvdata(dev);
struct lm3533_led *led = to_lm3533_led(led_cdev);
u8 reg;
- u8 val;
+ u32 val;
int linear;
int ret;
reg = lm3533_led_get_lv_reg(led, LM3533_REG_CTRLBANK_BCONF_BASE);
- ret = lm3533_read(led->lm3533, reg, &val);
+ ret = regmap_read(led->lm3533->regmap, reg, &val);
if (ret)
return ret;
@@ -529,22 +518,15 @@ static ssize_t store_linear(struct device *dev,
struct lm3533_led *led = to_lm3533_led(led_cdev);
unsigned long linear;
u8 reg;
- u8 mask;
- u8 val;
int ret;
if (kstrtoul(buf, 0, &linear))
return -EINVAL;
reg = lm3533_led_get_lv_reg(led, LM3533_REG_CTRLBANK_BCONF_BASE);
- mask = LM3533_REG_CTRLBANK_BCONF_MAPPING_MASK;
- if (linear)
- val = mask;
- else
- val = 0;
-
- ret = lm3533_update(led->lm3533, reg, val, mask);
+ ret = regmap_assign_bits(led->lm3533->regmap, reg,
+ LM3533_REG_CTRLBANK_BCONF_MAPPING_MASK, linear);
if (ret)
return ret;
@@ -557,7 +539,7 @@ static ssize_t show_pwm(struct device *dev,
{
struct led_classdev *led_cdev = dev_get_drvdata(dev);
struct lm3533_led *led = to_lm3533_led(led_cdev);
- u8 val;
+ u32 val;
int ret;
ret = lm3533_ctrlbank_get_pwm(&led->cb, &val);
@@ -573,10 +555,10 @@ static ssize_t store_pwm(struct device *dev,
{
struct led_classdev *led_cdev = dev_get_drvdata(dev);
struct lm3533_led *led = to_lm3533_led(led_cdev);
- u8 val;
+ u32 val;
int ret;
- if (kstrtou8(buf, 0, &val))
+ if (kstrtou32(buf, 0, &val))
return -EINVAL;
ret = lm3533_ctrlbank_set_pwm(&led->cb, val);
diff --git a/drivers/mfd/lm3533-core.c b/drivers/mfd/lm3533-core.c
index 0a2409d00b2e..f9bdc0a1d9be 100644
--- a/drivers/mfd/lm3533-core.c
+++ b/drivers/mfd/lm3533-core.c
@@ -80,66 +80,14 @@ static struct mfd_cell lm3533_led_devs[] = {
},
};
-int lm3533_read(struct lm3533 *lm3533, u8 reg, u8 *val)
-{
- int tmp;
- int ret;
-
- ret = regmap_read(lm3533->regmap, reg, &tmp);
- if (ret < 0) {
- dev_err(lm3533->dev, "failed to read register %02x: %d\n",
- reg, ret);
- return ret;
- }
-
- *val = tmp;
-
- dev_dbg(lm3533->dev, "read [%02x]: %02x\n", reg, *val);
-
- return ret;
-}
-EXPORT_SYMBOL_GPL(lm3533_read);
-
-int lm3533_write(struct lm3533 *lm3533, u8 reg, u8 val)
-{
- int ret;
-
- dev_dbg(lm3533->dev, "write [%02x]: %02x\n", reg, val);
-
- ret = regmap_write(lm3533->regmap, reg, val);
- if (ret < 0) {
- dev_err(lm3533->dev, "failed to write register %02x: %d\n",
- reg, ret);
- }
-
- return ret;
-}
-EXPORT_SYMBOL_GPL(lm3533_write);
-
-int lm3533_update(struct lm3533 *lm3533, u8 reg, u8 val, u8 mask)
-{
- int ret;
-
- dev_dbg(lm3533->dev, "update [%02x]: %02x/%02x\n", reg, val, mask);
-
- ret = regmap_update_bits(lm3533->regmap, reg, mask, val);
- if (ret < 0) {
- dev_err(lm3533->dev, "failed to update register %02x: %d\n",
- reg, ret);
- }
-
- return ret;
-}
-EXPORT_SYMBOL_GPL(lm3533_update);
-
static int lm3533_set_boost_freq(struct lm3533 *lm3533,
enum lm3533_boost_freq freq)
{
int ret;
- ret = lm3533_update(lm3533, LM3533_REG_BOOST_PWM,
- freq << LM3533_BOOST_FREQ_SHIFT,
- LM3533_BOOST_FREQ_MASK);
+ ret = regmap_update_bits(lm3533->regmap, LM3533_REG_BOOST_PWM,
+ LM3533_BOOST_FREQ_MASK,
+ freq << LM3533_BOOST_FREQ_SHIFT);
if (ret)
dev_err(lm3533->dev, "failed to set boost frequency\n");
@@ -152,9 +100,9 @@ static int lm3533_set_boost_ovp(struct lm3533 *lm3533,
{
int ret;
- ret = lm3533_update(lm3533, LM3533_REG_BOOST_PWM,
- ovp << LM3533_BOOST_OVP_SHIFT,
- LM3533_BOOST_OVP_MASK);
+ ret = regmap_update_bits(lm3533->regmap, LM3533_REG_BOOST_PWM,
+ LM3533_BOOST_OVP_MASK,
+ ovp << LM3533_BOOST_OVP_SHIFT);
if (ret)
dev_err(lm3533->dev, "failed to set boost ovp\n");
@@ -181,7 +129,8 @@ static int lm3533_set_hvled_config(struct lm3533 *lm3533, u8 hvled, u8 bl)
mask = LM3533_BL_ID_MASK << shift;
val = bl << shift;
- ret = lm3533_update(lm3533, LM3533_REG_OUTPUT_CONF1, val, mask);
+ ret = regmap_update_bits(lm3533->regmap, LM3533_REG_OUTPUT_CONF1,
+ mask, val);
if (ret)
dev_err(lm3533->dev, "failed to set hvled config\n");
@@ -216,7 +165,7 @@ static int lm3533_set_lvled_config(struct lm3533 *lm3533, u8 lvled, u8 led)
mask = LM3533_LED_ID_MASK << shift;
val = led << shift;
- ret = lm3533_update(lm3533, reg, val, mask);
+ ret = regmap_update_bits(lm3533->regmap, reg, mask, val);
if (ret)
dev_err(lm3533->dev, "failed to set lvled config\n");
@@ -258,7 +207,7 @@ static ssize_t show_output(struct device *dev,
struct lm3533_device_attribute *lattr = to_lm3533_dev_attr(attr);
int id = lattr->u.output.id;
u8 reg;
- u8 val;
+ u32 val;
u8 mask;
int shift;
int ret;
@@ -278,7 +227,7 @@ static ssize_t show_output(struct device *dev,
mask = LM3533_LED_ID_MASK << shift;
}
- ret = lm3533_read(lm3533, reg, &val);
+ ret = regmap_read(lm3533->regmap, reg, &val);
if (ret)
return ret;
diff --git a/drivers/mfd/lm3533-ctrlbank.c b/drivers/mfd/lm3533-ctrlbank.c
index 2537dfade51c..c2b5fd38b81d 100644
--- a/drivers/mfd/lm3533-ctrlbank.c
+++ b/drivers/mfd/lm3533-ctrlbank.c
@@ -9,6 +9,7 @@
#include <linux/device.h>
#include <linux/module.h>
+#include <linux/regmap.h>
#include <linux/mfd/lm3533.h>
@@ -38,8 +39,8 @@ int lm3533_ctrlbank_enable(struct lm3533_ctrlbank *cb)
dev_dbg(cb->dev, "%s - %d\n", __func__, cb->id);
mask = 1 << cb->id;
- ret = lm3533_update(cb->lm3533, LM3533_REG_CTRLBANK_ENABLE,
- mask, mask);
+ ret = regmap_set_bits(cb->lm3533->regmap, LM3533_REG_CTRLBANK_ENABLE,
+ mask);
if (ret)
dev_err(cb->dev, "failed to enable ctrlbank %d\n", cb->id);
@@ -55,7 +56,8 @@ int lm3533_ctrlbank_disable(struct lm3533_ctrlbank *cb)
dev_dbg(cb->dev, "%s - %d\n", __func__, cb->id);
mask = 1 << cb->id;
- ret = lm3533_update(cb->lm3533, LM3533_REG_CTRLBANK_ENABLE, 0, mask);
+ ret = regmap_clear_bits(cb->lm3533->regmap, LM3533_REG_CTRLBANK_ENABLE,
+ mask);
if (ret)
dev_err(cb->dev, "failed to disable ctrlbank %d\n", cb->id);
@@ -68,7 +70,7 @@ EXPORT_SYMBOL_GPL(lm3533_ctrlbank_disable);
*
* imax 5000 - 29800 uA (800 uA step)
*/
-int lm3533_ctrlbank_set_max_current(struct lm3533_ctrlbank *cb, u16 imax)
+int lm3533_ctrlbank_set_max_current(struct lm3533_ctrlbank *cb, u32 imax)
{
u8 reg;
u8 val;
@@ -80,7 +82,7 @@ int lm3533_ctrlbank_set_max_current(struct lm3533_ctrlbank *cb, u16 imax)
val = (imax - LM3533_MAX_CURRENT_MIN) / LM3533_MAX_CURRENT_STEP;
reg = lm3533_ctrlbank_get_reg(cb, LM3533_REG_MAX_CURRENT_BASE);
- ret = lm3533_write(cb->lm3533, reg, val);
+ ret = regmap_write(cb->lm3533->regmap, reg, val);
if (ret)
dev_err(cb->dev, "failed to set max current\n");
@@ -88,13 +90,13 @@ int lm3533_ctrlbank_set_max_current(struct lm3533_ctrlbank *cb, u16 imax)
}
EXPORT_SYMBOL_GPL(lm3533_ctrlbank_set_max_current);
-int lm3533_ctrlbank_set_brightness(struct lm3533_ctrlbank *cb, u8 val)
+int lm3533_ctrlbank_set_brightness(struct lm3533_ctrlbank *cb, u32 val)
{
u8 reg;
int ret;
reg = lm3533_ctrlbank_get_reg(cb, LM3533_REG_BRIGHTNESS_BASE);
- ret = lm3533_write(cb->lm3533, reg, val);
+ ret = regmap_write(cb->lm3533->regmap, reg, val);
if (ret)
dev_err(cb->dev, "failed to set brightness\n");
@@ -102,13 +104,13 @@ int lm3533_ctrlbank_set_brightness(struct lm3533_ctrlbank *cb, u8 val)
}
EXPORT_SYMBOL_GPL(lm3533_ctrlbank_set_brightness);
-int lm3533_ctrlbank_get_brightness(struct lm3533_ctrlbank *cb, u8 *val)
+int lm3533_ctrlbank_get_brightness(struct lm3533_ctrlbank *cb, u32 *val)
{
u8 reg;
int ret;
reg = lm3533_ctrlbank_get_reg(cb, LM3533_REG_BRIGHTNESS_BASE);
- ret = lm3533_read(cb->lm3533, reg, val);
+ ret = regmap_read(cb->lm3533->regmap, reg, val);
if (ret)
dev_err(cb->dev, "failed to get brightness\n");
@@ -126,7 +128,7 @@ EXPORT_SYMBOL_GPL(lm3533_ctrlbank_get_brightness);
* bit 1 - PWM-input enabled in Zone 0
* bit 0 - PWM-input enabled
*/
-int lm3533_ctrlbank_set_pwm(struct lm3533_ctrlbank *cb, u8 val)
+int lm3533_ctrlbank_set_pwm(struct lm3533_ctrlbank *cb, u32 val)
{
u8 reg;
int ret;
@@ -135,7 +137,7 @@ int lm3533_ctrlbank_set_pwm(struct lm3533_ctrlbank *cb, u8 val)
return -EINVAL;
reg = lm3533_ctrlbank_get_reg(cb, LM3533_REG_PWM_BASE);
- ret = lm3533_write(cb->lm3533, reg, val);
+ ret = regmap_write(cb->lm3533->regmap, reg, val);
if (ret)
dev_err(cb->dev, "failed to set PWM mask\n");
@@ -143,13 +145,13 @@ int lm3533_ctrlbank_set_pwm(struct lm3533_ctrlbank *cb, u8 val)
}
EXPORT_SYMBOL_GPL(lm3533_ctrlbank_set_pwm);
-int lm3533_ctrlbank_get_pwm(struct lm3533_ctrlbank *cb, u8 *val)
+int lm3533_ctrlbank_get_pwm(struct lm3533_ctrlbank *cb, u32 *val)
{
u8 reg;
int ret;
reg = lm3533_ctrlbank_get_reg(cb, LM3533_REG_PWM_BASE);
- ret = lm3533_read(cb->lm3533, reg, val);
+ ret = regmap_read(cb->lm3533->regmap, reg, val);
if (ret)
dev_err(cb->dev, "failed to get PWM mask\n");
diff --git a/drivers/video/backlight/lm3533_bl.c b/drivers/video/backlight/lm3533_bl.c
index babfd3ceec86..cd21c64b6485 100644
--- a/drivers/video/backlight/lm3533_bl.c
+++ b/drivers/video/backlight/lm3533_bl.c
@@ -11,6 +11,7 @@
#include <linux/init.h>
#include <linux/platform_device.h>
#include <linux/backlight.h>
+#include <linux/regmap.h>
#include <linux/slab.h>
#include <linux/mfd/lm3533.h>
@@ -45,7 +46,7 @@ static int lm3533_bl_update_status(struct backlight_device *bd)
static int lm3533_bl_get_brightness(struct backlight_device *bd)
{
struct lm3533_bl *bl = bl_get_data(bd);
- u8 val;
+ u32 val;
int ret;
ret = lm3533_ctrlbank_get_brightness(&bl->cb, &val);
@@ -82,12 +83,12 @@ static ssize_t show_als_en(struct device *dev,
{
struct lm3533_bl *bl = dev_get_drvdata(dev);
int ctrlbank = lm3533_bl_get_ctrlbank_id(bl);
- u8 val;
+ u32 val;
u8 mask;
bool enable;
int ret;
- ret = lm3533_read(bl->lm3533, LM3533_REG_CTRLBANK_AB_BCONF, &val);
+ ret = regmap_read(bl->lm3533->regmap, LM3533_REG_CTRLBANK_AB_BCONF, &val);
if (ret)
return ret;
@@ -104,7 +105,6 @@ static ssize_t store_als_en(struct device *dev,
struct lm3533_bl *bl = dev_get_drvdata(dev);
int ctrlbank = lm3533_bl_get_ctrlbank_id(bl);
int enable;
- u8 val;
u8 mask;
int ret;
@@ -113,13 +113,8 @@ static ssize_t store_als_en(struct device *dev,
mask = 1 << (2 * ctrlbank);
- if (enable)
- val = mask;
- else
- val = 0;
-
- ret = lm3533_update(bl->lm3533, LM3533_REG_CTRLBANK_AB_BCONF, val,
- mask);
+ ret = regmap_assign_bits(bl->lm3533->regmap, LM3533_REG_CTRLBANK_AB_BCONF,
+ mask, enable);
if (ret)
return ret;
@@ -130,12 +125,12 @@ static ssize_t show_linear(struct device *dev,
struct device_attribute *attr, char *buf)
{
struct lm3533_bl *bl = dev_get_drvdata(dev);
- u8 val;
+ u32 val;
u8 mask;
int linear;
int ret;
- ret = lm3533_read(bl->lm3533, LM3533_REG_CTRLBANK_AB_BCONF, &val);
+ ret = regmap_read(bl->lm3533->regmap, LM3533_REG_CTRLBANK_AB_BCONF, &val);
if (ret)
return ret;
@@ -156,7 +151,6 @@ static ssize_t store_linear(struct device *dev,
struct lm3533_bl *bl = dev_get_drvdata(dev);
unsigned long linear;
u8 mask;
- u8 val;
int ret;
if (kstrtoul(buf, 0, &linear))
@@ -164,13 +158,8 @@ static ssize_t store_linear(struct device *dev,
mask = 1 << (2 * lm3533_bl_get_ctrlbank_id(bl) + 1);
- if (linear)
- val = mask;
- else
- val = 0;
-
- ret = lm3533_update(bl->lm3533, LM3533_REG_CTRLBANK_AB_BCONF, val,
- mask);
+ ret = regmap_assign_bits(bl->lm3533->regmap, LM3533_REG_CTRLBANK_AB_BCONF,
+ mask, linear);
if (ret)
return ret;
@@ -182,7 +171,7 @@ static ssize_t show_pwm(struct device *dev,
char *buf)
{
struct lm3533_bl *bl = dev_get_drvdata(dev);
- u8 val;
+ u32 val;
int ret;
ret = lm3533_ctrlbank_get_pwm(&bl->cb, &val);
@@ -197,10 +186,10 @@ static ssize_t store_pwm(struct device *dev,
const char *buf, size_t len)
{
struct lm3533_bl *bl = dev_get_drvdata(dev);
- u8 val;
+ u32 val;
int ret;
- if (kstrtou8(buf, 0, &val))
+ if (kstrtou32(buf, 0, &val))
return -EINVAL;
ret = lm3533_ctrlbank_set_pwm(&bl->cb, val);
diff --git a/include/linux/mfd/lm3533.h b/include/linux/mfd/lm3533.h
index 69059a7a2ce5..3463b164d0c1 100644
--- a/include/linux/mfd/lm3533.h
+++ b/include/linux/mfd/lm3533.h
@@ -85,15 +85,10 @@ struct lm3533_platform_data {
extern int lm3533_ctrlbank_enable(struct lm3533_ctrlbank *cb);
extern int lm3533_ctrlbank_disable(struct lm3533_ctrlbank *cb);
-extern int lm3533_ctrlbank_set_brightness(struct lm3533_ctrlbank *cb, u8 val);
-extern int lm3533_ctrlbank_get_brightness(struct lm3533_ctrlbank *cb, u8 *val);
-extern int lm3533_ctrlbank_set_max_current(struct lm3533_ctrlbank *cb,
- u16 imax);
-extern int lm3533_ctrlbank_set_pwm(struct lm3533_ctrlbank *cb, u8 val);
-extern int lm3533_ctrlbank_get_pwm(struct lm3533_ctrlbank *cb, u8 *val);
-
-extern int lm3533_read(struct lm3533 *lm3533, u8 reg, u8 *val);
-extern int lm3533_write(struct lm3533 *lm3533, u8 reg, u8 val);
-extern int lm3533_update(struct lm3533 *lm3533, u8 reg, u8 val, u8 mask);
+extern int lm3533_ctrlbank_set_brightness(struct lm3533_ctrlbank *cb, u32 val);
+extern int lm3533_ctrlbank_get_brightness(struct lm3533_ctrlbank *cb, u32 *val);
+extern int lm3533_ctrlbank_set_max_current(struct lm3533_ctrlbank *cb, u32 imax);
+extern int lm3533_ctrlbank_set_pwm(struct lm3533_ctrlbank *cb, u32 val);
+extern int lm3533_ctrlbank_get_pwm(struct lm3533_ctrlbank *cb, u32 *val);
#endif /* __LINUX_MFD_LM3533_H */
--
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