* [PATCH v8 2/2] platform: Add initial synology microp driver
From: Markus Probst @ 2026-04-20 14:24 UTC (permalink / raw)
To: Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Lee Jones, Pavel Machek, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Greg Kroah-Hartman
Cc: platform-driver-x86, linux-leds, devicetree, linux-kernel,
rust-for-linux, Markus Probst
In-Reply-To: <20260420-synology_microp_initial-v8-0-7946a9124491@posteo.de>
Add a initial synology microp driver, written in Rust.
The driver targets a microcontroller found in Synology NAS devices. It
currently only supports controlling of the power led, status led, alert
led and usb led. Other components such as fan control or handling
on-device buttons will be added once the required rust abstractions are
there.
This driver can be used both on arm and x86, thus it goes into the root
directory of drivers/platform.
Tested successfully on a Synology DS923+.
Signed-off-by: Markus Probst <markus.probst@posteo.de>
---
MAINTAINERS | 6 +
drivers/platform/Kconfig | 2 +
drivers/platform/Makefile | 1 +
drivers/platform/synology_microp/Kconfig | 13 +
drivers/platform/synology_microp/Makefile | 3 +
drivers/platform/synology_microp/TODO | 7 +
drivers/platform/synology_microp/command.rs | 54 ++++
drivers/platform/synology_microp/led.rs | 281 +++++++++++++++++++++
drivers/platform/synology_microp/model.rs | 49 ++++
.../platform/synology_microp/synology_microp.rs | 110 ++++++++
10 files changed, 526 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index c1c686846cdd..49f08290eed0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -25555,6 +25555,12 @@ F: drivers/dma-buf/sync_*
F: include/linux/sync_file.h
F: include/uapi/linux/sync_file.h
+SYNOLOGY MICROP DRIVER
+M: Markus Probst <markus.probst@posteo.de>
+S: Maintained
+F: Documentation/devicetree/bindings/embedded-controller/synology,ds1825p-microp.yaml
+F: drivers/platform/synology_microp/
+
SYNOPSYS ARC ARCHITECTURE
M: Vineet Gupta <vgupta@kernel.org>
L: linux-snps-arc@lists.infradead.org
diff --git a/drivers/platform/Kconfig b/drivers/platform/Kconfig
index 312788f249c9..996050566a4a 100644
--- a/drivers/platform/Kconfig
+++ b/drivers/platform/Kconfig
@@ -22,3 +22,5 @@ source "drivers/platform/arm64/Kconfig"
source "drivers/platform/raspberrypi/Kconfig"
source "drivers/platform/wmi/Kconfig"
+
+source "drivers/platform/synology_microp/Kconfig"
diff --git a/drivers/platform/Makefile b/drivers/platform/Makefile
index fa322e7f8716..2381872e9133 100644
--- a/drivers/platform/Makefile
+++ b/drivers/platform/Makefile
@@ -15,3 +15,4 @@ obj-$(CONFIG_SURFACE_PLATFORMS) += surface/
obj-$(CONFIG_ARM64_PLATFORM_DEVICES) += arm64/
obj-$(CONFIG_BCM2835_VCHIQ) += raspberrypi/
obj-$(CONFIG_ACPI_WMI) += wmi/
+obj-$(CONFIG_SYNOLOGY_MICROP) += synology_microp/
diff --git a/drivers/platform/synology_microp/Kconfig b/drivers/platform/synology_microp/Kconfig
new file mode 100644
index 000000000000..7c4d8f2808f0
--- /dev/null
+++ b/drivers/platform/synology_microp/Kconfig
@@ -0,0 +1,13 @@
+# SPDX-License-Identifier: GPL-2.0
+
+config SYNOLOGY_MICROP
+ tristate "Synology Microp driver"
+ depends on LEDS_CLASS && LEDS_CLASS_MULTICOLOR
+ depends on RUST_SERIAL_DEV_BUS_ABSTRACTIONS
+ help
+ Enable support for the MCU found in Synology NAS devices.
+
+ This is needed to properly shutdown and reboot the device, as well as
+ additional functionality like fan and LED control.
+
+ This driver is work in progress and may not be fully functional.
diff --git a/drivers/platform/synology_microp/Makefile b/drivers/platform/synology_microp/Makefile
new file mode 100644
index 000000000000..63585ccf76e4
--- /dev/null
+++ b/drivers/platform/synology_microp/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-y += synology_microp.o
diff --git a/drivers/platform/synology_microp/TODO b/drivers/platform/synology_microp/TODO
new file mode 100644
index 000000000000..1961a33115db
--- /dev/null
+++ b/drivers/platform/synology_microp/TODO
@@ -0,0 +1,7 @@
+TODO:
+- add missing components:
+ - handle on-device buttons (Power, Factory reset, "USB Copy")
+ - handle fan failure
+ - beeper
+ - fan speed control
+ - correctly perform device power-off and restart on Synology devices
diff --git a/drivers/platform/synology_microp/command.rs b/drivers/platform/synology_microp/command.rs
new file mode 100644
index 000000000000..430cb858e1c3
--- /dev/null
+++ b/drivers/platform/synology_microp/command.rs
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0
+
+use kernel::{
+ device::Bound,
+ error::Result,
+ serdev, //
+};
+
+use crate::led;
+
+#[expect(
+ clippy::enum_variant_names,
+ reason = "future variants will not end with Led"
+)]
+pub(crate) enum Command {
+ PowerLed(led::State),
+ StatusLed(led::StatusLedColor, led::State),
+ AlertLed(led::State),
+ UsbLed(led::State),
+ EsataLed(led::State),
+}
+
+impl Command {
+ pub(crate) fn write(self, dev: &serdev::Device<Bound>) -> Result {
+ dev.write_all(
+ match self {
+ Self::PowerLed(led::State::On) => &[0x34],
+ Self::PowerLed(led::State::Blink) => &[0x35],
+ Self::PowerLed(led::State::Off) => &[0x36],
+
+ Self::StatusLed(_, led::State::Off) => &[0x37],
+ Self::StatusLed(led::StatusLedColor::Green, led::State::On) => &[0x38],
+ Self::StatusLed(led::StatusLedColor::Green, led::State::Blink) => &[0x39],
+ Self::StatusLed(led::StatusLedColor::Orange, led::State::On) => &[0x3A],
+ Self::StatusLed(led::StatusLedColor::Orange, led::State::Blink) => &[0x3B],
+
+ Self::AlertLed(led::State::On) => &[0x4C, 0x41, 0x31],
+ Self::AlertLed(led::State::Blink) => &[0x4C, 0x41, 0x32],
+ Self::AlertLed(led::State::Off) => &[0x4C, 0x41, 0x33],
+
+ Self::UsbLed(led::State::On) => &[0x40],
+ Self::UsbLed(led::State::Blink) => &[0x41],
+ Self::UsbLed(led::State::Off) => &[0x42],
+
+ Self::EsataLed(led::State::On) => &[0x4C, 0x45, 0x31],
+ Self::EsataLed(led::State::Blink) => &[0x4C, 0x45, 0x32],
+ Self::EsataLed(led::State::Off) => &[0x4C, 0x45, 0x33],
+ },
+ serdev::Timeout::Max,
+ )?;
+ dev.wait_until_sent(serdev::Timeout::Max);
+ Ok(())
+ }
+}
diff --git a/drivers/platform/synology_microp/led.rs b/drivers/platform/synology_microp/led.rs
new file mode 100644
index 000000000000..f89998a7e6b4
--- /dev/null
+++ b/drivers/platform/synology_microp/led.rs
@@ -0,0 +1,281 @@
+// SPDX-License-Identifier: GPL-2.0
+
+use kernel::{
+ device::Bound,
+ devres::{
+ self,
+ Devres, //
+ },
+ led::{
+ self,
+ LedOps,
+ MultiColorSubLed, //
+ },
+ new_mutex,
+ prelude::*,
+ serdev,
+ str::CString,
+ sync::Mutex, //
+};
+use pin_init::pin_init_scope;
+
+use crate::{
+ command::Command,
+ model::Model, //
+};
+
+#[pin_data]
+pub(crate) struct Data {
+ #[pin]
+ status: Devres<led::MultiColorDevice<StatusLedHandler>>,
+ power_name: CString,
+ #[pin]
+ power: Devres<led::Device<LedHandler>>,
+}
+
+impl Data {
+ pub(super) fn register<'a>(
+ dev: &'a serdev::Device<Bound>,
+ model: &'a Model,
+ ) -> impl PinInit<Self, Error> + 'a {
+ pin_init_scope(move || {
+ if let Some(color) = model.led_alert {
+ let name = CString::try_from_fmt(fmt!("{}:alarm", color.as_c_str().to_str()?))?;
+ devres::register(
+ dev.as_ref(),
+ led::DeviceBuilder::new().color(color).name(&name).build(
+ dev,
+ try_pin_init!(LedHandler {
+ blink <- new_mutex!(false),
+ command: Command::AlertLed,
+ }),
+ ),
+ GFP_KERNEL,
+ )?;
+ }
+
+ if model.led_usb_copy {
+ devres::register(
+ dev.as_ref(),
+ led::DeviceBuilder::new()
+ .color(led::Color::Green)
+ .name(c"green:usb")
+ .build(
+ dev,
+ try_pin_init!(LedHandler {
+ blink <- new_mutex!(false),
+ command: Command::UsbLed,
+ }),
+ ),
+ GFP_KERNEL,
+ )?;
+ }
+
+ if model.led_esata {
+ devres::register(
+ dev.as_ref(),
+ led::DeviceBuilder::new()
+ .color(led::Color::Green)
+ .name(c"green:esata")
+ .build(
+ dev,
+ try_pin_init!(LedHandler {
+ blink <- new_mutex!(false),
+ command: Command::EsataLed,
+ }),
+ ),
+ GFP_KERNEL,
+ )?;
+ }
+
+ Ok(try_pin_init!(Self {
+ status <- led::DeviceBuilder::new()
+ .color(led::Color::Multi)
+ .name(c"multicolor:status")
+ .build_multicolor(
+ dev,
+ try_pin_init!(StatusLedHandler {
+ blink <- new_mutex!(false),
+ }),
+ StatusLedHandler::SUBLEDS,
+ ),
+ power_name: CString::try_from_fmt(fmt!(
+ "{}:power",
+ model.led_power.as_c_str().to_str()?
+ ))?,
+ power <- led::DeviceBuilder::new()
+ .color(model.led_power)
+ .name(power_name)
+ .build(
+ dev,
+ try_pin_init!(LedHandler {
+ blink <- new_mutex!(true),
+ command: Command::PowerLed,
+ }),
+ ),
+ }))
+ })
+ }
+}
+
+#[derive(Copy, Clone)]
+pub(crate) enum StatusLedColor {
+ Green,
+ Orange,
+}
+
+#[derive(Copy, Clone)]
+pub(crate) enum State {
+ On,
+ Blink,
+ Off,
+}
+
+#[pin_data]
+struct LedHandler {
+ #[pin]
+ blink: Mutex<bool>,
+ command: fn(State) -> Command,
+}
+
+/// Blink delay measured using video recording on DS923+ for Power and Status Led.
+///
+/// We assume it is the same for all other leds and models.
+const BLINK_DELAY: usize = 167;
+
+#[vtable]
+impl LedOps for LedHandler {
+ type Bus = serdev::Device<Bound>;
+ type Mode = led::Normal;
+ const BLOCKING: bool = true;
+ const MAX_BRIGHTNESS: u32 = 1;
+
+ fn brightness_set(
+ &self,
+ dev: &Self::Bus,
+ _classdev: &led::Device<Self>,
+ brightness: u32,
+ ) -> Result<()> {
+ let mut blink = self.blink.lock();
+ (self.command)(if brightness == 0 {
+ *blink = false;
+ State::Off
+ } else if *blink {
+ State::Blink
+ } else {
+ State::On
+ })
+ .write(dev)?;
+
+ Ok(())
+ }
+
+ fn blink_set(
+ &self,
+ dev: &Self::Bus,
+ _classdev: &led::Device<Self>,
+ delay_on: &mut usize,
+ delay_off: &mut usize,
+ ) -> Result<()> {
+ let mut blink = self.blink.lock();
+
+ (self.command)(if *delay_on == 0 && *delay_off != 0 {
+ State::Off
+ } else if *delay_on != 0 && *delay_off == 0 {
+ State::On
+ } else {
+ *blink = true;
+ *delay_on = BLINK_DELAY;
+ *delay_off = BLINK_DELAY;
+
+ State::Blink
+ })
+ .write(dev)
+ }
+}
+
+#[pin_data]
+struct StatusLedHandler {
+ #[pin]
+ blink: Mutex<bool>,
+}
+
+impl StatusLedHandler {
+ const SUBLEDS: &[MultiColorSubLed] = &[
+ MultiColorSubLed::new(led::Color::Green).initial_intensity(1),
+ MultiColorSubLed::new(led::Color::Orange),
+ ];
+}
+
+#[vtable]
+impl LedOps for StatusLedHandler {
+ type Bus = serdev::Device<Bound>;
+ type Mode = led::MultiColor;
+ const BLOCKING: bool = true;
+ const MAX_BRIGHTNESS: u32 = 1;
+
+ fn brightness_set(
+ &self,
+ dev: &Self::Bus,
+ classdev: &led::MultiColorDevice<Self>,
+ brightness: u32,
+ ) -> Result<()> {
+ let mut blink = self.blink.lock();
+ if brightness == 0 {
+ *blink = false;
+ }
+
+ let (color, subled_brightness) = if classdev.subleds()[1].intensity == 0 {
+ (StatusLedColor::Green, classdev.subleds()[0].brightness)
+ } else {
+ (StatusLedColor::Orange, classdev.subleds()[1].brightness)
+ };
+
+ Command::StatusLed(
+ color,
+ if subled_brightness == 0 {
+ State::Off
+ } else if *blink {
+ State::Blink
+ } else {
+ State::On
+ },
+ )
+ .write(dev)
+ }
+
+ fn blink_set(
+ &self,
+ dev: &Self::Bus,
+ classdev: &led::MultiColorDevice<Self>,
+ delay_on: &mut usize,
+ delay_off: &mut usize,
+ ) -> Result<()> {
+ let mut blink = self.blink.lock();
+ *blink = true;
+
+ let (color, subled_intensity) = if classdev.subleds()[1].intensity == 0 {
+ (StatusLedColor::Green, classdev.subleds()[0].intensity)
+ } else {
+ (StatusLedColor::Orange, classdev.subleds()[1].intensity)
+ };
+ Command::StatusLed(
+ color,
+ if *delay_on == 0 && *delay_off != 0 {
+ *blink = false;
+ State::Off
+ } else if subled_intensity == 0 {
+ State::Off
+ } else if *delay_on != 0 && *delay_off == 0 {
+ *blink = false;
+ State::On
+ } else {
+ *delay_on = BLINK_DELAY;
+ *delay_off = BLINK_DELAY;
+
+ State::Blink
+ },
+ )
+ .write(dev)
+ }
+}
diff --git a/drivers/platform/synology_microp/model.rs b/drivers/platform/synology_microp/model.rs
new file mode 100644
index 000000000000..715d8840f56b
--- /dev/null
+++ b/drivers/platform/synology_microp/model.rs
@@ -0,0 +1,49 @@
+// SPDX-License-Identifier: GPL-2.0
+
+use kernel::led::Color;
+
+pub(crate) struct Model {
+ pub(crate) led_power: Color,
+ pub(crate) led_alert: Option<Color>,
+ pub(crate) led_usb_copy: bool,
+ pub(crate) led_esata: bool,
+}
+
+impl Model {
+ pub(super) const fn new() -> Self {
+ Self {
+ led_power: Color::Blue,
+ led_alert: None,
+ led_usb_copy: false,
+ led_esata: false,
+ }
+ }
+
+ pub(super) const fn led_power(self, color: Color) -> Self {
+ Self {
+ led_power: color,
+ ..self
+ }
+ }
+
+ pub(super) const fn led_alert(self, color: Color) -> Self {
+ Self {
+ led_alert: Some(color),
+ ..self
+ }
+ }
+
+ pub(super) const fn led_esata(self) -> Self {
+ Self {
+ led_esata: true,
+ ..self
+ }
+ }
+
+ pub(super) const fn led_usb_copy(self) -> Self {
+ Self {
+ led_usb_copy: true,
+ ..self
+ }
+ }
+}
diff --git a/drivers/platform/synology_microp/synology_microp.rs b/drivers/platform/synology_microp/synology_microp.rs
new file mode 100644
index 000000000000..1fd4fc658d85
--- /dev/null
+++ b/drivers/platform/synology_microp/synology_microp.rs
@@ -0,0 +1,110 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Synology Microp driver
+
+use kernel::{
+ device,
+ led::Color,
+ of::{
+ DeviceId,
+ IdTable, //
+ },
+ of_device_table,
+ prelude::*,
+ serdev, //
+};
+use pin_init::pin_init_scope;
+
+use crate::model::Model;
+
+pub(crate) mod command;
+mod led;
+mod model;
+
+kernel::module_serdev_device_driver! {
+ type: SynologyMicropDriver,
+ name: "synology_microp",
+ authors: ["Markus Probst <markus.probst@posteo.de>"],
+ description: "Synology Microp driver",
+ license: "GPL v2",
+}
+
+#[rustfmt::skip]
+of_device_table!(
+ OF_TABLE,
+ MODULE_OF_TABLE,
+ Model,
+ [
+ // apollolake
+ (DeviceId::new(c"synology,ds918p-microp"), Model::new()),
+
+ // evansport
+ (DeviceId::new(c"synology,ds214play-microp"), Model::new()),
+
+ // geminilakenk
+ (DeviceId::new(c"synology,ds225p-microp"), Model::new().led_usb_copy()),
+ (DeviceId::new(c"synology,ds425p-microp"), Model::new()),
+
+ // pineview
+ (DeviceId::new(c"synology,ds710p-microp"), Model::new().led_esata()),
+ (DeviceId::new(c"synology,ds1010p-microp"), Model::new().led_alert(Color::Orange)),
+ (DeviceId::new(c"synology,ds411p-microp"), Model::new()),
+
+ // r1000
+ (DeviceId::new(c"synology,ds923p-microp"), Model::new()),
+ (DeviceId::new(c"synology,ds723p-microp"), Model::new()),
+ (DeviceId::new(c"synology,ds1522p-microp"), Model::new()),
+ (DeviceId::new(c"synology,rs422p-microp"), Model::new().led_power(Color::Green)),
+
+ // r1000nk
+ (DeviceId::new(c"synology,ds725p-microp"), Model::new()),
+
+ // rtd1296
+ (DeviceId::new(c"synology,ds118-microp"), Model::new()),
+
+ // rtd1619b
+ (DeviceId::new(c"synology,ds124-microp"), Model::new()),
+ (DeviceId::new(c"synolody,ds223-microp"), Model::new().led_usb_copy()),
+ (DeviceId::new(c"synology,ds223j-microp"), Model::new()),
+
+ // v1000
+ (DeviceId::new(c"synology,ds1823xsp-microp"), Model::new()),
+ (DeviceId::new(c"synology,rs822p-microp"), Model::new().led_power(Color::Green)),
+ (DeviceId::new(c"synology,rs1221p-microp"), Model::new().led_power(Color::Green)),
+ (DeviceId::new(c"synology,rs1221rpp-microp"), Model::new().led_power(Color::Green)),
+
+ // v1000nk
+ (DeviceId::new(c"synology,ds925p-microp"), Model::new()),
+ (DeviceId::new(c"synology,ds1525p-microp"), Model::new()),
+ (DeviceId::new(c"synology,ds1825p-microp"), Model::new()),
+ ]
+);
+
+#[pin_data]
+struct SynologyMicropDriver {
+ #[pin]
+ led: led::Data,
+}
+
+#[vtable]
+impl serdev::Driver for SynologyMicropDriver {
+ type IdInfo = Model;
+ const OF_ID_TABLE: Option<IdTable<Self::IdInfo>> = Some(&OF_TABLE);
+
+ fn probe(
+ dev: &serdev::Device<device::Core>,
+ model: Option<&Model>,
+ ) -> impl PinInit<Self, kernel::error::Error> {
+ pin_init_scope(move || {
+ let model = model.ok_or(EINVAL)?;
+
+ dev.set_baudrate(9600).map_err(|_| EINVAL)?;
+ dev.set_flow_control(false);
+ dev.set_parity(serdev::Parity::None)?;
+
+ Ok(try_pin_init!(Self {
+ led <- led::Data::register(dev, model),
+ }))
+ })
+ }
+}
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v3 1/2] dt-bindings: rng: mtk-rng: add SMC-based TRNG variants
From: Daniel Golle @ 2026-04-20 14:24 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sean Wang, linux-crypto, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260420-flat-rook-of-hail-bbede5@quoll>
On Mon, Apr 20, 2026 at 04:07:33PM +0200, Krzysztof Kozlowski wrote:
> On Sun, Apr 19, 2026 at 01:05:01PM +0100, Daniel Golle wrote:
> > + rng {
> > + compatible = "mediatek,mt7981-rng";
>
> I asked at v1. Reminded at v2. Nothing serious, but repeating myself is
> pointless and kind of waste of time.
Replying *once* telling what you would actually want, or replying to
me asking back would have helped enormously:
https://patchwork.kernel.org/comment/26880354/
All I can see is that you concluded "no improvements" without telling
*what it is you would like to see improved*.
You want me to drop the whole example? Drop the compatible?
I did drop (and replace) the negative list with a positive list, and
thought that was what you have asked me for
https://patchwork.kernel.org/comment/26817847/
This binding is dead simple: It's a compatible, describing the identical
hardware now hidden behind and SMC call.
^ permalink raw reply
* Re: [PATCH v3 4/5] iio: magnetometer: qmc5883p: add oversampling ratio support
From: Jonathan Cameron @ 2026-04-20 14:25 UTC (permalink / raw)
To: Hardik Phalet
Cc: gregkh, andy, conor+dt, devicetree, dlechner, krzk+dt, linux-iio,
linux-kernel, linux-staging, me, nuno.sa, robh, skhan,
Hardik Phalet
In-Reply-To: <20260420-qmc5883p-driver-v3-4-da1e97088f8b@pm.me>
On Sun, 19 Apr 2026 22:32:56 +0000
Hardik Phalet <hardik.phalet@pm.me> wrote:
> Expose the CTRL_1 OSR field through IIO_CHAN_INFO_OVERSAMPLING_RATIO so
> userspace can select among the four oversampling settings (1, 2, 4, 8)
> supported by the device. Read, write and available handlers mirror the
> existing SAMP_FREQ plumbing and use the already-present rf.osr regmap
> field.
>
> Signed-off-by: Hardik Phalet <hardik.phalet@pm.me>
> ---
> @@ -306,6 +320,18 @@ static int qmc5883p_write_odr(struct qmc5883p_data *data, int val)
> return -EINVAL;
> }
>
> +static int qmc5883p_write_osr(struct qmc5883p_data *data, int val)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(qmc5883p_osr); i++) {
Whilst a fairly recent thing, it is now considered fine to do
for (int i = 0; i < ...
> + if (qmc5883p_osr[i] == val)
> + return regmap_field_write(data->rf.osr, i);
> + }
> +
> + return -EINVAL;
> +}
^ permalink raw reply
* [PATCH v2 0/2] pinctrl: qcom: eliza: Split up some QUP pin groups
From: Alexander Koskovich @ 2026-04-20 14:27 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Abel Vesa
Cc: linux-arm-msm, linux-gpio, linux-kernel, devicetree,
Alexander Koskovich
Multiple QUPs have lanes that can be routed to one of two GPIOs and
collapsing them prevents devicetrees from requesting specific routing.
For example, a board that wires an I2C SCL line to one of two GPIOs
cannot request that specific pin with the groups collapsed.
This series splits them up so devicetrees can request the configuration
they need.
Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
---
Changes in v2:
- Update bindings to reflect new split functions
- Link to v1: https://lore.kernel.org/r/20260418-fix-eliza-pinctrl-v1-1-864bf95ac83b@pm.me
---
Alexander Koskovich (2):
dt-bindings: pinctrl: qcom,eliza-tlmm: Update function list
pinctrl: qcom: eliza: Split up some QUP pin groups
.../bindings/pinctrl/qcom,eliza-tlmm.yaml | 13 +-
drivers/pinctrl/qcom/pinctrl-eliza.c | 200 +++++++++++++++++----
2 files changed, 179 insertions(+), 34 deletions(-)
---
base-commit: c7275b05bc428c7373d97aa2da02d3a7fa6b9f66
change-id: 20260418-fix-eliza-pinctrl-b6e66dd92766
Best regards,
--
Alexander Koskovich <akoskovich@pm.me>
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: pinctrl: qcom,eliza-tlmm: Update function list
From: Alexander Koskovich @ 2026-04-20 14:27 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Abel Vesa
Cc: linux-arm-msm, linux-gpio, linux-kernel, devicetree,
Alexander Koskovich
In-Reply-To: <20260420-fix-eliza-pinctrl-v2-0-b68329fd6701@pm.me>
Update the function list to include the QUPs whose lanes can have more
than one GPIO option.
This allows devicetrees to override the function for say, SE6 I2C SCL
pin from 54 to 42.
Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
---
.../devicetree/bindings/pinctrl/qcom,eliza-tlmm.yaml | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,eliza-tlmm.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,eliza-tlmm.yaml
index 282650426487..9010226bf1a0 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,eliza-tlmm.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,eliza-tlmm.yaml
@@ -86,9 +86,16 @@ $defs:
qdss_gpio_tracectl, qdss_gpio_tracedata, qlink_big_enable,
qlink_big_request, qlink_little_enable,
qlink_little_request, qlink_wmss, qspi0, qspi_clk,
- qspi_cs, qup1_se0, qup1_se1, qup1_se2, qup1_se3, qup1_se4,
- qup1_se5, qup1_se6, qup1_se7, qup2_se0, qup2_se1,
- qup2_se2, qup2_se3, qup2_se4, qup2_se5, qup2_se6,
+ qspi_cs, qup1_se0, qup1_se1, qup1_se2_l0, qup1_se2_l1,
+ qup1_se2_l2_mira, qup1_se2_l2_mirb, qup1_se2_l3_mira,
+ qup1_se2_l3_mirb, qup1_se2_l4, qup1_se2_l5, qup1_se2_l6,
+ qup1_se3, qup1_se4, qup1_se5, qup1_se6_l0, qup1_se6_l1_mira,
+ qup1_se6_l1_mirb, qup1_se6_l2, qup1_se6_l3_mira,
+ qup1_se6_l3_mirb, qup1_se7_l0_mira, qup1_se7_l0_mirb,
+ qup1_se7_l1_mira, qup1_se7_l1_mirb, qup1_se7_l2, qup1_se7_l3,
+ qup2_se0, qup2_se1, qup2_se2, qup2_se3_l0_mira,
+ qup2_se3_l0_mirb, qup2_se3_l1_mira, qup2_se3_l1_mirb,
+ qup2_se3_l2, qup2_se3_l3, qup2_se4, qup2_se5, qup2_se6,
qup2_se7, resout_gpio, sd_write_protect, sdc1, sdc2,
sdc2_fb_clk, tb_trig_sdc1, tb_trig_sdc2, tmess_prng0,
tmess_prng1, tmess_prng2, tmess_prng3, tsense_pwm1,
--
2.53.0
^ permalink raw reply related
* [PATCH v2 2/2] pinctrl: qcom: eliza: Split up some QUP pin groups
From: Alexander Koskovich @ 2026-04-20 14:28 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Abel Vesa
Cc: linux-arm-msm, linux-gpio, linux-kernel, devicetree,
Alexander Koskovich
In-Reply-To: <20260420-fix-eliza-pinctrl-v2-0-b68329fd6701@pm.me>
Multiple QUPs have lanes that can be routed to one of two GPIOs and
collapsing them prevents devicetrees from requesting specific routing.
For example, a board that wires an I2C SCL line to one of two GPIOs
cannot request that specific pin with the groups collapsed.
This change splits them up so devicetrees can request the configuration
they need.
Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
---
drivers/pinctrl/qcom/pinctrl-eliza.c | 200 +++++++++++++++++++++++++++++------
1 file changed, 169 insertions(+), 31 deletions(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-eliza.c b/drivers/pinctrl/qcom/pinctrl-eliza.c
index c1f756cbcdeb..a1365bcd3bf6 100644
--- a/drivers/pinctrl/qcom/pinctrl-eliza.c
+++ b/drivers/pinctrl/qcom/pinctrl-eliza.c
@@ -562,16 +562,39 @@ enum eliza_functions {
msm_mux_qspi_cs,
msm_mux_qup1_se0,
msm_mux_qup1_se1,
- msm_mux_qup1_se2,
+ msm_mux_qup1_se2_l0,
+ msm_mux_qup1_se2_l1,
+ msm_mux_qup1_se2_l2_mira,
+ msm_mux_qup1_se2_l2_mirb,
+ msm_mux_qup1_se2_l3_mira,
+ msm_mux_qup1_se2_l3_mirb,
+ msm_mux_qup1_se2_l4,
+ msm_mux_qup1_se2_l5,
+ msm_mux_qup1_se2_l6,
msm_mux_qup1_se3,
msm_mux_qup1_se4,
msm_mux_qup1_se5,
- msm_mux_qup1_se6,
- msm_mux_qup1_se7,
+ msm_mux_qup1_se6_l0,
+ msm_mux_qup1_se6_l1_mira,
+ msm_mux_qup1_se6_l1_mirb,
+ msm_mux_qup1_se6_l2,
+ msm_mux_qup1_se6_l3_mira,
+ msm_mux_qup1_se6_l3_mirb,
+ msm_mux_qup1_se7_l0_mira,
+ msm_mux_qup1_se7_l0_mirb,
+ msm_mux_qup1_se7_l1_mira,
+ msm_mux_qup1_se7_l1_mirb,
+ msm_mux_qup1_se7_l2,
+ msm_mux_qup1_se7_l3,
msm_mux_qup2_se0,
msm_mux_qup2_se1,
msm_mux_qup2_se2,
- msm_mux_qup2_se3,
+ msm_mux_qup2_se3_l0_mira,
+ msm_mux_qup2_se3_l0_mirb,
+ msm_mux_qup2_se3_l1_mira,
+ msm_mux_qup2_se3_l1_mirb,
+ msm_mux_qup2_se3_l2,
+ msm_mux_qup2_se3_l3,
msm_mux_qup2_se4,
msm_mux_qup2_se5,
msm_mux_qup2_se6,
@@ -977,8 +1000,40 @@ static const char *const qup1_se1_groups[] = {
"gpio32", "gpio33", "gpio34", "gpio35",
};
-static const char *const qup1_se2_groups[] = {
- "gpio52", "gpio53", "gpio54", "gpio52", "gpio55", "gpio53", "gpio40", "gpio42", "gpio30",
+static const char *const qup1_se2_l0_groups[] = {
+ "gpio52",
+};
+
+static const char *const qup1_se2_l1_groups[] = {
+ "gpio53",
+};
+
+static const char *const qup1_se2_l2_mira_groups[] = {
+ "gpio54",
+};
+
+static const char *const qup1_se2_l2_mirb_groups[] = {
+ "gpio52",
+};
+
+static const char *const qup1_se2_l3_mira_groups[] = {
+ "gpio55",
+};
+
+static const char *const qup1_se2_l3_mirb_groups[] = {
+ "gpio53",
+};
+
+static const char *const qup1_se2_l4_groups[] = {
+ "gpio40",
+};
+
+static const char *const qup1_se2_l5_groups[] = {
+ "gpio42",
+};
+
+static const char *const qup1_se2_l6_groups[] = {
+ "gpio30",
};
static const char *const qup1_se3_groups[] = {
@@ -993,12 +1048,52 @@ static const char *const qup1_se5_groups[] = {
"gpio132", "gpio133", "gpio134", "gpio135", "gpio34", "gpio35",
};
-static const char *const qup1_se6_groups[] = {
- "gpio40", "gpio42", "gpio54", "gpio42", "gpio40", "gpio55",
+static const char *const qup1_se6_l0_groups[] = {
+ "gpio40",
+};
+
+static const char *const qup1_se6_l1_mira_groups[] = {
+ "gpio42",
+};
+
+static const char *const qup1_se6_l1_mirb_groups[] = {
+ "gpio54",
+};
+
+static const char *const qup1_se6_l2_groups[] = {
+ "gpio42",
+};
+
+static const char *const qup1_se6_l3_mira_groups[] = {
+ "gpio40",
};
-static const char *const qup1_se7_groups[] = {
- "gpio81", "gpio78", "gpio80", "gpio114", "gpio114", "gpio78",
+static const char *const qup1_se6_l3_mirb_groups[] = {
+ "gpio55",
+};
+
+static const char *const qup1_se7_l0_mira_groups[] = {
+ "gpio81",
+};
+
+static const char *const qup1_se7_l0_mirb_groups[] = {
+ "gpio78",
+};
+
+static const char *const qup1_se7_l1_mira_groups[] = {
+ "gpio80",
+};
+
+static const char *const qup1_se7_l1_mirb_groups[] = {
+ "gpio114",
+};
+
+static const char *const qup1_se7_l2_groups[] = {
+ "gpio114",
+};
+
+static const char *const qup1_se7_l3_groups[] = {
+ "gpio78",
};
static const char *const qup2_se0_groups[] = {
@@ -1013,8 +1108,28 @@ static const char *const qup2_se2_groups[] = {
"gpio8", "gpio9", "gpio10", "gpio11", "gpio16", "gpio17", "gpio18",
};
-static const char *const qup2_se3_groups[] = {
- "gpio79", "gpio116", "gpio97", "gpio100", "gpio100", "gpio116",
+static const char *const qup2_se3_l0_mira_groups[] = {
+ "gpio79",
+};
+
+static const char *const qup2_se3_l0_mirb_groups[] = {
+ "gpio116",
+};
+
+static const char *const qup2_se3_l1_mira_groups[] = {
+ "gpio97",
+};
+
+static const char *const qup2_se3_l1_mirb_groups[] = {
+ "gpio100",
+};
+
+static const char *const qup2_se3_l2_groups[] = {
+ "gpio100",
+};
+
+static const char *const qup2_se3_l3_groups[] = {
+ "gpio116",
};
static const char *const qup2_se4_groups[] = {
@@ -1235,16 +1350,39 @@ static const struct pinfunction eliza_functions[] = {
MSM_PIN_FUNCTION(qspi_cs),
MSM_PIN_FUNCTION(qup1_se0),
MSM_PIN_FUNCTION(qup1_se1),
- MSM_PIN_FUNCTION(qup1_se2),
+ MSM_PIN_FUNCTION(qup1_se2_l0),
+ MSM_PIN_FUNCTION(qup1_se2_l1),
+ MSM_PIN_FUNCTION(qup1_se2_l2_mira),
+ MSM_PIN_FUNCTION(qup1_se2_l2_mirb),
+ MSM_PIN_FUNCTION(qup1_se2_l3_mira),
+ MSM_PIN_FUNCTION(qup1_se2_l3_mirb),
+ MSM_PIN_FUNCTION(qup1_se2_l4),
+ MSM_PIN_FUNCTION(qup1_se2_l5),
+ MSM_PIN_FUNCTION(qup1_se2_l6),
MSM_PIN_FUNCTION(qup1_se3),
MSM_PIN_FUNCTION(qup1_se4),
MSM_PIN_FUNCTION(qup1_se5),
- MSM_PIN_FUNCTION(qup1_se6),
- MSM_PIN_FUNCTION(qup1_se7),
+ MSM_PIN_FUNCTION(qup1_se6_l0),
+ MSM_PIN_FUNCTION(qup1_se6_l1_mira),
+ MSM_PIN_FUNCTION(qup1_se6_l1_mirb),
+ MSM_PIN_FUNCTION(qup1_se6_l2),
+ MSM_PIN_FUNCTION(qup1_se6_l3_mira),
+ MSM_PIN_FUNCTION(qup1_se6_l3_mirb),
+ MSM_PIN_FUNCTION(qup1_se7_l0_mira),
+ MSM_PIN_FUNCTION(qup1_se7_l0_mirb),
+ MSM_PIN_FUNCTION(qup1_se7_l1_mira),
+ MSM_PIN_FUNCTION(qup1_se7_l1_mirb),
+ MSM_PIN_FUNCTION(qup1_se7_l2),
+ MSM_PIN_FUNCTION(qup1_se7_l3),
MSM_PIN_FUNCTION(qup2_se0),
MSM_PIN_FUNCTION(qup2_se1),
MSM_PIN_FUNCTION(qup2_se2),
- MSM_PIN_FUNCTION(qup2_se3),
+ MSM_PIN_FUNCTION(qup2_se3_l0_mira),
+ MSM_PIN_FUNCTION(qup2_se3_l0_mirb),
+ MSM_PIN_FUNCTION(qup2_se3_l1_mira),
+ MSM_PIN_FUNCTION(qup2_se3_l1_mirb),
+ MSM_PIN_FUNCTION(qup2_se3_l2),
+ MSM_PIN_FUNCTION(qup2_se3_l3),
MSM_PIN_FUNCTION(qup2_se4),
MSM_PIN_FUNCTION(qup2_se5),
MSM_PIN_FUNCTION(qup2_se6),
@@ -1316,7 +1454,7 @@ static const struct msm_pingroup eliza_groups[] = {
[27] = PINGROUP(27, qup2_se4, aoss_cti, mdp_vsync11_out, qup2_se7, gcc_gp1, _, _, _, _, _, _),
[28] = PINGROUP(28, qup1_se0, ibi_i3c, _, _, _, _, _, _, _, _, egpio),
[29] = PINGROUP(29, qup1_se0, ibi_i3c, _, _, _, _, _, _, _, _, egpio),
- [30] = PINGROUP(30, qup1_se0, qup1_se2, cci_async_in, gcc_gp3, qdss_gpio_tracedata, _, _, _, _, _, egpio),
+ [30] = PINGROUP(30, qup1_se0, qup1_se2_l6, cci_async_in, gcc_gp3, qdss_gpio_tracedata, _, _, _, _, _, egpio),
[31] = PINGROUP(31, qup1_se0, cci_async_in, qdss_gpio_tracedata, _, _, _, _, _, _, _, egpio),
[32] = PINGROUP(32, qup1_se1, ibi_i3c, audio_ref_clk, gcc_gp2, qdss_cti, _, _, _, _, _, _),
[33] = PINGROUP(33, qup1_se1, ibi_i3c, host2wlan_sol, gcc_gp3, _, _, _, _, _, _, _),
@@ -1326,9 +1464,9 @@ static const struct msm_pingroup eliza_groups[] = {
[37] = PINGROUP(37, qup1_se4, qup1_se4, ibi_i3c, _, _, _, _, _, _, _, _),
[38] = PINGROUP(38, _, _, _, _, _, _, _, _, _, _, _),
[39] = PINGROUP(39, _, _, _, _, _, _, _, _, _, _, _),
- [40] = PINGROUP(40, qup1_se6, qup1_se2, qup1_se6, _, qdss_gpio_tracedata, gnss_adc1, ddr_pxi1, _, _, _, _),
+ [40] = PINGROUP(40, qup1_se6_l0, qup1_se2_l4, qup1_se6_l3_mira, _, qdss_gpio_tracedata, gnss_adc1, ddr_pxi1, _, _, _, _),
[41] = PINGROUP(41, _, _, _, _, _, _, _, _, _, _, _),
- [42] = PINGROUP(42, qup1_se6, qup1_se2, qup1_se6, qdss_gpio_tracedata, gnss_adc0, ddr_pxi1, _, _, _, _, _),
+ [42] = PINGROUP(42, qup1_se6_l2, qup1_se2_l5, qup1_se6_l1_mira, qdss_gpio_tracedata, gnss_adc0, ddr_pxi1, _, _, _, _, _),
[43] = PINGROUP(43, _, _, _, _, _, _, _, _, _, _, _),
[44] = PINGROUP(44, qup1_se3, _, _, _, _, _, _, _, _, _, _),
[45] = PINGROUP(45, qup1_se3, _, _, _, _, _, _, _, _, _, _),
@@ -1338,10 +1476,10 @@ static const struct msm_pingroup eliza_groups[] = {
[49] = PINGROUP(49, _, _, _, _, _, _, _, _, _, _, _),
[50] = PINGROUP(50, sdc2_fb_clk, _, _, _, _, _, _, _, _, _, _),
[51] = PINGROUP(51, _, _, _, _, _, _, _, _, _, _, _),
- [52] = PINGROUP(52, qup1_se2, pcie1_clk_req_n, qup1_se2, ddr_bist_complete, qdss_gpio_tracedata, _, vsense_trigger_mirnat, _, _, _, _),
- [53] = PINGROUP(53, qup1_se2, qup1_se2, gcc_gp1, ddr_bist_stop, _, qdss_gpio_tracedata, _, _, _, _, _),
- [54] = PINGROUP(54, qup1_se2, qup1_se6, qdss_gpio_tracedata, gnss_adc1, atest_usb, ddr_pxi0, _, _, _, _, _),
- [55] = PINGROUP(55, qup1_se2, dp0_hot, qup1_se6, _, gnss_adc0, atest_usb, ddr_pxi0, _, _, _, _),
+ [52] = PINGROUP(52, qup1_se2_l0, pcie1_clk_req_n, qup1_se2_l2_mirb, ddr_bist_complete, qdss_gpio_tracedata, _, vsense_trigger_mirnat, _, _, _, _),
+ [53] = PINGROUP(53, qup1_se2_l1, qup1_se2_l3_mirb, gcc_gp1, ddr_bist_stop, _, qdss_gpio_tracedata, _, _, _, _, _),
+ [54] = PINGROUP(54, qup1_se2_l2_mira, qup1_se6_l1_mirb, qdss_gpio_tracedata, gnss_adc1, atest_usb, ddr_pxi0, _, _, _, _, _),
+ [55] = PINGROUP(55, qup1_se2_l3_mira, dp0_hot, qup1_se6_l3_mirb, _, gnss_adc0, atest_usb, ddr_pxi0, _, _, _, _),
[56] = PINGROUP(56, usb0_hs, tsense_pwm1, tsense_pwm2, tsense_pwm3, tsense_pwm4, _, _, _, _, _, _),
[57] = PINGROUP(57, sd_write_protect, _, _, _, _, _, _, _, _, _, _),
[58] = PINGROUP(58, _, _, _, _, _, _, _, _, _, _, _),
@@ -1364,10 +1502,10 @@ static const struct msm_pingroup eliza_groups[] = {
[75] = PINGROUP(75, cci_i2c_scl, _, phase_flag, _, _, _, _, _, _, _, _),
[76] = PINGROUP(76, cci_i2c_sda, cci_timer, prng_rosc2, _, phase_flag, _, _, _, _, _, _),
[77] = PINGROUP(77, cci_i2c_scl, jitter_bist, _, _, _, _, _, _, _, _, _),
- [78] = PINGROUP(78, qup1_se7, qup1_se7, _, phase_flag, _, _, _, _, _, _, _),
- [79] = PINGROUP(79, qspi0, mdp_vsync, qup2_se3, _, _, _, _, _, _, _, _),
- [80] = PINGROUP(80, pcie0_clk_req_n, qup1_se7, _, phase_flag, _, _, _, _, _, _, _),
- [81] = PINGROUP(81, wcn_sw_ctrl, qup1_se7, dbg_out_clk, _, _, _, _, _, _, _, _),
+ [78] = PINGROUP(78, qup1_se7_l3, qup1_se7_l0_mirb, _, phase_flag, _, _, _, _, _, _, _),
+ [79] = PINGROUP(79, qspi0, mdp_vsync, qup2_se3_l0_mira, _, _, _, _, _, _, _, _),
+ [80] = PINGROUP(80, pcie0_clk_req_n, qup1_se7_l1_mira, _, phase_flag, _, _, _, _, _, _, _),
+ [81] = PINGROUP(81, wcn_sw_ctrl, qup1_se7_l0_mira, dbg_out_clk, _, _, _, _, _, _, _, _),
[82] = PINGROUP(82, _, _, _, _, _, _, _, _, _, _, _),
[83] = PINGROUP(83, _, _, _, _, _, _, _, _, _, _, _),
[84] = PINGROUP(84, uim0_data, _, _, _, _, _, _, _, _, _, _),
@@ -1383,10 +1521,10 @@ static const struct msm_pingroup eliza_groups[] = {
[94] = PINGROUP(94, qlink_wmss, _, _, _, _, _, _, _, _, _, _),
[95] = PINGROUP(95, qlink_big_request, _, _, _, _, _, _, _, _, _, _),
[96] = PINGROUP(96, qlink_big_enable, _, _, _, _, _, _, _, _, _, _),
- [97] = PINGROUP(97, uim1_data, qspi0, qup2_se3, _, _, _, _, _, _, _, _),
+ [97] = PINGROUP(97, uim1_data, qspi0, qup2_se3_l1_mira, _, _, _, _, _, _, _, _),
[98] = PINGROUP(98, uim1_clk, qspi0, _, _, _, _, _, _, _, _, _),
[99] = PINGROUP(99, uim1_reset, qspi0, _, _, _, _, _, _, _, _, _),
- [100] = PINGROUP(100, uim1_present, qspi0, qup2_se3, coex_uart2_tx, qup2_se3, mdp_vsync, _, _, _, _, _),
+ [100] = PINGROUP(100, uim1_present, qspi0, qup2_se3_l2, coex_uart2_tx, qup2_se3_l1_mirb, mdp_vsync, _, _, _, _, _),
[101] = PINGROUP(101, _, _, _, _, _, _, _, _, _, _, _),
[102] = PINGROUP(102, _, _, _, _, _, _, _, _, _, _, _),
[103] = PINGROUP(103, _, _, _, _, _, _, _, _, _, _, _),
@@ -1400,9 +1538,9 @@ static const struct msm_pingroup eliza_groups[] = {
[111] = PINGROUP(111, coex_uart1_tx, _, _, _, _, _, _, _, _, _, _),
[112] = PINGROUP(112, coex_uart1_rx, _, _, _, _, _, _, _, _, _, _),
[113] = PINGROUP(113, _, nav_gpio3, _, _, _, _, _, _, _, _, _),
- [114] = PINGROUP(114, qup1_se7, qup1_se7, _, qdss_gpio_tracedata, _, _, _, _, _, _, _),
+ [114] = PINGROUP(114, qup1_se7_l2, qup1_se7_l1_mirb, _, qdss_gpio_tracedata, _, _, _, _, _, _, _),
[115] = PINGROUP(115, _, qspi0, cci_async_in, _, _, _, _, _, _, _, _),
- [116] = PINGROUP(116, qspi0, coex_uart2_rx, qup2_se3, qup2_se3, _, _, _, _, _, _, _),
+ [116] = PINGROUP(116, qspi0, coex_uart2_rx, qup2_se3_l3, qup2_se3_l0_mirb, _, _, _, _, _, _, _),
[117] = PINGROUP(117, nav_gpio1, _, vfr_1, _, _, _, _, _, _, _, _),
[118] = PINGROUP(118, nav_gpio2, _, _, _, _, _, _, _, _, _, _),
[119] = PINGROUP(119, nav_gpio0, _, _, _, _, _, _, _, _, _, _),
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v8 0/3] iio: adc: ad4080: add support for AD4880 dual-channel ADC
From: Jonathan Cameron @ 2026-04-20 14:29 UTC (permalink / raw)
To: Miclaus, Antoniu
Cc: Lars-Peter Clausen, Hennerich, Michael, David Lechner, Sa, Nuno,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Olivier Moysan,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <SN6SPR01MB0090FF0C73500BB51F63D7FB9B232@SN6SPR01MB0090.namprd03.prod.outlook.com>
On Thu, 16 Apr 2026 08:51:46 +0000
"Miclaus, Antoniu" <Antoniu.Miclaus@analog.com> wrote:
> --
> Antoniu Miclăuş
>
> > -----Original Message-----
> > From: Jonathan Cameron <jic23@kernel.org>
> > Sent: Sunday, April 12, 2026 9:34 PM
> > To: Miclaus, Antoniu <Antoniu.Miclaus@analog.com>
> > Cc: Lars-Peter Clausen <lars@metafoo.de>; Hennerich, Michael
> > <Michael.Hennerich@analog.com>; David Lechner <dlechner@baylibre.com>;
> > Sa, Nuno <Nuno.Sa@analog.com>; Rob Herring <robh@kernel.org>; Krzysztof
> > Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
> > Olivier Moysan <olivier.moysan@foss.st.com>; linux-iio@vger.kernel.org;
> > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH v8 0/3] iio: adc: ad4080: add support for AD4880 dual-
> > channel ADC
> >
> > [External]
> >
> > On Sat, 28 Mar 2026 13:40:47 +0200
> > Antoniu Miclaus <antoniu.miclaus@analog.com> wrote:
> >
> > > Add support for the AD4880, a dual-channel 20-bit 40MSPS SAR ADC with
> > > integrated fully differential amplifiers (FDA).
> > >
> > > Architecture notes:
> > >
> > > The AD4880 is modeled as a single IIO device rather than two independent
> > > devices because the channels share power supplies, a voltage reference,
> > > the CNV conversion clock, and a single interleaved data output stream.
> > > Splitting them into separate IIO devices would make synchronized
> > > dual-channel capture impossible from userspace.
> > >
> > > An MFD approach does not apply here either - the channels are not
> > > functionally distinct sub-devices but identical ADC paths sharing a
> > > common data interface.
> > >
> > > Each channel has fully independent configuration registers accessible
> > > through separate SPI chip selects, so per-channel regmaps are used with
> > > no locking between them. The data path has no software involvement at
> > > runtime: the CNV clock triggers simultaneous conversions and the device
> > > outputs an interleaved bitstream captured directly by the IIO backend
> > > (FPGA). spi_new_ancillary_device() handles the configuration path;
> > > the IIO backend handles the data path.
> > >
> > > The debugfs_reg_access callback is not exposed for the dual-channel
> > > variant since the IIO framework provides a single (reg, val) interface
> > > with no channel parameter, and exposing only one channel would be
> > > misleading.
> > >
> > > The AD4880 is a fairly unique part - having separate SPI config
> > > interfaces per channel with a shared interleaved data output is not
> > > a common pattern.
> > I tried applying this and it's not going in cleanly (I didn't check
> > exactly why). Please could you send a rebased version. The togreg
> > branch should be fine I think, but maybe sanity check it against
> > my current testing branch as well.
>
> The AD4880 driver has a cross-tree dependency on two SPI patches that are queued in spi/for-7.1:
>
> - ffef4123043c ("spi: allow ancillary devices to share parent's chip selects")
> - 463279e58811 ("spi: add devm_spi_new_ancillary_device()")
>
> The driver uses devm_spi_new_ancillary_device() with multi-CS to create an ancillary SPI device for the second channel's configuration interface, so it won't build against togreg alone.
>
> What approach do you suggest in this situation?
Ah. Makes sense.
Given timing, wait and if I look to have forgotten this ping me around
rc2 when I should have that 7.1 material in my base tree anyway.
thanks,
Jonathan
>
> >
> > Whilst this driver is making a few more assumptions about the backend
> > than I'd ideally like, I think it is reasonable to postpone any handling
> > for truely separate backends until (maybe) someone needs it.
> >
> > Thanks,
> >
> > Jonathan
> >
> > >
> > > Changes in v8:
> > > - Drop fwnode_handle cleanup patch (now in jic23/testing)
> > > - Clarify backend buffer comment to describe FPGA architecture
> > > (two axi_ad408x IP instances with a packer block)
> > > - Make filter_type a per-channel array instead of a single variable
> > > - Restore debugfs_reg_access for AD4880 (uses channel 0 regmap),
> > > based on sashiko's review
> > >
> > > Antoniu Miclaus (3):
> > > iio: backend: add devm_iio_backend_get_by_index()
> > > dt-bindings: iio: adc: ad4080: add AD4880 support
> > > iio: adc: ad4080: add support for AD4880 dual-channel ADC
> > >
> > > .../bindings/iio/adc/adi,ad4080.yaml | 53 +++-
> > > drivers/iio/adc/ad4080.c | 251 ++++++++++++++----
> > > drivers/iio/industrialio-backend.c | 53 ++--
> > > include/linux/iio/backend.h | 1 +
> > > 4 files changed, 282 insertions(+), 76 deletions(-)
> > >
>
^ permalink raw reply
* Re: [PATCH v1 1/1 RESEND] dt-bindings: display: bridge: ssd2825: inherit dsi-controller properties
From: Rob Herring (Arm) @ 2026-04-20 14:33 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Maarten Lankhorst, Thomas Zimmermann, Andrzej Hajda, David Airlie,
Maxime Ripard, Jonas Karlman, Simona Vetter, dri-devel,
linux-kernel, Laurent Pinchart, devicetree, Jernej Skrabec,
Neil Armstrong, Robert Foss
In-Reply-To: <20260417064657.20293-2-clamor95@gmail.com>
On Fri, 17 Apr 2026 09:46:57 +0300, Svyatoslav Ryhel wrote:
> SSD2825 being RGB-DSI bridge should inherit dsi-controller properties same
> way other DSI controllers and DSI bridges do.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> .../devicetree/bindings/display/bridge/solomon,ssd2825.yaml | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Applied, thanks!
^ permalink raw reply
* RE: [PATCH v8 0/3] iio: adc: ad4080: add support for AD4880 dual-channel ADC
From: Miclaus, Antoniu @ 2026-04-20 14:35 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Lars-Peter Clausen, Hennerich, Michael, David Lechner, Sa, Nuno,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Olivier Moysan,
linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260420152914.323238fe@jic23-huawei>
--
Antoniu Miclăuş
> -----Original Message-----
> From: Jonathan Cameron <jic23@kernel.org>
> Sent: Monday, April 20, 2026 5:29 PM
> To: Miclaus, Antoniu <Antoniu.Miclaus@analog.com>
> Cc: Lars-Peter Clausen <lars@metafoo.de>; Hennerich, Michael
> <Michael.Hennerich@analog.com>; David Lechner <dlechner@baylibre.com>;
> Sa, Nuno <Nuno.Sa@analog.com>; Rob Herring <robh@kernel.org>; Krzysztof
> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
> Olivier Moysan <olivier.moysan@foss.st.com>; linux-iio@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v8 0/3] iio: adc: ad4080: add support for AD4880 dual-
> channel ADC
>
> On Thu, 16 Apr 2026 08:51:46 +0000
> "Miclaus, Antoniu" <Antoniu.Miclaus@analog.com> wrote:
>
> > --
> > Antoniu Miclăuş
> >
> > > -----Original Message-----
> > > From: Jonathan Cameron <jic23@kernel.org>
> > > Sent: Sunday, April 12, 2026 9:34 PM
> > > To: Miclaus, Antoniu <Antoniu.Miclaus@analog.com>
> > > Cc: Lars-Peter Clausen <lars@metafoo.de>; Hennerich, Michael
> > > <Michael.Hennerich@analog.com>; David Lechner
> <dlechner@baylibre.com>;
> > > Sa, Nuno <Nuno.Sa@analog.com>; Rob Herring <robh@kernel.org>;
> Krzysztof
> > > Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
> > > Olivier Moysan <olivier.moysan@foss.st.com>; linux-iio@vger.kernel.org;
> > > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
> > > Subject: Re: [PATCH v8 0/3] iio: adc: ad4080: add support for AD4880
> dual-
> > > channel ADC
> > >
> > > [External]
> > >
> > > On Sat, 28 Mar 2026 13:40:47 +0200
> > > Antoniu Miclaus <antoniu.miclaus@analog.com> wrote:
> > >
> > > > Add support for the AD4880, a dual-channel 20-bit 40MSPS SAR ADC
> with
> > > > integrated fully differential amplifiers (FDA).
> > > >
> > > > Architecture notes:
> > > >
> > > > The AD4880 is modeled as a single IIO device rather than two
> independent
> > > > devices because the channels share power supplies, a voltage reference,
> > > > the CNV conversion clock, and a single interleaved data output stream.
> > > > Splitting them into separate IIO devices would make synchronized
> > > > dual-channel capture impossible from userspace.
> > > >
> > > > An MFD approach does not apply here either - the channels are not
> > > > functionally distinct sub-devices but identical ADC paths sharing a
> > > > common data interface.
> > > >
> > > > Each channel has fully independent configuration registers accessible
> > > > through separate SPI chip selects, so per-channel regmaps are used with
> > > > no locking between them. The data path has no software involvement at
> > > > runtime: the CNV clock triggers simultaneous conversions and the device
> > > > outputs an interleaved bitstream captured directly by the IIO backend
> > > > (FPGA). spi_new_ancillary_device() handles the configuration path;
> > > > the IIO backend handles the data path.
> > > >
> > > > The debugfs_reg_access callback is not exposed for the dual-channel
> > > > variant since the IIO framework provides a single (reg, val) interface
> > > > with no channel parameter, and exposing only one channel would be
> > > > misleading.
> > > >
> > > > The AD4880 is a fairly unique part - having separate SPI config
> > > > interfaces per channel with a shared interleaved data output is not
> > > > a common pattern.
> > > I tried applying this and it's not going in cleanly (I didn't check
> > > exactly why). Please could you send a rebased version. The togreg
> > > branch should be fine I think, but maybe sanity check it against
> > > my current testing branch as well.
> >
> > The AD4880 driver has a cross-tree dependency on two SPI patches that are
> queued in spi/for-7.1:
> >
> > - ffef4123043c ("spi: allow ancillary devices to share parent's chip selects")
> > - 463279e58811 ("spi: add devm_spi_new_ancillary_device()")
> >
> > The driver uses devm_spi_new_ancillary_device() with multi-CS to create an
> ancillary SPI device for the second channel's configuration interface, so it won't
> build against togreg alone.
> >
> > What approach do you suggest in this situation?
> Ah. Makes sense.
>
> Given timing, wait and if I look to have forgotten this ping me around
> rc2 when I should have that 7.1 material in my base tree anyway.
>
Seems like the patches are already on the master branch:
https://github.com/torvalds/linux/commit/405f6584d7d0fc46534fd370e374630283dffe60
There were some conflicts anyways with the ad4088 support that was not on my local branch. I added v9 in the meantime which solves those conflicts too.
Regards,
> thanks,
>
> Jonathan
> >
> > >
> > > Whilst this driver is making a few more assumptions about the backend
> > > than I'd ideally like, I think it is reasonable to postpone any handling
> > > for truely separate backends until (maybe) someone needs it.
> > >
> > > Thanks,
> > >
> > > Jonathan
> > >
> > > >
> > > > Changes in v8:
> > > > - Drop fwnode_handle cleanup patch (now in jic23/testing)
> > > > - Clarify backend buffer comment to describe FPGA architecture
> > > > (two axi_ad408x IP instances with a packer block)
> > > > - Make filter_type a per-channel array instead of a single variable
> > > > - Restore debugfs_reg_access for AD4880 (uses channel 0 regmap),
> > > > based on sashiko's review
> > > >
> > > > Antoniu Miclaus (3):
> > > > iio: backend: add devm_iio_backend_get_by_index()
> > > > dt-bindings: iio: adc: ad4080: add AD4880 support
> > > > iio: adc: ad4080: add support for AD4880 dual-channel ADC
> > > >
> > > > .../bindings/iio/adc/adi,ad4080.yaml | 53 +++-
> > > > drivers/iio/adc/ad4080.c | 251 ++++++++++++++----
> > > > drivers/iio/industrialio-backend.c | 53 ++--
> > > > include/linux/iio/backend.h | 1 +
> > > > 4 files changed, 282 insertions(+), 76 deletions(-)
> > > >
> >
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: rng: mtk-rng: add SMC-based TRNG variants
From: Krzysztof Kozlowski @ 2026-04-20 14:43 UTC (permalink / raw)
To: Daniel Golle
Cc: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sean Wang, linux-crypto, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <aeY3HuP01VYl5x6X@makrotopia.org>
On 20/04/2026 16:24, Daniel Golle wrote:
> On Mon, Apr 20, 2026 at 04:07:33PM +0200, Krzysztof Kozlowski wrote:
>> On Sun, Apr 19, 2026 at 01:05:01PM +0100, Daniel Golle wrote:
>>> + rng {
>>> + compatible = "mediatek,mt7981-rng";
>>
>> I asked at v1. Reminded at v2. Nothing serious, but repeating myself is
>> pointless and kind of waste of time.
>
> Replying *once* telling what you would actually want, or replying to
> me asking back would have helped enormously:
> https://patchwork.kernel.org/comment/26880354/
>
> All I can see is that you concluded "no improvements" without telling
> *what it is you would like to see improved*.
>
Yes, and then you should go to v1 and read the review. There was only
single comment in this spot, so trivial to find.
AGAIN:
Use four spaces for indentation.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: rng: mtk-rng: add SMC-based TRNG variants
From: Daniel Golle @ 2026-04-20 14:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Olivia Mackall, Herbert Xu, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Sean Wang, linux-crypto, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <e747a3c5-1c43-412b-8ff6-f447ee33995c@kernel.org>
On Mon, Apr 20, 2026 at 04:43:00PM +0200, Krzysztof Kozlowski wrote:
> On 20/04/2026 16:24, Daniel Golle wrote:
> > On Mon, Apr 20, 2026 at 04:07:33PM +0200, Krzysztof Kozlowski wrote:
> >> On Sun, Apr 19, 2026 at 01:05:01PM +0100, Daniel Golle wrote:
> >>> + rng {
> >>> + compatible = "mediatek,mt7981-rng";
> >>
> >> I asked at v1. Reminded at v2. Nothing serious, but repeating myself is
> >> pointless and kind of waste of time.
> >
> > Replying *once* telling what you would actually want, or replying to
> > me asking back would have helped enormously:
> > https://patchwork.kernel.org/comment/26880354/
> >
> > All I can see is that you concluded "no improvements" without telling
> > *what it is you would like to see improved*.
> >
>
> Yes, and then you should go to v1 and read the review. There was only
> single comment in this spot, so trivial to find.
>
> AGAIN:
>
> Use four spaces for indentation.
Thank you, that IS helpful.
I've read the "no improvements" statement as an overall conclusion and
not even considered it to be specific to any *place* without further
context.
Is that the only remaining problem you see in the binding right now?
^ permalink raw reply
* Re: [PATCH v3 2/5] dt-bindings: iio: adc: ad4130: Add new supported parts
From: Jonathan Cameron @ 2026-04-20 14:54 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Santos, linux-iio, linux-kernel, devicetree, lars,
Michael.Hennerich, nuno.sa, andy, robh, krzk+dt, conor+dt,
Krzysztof Kozlowski
In-Reply-To: <cf4ac074-9098-45f5-9cd6-0eeea0b41179@baylibre.com>
On Sat, 11 Apr 2026 14:08:59 -0500
David Lechner <dlechner@baylibre.com> wrote:
> On 4/1/26 6:58 AM, Jonathan Santos wrote:
> > Extend driver support for AD4129-4/8, AD4130-4, and AD4131-4/8 ADC
> > variants.
> >
> > Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > Signed-off-by: Jonathan Santos <Jonathan.Santos@analog.com>
> > ---
> > Changes in v3:
> > * None.
> >
> > Changes in v2:
> > * None.
> > ---
> > .../devicetree/bindings/iio/adc/adi,ad4130.yaml | 15 +++++++++++++--
> > 1 file changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad4130.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad4130.yaml
> > index fcc00e5cfd54..f4cad68fa04d 100644
> > --- a/Documentation/devicetree/bindings/iio/adc/adi,ad4130.yaml
> > +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad4130.yaml
> > @@ -5,19 +5,30 @@
> > $id: http://devicetree.org/schemas/iio/adc/adi,ad4130.yaml#
> > $schema: http://devicetree.org/meta-schemas/core.yaml#
> >
> > -title: Analog Devices AD4130 ADC device driver
> > +title: Analog Devices AD4130 family ADC device driver
>
> I'm surprised that on one said anything about the word "driver"
> in a devicetree binding. :-)
>
You could have kept quiet! :) Anyhow, tweaked here and in the patch title
to not mention driver.
Series applied to the testing branch of iio.git.
Jonathan
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: iio: dac: mcp47feb02: Fix maxItems value for reg property
From: Rob Herring @ 2026-04-20 15:01 UTC (permalink / raw)
To: Ariana Lazar
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Krzysztof Kozlowski, Conor Dooley, Conor Dooley, Jonathan Cameron,
linux-iio, devicetree, linux-kernel
In-Reply-To: <20260417-mcp47feb02-fix5-v2-1-6592ea499cce@microchip.com>
On Fri, Apr 17, 2026 at 04:38:29PM +0300, Ariana Lazar wrote:
> Change maxItems value from 8 to 1 for the channel number reg property.
>
> Fixes: 4ba12d304175 ("dt-bindings: iio: dac: adding support for Microchip MCP47FEB02")
> Link: https://lore.kernel.org/all/20260403-speed-childless-1360de358229@spud/
> Signed-off-by: Ariana Lazar <ariana.lazar@microchip.com>
> ---
> Changes in v2:
> - keep just maxItems value update in this patch
> - remove Reported-by from commit message
> - Link to v1: https://lore.kernel.org/r/20260416-mcp47feb02-fix5-v1-1-9656c2fed6d2@microchip.com
> ---
> Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml b/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
> index d2466aa6bda2106a8b695347a0edf38462294d03..f2efa0ccbaa32482dcdc69d98c1565518538793f 100644
> --- a/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
> +++ b/Documentation/devicetree/bindings/iio/dac/microchip,mcp47feb02.yaml
> @@ -161,8 +161,7 @@ patternProperties:
> properties:
> reg:
> description: The channel number.
> - minItems: 1
> - maxItems: 8
> + maxItems: 1
Perhaps there are 8 channels and 'maximum: 8' is what was intended?
Rob
^ permalink raw reply
* Re: [PATCH v5 4/4] Input: charlieplex_keypad: add GPIO charlieplex keypad
From: Hugo Villeneuve @ 2026-04-20 15:01 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: robin, andy, geert, robh, krzk+dt, conor+dt, hvilleneuve,
mkorpershoek, matthias.bgg, angelogioacchino.delregno, lee,
alexander.sverdlin, marek.vasut, akurz, devicetree, linux-kernel,
linux-input, linux-arm-kernel, linux-mediatek
In-Reply-To: <aeWtDA7snjJmiF9K@google.com>
Hi Dmitry,
On Sun, 19 Apr 2026 21:47:40 -0700
Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> Hi Hugo,
>
> On Thu, Mar 12, 2026 at 02:00:58PM -0400, Hugo Villeneuve wrote:
> > +
> > +static void charlieplex_keypad_report_key(struct input_dev *input)
> > +{
> > + struct charlieplex_keypad *keypad = input_get_drvdata(input);
> > + const unsigned short *keycodes = input->keycode;
> > +
> > + if (keypad->current_code > 0) {
> > + input_event(input, EV_MSC, MSC_SCAN, keypad->current_code);
> > + input_report_key(input, keycodes[keypad->current_code], 0);
>
> This needs input_sync() as otherwise userspace is free to only recognize
> the last MSC_SCAN event.
Ok, now I get it, my code would have been be working only if it was an
if/else.
>
> > + }
> > +
> > + if (keypad->debounce_code) {
> > + input_event(input, EV_MSC, MSC_SCAN, keypad->debounce_code);
> > + input_report_key(input, keycodes[keypad->debounce_code], 1);
> > + }
> > +
> > + input_sync(input);
> > + keypad->current_code = keypad->debounce_code;
> > +}
> > +
> > +static void charlieplex_keypad_check_switch_change(struct input_dev *input,
> > + int code)
> > +{
> > + struct charlieplex_keypad *keypad = input_get_drvdata(input);
> > +
> > + if (code != keypad->debounce_code) {
> > + keypad->debounce_count = 0;
> > + keypad->debounce_code = code;
> > + } else if (keypad->debounce_count < keypad->debounce_threshold) {
>
> This does not work if debouncing is disabled (debounce threshold is 0).
Yes.
>
> > + keypad->debounce_count++;
> > +
> > + if (keypad->debounce_count >= keypad->debounce_threshold &&
> > + keypad->debounce_code != keypad->current_code)
> > + charlieplex_keypad_report_key(input);
> > + }
> > +}
> > +
> > +static void charlieplex_keypad_poll(struct input_dev *input)
> > +{
> > + struct charlieplex_keypad *keypad = input_get_drvdata(input);
> > + int code;
> > +
> > + code = 0;
> > + for (unsigned int oline = 0; oline < keypad->nlines; oline++) {
> > + DECLARE_BITMAP(values, MATRIX_MAX_ROWS);
> > + int err;
> > +
> > + /* Activate only one line as output at a time. */
> > + gpiod_direction_output(keypad->line_gpios->desc[oline], 1);
> > +
> > + if (keypad->settling_time_us)
> > + fsleep(keypad->settling_time_us);
> > +
> > + /* Read input on all other lines. */
> > + err = gpiod_get_array_value_cansleep(keypad->line_gpios->ndescs,
> > + keypad->line_gpios->desc,
> > + keypad->line_gpios->info, values);
> > + if (err)
> > + return;
>
> We need to deactivate the line on error too.
Yer, good catch.
>
> > +
> > + for (unsigned int iline = 0; iline < keypad->nlines; iline++) {
> > + if (iline == oline)
> > + continue; /* Do not read active output line. */
> > +
> > + /* Check if GPIO is asserted. */
> > + if (test_bit(iline, values)) {
> > + code = MATRIX_SCAN_CODE(oline, iline,
> > + get_count_order(keypad->nlines));
> > + /*
> > + * Exit loop immediately since we cannot detect
> > + * more than one key press at a time.
> > + */
> > + break;
> > + }
> > + }
> > +
> > + gpiod_direction_input(keypad->line_gpios->desc[oline]);
> > +
> > + if (code)
> > + break;
> > + }
> > +
> > + charlieplex_keypad_check_switch_change(input, code);
> > +}
> > +
> > +static int charlieplex_keypad_init_gpio(struct platform_device *pdev,
> > + struct charlieplex_keypad *keypad)
> > +{
> > + char **pin_names;
> > + char label[32];
> > +
> > + snprintf(label, sizeof(label), "%s-pin", pdev->name);
> > +
> > + keypad->line_gpios = devm_gpiod_get_array(&pdev->dev, "line", GPIOD_IN);
> > + if (IS_ERR(keypad->line_gpios))
> > + return PTR_ERR(keypad->line_gpios);
> > +
> > + keypad->nlines = keypad->line_gpios->ndescs;
> > +
> > + if (keypad->nlines > MATRIX_MAX_ROWS)
> > + return -EINVAL;
> > +
> > + pin_names = devm_kasprintf_strarray(&pdev->dev, label, keypad->nlines);
> > + if (IS_ERR(pin_names))
> > + return PTR_ERR(pin_names);
> > +
> > + for (unsigned int i = 0; i < keypad->line_gpios->ndescs; i++)
> > + gpiod_set_consumer_name(keypad->line_gpios->desc[i], pin_names[i]);
> > +
> > + return 0;
> > +}
> > +
> > +static int charlieplex_keypad_probe(struct platform_device *pdev)
> > +{
> > + struct charlieplex_keypad *keypad;
> > + unsigned int debounce_interval_ms;
> > + unsigned int poll_interval_ms;
> > + struct input_dev *input_dev;
> > + int err;
> > +
> > + keypad = devm_kzalloc(&pdev->dev, sizeof(*keypad), GFP_KERNEL);
> > + if (!keypad)
> > + return -ENOMEM;
> > +
> > + input_dev = devm_input_allocate_device(&pdev->dev);
> > + if (!input_dev)
> > + return -ENOMEM;
> > +
> > + keypad->input_dev = input_dev;
> > +
> > + device_property_read_u32(&pdev->dev, "poll-interval", &poll_interval_ms);
> > + device_property_read_u32(&pdev->dev, "debounce-delay-ms", &debounce_interval_ms);
> > + device_property_read_u32(&pdev->dev, "settling-time-us", &keypad->settling_time_us);
>
> Not all of these are required properties. If they are missing the driver
> will operate on garbage values.
Yes.
>
> > +
> > + keypad->current_code = -1;
> > + keypad->debounce_code = -1;
> > + keypad->debounce_threshold = DIV_ROUND_UP(debounce_interval_ms, poll_interval_ms);
>
> This will bomb if poll interval is 0.
Yes.
>
> > +
> > + err = charlieplex_keypad_init_gpio(pdev, keypad);
> > + if (err)
> > + return err;
> > +
> > + input_dev->name = pdev->name;
> > + input_dev->id.bustype = BUS_HOST;
> > +
> > + err = matrix_keypad_build_keymap(NULL, NULL, keypad->nlines,
> > + keypad->nlines, NULL, input_dev);
> > + if (err)
> > + dev_err_probe(&pdev->dev, -ENOMEM, "failed to build keymap\n");
>
> Missing "return".
>
> > +
> > + if (device_property_read_bool(&pdev->dev, "autorepeat"))
> > + __set_bit(EV_REP, input_dev->evbit);
> > +
> > + input_set_capability(input_dev, EV_MSC, MSC_SCAN);
> > +
> > + err = input_setup_polling(input_dev, charlieplex_keypad_poll);
> > + if (err)
> > + dev_err_probe(&pdev->dev, err, "unable to set up polling\n");
>
> Missing "return".
Ok for both.
> I fixed it up and applied, please take a look in my 'next' branch and
> tell me if I messed up.
Thank you for the review and the fixes.
I tested it on the real hardware and all is good.
So I imagine that it can still go into 7.1 since it is a new driver
and not a modification of an existing one?
--
Hugo Villeneuve
^ permalink raw reply
* Re: [PATCH] arm64: dts: exynos850: Add syscon-poweroff node
From: Alexey Klimov @ 2026-04-20 15:04 UTC (permalink / raw)
To: Sam Protsenko, Krzysztof Kozlowski
Cc: linux-samsung-soc, linux-arm-kernel, devicetree, linux-kernel,
Rob Herring, Conor Dooley, Alim Akhtar
In-Reply-To: <20260325-exynos850-poweroff-v1-1-34c19c06e74d@linaro.org>
On Wed Mar 25, 2026 at 12:26 AM GMT, Alexey Klimov wrote:
> Without poweroff node Exynos850-based board continue to draw current
> (around ~60 mA with my test setup) after poweroff. Kernel also reports
> different lockup problems and RCU stalls warnings continuosly after
> last kernel messages about hardware being switched off.
> Turns out we missed a write to PMU's PS_HOLD_CONTROL (PMU + 0x30c)
> register that actually switches the SoC off.
>
> Add poweroff node that implements this.
>
> With this change the current draw after power off is in range of few
> milliampers and lockup messages are no more.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> arch/arm64/boot/dts/exynos/exynos850.dtsi | 7 +++++++
Any feedback on this?
BR,
Alexey
^ permalink raw reply
* Re: [PATCH v3 2/3] dt-bindings: sram: Document qcom,eliza-imem
From: Rob Herring (Arm) @ 2026-04-20 15:05 UTC (permalink / raw)
To: Alexander Koskovich
Cc: linux-kernel, Konrad Dybcio, linux-arm-msm, Bjorn Andersson,
Conor Dooley, devicetree, Krzysztof Kozlowski,
Krzysztof Kozlowski
In-Reply-To: <20260418-eliza-imem-v3-2-bfbd499b6e77@pm.me>
On Sat, 18 Apr 2026 10:39:52 +0000, Alexander Koskovich wrote:
> Add compatible for Eliza SoC IMEM.
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
> Documentation/devicetree/bindings/sram/sram.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 00/40] arm64: dts: rockchip: Wire up frl-enable-gpios for RK3576/RK3588 boards
From: Heiko Stuebner @ 2026-04-20 15:08 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Cristian Ciocaltea
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <66f9574c-8dff-4de2-bf54-20f1c1e64c24@collabora.com>
Hi Cristian,
Am Montag, 20. April 2026, 13:10:27 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> On 4/18/26 2:18 AM, Heiko Stuebner wrote:
> > Am Freitag, 17. April 2026, 19:55:17 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> >> On 4/17/26 2:34 PM, Heiko Stuebner wrote:
> >>> Am Freitag, 17. April 2026, 11:24:34 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> >>>
> >>> [...]
> >>>
> >>>> Cristian Ciocaltea (40):
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-100ask-dshanpi-a1
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-armsom-sige5
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb1-v10
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-evb2-v10
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-m5
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-nanopi-r76s
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-roc-pc
> >>>> arm64: dts: rockchip: Add frl-enable-gpios to rk3576-rock-4d
> >>>
> >>> I do think one patch per SoC (rk3576, rk3588, rk3588s) would make more
> >>> sense, because these patches really are mostly identical :-)
> >>
> >> Yeah, apologies for the large number of patches, I went this way to allow
> >> per-board reviews. As previously noted, I tried to identify the GPIO pins from
> >> multiple sources, so I'm not entirely sure about the accuracy in every case.
> >>
> >> Would it be preferable to squash the patches per SoC and board vendor, instead?
> >
> > I really would just do it per soc .. so 3 patches. That is a size that is
> > still reviewable for people, who can then check for their board.
> >
> > If the patch is labeled "Add frl-enable-gpios for all RK3588s boards", I
> > do expect people to notice it the same as "oh _my_ board gets changed".
> > ("all" could also be "most" :-) ).
>
> Ack.
>
> I would still keep the more invasive changes — such as those touching
> the regulator hacks — in separate patches, though.
sure, that sounds perfectly reasonable :-) .
Heiko
^ permalink raw reply
* Re: [PATCH 05/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3576-luckfox-core3576
From: Heiko Stuebner @ 2026-04-20 15:18 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Cristian Ciocaltea
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <401a020f-ca5d-4c7d-941e-f0288e144357@collabora.com>
Am Montag, 20. April 2026, 13:00:25 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> Hi Heiko,
>
> On 4/18/26 2:12 AM, Heiko Stuebner wrote:
> > Hi Cristian,
> >
> > Am Freitag, 17. April 2026, 18:34:17 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> >> On 4/17/26 2:32 PM, Heiko Stuebner wrote:
> >>> the comments below apply sort of to all patches in that series.
> >>>
> >>> Am Freitag, 17. April 2026, 11:24:39 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
> >>>> The board exposes the GPIO4_C6 line to control the voltage bias on the
> >>>> HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
> >>>> mode and deasserted for HDMI 1.4/2.0 TMDS mode.
> >>>>
> >>>> Wire up the HDMI node to the GPIO line using the frl-enable-gpios
> >>>> property and drop the line from the vcc_5v0_hdmi regulator to allow
> >>>> adjusting the bias when transitioning between TMDS and FRL operating
> >>>> modes.
>
> [...]
>
> >>>
> >>>
> >>>> @@ -231,6 +228,8 @@ &gpu {
> >>>> };
> >>>>
> >>>> &hdmi {
> >>>> + pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda &hdmi_frl_en>;
> >>>> + frl-enable-gpios = <&gpio4 RK_PC6 GPIO_ACTIVE_LOW>;
> >>>
> >>> this should be sorted the other way around I think.
> >>>
> >>> Also please provide a pinctrl-names property too. If for whatever reason
> >>> the dw-hdmi aquires a 2nd pinctrl state in the future, this makes sure
> >>> board DTs are staying in the "old" compatible mode until they are adapted.
> >>
> >> Just to make sure I fully understand, the convention is that
> >>
> >> pinctrl-names = "default";
> >>
> >> should be always provided, even when the node overrides an existing pinctrl-0
> >> property?
> >>
> >> E.g. in rk3576.dtsi we have:
> >>
> >> hdmi: hdmi@27da0000 {
> >> ...
> >> pinctrl-names = "default";
> >> pinctrl-0 = <&hdmi_txm0_pins &hdmi_tx_scl &hdmi_tx_sda>;
> >> ...
> >> }
> >>
> >> Hence I omitted pinctrl-names which doesn't change and just appended
> >> &hdmi_frl_en to pinctrl-0's original value.
> >
> > correct, please always provide a pinctrl-names entry when setting a new
> > pinctrl-0 .
> >
> > The background is, imagine you have a base:
> >
> > pinctrl-names = "default";
> > pinstrl-0 = <....>;
> >
> > and override pinctrl-0 in a board.
> >
> > Now a newer binding introduces a 2nd pinctrl state "foo". Of course
> > we're backwards compatible, and both are valid and the driver checks
> > what states are defined.
> >
> > So the base sets:
> > pinctrl-names = "default", "foo";
> > pinctrl-0 = <...>;
> > pinctrl-1 = <...>;
> >
> > in your (old) board you override pinctrl-0, but the driver still sees
> > the new variant with 2 pinctrl states, where it should've stayed with
> > the legacy 1-state, until the board-dts might get adapted in the future.
> >
> >
> > And I know, we're likely not doing that everywhere, and also in most
> > cases it won't really matter, but still it is safer and sets the better
> > precedent :-) .
>
> Thanks for the detailed explanation, that clears things up!
>
> There are several other nodes (e.g. i2c, pwm, uart) that also lack
> pinctrl-names despite providing pinctrl-0 - I can address those in a
> separate patch.
As said above it is an ideal to aspire to (having -names together with
defining states), but if you want to add the "missing" -names,
go ahead :-) .
> I also noticed an inconsistency in property ordering: some nodes place
> pinctrl-names before pinctrl-<n> and others after. I have always used
> the former, but we should probably prefer the latter to stay consistent
> with how clocks, resets, phys, etc. are ordered.
>
> Thoughts?
There is sort of a "conflict" between regular ordering and possibly
better readability. I.e. the dt-writing guidelines propose alphabetical
ordering which I guess puts numbers before letters.
On the other hand the semantic definition of list the states and then
define them (names first, -0, -1, etc second) looks more sensible from
a understanding standpoint.
But there we'd end up with special rules, so just sticking to the
base sorting will cause less friction in the long run I think.
Aka, -0, -1 first; -names after, follows the main sorting suggestions
so it's easy to explain to newcomers.
But please don't re-sort existing entries :-)
Heiko
^ permalink raw reply
* Re: [PATCH] arm64: dts: exynos850: Add syscon-poweroff node
From: Krzysztof Kozlowski @ 2026-04-20 15:18 UTC (permalink / raw)
To: Alexey Klimov, Sam Protsenko, Krzysztof Kozlowski
Cc: linux-samsung-soc, linux-arm-kernel, devicetree, linux-kernel,
Rob Herring, Conor Dooley, Alim Akhtar
In-Reply-To: <DHY2P02B6E6H.J79TDOADC4BS@linaro.org>
On 20/04/2026 17:04, Alexey Klimov wrote:
> On Wed Mar 25, 2026 at 12:26 AM GMT, Alexey Klimov wrote:
>> Without poweroff node Exynos850-based board continue to draw current
>> (around ~60 mA with my test setup) after poweroff. Kernel also reports
>> different lockup problems and RCU stalls warnings continuosly after
>> last kernel messages about hardware being switched off.
>> Turns out we missed a write to PMU's PS_HOLD_CONTROL (PMU + 0x30c)
>> register that actually switches the SoC off.
>>
>> Add poweroff node that implements this.
>>
>> With this change the current draw after power off is in range of few
>> milliampers and lockup messages are no more.
>>
>> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
>> ---
>> arch/arm64/boot/dts/exynos/exynos850.dtsi | 7 +++++++
>
> Any feedback on this?
You posted it right before closing tree, so this was waiting for a few
days for anyone to chime in and then tree is closed. It's merge window
now, so I don't review anything. Nothing new here...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] arm64: dts: exynos850: Add syscon-poweroff node
From: Krzysztof Kozlowski @ 2026-04-20 15:20 UTC (permalink / raw)
To: Alexey Klimov, Sam Protsenko, Krzysztof Kozlowski
Cc: linux-samsung-soc, linux-arm-kernel, devicetree, linux-kernel,
Rob Herring, Conor Dooley, Alim Akhtar
In-Reply-To: <b9117d52-1a12-480b-a762-31d3eab6b827@kernel.org>
On 20/04/2026 17:18, Krzysztof Kozlowski wrote:
> On 20/04/2026 17:04, Alexey Klimov wrote:
>> On Wed Mar 25, 2026 at 12:26 AM GMT, Alexey Klimov wrote:
>>> Without poweroff node Exynos850-based board continue to draw current
>>> (around ~60 mA with my test setup) after poweroff. Kernel also reports
>>> different lockup problems and RCU stalls warnings continuosly after
>>> last kernel messages about hardware being switched off.
>>> Turns out we missed a write to PMU's PS_HOLD_CONTROL (PMU + 0x30c)
>>> register that actually switches the SoC off.
>>>
>>> Add poweroff node that implements this.
>>>
>>> With this change the current draw after power off is in range of few
>>> milliampers and lockup messages are no more.
>>>
>>> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
>>> ---
>>> arch/arm64/boot/dts/exynos/exynos850.dtsi | 7 +++++++
>>
>> Any feedback on this?
>
> You posted it right before closing tree, so this was waiting for a few
> days for anyone to chime in and then tree is closed. It's merge window
> now, so I don't review anything. Nothing new here...
... and the pull to SoC actually happened before. It's public, so you
could check that.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] riscv: dts: starfive: jh7110: Drop CAMSS node
From: Conor Dooley @ 2026-04-20 15:30 UTC (permalink / raw)
To: Jai Luthra
Cc: Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Changhuang Liang, Mauro Carvalho Chehab, Sakari Ailus,
Laurent Pinchart, Krzysztof Kozlowski, linux-riscv, devicetree,
linux-kernel
In-Reply-To: <20260420-starfive_camss_use-v1-1-ec326af71ca7@ideasonboard.com>
[-- Attachment #1: Type: text/plain, Size: 995 bytes --]
On Mon, Apr 20, 2026 at 06:48:07PM +0530, Jai Luthra wrote:
> The starfive-camss driver and bindings were dropped, as they were no
> longer being worked upon for destaging.
>
> Drop the relevant node as well to avoid the following build warning:
> "failed to match any schema with compatible: ['starfive,jh7110-camss']"
>
> Fixes: 644673fc8fb04 ("media: dt-bindings: Drop starfive,jh7110-camss from staging")
> Reported-by: Conor Dooley <conor@kernel.org>
> Closes: https://lore.kernel.org/all/20260420-very-cartel-645595ffd1c7@spud/
> Signed-off-by: Jai Luthra <jai.luthra@ideasonboard.com>
> ---
> Ideally this patch should have gone in the original series, before the
> one that dropped the bindings which is now merged in mainline.
>
> I've added a Fixes tag so it gets picked in the RC cycles for 7.1.
I don't believe this fixes tag is appropriate, so I will drop it on
application. Doesn't really make sense to cite a binding patch as being
the problem with a dts.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [net-next v2 2/5] dt-bindings: net: starfive,jh7110-dwmac: Add JHB100 support
From: Krzysztof Kozlowski @ 2026-04-20 15:33 UTC (permalink / raw)
To: Minda Chen
Cc: Alexandre Torgue, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev, linux-kernel, linux-stm32, devicetree
In-Reply-To: <20260417024523.107786-3-minda.chen@starfivetech.com>
On Fri, Apr 17, 2026 at 10:45:20AM +0800, Minda Chen wrote:
> Add StarFive JHB100 dwmac support and compatible.
> The JHB100 dwmac shares the same driver code as the JH7110 dwmac,
Please describe the hardware or programming interface, not driver code.
> which contains 2 SGMII interfaces, 1 RGMII/RMII interface and
> 1 RMII interface.
> JHB100 dwmac has only one reset signal and one main interrupt
> line.
Drop all below, not relevant.
>
> Please refer to below:
>
> JHB100: reset-names = "stmmaceth";
>
> Example usage of JHB100 in the device tree:
>
> gmac0: ethernet@11b80000 {
> compatible = "starfive,jhb100-dwmac",
> "snps,dwmac-5.20";
> interrupts = <225>;
> interrupt-names = "macirq";
> ...
> };
>
> Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
> ---
> .../devicetree/bindings/net/snps,dwmac.yaml | 1 +
> .../bindings/net/starfive,jh7110-dwmac.yaml | 23 +++++++++++++++++++
> 2 files changed, 24 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> index 38bc34dc4f09..85cd3252e8b1 100644
> --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> @@ -115,6 +115,7 @@ properties:
> - sophgo,sg2044-dwmac
> - starfive,jh7100-dwmac
> - starfive,jh7110-dwmac
> + - starfive,jhb100-dwmac
> - tesla,fsd-ethqos
> - thead,th1520-gmac
>
> diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> index 0d1962980f57..edc246a71ce3 100644
> --- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> @@ -18,6 +18,7 @@ select:
> enum:
> - starfive,jh7100-dwmac
> - starfive,jh7110-dwmac
> + - starfive,jhb100-dwmac
> required:
> - compatible
>
> @@ -30,6 +31,9 @@ properties:
> - items:
> - const: starfive,jh7110-dwmac
> - const: snps,dwmac-5.20
> + - items:
> + - const: starfive,jhb100-dwmac
So that's an enum in previous "items" list.... but your commit msg said
your devices are compatible, so confusing.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: arm: aspeed: add Anacapa EVT1 EVT2 board
From: Conor Dooley @ 2026-04-20 15:36 UTC (permalink / raw)
To: Colin Huang
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, colin.huang2
In-Reply-To: <CAPBH0A_K39218+=QHJuEY+SbFk-nCnM=Z8RQMdHBK7SkCj2QtQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 719 bytes --]
On Mon, Apr 20, 2026 at 01:41:30PM +0800, Colin Huang wrote:
> Conor Dooley <conor@kernel.org> 於 2026年4月9日週四 下午11:36寫道：
> >
> > On Thu, Apr 09, 2026 at 07:40:26PM +0800, Colin Huang wrote:
> > > Document Anacapa BMC EVT1 and EVT2 compatibles.
> > >
> > > Signed-off-by: Colin Huang <u8813345@gmail.com>
> >
> > Acked-by: Conor Dooley <conor.dooley@microchip.com>
> > pw-bot: not-applicable
>
> Hi
> Could anyone let me know, what is my next step which I need to do?
> I can't find the changed in for-next branch of
> https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux.git .
> Thanks.
You wait for the merge window to end and the maintainer to apply your
patches.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: counter: add gpio-quadrature-encoder binding
From: Conor Dooley @ 2026-04-20 15:37 UTC (permalink / raw)
To: Wadim Mueller
Cc: linux-iio, devicetree, wbg, conor+dt, krzk+dt, robh, linux-kernel
In-Reply-To: <20260419195908.12202-2-wafgo01@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 609 bytes --]
On Sun, Apr 19, 2026 at 09:59:06PM +0200, Wadim Mueller wrote:
> Add devicetree binding documentation for the GPIO-based quadrature
> encoder counter driver. The driver reads A/B quadrature signals and
> an optional index pulse via edge-triggered GPIO interrupts, supporting
> X1, X2, X4 quadrature decoding and pulse-direction mode.
>
> This is useful on SoCs that lack a dedicated hardware quadrature
> decoder or where the encoder is wired to generic GPIO pins.
>
> Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v5 1/9] media: v4l2-common: Add YUV24 format info
From: Nicolas Dufresne @ 2026-04-20 15:39 UTC (permalink / raw)
To: Nas Chung, mchehab, hverkuil, robh, krzk+dt, conor+dt, shawnguo,
s.hauer
Cc: linux-media, devicetree, linux-kernel, linux-imx,
linux-arm-kernel, marek.vasut, ming.qian
In-Reply-To: <20260415092529.577-2-nas.chung@chipsnmedia.com>
[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]
Le mercredi 15 avril 2026 à 18:25 +0900, Nas Chung a écrit :
> The YUV24 format is missing an entry in the v4l2_format_info().
> The YUV24 format is the packed YUV 4:4:4 formats with 8 bits
> per component.
>
> Fixes: 0376a51fbe5e ("media: v4l: Add packed YUV444 24bpp pixel format")
> Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Unless you disagree, I might cherry-pick this one. Would it be ok with you ?
Nicolas
> ---
> drivers/media/v4l2-core/v4l2-common.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
> index 554c591e1113..55bcd5975d9f 100644
> --- a/drivers/media/v4l2-core/v4l2-common.c
> +++ b/drivers/media/v4l2-core/v4l2-common.c
> @@ -281,6 +281,7 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
> { .format = V4L2_PIX_FMT_Y212, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 4, 0, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 1 },
> { .format = V4L2_PIX_FMT_Y216, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 4, 0, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 1 },
> { .format = V4L2_PIX_FMT_YUV48_12, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 6, 0, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 1, .vdiv = 1 },
> + { .format = V4L2_PIX_FMT_YUV24, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 3, 0, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 1, .vdiv = 1 },
> { .format = V4L2_PIX_FMT_MT2110T, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 5, 10, 0, 0 }, .bpp_div = { 4, 4, 1, 1 }, .hdiv = 2, .vdiv = 2,
> .block_w = { 16, 8, 0, 0 }, .block_h = { 32, 16, 0, 0 }},
> { .format = V4L2_PIX_FMT_MT2110R, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 5, 10, 0, 0 }, .bpp_div = { 4, 4, 1, 1 }, .hdiv = 2, .vdiv = 2,
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox