From: Elle Rhumsaa <elle@weathered-steel.dev>
To: Michal Wilczynski <m.wilczynski@samsung.com>
Cc: "Uwe Kleine-König" <ukleinek@kernel.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Danilo Krummrich" <dakr@kernel.org>,
"Guo Ren" <guoren@kernel.org>, "Fu Wei" <wefu@redhat.com>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Alexandre Ghiti" <alex@ghiti.fr>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Benno Lossin" <lossin@kernel.org>,
"Michael Turquette" <mturquette@baylibre.com>,
"Drew Fustini" <fustini@kernel.org>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
rust-for-linux@vger.kernel.org, linux-riscv@lists.infradead.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH v14 4/7] pwm: Add Rust driver for T-HEAD TH1520 SoC
Date: Wed, 20 Aug 2025 21:14:17 +0000 [thread overview]
Message-ID: <aKY6qa63SFZt7j8w@archiso> (raw)
In-Reply-To: <20250820-rust-next-pwm-working-fan-for-sending-v14-4-df2191621429@samsung.com>
On Wed, Aug 20, 2025 at 10:35:39AM +0200, Michal Wilczynski wrote:
> Introduce a PWM driver for the T-HEAD TH1520 SoC, written in Rust and
> utilizing the safe PWM abstractions from the preceding commit.
>
> The driver implements the pwm::PwmOps trait using the modern waveform
> API (round_waveform_tohw, write_waveform, etc.) to support configuration
> of period, duty cycle, and polarity for the TH1520's PWM channels.
>
> Resource management is handled using idiomatic Rust patterns. The PWM
> chip object is allocated via pwm::Chip::new and its registration with
> the PWM core is managed by the pwm::Registration RAII guard. This
> ensures pwmchip_remove is always called when the driver unbinds,
> preventing resource leaks. Device managed resources are used for the
> MMIO region, and the clock lifecycle is correctly managed in the
> driver's private data Drop implementation.
>
> The driver's core logic is written entirely in safe Rust, with no unsafe
> blocks, except for the Send and Sync implementations for the driver
> data, which are explained in the comments.
>
> Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>
> ---
> MAINTAINERS | 1 +
> drivers/pwm/Kconfig | 11 ++
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm_th1520.rs | 355 ++++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 368 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5d7c0676c1d00a02b3d7db2de88b039c08c99c6e..d79dc21f22d143ca8cde6a06194545fbc640e695 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -21741,6 +21741,7 @@ F: drivers/net/ethernet/stmicro/stmmac/dwmac-thead.c
> F: drivers/pinctrl/pinctrl-th1520.c
> F: drivers/pmdomain/thead/
> F: drivers/power/sequencing/pwrseq-thead-gpu.c
> +F: drivers/pwm/pwm_th1520.rs
> F: drivers/reset/reset-th1520.c
> F: include/dt-bindings/clock/thead,th1520-clk-ap.h
> F: include/dt-bindings/power/thead,th1520-power.h
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 2b608f4378138775ee3ba4d53f682952e1914118..dd6db01832ee985e2e588a413a13df869a029d3d 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -729,6 +729,17 @@ config PWM_TEGRA
> To compile this driver as a module, choose M here: the module
> will be called pwm-tegra.
>
> +config PWM_TH1520
> + tristate "TH1520 PWM support"
> + depends on RUST
> + select RUST_PWM_ABSTRACTIONS
> + help
> + This option enables the driver for the PWM controller found on the
> + T-HEAD TH1520 SoC.
> +
> + To compile this driver as a module, choose M here; the module
> + will be called pwm-th1520. If you are unsure, say N.
> +
> config PWM_TIECAP
> tristate "ECAP PWM support"
> depends on ARCH_OMAP2PLUS || ARCH_DAVINCI_DA8XX || ARCH_KEYSTONE || ARCH_K3 || COMPILE_TEST
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index ff4f47e5fb7a0dbac72c12de82c3773e5582db6d..5c15c95c6e49143969389198657eed0ecf4086b2 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -67,6 +67,7 @@ obj-$(CONFIG_PWM_STMPE) += pwm-stmpe.o
> obj-$(CONFIG_PWM_SUN4I) += pwm-sun4i.o
> obj-$(CONFIG_PWM_SUNPLUS) += pwm-sunplus.o
> obj-$(CONFIG_PWM_TEGRA) += pwm-tegra.o
> +obj-$(CONFIG_PWM_TH1520) += pwm_th1520.o
> obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o
> obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
> obj-$(CONFIG_PWM_TWL) += pwm-twl.o
> diff --git a/drivers/pwm/pwm_th1520.rs b/drivers/pwm/pwm_th1520.rs
> new file mode 100644
> index 0000000000000000000000000000000000000000..5ef887b1b5dfed92c5d4b87a7d48f673352a257e
> --- /dev/null
> +++ b/drivers/pwm/pwm_th1520.rs
> @@ -0,0 +1,355 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2025 Samsung Electronics Co., Ltd.
> +// Author: Michal Wilczynski <m.wilczynski@samsung.com>
> +
> +//! Rust T-HEAD TH1520 PWM driver
> +//!
> +//! Limitations:
> +//! - The period and duty cycle are controlled by 32-bit hardware registers,
> +//! limiting the maximum resolution.
> +//! - The driver supports continuous output mode only; one-shot mode is not
> +//! implemented.
> +//! - The controller hardware provides up to 6 PWM channels.
> +//! - Reconfiguration is glitch free - new period and duty cycle values are
> +//! latched and take effect at the start of the next period.
> +//! - Polarity is handled via a simple hardware inversion bit; arbitrary
> +//! duty cycle offsets are not supported.
> +//! - Disabling a channel is achieved by configuring its duty cycle to zero to
> +//! produce a static low output. Clearing the `start` does not reliably
> +//! force the static inactive level defined by the `INACTOUT` bit. Hence
> +//! this method is not used in this driver.
> +//!
> +
> +use core::ops::Deref;
> +use kernel::{
> + c_str,
> + clk::Clk,
> + device::{Bound, Core, Device},
> + devres,
> + io::mem::IoMem,
> + of, platform,
> + prelude::*,
> + pwm, time,
> +};
> +
> +const TH1520_MAX_PWM_NUM: u32 = 6;
> +
> +// Register offsets
> +const fn th1520_pwm_chn_base(n: u32) -> usize {
> + (n * 0x20) as usize
> +}
> +
> +const fn th1520_pwm_ctrl(n: u32) -> usize {
> + th1520_pwm_chn_base(n)
> +}
> +
> +const fn th1520_pwm_per(n: u32) -> usize {
> + th1520_pwm_chn_base(n) + 0x08
> +}
> +
> +const fn th1520_pwm_fp(n: u32) -> usize {
> + th1520_pwm_chn_base(n) + 0x0c
> +}
> +
> +// Control register bits
> +const TH1520_PWM_START: u32 = 1 << 0;
> +const TH1520_PWM_CFG_UPDATE: u32 = 1 << 2;
> +const TH1520_PWM_CONTINUOUS_MODE: u32 = 1 << 5;
> +const TH1520_PWM_FPOUT: u32 = 1 << 8;
> +
> +const TH1520_PWM_REG_SIZE: usize = 0xB0;
> +
> +fn ns_to_cycles(ns: u64, rate_hz: u64) -> u64 {
> + const NSEC_PER_SEC_U64: u64 = time::NSEC_PER_SEC as u64;
> +
> + (match ns.checked_mul(rate_hz) {
> + Some(product) => product,
> + None => u64::MAX,
> + }) / NSEC_PER_SEC_U64
> +}
> +
> +fn cycles_to_ns(cycles: u64, rate_hz: u64) -> u64 {
> + const NSEC_PER_SEC_U64: u64 = time::NSEC_PER_SEC as u64;
> +
> + // Round up
> + let Some(numerator) = cycles
> + .checked_mul(NSEC_PER_SEC_U64)
> + .and_then(|p| p.checked_add(rate_hz - 1))
> + else {
> + return u64::MAX;
> + };
> +
> + numerator / rate_hz
> +}
> +
> +/// Hardware-specific waveform representation for TH1520.
> +#[derive(Copy, Clone, Debug, Default)]
> +struct Th1520WfHw {
> + period_cycles: u32,
> + duty_cycles: u32,
> + ctrl_val: u32,
> + enabled: bool,
> +}
> +
> +/// The driver's private data struct. It holds all necessary devres managed resources.
> +#[pin_data(PinnedDrop)]
> +struct Th1520PwmDriverData {
> + #[pin]
> + iomem: devres::Devres<IoMem<TH1520_PWM_REG_SIZE>>,
> + clk: Clk,
> +}
> +
> +// This `unsafe` implementation is a temporary necessity because the underlying `kernel::clk::Clk`
> +// type does not yet expose `Send` and `Sync` implementations. This block should be removed
> +// as soon as the clock abstraction provides these guarantees directly.
> +// TODO: Remove those unsafe impl's when Clk will support them itself.
> +
> +// SAFETY: The `devres` framework requires the driver's private data to be `Send` and `Sync`.
> +// We can guarantee this because the PWM core synchronizes all callbacks, preventing concurrent
> +// access to the contained `iomem` and `clk` resources.
> +unsafe impl Send for Th1520PwmDriverData {}
> +
> +// SAFETY: The same reasoning applies as for `Send`. The PWM core's synchronization
> +// guarantees that it is safe for multiple threads to have shared access (`&self`)
> +// to the driver data during callbacks.
> +unsafe impl Sync for Th1520PwmDriverData {}
> +
> +impl pwm::PwmOps for Th1520PwmDriverData {
> + type WfHw = Th1520WfHw;
> +
> + fn round_waveform_tohw(
> + chip: &pwm::Chip<Self>,
> + _pwm: &pwm::Device,
> + wf: &pwm::Waveform,
> + ) -> Result<pwm::RoundedWaveform<Self::WfHw>> {
> + let data = chip.drvdata();
> +
> + if wf.period_length_ns == 0 {
> + return Ok(pwm::RoundedWaveform {
> + status: 0,
> + hardware_waveform: Th1520WfHw {
> + enabled: false,
> + ..Default::default()
> + },
> + });
> + }
> +
> + let rate_hz = data.clk.rate().as_hz() as u64;
> +
> + let period_cycles = ns_to_cycles(wf.period_length_ns, rate_hz).min(u64::from(u32::MAX));
> + let mut duty_cycles = ns_to_cycles(wf.duty_length_ns, rate_hz).min(u64::from(u32::MAX));
> +
> + let mut ctrl_val = TH1520_PWM_CONTINUOUS_MODE;
> +
> + let is_inversed = wf.duty_length_ns > 0
> + && wf.duty_offset_ns > 0
> + && wf.duty_length_ns + wf.duty_offset_ns >= wf.period_length_ns;
> + if is_inversed {
> + duty_cycles = period_cycles - duty_cycles;
> + } else {
> + ctrl_val |= TH1520_PWM_FPOUT;
> + }
> +
> + let wfhw = Th1520WfHw {
> + period_cycles: period_cycles as u32,
> + duty_cycles: duty_cycles as u32,
> + ctrl_val,
> + enabled: true,
> + };
> +
> + dev_dbg!(
> + chip.device(),
> + "clk_rate: {}Hz Requested: period {}ns, duty {}ns, offset {}ns -> HW: period {} cyc, duty {} cyc, ctrl 0x{:x}\n",
> + rate_hz,
> + wf.period_length_ns,
> + wf.duty_length_ns,
> + wf.duty_offset_ns,
> + wfhw.period_cycles,
> + wfhw.duty_cycles,
> + wfhw.ctrl_val
> + );
> +
> + Ok(pwm::RoundedWaveform {
> + status: 0,
> + hardware_waveform: wfhw,
> + })
> + }
> +
> + fn round_waveform_fromhw(
> + chip: &pwm::Chip<Self>,
> + _pwm: &pwm::Device,
> + wfhw: &Self::WfHw,
> + wf: &mut pwm::Waveform,
> + ) -> Result {
> + let data = chip.drvdata();
> + let rate_hz = data.clk.rate().as_hz() as u64;
> +
> + wf.period_length_ns = cycles_to_ns(u64::from(wfhw.period_cycles), rate_hz);
> +
> + let duty_cycles = u64::from(wfhw.duty_cycles);
> +
> + if (wfhw.ctrl_val & TH1520_PWM_FPOUT) != 0 {
> + wf.duty_length_ns = cycles_to_ns(duty_cycles, rate_hz);
> + wf.duty_offset_ns = 0;
> + } else {
> + let period_cycles = u64::from(wfhw.period_cycles);
> + let original_duty_cycles = period_cycles.saturating_sub(duty_cycles);
> +
> + // For an inverted signal, `duty_length_ns` is the high time (period - low_time).
> + wf.duty_length_ns = cycles_to_ns(original_duty_cycles, rate_hz);
> + // The offset is the initial low time, which is what the hardware register provides.
> + wf.duty_offset_ns = cycles_to_ns(duty_cycles, rate_hz);
> + }
> +
> + Ok(())
> + }
> +
> + fn read_waveform(
> + chip: &pwm::Chip<Self>,
> + pwm: &pwm::Device,
> + parent_dev: &Device<Bound>,
> + ) -> Result<Self::WfHw> {
> + let data = chip.drvdata();
> + let hwpwm = pwm.hwpwm();
> + let iomem_accessor = data.iomem.access(parent_dev)?;
> + let iomap = iomem_accessor.deref();
> +
> + let ctrl = iomap.try_read32(th1520_pwm_ctrl(hwpwm))?;
> + let period_cycles = iomap.try_read32(th1520_pwm_per(hwpwm))?;
> + let duty_cycles = iomap.try_read32(th1520_pwm_fp(hwpwm))?;
> +
> + let wfhw = Th1520WfHw {
> + period_cycles,
> + duty_cycles,
> + ctrl_val: ctrl,
> + enabled: duty_cycles != 0,
> + };
> +
> + dev_dbg!(
> + chip.device(),
> + "PWM-{}: read_waveform: Read hw state - period: {}, duty: {}, ctrl: 0x{:x}, enabled: {}",
> + hwpwm,
> + wfhw.period_cycles,
> + wfhw.duty_cycles,
> + wfhw.ctrl_val,
> + wfhw.enabled
> + );
> +
> + Ok(wfhw)
> + }
> +
> + fn write_waveform(
> + chip: &pwm::Chip<Self>,
> + pwm: &pwm::Device,
> + wfhw: &Self::WfHw,
> + parent_dev: &Device<Bound>,
> + ) -> Result {
> + let data = chip.drvdata();
> + let hwpwm = pwm.hwpwm();
> + let iomem_accessor = data.iomem.access(parent_dev)?;
> + let iomap = iomem_accessor.deref();
> + let was_enabled = pwm.state().enabled();
> +
> + if !wfhw.enabled {
> + if was_enabled {
> + iomap.try_write32(wfhw.ctrl_val, th1520_pwm_ctrl(hwpwm))?;
> + iomap.try_write32(0, th1520_pwm_fp(hwpwm))?;
> + iomap.try_write32(wfhw.ctrl_val | TH1520_PWM_CFG_UPDATE, th1520_pwm_ctrl(hwpwm))?;
> + }
> + return Ok(());
> + }
> +
> + iomap.try_write32(wfhw.ctrl_val, th1520_pwm_ctrl(hwpwm))?;
> + iomap.try_write32(wfhw.period_cycles, th1520_pwm_per(hwpwm))?;
> + iomap.try_write32(wfhw.duty_cycles, th1520_pwm_fp(hwpwm))?;
> + iomap.try_write32(wfhw.ctrl_val | TH1520_PWM_CFG_UPDATE, th1520_pwm_ctrl(hwpwm))?;
> +
> + // The `TH1520_PWM_START` bit must be written in a separate, final transaction, and
> + // only when enabling the channel from a disabled state.
> + if !was_enabled {
> + iomap.try_write32(wfhw.ctrl_val | TH1520_PWM_START, th1520_pwm_ctrl(hwpwm))?;
> + }
> +
> + dev_dbg!(
> + chip.device(),
> + "PWM-{}: Wrote (per: {}, duty: {})",
> + hwpwm,
> + wfhw.period_cycles,
> + wfhw.duty_cycles,
> + );
> +
> + Ok(())
> + }
> +}
> +
> +#[pinned_drop]
> +impl PinnedDrop for Th1520PwmDriverData {
> + fn drop(self: Pin<&mut Self>) {
> + self.clk.disable_unprepare();
> + }
> +}
> +
> +struct Th1520PwmPlatformDriver;
> +
> +kernel::of_device_table!(
> + OF_TABLE,
> + MODULE_OF_TABLE,
> + <Th1520PwmPlatformDriver as platform::Driver>::IdInfo,
> + [(of::DeviceId::new(c_str!("thead,th1520-pwm")), ())]
> +);
> +
> +impl platform::Driver for Th1520PwmPlatformDriver {
> + type IdInfo = ();
> + const OF_ID_TABLE: Option<of::IdTable<Self::IdInfo>> = Some(&OF_TABLE);
> +
> + fn probe(
> + pdev: &platform::Device<Core>,
> + _id_info: Option<&Self::IdInfo>,
> + ) -> Result<Pin<KBox<Self>>> {
> + let dev = pdev.as_ref();
> + let request = pdev.io_request_by_index(0).ok_or(ENODEV)?;
> +
> + let clk = Clk::get(dev, None)?;
> +
> + clk.prepare_enable()?;
> +
> + // TODO: Get exclusive ownership of the clock to prevent rate changes.
> + // The Rust equivalent of `clk_rate_exclusive_get()` is not yet available.
> + // This should be updated once it is implemented.
> + let rate_hz = clk.rate().as_hz();
> + if rate_hz == 0 {
> + dev_err!(dev, "Clock rate is zero\n");
> + return Err(EINVAL);
> + }
> +
> + if rate_hz > time::NSEC_PER_SEC as usize {
> + dev_err!(
> + dev,
> + "Clock rate {} Hz is too high, not supported.\n",
> + rate_hz
> + );
> + return Err(ERANGE);
> + }
> +
> + let chip = pwm::Chip::new(
> + dev,
> + TH1520_MAX_PWM_NUM,
> + try_pin_init!(Th1520PwmDriverData {
> + iomem <- request.iomap_sized::<TH1520_PWM_REG_SIZE>(),
> + clk <- clk,
> + }),
> + )?;
> +
> + pwm::Registration::register(dev, chip)?;
> +
> + Ok(KBox::new(Th1520PwmPlatformDriver, GFP_KERNEL)?.into())
> + }
> +}
> +
> +kernel::module_platform_driver! {
> + type: Th1520PwmPlatformDriver,
> + name: "pwm-th1520",
> + authors: ["Michal Wilczynski <m.wilczynski@samsung.com>"],
> + description: "T-HEAD TH1520 PWM driver",
> + license: "GPL v2",
> +}
>
> --
> 2.34.1
Reviewed-by: Elle Rhumsaa <elle@weathered-steel.dev>
next prev parent reply other threads:[~2025-08-20 21:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20250820083539eucas1p127f39561c51a44d7d2b5ace73b5eca7b@eucas1p1.samsung.com>
2025-08-20 8:35 ` [PATCH v14 0/7] Rust Abstractions for PWM subsystem with TH1520 PWM driver Michal Wilczynski
[not found] ` <CGME20250820083541eucas1p2ad7d78418576b8bc8cbddd8efe83bbe9@eucas1p2.samsung.com>
2025-08-20 8:35 ` [PATCH v14 1/7] pwm: Export `pwmchip_release` for external use Michal Wilczynski
2025-08-20 20:30 ` Elle Rhumsaa
[not found] ` <CGME20250820083542eucas1p221dacb3b69524b0dd6f7abf870adbe04@eucas1p2.samsung.com>
2025-08-20 8:35 ` [PATCH v14 2/7] rust: pwm: Add Kconfig and basic data structures Michal Wilczynski
2025-08-20 20:35 ` Elle Rhumsaa
[not found] ` <CGME20250820083544eucas1p233f8b8f7d1c0b59acededa3572d632aa@eucas1p2.samsung.com>
2025-08-20 8:35 ` [PATCH v14 3/7] rust: pwm: Add complete abstraction layer Michal Wilczynski
2025-08-20 21:11 ` Elle Rhumsaa
2025-08-21 22:35 ` Michal Wilczynski
[not found] ` <CGME20250820083544eucas1p2be0157353ec1201b0651292792429aa4@eucas1p2.samsung.com>
2025-08-20 8:35 ` [PATCH v14 4/7] pwm: Add Rust driver for T-HEAD TH1520 SoC Michal Wilczynski
2025-08-20 21:14 ` Elle Rhumsaa [this message]
[not found] ` <CGME20250820083546eucas1p2cc370ae89e7a87e3f3b9266967501b44@eucas1p2.samsung.com>
2025-08-20 8:35 ` [PATCH v14 5/7] dt-bindings: pwm: thead: Add T-HEAD TH1520 PWM controller Michal Wilczynski
2025-08-20 21:16 ` Elle Rhumsaa
[not found] ` <CGME20250820083547eucas1p265478a3c9cf55a71e4e4b7fcfc5aadae@eucas1p2.samsung.com>
2025-08-20 8:35 ` [PATCH v14 6/7] riscv: dts: thead: Add PWM controller node Michal Wilczynski
2025-08-20 21:17 ` Elle Rhumsaa
[not found] ` <CGME20250820083548eucas1p2a40775d53dfd9f8608671cc20003fd7d@eucas1p2.samsung.com>
2025-08-20 8:35 ` [PATCH v14 7/7] riscv: dts: thead: Add PWM fan and thermal control Michal Wilczynski
2025-08-20 21:18 ` Elle Rhumsaa
2025-08-22 20:49 ` Drew Fustini
2025-08-23 10:13 ` Michal Wilczynski
2025-08-23 10:17 ` Michal Wilczynski
2025-08-23 14:20 ` Miguel Ojeda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aKY6qa63SFZt7j8w@archiso \
--to=elle@weathered-steel.dev \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=alex@ghiti.fr \
--cc=aliceryhl@google.com \
--cc=aou@eecs.berkeley.edu \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=conor+dt@kernel.org \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=fustini@kernel.org \
--cc=gary@garyguo.net \
--cc=guoren@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=lossin@kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=m.wilczynski@samsung.com \
--cc=mturquette@baylibre.com \
--cc=ojeda@kernel.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robh@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
--cc=ukleinek@kernel.org \
--cc=wefu@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).