* Re: [PATCH 1/3] arm64: dts: imx8mn-vhip4-evalboard-v1: Correct interrupt flags
From: Marek Vasut @ 2026-04-06 14:49 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Peng Fan, Fedor Ross, Shawn Guo, Shengjiu Wang,
Viorel Suman, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260406063810.25531-4-krzysztof.kozlowski@oss.qualcomm.com>
On 4/6/26 8:38 AM, Krzysztof Kozlowski wrote:
> GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
> These are simple defines so they could be used in DTS but they will not
> have the same meaning:
> 1. GPIO_ACTIVE_HIGH = 0 => IRQ_TYPE_NONE
> 2. GPIO_ACTIVE_LOW = 1 => IRQ_TYPE_EDGE_RISING
>
> Correct the interrupt flags, assuming the author of the code wanted the
> same logical behavior behind the name "ACTIVE_xxx", this is:
> ACTIVE_LOW => IRQ_TYPE_LEVEL_LOW
>
> Fixes: 5eb7405db99b ("arm64: dts: imx8mn: Add ifm VHIP4 EvalBoard v1 and v2")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Marek Vasut <marex@nabladev.com>
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: imx8mn-vhip4-evalboard-v2: Correct interrupt flags
From: Marek Vasut @ 2026-04-06 14:49 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Peng Fan, Fedor Ross, Shawn Guo, Shengjiu Wang,
Viorel Suman, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260406063810.25531-5-krzysztof.kozlowski@oss.qualcomm.com>
On 4/6/26 8:38 AM, Krzysztof Kozlowski wrote:
> GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
> These are simple defines so they could be used in DTS but they will not
> have the same meaning:
> 1. GPIO_ACTIVE_HIGH = 0 => IRQ_TYPE_NONE
> 2. GPIO_ACTIVE_LOW = 1 => IRQ_TYPE_EDGE_RISING
>
> Correct the interrupt flags, assuming the author of the code wanted the
> same logical behavior behind the name "ACTIVE_xxx", this is:
> ACTIVE_LOW => IRQ_TYPE_LEVEL_LOW
>
> Fixes: 5eb7405db99b ("arm64: dts: imx8mn: Add ifm VHIP4 EvalBoard v1 and v2")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Marek Vasut <marex@nabladev.com>
^ permalink raw reply
* Re: [PATCH v6 2/2] dt-bindings: embedded-controller: Add synology microp devices
From: Markus Probst @ 2026-04-06 15:35 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: 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, platform-driver-x86, linux-leds,
devicetree, linux-kernel, rust-for-linux
In-Reply-To: <0b785ee4-7d15-4a9d-a820-20ea15225ea1@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 6882 bytes --]
On Mon, 2026-04-06 at 16:42 +0200, Krzysztof Kozlowski wrote:
> On 06/04/2026 16:22, Markus Probst wrote:
> > On Mon, 2026-04-06 at 09:59 +0200, Krzysztof Kozlowski wrote:
> > > On Sun, Apr 05, 2026 at 07:36:29PM +0200, Markus Probst wrote:
> > > > Add the Synology Microp devicetree bindings. Those devices are
> > > > microcontrollers found on Synology NAS devices. They are connected to a
> > > > serial port on the host device.
> > > >
> > > > Those devices are used to control certain LEDs, fan speeds, a beeper, to
> > > > handle buttons, fan failures and to properly shutdown and reboot the
> > > > device.
> > > >
> > > > This includes the following compatible ids:
> > > > - synology,ds923p-microp
> > > > - synology,ds918p-microp
> > > > - synology,ds214play-microp
> > > > - synology,ds225p-microp
> > > > - synology,ds425p-microp
> > > > - synology,ds710p-microp
> > > > - synology,ds1010p-microp
> > > > - synology,ds723p-microp
> > > > - synology,ds1522p-microp
> > > > - synology,rs422p-microp
> > > > - synology,ds725p-microp
> > > > - synology,ds118-microp
> > > > - synology,ds124-microp
> > > > - synology,ds223-microp
> > > > - synology,ds223j-microp
> > > > - synology,ds1823xsp-microp
> > > > - synology,rs822p-microp
> > > > - synology,rs1221p-microp
> > > > - synology,rs1221rpp-microp
> > > > - synology,ds925p-microp
> > > > - synology,ds1525p-microp
> > > > - synology,ds1825p-microp
> > >
> > > Drop, we see this in the diff.
> > A prior review commit suggested I should add them [1].
> > So only synology,ds923p-microp in the Subject then?
>
> I do not see how this list resolves my comment. Really, explain my how
> listing part of binding answers WHY they are not compatible?
I might have misunderstood it then, my apologies for that.
>
>
> >
> > [1]
> > https://lore.kernel.org/all/20260330-delicate-sassy-mayfly-ebcca7@quoll/
> >
> > >
> > > >
> > > > Signed-off-by: Markus Probst <markus.probst@posteo.de>
> > > > ---
> > > > .../synology,ds923p-microp.yaml | 112 +++++++++++++++++++++
> > > > MAINTAINERS | 1 +
> > > > 2 files changed, 113 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/embedded-controller/synology,ds923p-microp.yaml b/Documentation/devicetree/bindings/embedded-controller/synology,ds923p-microp.yaml
> > > > new file mode 100644
> > > > index 000000000000..4518e9b74be1
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/embedded-controller/synology,ds923p-microp.yaml
> > > > @@ -0,0 +1,112 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/embedded-controller/synology,ds923p-microp.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Synology NAS on-board Microcontroller
> > > > +
> > > > +maintainers:
> > > > + - Markus Probst <markus.probst@posteo.de>
> > > > +
> > > > +description: |
> > > > + Synology Microp is a microcontroller found in Synology NAS devices.
> > > > + It is connected to a serial port on the host device.
> > > > +
> > > > + It is necessary to properly shutdown and reboot the NAS device and
> > > > + provides additional functionality such as led control, fan speed control,
> > > > + a beeper and buttons on the NAS device.
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > + enum:
> > > > + - synology,ds923p-microp
> > > > + - synology,ds918p-microp
> > > > + - synology,ds214play-microp
> > > > + - synology,ds225p-microp
> > > > + - synology,ds425p-microp
> > > > + - synology,ds710p-microp
> > > > + - synology,ds1010p-microp
> > > > + - synology,ds723p-microp
> > > > + - synology,ds1522p-microp
> > > > + - synology,rs422p-microp
> > > > + - synology,ds725p-microp
> > > > + - synology,ds118-microp
> > > > + - synology,ds124-microp
> > > > + - synology,ds223-microp
> > > > + - synology,ds223j-microp
> > > > + - synology,ds1823xsp-microp
> > > > + - synology,rs822p-microp
> > > > + - synology,rs1221p-microp
> > > > + - synology,rs1221rpp-microp
> > > > + - synology,ds925p-microp
> > > > + - synology,ds1525p-microp
> > > > + - synology,ds1825p-microp
> > >
> > > So we already talked about this and you were told to use compatibility.
> > > Your driver clearly states several of these are compatible, so I am
> > > confused that I do not see it expressed here.
> > The driver does not have all functionality implemented yet.
>
> Either this drivers works or not. If it works, explain me how they are
> not compatible.
I will use my ds923+ as baseline here.
Known relevant differences that make them not compatible:
ds918p:
- no system current sensor
ds214play:
- has an cpu fan
- has only 1 fan
- no system current sensor
ds225p:
- has usb copy led and button
- has only 1 fan
- no system current sensor
ds415p:
- no system current sensor
ds710p:
- has esata led
- has only 1 fan
- no system current sensor
ds1010p:
- has alert led controlled via microp
- no system current sensor
ds723p
- has only 1 fan
ds725p:
- has only 1 fan
- no system current sensor
ds1522p: <no relevant known difference>
rs422p:
- power led is green
- has 3 fans
rs822p:
- power led is green
- supports fan rpm report via an adt7475 chip and therefore does not
have gpios for fan failure
- no system current sensor
ds118, ds124, ds223j:
- different shutdown behaviour
- has only 1 fan
- no system current sensor
ds223:
- different shutdown behaviour
- has usb copy led and button
- has only 1 fan
- no system current sensor
rs1221p, rs1221rpp:
- power led is green
- supports fan rpm report via an adt7475 chip and therefore does not
have gpios for fan failure
- no system current sensor
ds925p, ds1525p, ds1825p, ds1823xsp:
- supports fan rpm report via an adt7475 chip and therefore does not
have gpios for fan failure
- no system current sensor
Thanks
- Markus Probst
>
> >
> > A few examples of differences not yet visible in the driver:
> > - synology,ds214play-microp is the only model in the current list to
> > have an cpu fan
> > - 4 of the models are arm based and need a different shutdown behaviour
> > - different amount of fans (already present in the binding via fan-
> > failure-gpios)
> >
> > I could try to group them together, but Synology does not document the
> > exact difference between them.
> >
> > As Rob mentioned [2], I need to be able to handle unexpected
> > differences without qurik properties.
>
> I did not object that.
>
>
> Best regards,
> Krzysztof
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* Re: [PATCH v5 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: Bryan O'Donoghue @ 2026-04-06 15:37 UTC (permalink / raw)
To: Abel Vesa, Bryan O'Donoghue
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Vladimir Zapolskiy, linux-arm-msm, linux-phy, linux-media,
devicetree, linux-kernel
In-Reply-To: <qrzaihfpujlhqeukp7wioqrqjbpih65smmieliixavzlev6las@odmnpbuc3wrm>
On 06/04/2026 15:28, Abel Vesa wrote:
>> +
>> + for (i = 0; i < num_pds; i++) {
>> + csi2phy->pds[i] = dev_pm_domain_attach_by_name(dev,
>> + csi2phy->soc_cfg->genpd_names[i]);
> You need to do detach these on error, otherwise you get:
>
> sysfs: cannot create duplicate filename '/devices/genpd:0:acec000.phy'
> CPU: 1 UID: 0 PID: 93 Comm: kworker/u49:2 Not tainted 7.0.0-rc6-00062-gd691cf9ea708 #12 PREEMPT
> Hardware name: Dell Inc. XPS 13 9345/05H2K4, BIOS 2.11.0 09/21/2025
> Workqueue: events_unbound deferred_probe_work_func
Yeah I noticed that myself, thanks for posting.
---
bod
^ permalink raw reply
* Re: [PATCH RFC 0/2] clk: scmi: DT support for SCMI clock rate rounding modes (per‑clock policy)
From: Brian Masney @ 2026-04-06 15:38 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sudeep Holla, Cristian Marussi, linux-kernel,
linux-clk, devicetree, arm-scmi, linux-arm-kernel, Peng Fan
In-Reply-To: <20260306-scmi-clk-round-v1-0-61e2a5df9051@nxp.com>
Hi Peng,
On Fri, Mar 06, 2026 at 02:20:11PM +0800, Peng Fan (OSS) wrote:
> The ARM SCMI specification (DEN0056E) defines rounding‑mode flags for the
> CLOCK_RATE_SET command, allowing a client to request that the firmware
> round a requested clock rate down, up, or autonomously choose the
> closest achievable rate.
> This series introduces DT support in the SCMI clock provider to carry a
> per‑clock rounding policy from the device tree into the SCMI protocol.
>
> Patch 1 adds dt‑bindings constants for rounding modes:
> ROUND_DOWN, ROUND_UP, ROUND_AUTO.
>
> Patch 2 extends the SCMI clock provider to optionally support
> "#clock-cells = <2>", where the second cell encodes the rounding mode.
> The first consumer that references a given clock latches the per‑clock
> policy. Subsequent consumers of the same clock must specify the same
> mode; otherwise, the request is rejected to avoid non‑deterministic
> behavior. The selected mode is passed through to the SCMI Clock protocol
> and mapped to the corresponding CLOCK_SET_* flag.
>
> Patch 2 includes changes to drivers/clk/clk-scmi.c and drivers/firmware
> arm_scmi/clock.c, it is hard to separate the changes without breaking,
> so I put the changes in one patch.
>
> This design adopts a per‑clock policy model, not per‑consumer. The rounding
> mode is applied by the provider per clock (index).
> All consumers of the same clock must agree on the rounding mode.
> Conflicting per‑consumer requests for the same clock are invalid and
> are rejected during phandle translation.
>
> This avoids silent clobbering and preserves deterministic behavior.
>
> Existing device trees using #clock-cells = <1> continue to work and
> default to ROUND_DOWN, exactly as before.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
My high level feedback about this:
1) Since you are making changes to the DT schema for the clock-cells,
does the SCMI DT schema document also need to be updated to allow
clock-cells to be 1 or 2?
2) For the ROUND_XXX constants, I would prefix them with something
since the existing ROUND names are fairly generic sounding. Maybe
CLK_SCMI_?
Brian
^ permalink raw reply
* [PATCH 0/2] pwm: clk-pwm: Add GPIO support for constant output levels
From: Xilin Wu @ 2026-04-06 15:50 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Nikita Travkin
Cc: linux-pwm, devicetree, linux-kernel, linux-arm-msm, Xilin Wu
The clk-pwm driver uses a clock with duty cycle control to generate
PWM output. However, when the PWM is disabled or a 0%/100% duty cycle
is requested, the clock must be stopped, and the resulting pin level
is undefined and hardware-dependent.
This series adds optional GPIO and pinctrl support to the clk-pwm
driver. When a GPIO and pinctrl states ("default" for clock mux,
"gpio" for GPIO mode) are provided in the device tree, the driver
switches the pin to GPIO mode and drives a deterministic output level
for disabled/0%/100% states. For normal PWM output the pin is switched
back to its clock function mux. If no GPIO is provided, the driver
falls back to the original clock-only behavior.
Signed-off-by: Xilin Wu <sophon@radxa.com>
---
Xilin Wu (2):
dt-bindings: pwm: clk-pwm: add optional GPIO and pinctrl properties
pwm: clk-pwm: add GPIO and pinctrl support for constant output levels
Documentation/devicetree/bindings/pwm/clk-pwm.yaml | 36 ++++++++++-
drivers/pwm/pwm-clk.c | 72 ++++++++++++++++++++--
2 files changed, 101 insertions(+), 7 deletions(-)
---
base-commit: 2febe6e6ee6e34c7754eff3c4d81aa7b0dcb7979
change-id: 20260406-clk-pwm-gpio-7f63b38908a5
Best regards,
--
Xilin Wu <sophon@radxa.com>
^ permalink raw reply
* [PATCH 1/2] dt-bindings: pwm: clk-pwm: add optional GPIO and pinctrl properties
From: Xilin Wu @ 2026-04-06 15:50 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Nikita Travkin
Cc: linux-pwm, devicetree, linux-kernel, linux-arm-msm, Xilin Wu
In-Reply-To: <20260406-clk-pwm-gpio-v1-0-40d2f3a20aff@radxa.com>
The clk-pwm driver cannot produce constant output levels (0% or 100%
duty cycle, or disabled state) through the clock hardware alone - the
actual pin level when the clock is off is undefined and
hardware-dependent.
Document optional gpios, pinctrl-names, pinctrl-0, and pinctrl-1
properties that allow the driver to switch the pin between clock
function mux (for normal PWM output) and GPIO mode (to drive a
deterministic constant level).
Signed-off-by: Xilin Wu <sophon@radxa.com>
---
Documentation/devicetree/bindings/pwm/clk-pwm.yaml | 36 +++++++++++++++++++++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/pwm/clk-pwm.yaml b/Documentation/devicetree/bindings/pwm/clk-pwm.yaml
index ec1768291503..2a0e3e02d27b 100644
--- a/Documentation/devicetree/bindings/pwm/clk-pwm.yaml
+++ b/Documentation/devicetree/bindings/pwm/clk-pwm.yaml
@@ -15,6 +15,11 @@ description: |
It's often possible to control duty-cycle of such clocks which makes them
suitable for generating PWM signal.
+ Optionally, a GPIO and pinctrl states can be provided. When a constant
+ output level is needed (0%, 100%, or disabled), the pin is switched to
+ GPIO mode to drive the level directly. For normal PWM output the pin is
+ switched back to its clock function mux.
+
allOf:
- $ref: pwm.yaml#
@@ -29,6 +34,26 @@ properties:
"#pwm-cells":
const: 2
+ gpios:
+ description:
+ Optional GPIO used to drive a constant level when the PWM output is
+ disabled or set to 0% / 100% duty cycle. When provided, pinctrl states
+ "default" (clock mux) and "gpio" must also be defined.
+ maxItems: 1
+
+ pinctrl-names: true
+
+ pinctrl-0:
+ description: Pin configuration for clock function mux (normal PWM).
+ maxItems: 1
+
+ pinctrl-1:
+ description: Pin configuration for GPIO mode (constant level output).
+ maxItems: 1
+
+dependencies:
+ gpios: [ pinctrl-0, pinctrl-1 ]
+
unevaluatedProperties: false
required:
@@ -41,6 +66,15 @@ examples:
compatible = "clk-pwm";
#pwm-cells = <2>;
clocks = <&gcc 0>;
- pinctrl-names = "default";
+ };
+
+ - |
+ pwm {
+ compatible = "clk-pwm";
+ #pwm-cells = <2>;
+ clocks = <&gcc 0>;
+ pinctrl-names = "default", "gpio";
pinctrl-0 = <&pwm_clk_flash_default>;
+ pinctrl-1 = <&pwm_clk_flash_gpio>;
+ gpios = <&tlmm 32 0>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH 2/2] pwm: clk-pwm: add GPIO and pinctrl support for constant output levels
From: Xilin Wu @ 2026-04-06 15:50 UTC (permalink / raw)
To: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Nikita Travkin
Cc: linux-pwm, devicetree, linux-kernel, linux-arm-msm, Xilin Wu
In-Reply-To: <20260406-clk-pwm-gpio-v1-0-40d2f3a20aff@radxa.com>
The clk-pwm driver cannot guarantee a defined output level when the
PWM is disabled or when 0%/100% duty cycle is requested, because the
pin state when the clock is stopped is hardware-dependent.
Add optional GPIO and pinctrl support: when a GPIO descriptor and
pinctrl states ("default" for clock mux, "gpio" for GPIO mode) are
provided in the device tree, the driver switches the pin to GPIO mode
and drives the appropriate level for disabled/0%/100% states. For
normal PWM output, the pin is switched back to its clock function mux.
If no GPIO is provided, the driver falls back to the original
clock-only behavior.
Signed-off-by: Xilin Wu <sophon@radxa.com>
---
drivers/pwm/pwm-clk.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 66 insertions(+), 6 deletions(-)
diff --git a/drivers/pwm/pwm-clk.c b/drivers/pwm/pwm-clk.c
index f8f5af57acba..99821fae54e7 100644
--- a/drivers/pwm/pwm-clk.c
+++ b/drivers/pwm/pwm-clk.c
@@ -10,12 +10,15 @@
* Limitations:
* - Due to the fact that exact behavior depends on the underlying
* clock driver, various limitations are possible.
- * - Underlying clock may not be able to give 0% or 100% duty cycle
- * (constant off or on), exact behavior will depend on the clock.
- * - When the PWM is disabled, the clock will be disabled as well,
- * line state will depend on the clock.
* - The clk API doesn't expose the necessary calls to implement
* .get_state().
+ *
+ * Optionally, a GPIO descriptor and pinctrl states ("default" and
+ * "gpio") can be provided. When a constant output level is needed
+ * (0% duty, 100% duty, or disabled), the driver switches the pin to
+ * GPIO mode and drives the appropriate level. For normal PWM output
+ * the pin is switched back to its clock function mux. If no GPIO is
+ * provided, the driver falls back to the original clock-only behavior.
*/
#include <linux/kernel.h>
@@ -25,11 +28,17 @@
#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/clk.h>
+#include <linux/gpio/consumer.h>
+#include <linux/pinctrl/consumer.h>
#include <linux/pwm.h>
struct pwm_clk_chip {
struct clk *clk;
bool clk_enabled;
+ struct pinctrl *pinctrl;
+ struct pinctrl_state *pins_default; /* clock function mux */
+ struct pinctrl_state *pins_gpio; /* GPIO mode */
+ struct gpio_desc *gpiod;
};
static inline struct pwm_clk_chip *to_pwm_clk_chip(struct pwm_chip *chip)
@@ -45,14 +54,36 @@ static int pwm_clk_apply(struct pwm_chip *chip, struct pwm_device *pwm,
u32 rate;
u64 period = state->period;
u64 duty_cycle = state->duty_cycle;
+ bool constant_level = false;
+ int gpio_value = 0;
if (!state->enabled) {
- if (pwm->state.enabled) {
+ constant_level = true;
+ gpio_value = 0;
+ } else if (state->duty_cycle == 0) {
+ constant_level = true;
+ gpio_value = (state->polarity == PWM_POLARITY_INVERSED) ? 1 : 0;
+ } else if (state->duty_cycle >= state->period) {
+ constant_level = true;
+ gpio_value = (state->polarity == PWM_POLARITY_INVERSED) ? 0 : 1;
+ }
+
+ if (constant_level) {
+ if (pcchip->gpiod) {
+ pinctrl_select_state(pcchip->pinctrl, pcchip->pins_gpio);
+ gpiod_direction_output(pcchip->gpiod, gpio_value);
+ }
+ if (pcchip->clk_enabled) {
clk_disable(pcchip->clk);
pcchip->clk_enabled = false;
}
return 0;
- } else if (!pwm->state.enabled) {
+ }
+
+ if (pcchip->gpiod)
+ pinctrl_select_state(pcchip->pinctrl, pcchip->pins_default);
+
+ if (!pcchip->clk_enabled) {
ret = clk_enable(pcchip->clk);
if (ret)
return ret;
@@ -97,6 +128,35 @@ static int pwm_clk_probe(struct platform_device *pdev)
return dev_err_probe(&pdev->dev, PTR_ERR(pcchip->clk),
"Failed to get clock\n");
+ pcchip->pinctrl = devm_pinctrl_get(&pdev->dev);
+ if (IS_ERR(pcchip->pinctrl)) {
+ ret = PTR_ERR(pcchip->pinctrl);
+ pcchip->pinctrl = NULL;
+ if (ret == -EPROBE_DEFER)
+ return ret;
+ } else {
+ pcchip->pins_default = pinctrl_lookup_state(pcchip->pinctrl,
+ PINCTRL_STATE_DEFAULT);
+ pcchip->pins_gpio = pinctrl_lookup_state(pcchip->pinctrl,
+ "gpio");
+ if (IS_ERR(pcchip->pins_default) || IS_ERR(pcchip->pins_gpio))
+ pcchip->pinctrl = NULL;
+ }
+
+ /*
+ * Switch to GPIO pinctrl state before requesting the GPIO.
+ * The driver core has already applied the "default" state, which
+ * muxes the pin to the clock function and claims it. We must
+ * release that claim first so that gpiolib can request the pin.
+ */
+ if (pcchip->pinctrl)
+ pinctrl_select_state(pcchip->pinctrl, pcchip->pins_gpio);
+
+ pcchip->gpiod = devm_gpiod_get_optional(&pdev->dev, NULL, GPIOD_ASIS);
+ if (IS_ERR(pcchip->gpiod))
+ return dev_err_probe(&pdev->dev, PTR_ERR(pcchip->gpiod),
+ "Failed to get gpio\n");
+
chip->ops = &pwm_clk_ops;
ret = pwmchip_add(chip);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v4 1/3] dt-bindings: wireless: ath10k: Add quirk to skip host cap QMI requests
From: Jeff Johnson @ 2026-04-06 15:51 UTC (permalink / raw)
To: david, Johannes Berg, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jeff Johnson, Bjorn Andersson, Konrad Dybcio,
Paul Sajna
Cc: Amit Pundir, linux-wireless, devicetree, ath10k, linux-kernel,
linux-arm-msm, phone-devel
In-Reply-To: <20260325-skip-host-cam-qmi-req-v4-1-bc08538487aa@ixit.cz>
On 3/25/2026 10:57 AM, David Heidelberg via B4 Relay wrote:
> From: Amit Pundir <amit.pundir@linaro.org>
>
> Some firmware versions do not support the host-capability QMI request.
> Since this request occurs before firmware and board files are loaded,
> the quirk cannot be expressed in the firmware itself and must be described
> in the device tree.
>
> Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> index f2440d39b7ebc..5120b3589ab57 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> @@ -171,6 +171,12 @@ properties:
> Quirk specifying that the firmware expects the 8bit version
> of the host capability QMI request
>
> + qcom,snoc-host-cap-skip-quirk:
> + type: boolean
> + description:
> + Quirk specifying that the firmware wants to skip the host
> + capability QMI request
> +
> qcom,xo-cal-data:
> $ref: /schemas/types.yaml#/definitions/uint32
> description:
>
DT folks, there is a pending DTS series [1] that would like to reference this
capability. Would like to get an ack so I can get this in the upcoming merge
window.
Thanks,
/jeff
[1] https://lore.kernel.org/all/20260401-judyln-dts-v8-0-7677cfafbc78@postmarketos.org/
^ permalink raw reply
* Re: Devicetree spec: Specifying /cpus/cpu@* unit address format?
From: Kyle Bonnici @ 2026-04-06 16:08 UTC (permalink / raw)
To: Rob Herring
Cc: David Gibson, Vivian Wang, devicetree-spec@vger.kernel.org,
Krzysztof Kozlowski, Conor Dooley, Paul Walmsley, Palmer Dabbelt,
Alexandre Ghiti, Chen Wang, Inochi Amaoto,
devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
sophgo@lists.linux.dev
In-Reply-To: <CAL_JsqJFv3+UJ-bjLGk0i7Wc+spsowCrqQZ_s3P4gN8r1W-Q-w@mail.gmail.com>
> On 6 Apr 2026, at 14:48, Rob Herring <robh@kernel.org> wrote:
>
> On Sat, Apr 4, 2026 at 11:43 PM David Gibson
> <david@gibson.dropbear.id.au> wrote:
>>
>> On Fri, Apr 03, 2026 at 06:06:17PM +0800, Vivian Wang wrote:
>>> (Also posted at: https://github.com/devicetree-org/devicetree-specification/issues/86 )
>>>
>>> Hi all,
>>>
>>> Presently, there seems to be some confusion in the community about the
>>> format of unit addresses for "/cpus/cpu@*" nodes for a CPU with ID > 9, e.g.
>>>
>>> cpu@??? {
>>> reg = <10>;
>>> /* reg = <0xa>; */ /* This should be equivalent */
>>> }
>>>
>>>
>>> Should this be a decimal "cpu@10", or hexadecimal "cpu@a"? I can't find
>>> any explicit specification.
>>
>> It should be hex. That's a general convention for unit addresses.
>> Before flattened trees, OF essentially never used decimal
>> representations of things.
I am also of the understanding that it should be in hex.
This understanding was developed after looking at the devicetree files in
Linux kernel and Zephyr project.
However this is not well defined in the spec. In addition the spec V0.4 has other contradictions
related to the node address. See
https://github.com/devicetree-org/devicetree-specification/issues/86#issuecomment-4193317641
>
> The only decimal usage in FDT were mistakes.
>
> Rather than worrying about what the spec says, please worry about what
> the tools check. Unfortunately, this is still only checked for
> specific bus types and the default is not checked.
>
> Rob
>
^ permalink raw reply
* Re: [PATCH 2/2] pwm: clk-pwm: add GPIO and pinctrl support for constant output levels
From: Nikita Travkin @ 2026-04-06 16:20 UTC (permalink / raw)
To: Xilin Wu
Cc: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-pwm, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20260406-clk-pwm-gpio-v1-2-40d2f3a20aff@radxa.com>
Xilin Wu писал(а) 06.04.2026 20:50:
> The clk-pwm driver cannot guarantee a defined output level when the
> PWM is disabled or when 0%/100% duty cycle is requested, because the
> pin state when the clock is stopped is hardware-dependent.
>
> Add optional GPIO and pinctrl support: when a GPIO descriptor and
> pinctrl states ("default" for clock mux, "gpio" for GPIO mode) are
> provided in the device tree, the driver switches the pin to GPIO mode
> and drives the appropriate level for disabled/0%/100% states. For
> normal PWM output, the pin is switched back to its clock function mux.
>
> If no GPIO is provided, the driver falls back to the original
> clock-only behavior.
>
> Signed-off-by: Xilin Wu <sophon@radxa.com>
> ---
> drivers/pwm/pwm-clk.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++-----
> 1 file changed, 66 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/pwm/pwm-clk.c b/drivers/pwm/pwm-clk.c
> index f8f5af57acba..99821fae54e7 100644
> --- a/drivers/pwm/pwm-clk.c
> +++ b/drivers/pwm/pwm-clk.c
> @@ -10,12 +10,15 @@
> * Limitations:
> * - Due to the fact that exact behavior depends on the underlying
> * clock driver, various limitations are possible.
> - * - Underlying clock may not be able to give 0% or 100% duty cycle
> - * (constant off or on), exact behavior will depend on the clock.
> - * - When the PWM is disabled, the clock will be disabled as well,
> - * line state will depend on the clock.
nit: I think those limitations would still stand for existing
users, perhaps we could just add "... unless gpio pinctrl state
is supplied" to these two?
> * - The clk API doesn't expose the necessary calls to implement
> * .get_state().
> + *
> + * Optionally, a GPIO descriptor and pinctrl states ("default" and
> + * "gpio") can be provided. When a constant output level is needed
> + * (0% duty, 100% duty, or disabled), the driver switches the pin to
> + * GPIO mode and drives the appropriate level. For normal PWM output
> + * the pin is switched back to its clock function mux. If no GPIO is
> + * provided, the driver falls back to the original clock-only behavior.
> */
>
> #include <linux/kernel.h>
> @@ -25,11 +28,17 @@
> #include <linux/of.h>
> #include <linux/platform_device.h>
> #include <linux/clk.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/pinctrl/consumer.h>
> #include <linux/pwm.h>
>
> struct pwm_clk_chip {
> struct clk *clk;
> bool clk_enabled;
> + struct pinctrl *pinctrl;
> + struct pinctrl_state *pins_default; /* clock function mux */
> + struct pinctrl_state *pins_gpio; /* GPIO mode */
> + struct gpio_desc *gpiod;
> };
>
> static inline struct pwm_clk_chip *to_pwm_clk_chip(struct pwm_chip *chip)
> @@ -45,14 +54,36 @@ static int pwm_clk_apply(struct pwm_chip *chip, struct pwm_device *pwm,
> u32 rate;
> u64 period = state->period;
> u64 duty_cycle = state->duty_cycle;
> + bool constant_level = false;
> + int gpio_value = 0;
>
> if (!state->enabled) {
> - if (pwm->state.enabled) {
> + constant_level = true;
> + gpio_value = 0;
> + } else if (state->duty_cycle == 0) {
> + constant_level = true;
> + gpio_value = (state->polarity == PWM_POLARITY_INVERSED) ? 1 : 0;
> + } else if (state->duty_cycle >= state->period) {
> + constant_level = true;
> + gpio_value = (state->polarity == PWM_POLARITY_INVERSED) ? 0 : 1;
> + }
> +
> + if (constant_level) {
> + if (pcchip->gpiod) {
> + pinctrl_select_state(pcchip->pinctrl, pcchip->pins_gpio);
> + gpiod_direction_output(pcchip->gpiod, gpio_value);
Is this the same case as below where gpio state has to be set
before we can control it, or can we swap those so we first
put gpio into a known state and only then mux it to the pad?
Thanks for improving this driver,
Nikita
> + }
> + if (pcchip->clk_enabled) {
> clk_disable(pcchip->clk);
> pcchip->clk_enabled = false;
> }
> return 0;
> - } else if (!pwm->state.enabled) {
> + }
> +
> + if (pcchip->gpiod)
> + pinctrl_select_state(pcchip->pinctrl, pcchip->pins_default);
> +
> + if (!pcchip->clk_enabled) {
> ret = clk_enable(pcchip->clk);
> if (ret)
> return ret;
> @@ -97,6 +128,35 @@ static int pwm_clk_probe(struct platform_device *pdev)
> return dev_err_probe(&pdev->dev, PTR_ERR(pcchip->clk),
> "Failed to get clock\n");
>
> + pcchip->pinctrl = devm_pinctrl_get(&pdev->dev);
> + if (IS_ERR(pcchip->pinctrl)) {
> + ret = PTR_ERR(pcchip->pinctrl);
> + pcchip->pinctrl = NULL;
> + if (ret == -EPROBE_DEFER)
> + return ret;
> + } else {
> + pcchip->pins_default = pinctrl_lookup_state(pcchip->pinctrl,
> + PINCTRL_STATE_DEFAULT);
> + pcchip->pins_gpio = pinctrl_lookup_state(pcchip->pinctrl,
> + "gpio");
> + if (IS_ERR(pcchip->pins_default) || IS_ERR(pcchip->pins_gpio))
> + pcchip->pinctrl = NULL;
> + }
> +
> + /*
> + * Switch to GPIO pinctrl state before requesting the GPIO.
> + * The driver core has already applied the "default" state, which
> + * muxes the pin to the clock function and claims it. We must
> + * release that claim first so that gpiolib can request the pin.
> + */
> + if (pcchip->pinctrl)
> + pinctrl_select_state(pcchip->pinctrl, pcchip->pins_gpio);
> +
> + pcchip->gpiod = devm_gpiod_get_optional(&pdev->dev, NULL, GPIOD_ASIS);
> + if (IS_ERR(pcchip->gpiod))
> + return dev_err_probe(&pdev->dev, PTR_ERR(pcchip->gpiod),
> + "Failed to get gpio\n");
> +
> chip->ops = &pwm_clk_ops;
>
> ret = pwmchip_add(chip);
^ permalink raw reply
* [PATCH 0/2] Enable iface clock for kodiak and monaco ice sdhc
From: Kuldeep Singh @ 2026-04-06 16:30 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Kuldeep Singh
As ice is now standalone driver decoupled from ufs driver.
MMC ice controller should also now specify iface clock alongwith core
clock.
The patchset is motivation to fix ice mmc where ice ufs is fixed with
below series.
https://lore.kernel.org/linux-arm-msm/20260323-qcom_ice_power_and_clk_vote-v4-0-e36044bbdfe9@oss.qualcomm.com/T/#m5da5dd7a18318583b23ffeb42fa07ef1438042d5
Testing:
* dtbs check
* Custom monaco/kodiak device with emmc storage.
This series depends on the following prerequisite patchsets:
[1] Add explicit clock vote and enable power-domain for QCOM-ICE
https://lore.kernel.org/linux-arm-msm/20260323-qcom_ice_power_and_clk_vote-v4-0-e36044bbdfe9@oss.qualcomm.com
[2] Enable Inline crypto engine for kodiak and monaco
https://lore.kernel.org/lkml/20260310113557.348502-1-neeraj.soni@oss.qualcomm.com/
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
---
Kuldeep Singh (2):
arm64: dts: qcom: kodiak: Add iface clock for ice sdhc
arm64: dts: qcom: monaco: Add iface clock for ice sdhc
arch/arm64/boot/dts/qcom/kodiak.dtsi | 3 ++-
arch/arm64/boot/dts/qcom/monaco.dtsi | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
---
base-commit: 816f193dd0d95246f208590924dd962b192def78
change-id: 20260406-ice_emmc_clock_addition-e19f36c1fca5
Best regards,
--
Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
^ permalink raw reply
* [PATCH 1/2] arm64: dts: qcom: kodiak: Add iface clock for ice sdhc
From: Kuldeep Singh @ 2026-04-06 16:30 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Kuldeep Singh
In-Reply-To: <20260406-ice_emmc_clock_addition-v1-0-e7b237bf7a69@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core'
clock the 'iface' clock should also be turned on by the driver.
As bindings allow to specify 2 clocks, add iface clock now.
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kodiak.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index dda4697a61b7..5e6b659e8719 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -1082,7 +1082,8 @@ sdhc_ice: crypto@7c8000 {
compatible = "qcom,sc7280-inline-crypto-engine",
"qcom,inline-crypto-engine";
reg = <0x0 0x007c8000 0x0 0x18000>;
- clocks = <&gcc GCC_SDCC1_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_SDCC1_ICE_CORE_CLK>, <&gcc GCC_SDCC1_AHB_CLK>;
+ clock-names = "core", "iface";
};
gpi_dma0: dma-controller@900000 {
--
2.34.1
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: qcom: monaco: Add iface clock for ice sdhc
From: Kuldeep Singh @ 2026-04-06 16:30 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Kuldeep Singh
In-Reply-To: <20260406-ice_emmc_clock_addition-v1-0-e7b237bf7a69@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core'
clock the 'iface' clock should also be turned on by the driver.
As bindings allow to specify 2 clocks, add iface clock now.
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/monaco.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index 5fd289669353..e4bc1cc34097 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -4873,7 +4873,8 @@ sdhc_ice: crypto@87c8000 {
compatible = "qcom,qcs8300-inline-crypto-engine",
"qcom,inline-crypto-engine";
reg = <0x0 0x087c8000 0x0 0x18000>;
- clocks = <&gcc GCC_SDCC1_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_SDCC1_ICE_CORE_CLK>, <&gcc GCC_SDCC1_AHB_CLK>;
+ clock-names = "core", "iface";
};
usb_1_hsphy: phy@8904000 {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 2/4] clk: fsl-sai: Add i.MX8M support with 8 byte register offset
From: Brian Masney @ 2026-04-06 16:42 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-clk, Peng Fan, Conor Dooley, Krzysztof Kozlowski,
Michael Turquette, Michael Walle, Rob Herring, Stephen Boyd,
devicetree, linux-kernel
In-Reply-To: <20260404183419.46455-2-marex@nabladev.com>
On Sat, Apr 04, 2026 at 08:33:26PM +0200, Marek Vasut wrote:
> The i.MX8M/Mini/Nano/Plus variant of the SAI IP has control registers
> shifted by +8 bytes and requires additional bus clock. Add support for
> the i.MX8M variant of the IP with this register shift and additional
> clock.
>
> Reviewed-by: Peng Fan <peng.fan@nxp.com>
> Signed-off-by: Marek Vasut <marex@nabladev.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
^ permalink raw reply
* Re: [PATCH] dt-bindings: thermal: idle: Correct node name in the example
From: Rob Herring (Arm) @ 2026-04-06 16:51 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Daniel Lezcano, Conor Dooley, Krzysztof Kozlowski,
Rafael J. Wysocki, linux-kernel, linux-pm, Zhang Rui, Lukasz Luba,
devicetree
In-Reply-To: <20260406145104.36472-2-krzysztof.kozlowski@oss.qualcomm.com>
On Mon, 06 Apr 2026 16:51:05 +0200, Krzysztof Kozlowski wrote:
> Thermal bindings expect the node name with all the zones to be named
> 'thermal-zones' (hyphen instead of underscore) and also DTS coding style
> is not to use underscores for node names, so adjust the example code.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/thermal/thermal-idle.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/thermal/thermal-idle.example.dtb: thermal-zones: 'cpu' does not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-]{1,10}-thermal$', '^pinctrl-[0-9]+$'
from schema $id: http://devicetree.org/schemas/thermal/thermal-zones.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260406145104.36472-2-krzysztof.kozlowski@oss.qualcomm.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v3 4/4] clk: fsl-sai: Add MCLK generation support
From: Brian Masney @ 2026-04-06 17:10 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-clk, Michael Walle, Conor Dooley, Krzysztof Kozlowski,
Michael Turquette, Michael Walle, Rob Herring, Stephen Boyd,
devicetree, linux-kernel
In-Reply-To: <20260404183419.46455-4-marex@nabladev.com>
Hi Marek,
On Sat, Apr 04, 2026 at 08:33:28PM +0200, Marek Vasut wrote:
> The driver currently supports generating BCLK. There are systems which
> require generation of MCLK instead. Register new MCLK clock and handle
> clock-cells = <1> to differentiate between BCLK and MCLK. In case of a
> legacy system with clock-cells = <0>, the driver behaves as before, i.e.
> always returns BCLK.
>
> Note that it is not possible re-use the current SAI audio driver to
> generate MCLK and correctly enable and disable the MCLK.
>
> If SAI (audio driver) is used to control the MCLK enablement, then MCLK
> clock is not always enabled, and it is not necessarily enabled when the
> codec may need the clock to be enabled. There is also no way for the
> codec node to specify phandle to clock provider in DT, because the SAI
> (audio driver) is not clock provider.
>
> If SAI (clock driver) is used to control the MCLK enablement, then MCLK
> clock is enabled when the codec needs the clock enabled, because the
> codec is the clock consumer and the SAI (clock driver) is the clock
> provider, and the codec driver can request the clock to be enabled when
> needed. There is also the usual phandle to clock provider in DT, because
> the SAI (clock driver) is clock provider.
>
> Acked-by: Michael Walle <mwalle@kernel.org>
> Signed-off-by: Marek Vasut <marex@nabladev.com>
> ---
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Michael Walle <michael@walle.cc>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-clk@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> V2: No change
> V3: - Rebase on current next, update mail address
> - Update commit message according to clarify the difference between
> SAI audio and SAI clock driver
> - Pick ancient AB from Michael, although this may be outdated
> https://patchwork.kernel.org/project/alsa-devel/patch/20241226162234.40141-4-marex@denx.de/
> ---
> drivers/clk/clk-fsl-sai.c | 74 ++++++++++++++++++++++++++++++++-------
> 1 file changed, 61 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/clk/clk-fsl-sai.c b/drivers/clk/clk-fsl-sai.c
> index 336aa8477d0ea..f00b49edb2e9f 100644
> --- a/drivers/clk/clk-fsl-sai.c
> +++ b/drivers/clk/clk-fsl-sai.c
> @@ -7,6 +7,7 @@
>
> #include <linux/module.h>
> #include <linux/platform_device.h>
> +#include <linux/clk.h>
> #include <linux/clk-provider.h>
> #include <linux/err.h>
> #include <linux/of.h>
Since changes are being made here, could the includes be sorted in a
separate patch?
> @@ -15,21 +16,37 @@
>
> #define I2S_CSR 0x00
> #define I2S_CR2 0x08
> +#define I2S_MCR 0x100
> #define CSR_BCE_BIT 28
> +#define CSR_TE_BIT 31
> #define CR2_BCD BIT(24)
> #define CR2_DIV_SHIFT 0
> #define CR2_DIV_WIDTH 8
> +#define MCR_MOE BIT(30)
>
> struct fsl_sai_clk {
> - struct clk_divider div;
> - struct clk_gate gate;
> + struct clk_divider bclk_div;
> + struct clk_divider mclk_div;
> + struct clk_gate bclk_gate;
> + struct clk_gate mclk_gate;
> + struct clk_hw *bclk_hw;
> + struct clk_hw *mclk_hw;
> spinlock_t lock;
> };
>
> struct fsl_sai_data {
> unsigned int offset; /* Register offset */
> + bool have_mclk; /* Have MCLK control */
> };
>
> +static struct clk_hw *
> +fsl_sai_of_clk_get(struct of_phandle_args *clkspec, void *data)
> +{
> + struct fsl_sai_clk *sai_clk = data;
> +
> + return clkspec->args[0] ? sai_clk->mclk_hw : sai_clk->bclk_hw;
> +}
> +
> static int fsl_sai_clk_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> @@ -54,37 +71,68 @@ static int fsl_sai_clk_probe(struct platform_device *pdev)
>
> spin_lock_init(&sai_clk->lock);
>
> - sai_clk->gate.reg = base + data->offset + I2S_CSR;
> - sai_clk->gate.bit_idx = CSR_BCE_BIT;
> - sai_clk->gate.lock = &sai_clk->lock;
> + sai_clk->bclk_gate.reg = base + data->offset + I2S_CSR;
> + sai_clk->bclk_gate.bit_idx = CSR_BCE_BIT;
> + sai_clk->bclk_gate.lock = &sai_clk->lock;
>
> - sai_clk->div.reg = base + data->offset + I2S_CR2;
> - sai_clk->div.shift = CR2_DIV_SHIFT;
> - sai_clk->div.width = CR2_DIV_WIDTH;
> - sai_clk->div.lock = &sai_clk->lock;
> + sai_clk->bclk_div.reg = base + data->offset + I2S_CR2;
> + sai_clk->bclk_div.shift = CR2_DIV_SHIFT;
> + sai_clk->bclk_div.width = CR2_DIV_WIDTH;
> + sai_clk->bclk_div.lock = &sai_clk->lock;
>
> /* set clock direction, we are the BCLK master */
> writel(CR2_BCD, base + data->offset + I2S_CR2);
>
> - hw = devm_clk_hw_register_composite_pdata(dev, dev->of_node->name,
> + hw = devm_clk_hw_register_composite_pdata(dev, "BCLK",
Will there ever be multiple instances of this IP block on a system? If
so, the hardcoded BCLK and MCLK clk names will collide.
> &pdata, 1, NULL, NULL,
> - &sai_clk->div.hw,
> + &sai_clk->bclk_div.hw,
> &clk_divider_ops,
> - &sai_clk->gate.hw,
> + &sai_clk->bclk_gate.hw,
> &clk_gate_ops,
> CLK_SET_RATE_GATE);
> if (IS_ERR(hw))
> return PTR_ERR(hw);
>
> - return devm_of_clk_add_hw_provider(dev, of_clk_hw_simple_get, hw);
> + sai_clk->bclk_hw = hw;
> +
> + if (data->have_mclk) {
> + sai_clk->mclk_gate.reg = base + data->offset + I2S_CSR;
> + sai_clk->mclk_gate.bit_idx = CSR_TE_BIT;
> + sai_clk->mclk_gate.lock = &sai_clk->lock;
> +
> + sai_clk->mclk_div.reg = base + I2S_MCR;
> + sai_clk->mclk_div.shift = CR2_DIV_SHIFT;
> + sai_clk->mclk_div.width = CR2_DIV_WIDTH;
> + sai_clk->mclk_div.lock = &sai_clk->lock;
> +
> + pdata.index = 1; /* MCLK1 */
> + hw = devm_clk_hw_register_composite_pdata(dev, "MCLK",
> + &pdata, 1, NULL, NULL,
> + &sai_clk->mclk_div.hw,
> + &clk_divider_ops,
> + &sai_clk->mclk_gate.hw,
> + &clk_gate_ops,
> + CLK_SET_RATE_GATE);
> + if (IS_ERR(hw))
> + return PTR_ERR(hw);
> +
> + sai_clk->mclk_hw = hw;
This section is basically a copy/paste of the bclk from above, with a
few minor changes (bclk renamed to mclk, different gate and div regs,
and a different base offset). What do you think about mostly keeping
struct fsl_sai_clk with the same names, and add a new helper to do
the registrations?
Brian
> +
> + /* set clock direction, we are the MCLK output */
> + writel(MCR_MOE, base + I2S_MCR);
> + }
> +
> + return devm_of_clk_add_hw_provider(dev, fsl_sai_of_clk_get, sai_clk);
> }
>
> static const struct fsl_sai_data fsl_sai_vf610_data = {
> .offset = 0,
> + .have_mclk = false,
> };
>
> static const struct fsl_sai_data fsl_sai_imx8mq_data = {
> .offset = 8,
> + .have_mclk = true,
> };
>
> static const struct of_device_id of_fsl_sai_clk_ids[] = {
> --
> 2.53.0
>
^ permalink raw reply
* [PATCH v3 0/3] Add USB support for Kaanapali
From: Krishna Kurapati @ 2026-04-06 17:46 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Krishna Kurapati
Add support for the PHYs and controllers used for USB on Kaanapali SoCs.
V1 of this was a consolidated series of many functionlities on Kaanapali.
The first patch is patch-6 from v1 unchanges. The second and third patches
are parts of MTP and QRD specific changes (patches 14 and 16) and commit
text modified to indicate mtp and qrd specific changes are being made.
Ronak is the original author of the patches. Kept Jingyi's and mine SoB
(with no CDB) since we just rebased and send the patches in v1 and v2.
SoCCP changes [1]/[2] are needed to get ChargerFW running and receive role
notificaitons and enable vbus to test host mode. Since the SoCCP changes
are not yet acked, I enabled only device mode for now.
Changes in v3:
- Fixed repeater label in platform files
- Fixed commit text in cover letter
Link to v2:
https://lore.kernel.org/all/20260329175249.2946508-1-krishna.kurapati@oss.qualcomm.com/
Changes in v2:
- Sent USB specific changes instead of all MTP and QRD specific changes
Link to v1:
https://lore.kernel.org/all/20250924-knp-dts-v1-0-3fdbc4b9e1b1@oss.qualcomm.com/
[1]: https://lore.kernel.org/all/20260310-knp-soccp-v4-0-0a91575e0e7e@oss.qualcomm.com/
[2]: https://lore.kernel.org/all/20260326-knp-soccp-dt-v1-0-a60c2ae36e9b@oss.qualcomm.com/
Ronak Raheja (3):
arm64: dts: qcom: kaanapali: Add USB support for Kaanapali SoC
arm64: dts: qcom: kaanpaali: Add USB support for MTP platform
arm64: dts: qcom: kaanpaali: Add USB support for QRD platform
arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 27 ++++
arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 27 ++++
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 154 +++++++++++++++++++++
3 files changed, 208 insertions(+)
--
2.34.1
^ permalink raw reply
* [PATCH v3 1/3] arm64: dts: qcom: kaanapali: Add USB support for Kaanapali SoC
From: Krishna Kurapati @ 2026-04-06 17:46 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Ronak Raheja,
Jingyi Wang, Krishna Kurapati
In-Reply-To: <20260406174613.3388987-1-krishna.kurapati@oss.qualcomm.com>
From: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
Add the base USB devicetree definitions for Kaanapali platform. The overall
chipset contains a single DWC3 USB3 controller (rev. 200a), SS QMP PHY
(rev. v8) and M31 eUSB2 PHY.
Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 154 ++++++++++++++++++++++++
1 file changed, 154 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 7cc326aa1a1a..bab654bbd6d0 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -3138,6 +3138,77 @@ opp-202000000 {
};
};
+ usb_hsphy: phy@88e3000 {
+ compatible = "qcom,kaanapali-m31-eusb2-phy",
+ "qcom,sm8750-m31-eusb2-phy";
+ reg = <0x0 0x88e3000 0x0 0x29c>;
+
+ clocks = <&tcsr TCSR_USB2_CLKREF_EN>;
+ clock-names = "ref";
+
+ resets = <&gcc GCC_QUSB2PHY_PRIM_BCR>;
+
+ #phy-cells = <0>;
+
+ status = "disabled";
+ };
+
+ usb_dp_qmpphy: phy@88e8000 {
+ compatible = "qcom,kaanapali-qmp-usb3-dp-phy",
+ "qcom,sm8750-qmp-usb3-dp-phy";
+ reg = <0x0 0x088e8000 0x0 0x4000>;
+
+ clocks = <&gcc GCC_USB3_PRIM_PHY_AUX_CLK>,
+ <&tcsr TCSR_USB3_CLKREF_EN>,
+ <&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>,
+ <&gcc GCC_USB3_PRIM_PHY_PIPE_CLK>;
+ clock-names = "aux",
+ "ref",
+ "com_aux",
+ "usb3_pipe";
+
+ resets = <&gcc GCC_USB3_PHY_PRIM_BCR>,
+ <&gcc GCC_USB3_DP_PHY_PRIM_BCR>;
+ reset-names = "phy",
+ "common";
+
+ power-domains = <&gcc GCC_USB3_PHY_GDSC>;
+
+ #clock-cells = <1>;
+ #phy-cells = <1>;
+
+ orientation-switch;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ usb_dp_qmpphy_out: endpoint {
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ usb_dp_qmpphy_usb_ss_in: endpoint {
+ remote-endpoint = <&usb_dwc3_ss>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ usb_dp_qmpphy_dp_in: endpoint {
+ };
+ };
+ };
+ };
+
camcc: clock-controller@956d000 {
compatible = "qcom,kaanapali-camcc";
reg = <0x0 0x0956d000 0x0 0x80000>;
@@ -3422,6 +3493,89 @@ dispcc: clock-controller@9ba2000 {
#reset-cells = <1>;
};
+ usb: usb@a600000 {
+ compatible = "qcom,kaanapali-dwc3", "qcom,snps-dwc3";
+ reg = <0x0 0x0a600000 0x0 0xfc100>;
+
+ clocks = <&gcc GCC_CFG_NOC_USB3_PRIM_AXI_CLK>,
+ <&gcc GCC_USB30_PRIM_MASTER_CLK>,
+ <&gcc GCC_AGGRE_USB3_PRIM_AXI_CLK>,
+ <&gcc GCC_USB30_PRIM_SLEEP_CLK>,
+ <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>;
+ clock-names = "cfg_noc",
+ "core",
+ "iface",
+ "sleep",
+ "mock_utmi";
+
+ assigned-clocks = <&gcc GCC_USB30_PRIM_MOCK_UTMI_CLK>,
+ <&gcc GCC_USB30_PRIM_MASTER_CLK>;
+ assigned-clock-rates = <19200000>, <200000000>;
+
+ interrupts-extended = <&intc GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>,
+ <&intc GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>,
+ <&intc GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>,
+ <&pdc 14 IRQ_TYPE_EDGE_BOTH>,
+ <&pdc 15 IRQ_TYPE_EDGE_BOTH>,
+ <&pdc 17 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "dwc_usb3",
+ "pwr_event",
+ "hs_phy_irq",
+ "dp_hs_phy_irq",
+ "dm_hs_phy_irq",
+ "ss_phy_irq";
+
+ power-domains = <&gcc GCC_USB30_PRIM_GDSC>;
+ required-opps = <&rpmhpd_opp_nom>;
+
+ resets = <&gcc GCC_USB30_PRIM_BCR>;
+
+ interconnects = <&aggre_noc MASTER_USB3 QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &config_noc SLAVE_USB3 QCOM_ICC_TAG_ACTIVE_ONLY>;
+ interconnect-names = "usb-ddr", "apps-usb";
+ iommus = <&apps_smmu 0x40 0x0>;
+
+ phys = <&usb_hsphy>, <&usb_dp_qmpphy QMP_USB43DP_USB3_PHY>;
+ phy-names = "usb2-phy", "usb3-phy";
+
+ snps,hird-threshold = /bits/ 8 <0x0>;
+ snps,usb2-gadget-lpm-disable;
+ snps,dis_u2_susphy_quirk;
+ snps,dis_enblslpm_quirk;
+ snps,dis-u1-entry-quirk;
+ snps,dis-u2-entry-quirk;
+ snps,is-utmi-l1-suspend;
+ snps,usb3_lpm_capable;
+ snps,usb2-lpm-disable;
+ snps,has-lpm-erratum;
+ tx-fifo-resize;
+ dma-coherent;
+
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ usb_dwc3_hs: endpoint {
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ usb_dwc3_ss: endpoint {
+ remote-endpoint = <&usb_dp_qmpphy_usb_ss_in>;
+ };
+ };
+ };
+ };
+
pdc: interrupt-controller@b220000 {
compatible = "qcom,kaanapali-pdc", "qcom,pdc";
reg = <0x0 0x0b220000 0x0 0x10000>,
--
2.34.1
^ permalink raw reply related
* [PATCH v3 2/3] arm64: dts: qcom: kaanpaali: Add USB support for MTP platform
From: Krishna Kurapati @ 2026-04-06 17:46 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Ronak Raheja,
Jingyi Wang, Krishna Kurapati
In-Reply-To: <20260406174613.3388987-1-krishna.kurapati@oss.qualcomm.com>
From: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
Enable USB support on Kaanapali MTP variant. Enable USB controller in
device mode till glink node is added.
Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 27 ++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
index 07247dc98b70..f9b5b5718b90 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
+++ b/arch/arm64/boot/dts/qcom/kaanapali-mtp.dts
@@ -952,6 +952,11 @@ wifi@0 {
};
};
+&pmih0108_e1_eusb2_repeater {
+ vdd18-supply = <&vreg_l15b_1p8>;
+ vdd3-supply = <&vreg_l5b_3p1>;
+};
+
&pmh0101_flash {
status = "okay";
@@ -1321,3 +1326,25 @@ &ufs_mem_phy {
status = "okay";
};
+
+&usb {
+ dr_mode = "peripheral";
+
+ status = "okay";
+};
+
+&usb_hsphy {
+ vdd-supply = <&vreg_l4f_0p8>;
+ vdda12-supply = <&vreg_l1d_1p2>;
+
+ phys = <&pmih0108_e1_eusb2_repeater>;
+
+ status = "okay";
+};
+
+&usb_dp_qmpphy {
+ vdda-phy-supply = <&vreg_l1d_1p2>;
+ vdda-pll-supply = <&vreg_l4f_0p8>;
+
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v3 3/3] arm64: dts: qcom: kaanpaali: Add USB support for QRD platform
From: Krishna Kurapati @ 2026-04-06 17:46 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Ronak Raheja,
Jingyi Wang, Krishna Kurapati
In-Reply-To: <20260406174613.3388987-1-krishna.kurapati@oss.qualcomm.com>
From: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
Enable USB support on Kaanapali QRD variant. Enable USB controller in
device mode till glink node is added.
Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 27 ++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts b/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
index da0e8f9091c3..55d02219ef4e 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
+++ b/arch/arm64/boot/dts/qcom/kaanapali-qrd.dts
@@ -744,6 +744,11 @@ led@3 {
};
};
+&pmih0108_e1_eusb2_repeater {
+ vdd18-supply = <&vreg_l15b_1p8>;
+ vdd3-supply = <&vreg_l5b_3p1>;
+};
+
&pon_resin {
linux,code = <KEY_VOLUMEDOWN>;
@@ -816,3 +821,25 @@ &ufs_mem_phy {
status = "okay";
};
+
+&usb {
+ dr_mode = "peripheral";
+
+ status = "okay";
+};
+
+&usb_hsphy {
+ vdd-supply = <&vreg_l4f_0p8>;
+ vdda12-supply = <&vreg_l1d_1p2>;
+
+ phys = <&pmih0108_e1_eusb2_repeater>;
+
+ status = "okay";
+};
+
+&usb_dp_qmpphy {
+ vdda-phy-supply = <&vreg_l1d_1p2>;
+ vdda-pll-supply = <&vreg_l4f_0p8>;
+
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 1/3] arm64: dts: qcom: kaanapali: Add USB support for Kaanapali SoC
From: Krishna Kurapati @ 2026-04-06 17:52 UTC (permalink / raw)
To: Konrad Dybcio
Cc: linux-arm-msm, devicetree, Konrad Dybcio, Bjorn Andersson,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-kernel,
Ronak Raheja, Jingyi Wang
In-Reply-To: <f971b7d9-8e88-446f-ac93-c3506bca83bb@oss.qualcomm.com>
On 3/30/2026 2:48 PM, Konrad Dybcio wrote:
> On 3/29/26 7:52 PM, Krishna Kurapati wrote:
>> From: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
>>
>> Add the base USB devicetree definitions for Kaanapali platform. The overall
>> chipset contains a single DWC3 USB3 controller (rev. 200a), SS QMP PHY
>> (rev. v8) and M31 eUSB2 PHY.
>>
>> Signed-off-by: Ronak Raheja <ronak.raheja@oss.qualcomm.com>
>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
>> Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
>> ---
>
> [...]
>
>> + usb: usb@a600000 {
>> + compatible = "qcom,kaanapali-dwc3", "qcom,snps-dwc3";
>> + reg = <0x0 0x0a600000 0x0 0xfc100>;
>
> Following the woes on Hamoa, can the platform suspend and wake up
> succesfully with the flattened DT node?
>
There is a crash on resume when I tested but it comes up even without my
changes:
[ 65.263890] Call trace:
[ 65.266489] kthreads_update_affinity+0x94/0x158 (P)
[ 65.271664] kthreads_online_cpu+0x14/0x84
[ 65.275951] cpuhp_invoke_callback+0xdc/0x1dc
[ 65.280514] cpuhp_thread_fun+0x11c/0x168
[ 65.284717] smpboot_thread_fn+0x1e4/0x24c
[ 65.289019] kthread+0x104/0x124
[ 65.292411] ret_from_fork+0x10/0x20
[ 65.296156] Code: f94002f7 eb1602ff 540003a0 f85f82e8 (b9402d09)
[ 65.302490] ---[ end trace 0000000000000000 ]---
Hence I believe my changes are not causing any crash.
Regards,
Krishna,
^ permalink raw reply
* [PATCH v4 0/6] phy: realtek: usb2: support for RTL9607C USB2 PHY
From: Rustam Adilov @ 2026-04-06 18:12 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stanley Chang, linux-phy, devicetree, linux-kernel
Cc: Rustam Adilov
This patch series for Realtek USB2 PHY driver adds support for RTL9607C
USB2 PHY.
RTL9607C is a big endian MIPS CPU which is quite far from RTD series SoCs
supported by realtek usb2 phy driver, but the phy initilization is found
to be very indentical in most areas.
Most of the code was based on the Realtek's usb driver from the GPL tarball
in [1] and adjusted to fit into the realtek usb2 phy driver code format.
The patch series was split into smaller patches that add/change something
in the driver that are not exactly related to RTL9607C and that also
helps for easier review. That also means, patch 5 depends on all the prior
patches that come before it.
USB2 PHY on RTL9607C is primarly used for its internal OHCI/EHCI controllers.
[1] - https://github.com/jameywine/GPL-for-GP3000/blob/main/linux-5.10.x/arch/mips/rtl9607c/usb.c
---
Changelog in v4:
- Patch 2
- moved the le variations of read/write functions to Patch 5 where it is actually used because
otherwise, it results in unused errors when only Patch 2 is applied.
- updated the commit message to to point the reason for le32 wrappers around readl/writel.
- Patch 3
- added "Reviewed by Krzysztof Kozlowski"
- Patch 5
- updated the commit message to include the addition of little endian read/write functions from
Patch 2.
- Link to v3: https://lore.kernel.org/linux-phy/20260402154414.196012-1-adilov@disroot.org/
Changelog in v3:
- Patch 2
- renamed phy read and functions to "rtk_usb2phy" to not collide with networking API functions
- fixed the sparse warnings by creating intermidiate "tmp" variable and then pass it to writel
- sligtly adjusted commit message to instead use "default read" not "default phy_read"
- Patch 4
- added the check for reset_control_deassert() just in case
- changed mdelay(5) to msleep(5)
- changed dev_err and return combo with one dev_err_probe for phy_rst
- Patch 5
- changed mdelay(10) under force_host_disconnect to msleep(10)
- removed struct fields with false like force_host_disconnect and more in rtl9607_phy_cfg
- Patch 6
- updated the #endif commend to now include MACH_REALTEK_RTL to reflect if on top
- Link to v2: https://lore.kernel.org/linux-phy/20260327160638.15134-1-adilov@disroot.org/
Changelog in v2:
- Patch 3
- removed the line about OHCI/EHCI controllers from description.
- set the resets to false for RTD SoC devices and changed the
commit message to reflect that.
- Link to v1: https://lore.kernel.org/linux-phy/20260326193419.48419-1-adilov@disroot.org/
Rustam Adilov (6):
phy: realtek: usb2: introduce vstatus/new_reg_req variables to driver
data
phy: realtek: usb2: introduce read and write functions to driver data
dt-bindings: phy: realtek,usb2phy.yaml: extend for resets and RTL9607C
support
phy: realtek: usb2: introduce reset controller struct
phy: realtek: usb2: add support for RTL9607C USB2 PHY
phy: realtek: Make configs available for MACH_REALTEK_RTL
.../bindings/phy/realtek,usb2phy.yaml | 25 ++-
drivers/phy/realtek/Kconfig | 4 +-
drivers/phy/realtek/phy-rtk-usb2.c | 183 ++++++++++++++++--
3 files changed, 191 insertions(+), 21 deletions(-)
--
2.53.0
^ permalink raw reply
* [PATCH v4 1/6] phy: realtek: usb2: introduce vstatus/new_reg_req variables to driver data
From: Rustam Adilov @ 2026-04-06 18:12 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stanley Chang, linux-phy, devicetree, linux-kernel
Cc: Rustam Adilov, Michael Zavertkin
In-Reply-To: <20260406181228.25892-1-adilov@disroot.org>
In RTL9607C SoC, the vstatus register is located at a certain offset from
the base and so introduce the vstatus_offset to handle it.
Busy bit of the vstatus and new_reg_req bit are also different and so
introduce these variables to the driver data as well.
Add these variables to the pre-existing phy cfg structs for RTD SoCs and
assign them the default values.
Co-developed-by: Michael Zavertkin <misha.zavertkin@mail.ru>
Signed-off-by: Michael Zavertkin <misha.zavertkin@mail.ru>
Signed-off-by: Rustam Adilov <adilov@disroot.org>
---
drivers/phy/realtek/phy-rtk-usb2.c | 59 ++++++++++++++++++++++++------
1 file changed, 48 insertions(+), 11 deletions(-)
diff --git a/drivers/phy/realtek/phy-rtk-usb2.c b/drivers/phy/realtek/phy-rtk-usb2.c
index 248550ef98ca..f5d2f0c3376a 100644
--- a/drivers/phy/realtek/phy-rtk-usb2.c
+++ b/drivers/phy/realtek/phy-rtk-usb2.c
@@ -64,6 +64,9 @@ struct phy_reg {
void __iomem *reg_wrap_vstatus;
void __iomem *reg_gusb2phyacc0;
int vstatus_index;
+ int vstatus_offset;
+ int vstatus_busy;
+ int new_reg_req;
};
struct phy_data {
@@ -96,6 +99,9 @@ struct phy_cfg {
bool do_toggle_driving;
bool use_default_parameter;
bool is_double_sensitivity_mode;
+ int vstatus_offset;
+ int vstatus_busy;
+ int new_reg_req;
};
struct phy_parameter {
@@ -162,21 +168,21 @@ static char rtk_phy_read(struct phy_reg *phy_reg, char addr)
addr -= OFFEST_PHY_READ;
/* polling until VBusy == 0 */
- ret = utmi_wait_register(reg_gusb2phyacc0, PHY_VSTS_BUSY, 0);
+ ret = utmi_wait_register(reg_gusb2phyacc0, phy_reg->vstatus_busy, 0);
if (ret)
return (char)ret;
/* VCtrl = low nibble of addr, and set PHY_NEW_REG_REQ */
- val = PHY_NEW_REG_REQ | (GET_LOW_NIBBLE(addr) << PHY_VCTRL_SHIFT);
+ val = phy_reg->new_reg_req | (GET_LOW_NIBBLE(addr) << PHY_VCTRL_SHIFT);
writel(val, reg_gusb2phyacc0);
- ret = utmi_wait_register(reg_gusb2phyacc0, PHY_VSTS_BUSY, 0);
+ ret = utmi_wait_register(reg_gusb2phyacc0, phy_reg->vstatus_busy, 0);
if (ret)
return (char)ret;
/* VCtrl = high nibble of addr, and set PHY_NEW_REG_REQ */
- val = PHY_NEW_REG_REQ | (GET_HIGH_NIBBLE(addr) << PHY_VCTRL_SHIFT);
+ val = phy_reg->new_reg_req | (GET_HIGH_NIBBLE(addr) << PHY_VCTRL_SHIFT);
writel(val, reg_gusb2phyacc0);
- ret = utmi_wait_register(reg_gusb2phyacc0, PHY_VSTS_BUSY, 0);
+ ret = utmi_wait_register(reg_gusb2phyacc0, phy_reg->vstatus_busy, 0);
if (ret)
return (char)ret;
@@ -194,25 +200,25 @@ static int rtk_phy_write(struct phy_reg *phy_reg, char addr, char data)
int ret = 0;
/* write data to VStatusOut2 (data output to phy) */
- writel((u32)data << shift_bits, reg_wrap_vstatus);
+ writel((u32)data << shift_bits, reg_wrap_vstatus + phy_reg->vstatus_offset);
- ret = utmi_wait_register(reg_gusb2phyacc0, PHY_VSTS_BUSY, 0);
+ ret = utmi_wait_register(reg_gusb2phyacc0, phy_reg->vstatus_busy, 0);
if (ret)
return ret;
/* VCtrl = low nibble of addr, set PHY_NEW_REG_REQ */
- val = PHY_NEW_REG_REQ | (GET_LOW_NIBBLE(addr) << PHY_VCTRL_SHIFT);
+ val = phy_reg->new_reg_req | (GET_LOW_NIBBLE(addr) << PHY_VCTRL_SHIFT);
writel(val, reg_gusb2phyacc0);
- ret = utmi_wait_register(reg_gusb2phyacc0, PHY_VSTS_BUSY, 0);
+ ret = utmi_wait_register(reg_gusb2phyacc0, phy_reg->vstatus_busy, 0);
if (ret)
return ret;
/* VCtrl = high nibble of addr, set PHY_NEW_REG_REQ */
- val = PHY_NEW_REG_REQ | (GET_HIGH_NIBBLE(addr) << PHY_VCTRL_SHIFT);
+ val = phy_reg->new_reg_req | (GET_HIGH_NIBBLE(addr) << PHY_VCTRL_SHIFT);
writel(val, reg_gusb2phyacc0);
- ret = utmi_wait_register(reg_gusb2phyacc0, PHY_VSTS_BUSY, 0);
+ ret = utmi_wait_register(reg_gusb2phyacc0, phy_reg->vstatus_busy, 0);
if (ret)
return ret;
@@ -957,6 +963,7 @@ static int get_phy_data_by_efuse(struct rtk_phy *rtk_phy,
static int parse_phy_data(struct rtk_phy *rtk_phy)
{
+ struct phy_cfg *phy_cfg = rtk_phy->phy_cfg;
struct device *dev = rtk_phy->dev;
struct device_node *np = dev->of_node;
struct phy_parameter *phy_parameter;
@@ -974,6 +981,9 @@ static int parse_phy_data(struct rtk_phy *rtk_phy)
phy_parameter->phy_reg.reg_wrap_vstatus = of_iomap(np, 0);
phy_parameter->phy_reg.reg_gusb2phyacc0 = of_iomap(np, 1) + index;
phy_parameter->phy_reg.vstatus_index = index;
+ phy_parameter->phy_reg.vstatus_offset = phy_cfg->vstatus_offset;
+ phy_parameter->phy_reg.vstatus_busy = phy_cfg->vstatus_busy;
+ phy_parameter->phy_reg.new_reg_req = phy_cfg->new_reg_req;
if (of_property_read_bool(np, "realtek,inverse-hstx-sync-clock"))
phy_parameter->inverse_hstx_sync_clock = true;
@@ -1085,6 +1095,9 @@ static const struct phy_cfg rtd1295_phy_cfg = {
.driving_updated_for_dev_dis = 0xf,
.use_default_parameter = false,
.is_double_sensitivity_mode = false,
+ .vstatus_offset = 0,
+ .vstatus_busy = PHY_VSTS_BUSY,
+ .new_reg_req = PHY_NEW_REG_REQ,
};
static const struct phy_cfg rtd1395_phy_cfg = {
@@ -1109,6 +1122,9 @@ static const struct phy_cfg rtd1395_phy_cfg = {
.driving_updated_for_dev_dis = 0xf,
.use_default_parameter = false,
.is_double_sensitivity_mode = false,
+ .vstatus_offset = 0,
+ .vstatus_busy = PHY_VSTS_BUSY,
+ .new_reg_req = PHY_NEW_REG_REQ,
};
static const struct phy_cfg rtd1395_phy_cfg_2port = {
@@ -1133,6 +1149,9 @@ static const struct phy_cfg rtd1395_phy_cfg_2port = {
.driving_updated_for_dev_dis = 0xf,
.use_default_parameter = false,
.is_double_sensitivity_mode = false,
+ .vstatus_offset = 0,
+ .vstatus_busy = PHY_VSTS_BUSY,
+ .new_reg_req = PHY_NEW_REG_REQ,
};
static const struct phy_cfg rtd1619_phy_cfg = {
@@ -1155,6 +1174,9 @@ static const struct phy_cfg rtd1619_phy_cfg = {
.driving_updated_for_dev_dis = 0xf,
.use_default_parameter = false,
.is_double_sensitivity_mode = false,
+ .vstatus_offset = 0,
+ .vstatus_busy = PHY_VSTS_BUSY,
+ .new_reg_req = PHY_NEW_REG_REQ,
};
static const struct phy_cfg rtd1319_phy_cfg = {
@@ -1181,6 +1203,9 @@ static const struct phy_cfg rtd1319_phy_cfg = {
.driving_updated_for_dev_dis = 0xf,
.use_default_parameter = false,
.is_double_sensitivity_mode = true,
+ .vstatus_offset = 0,
+ .vstatus_busy = PHY_VSTS_BUSY,
+ .new_reg_req = PHY_NEW_REG_REQ,
};
static const struct phy_cfg rtd1312c_phy_cfg = {
@@ -1206,6 +1231,9 @@ static const struct phy_cfg rtd1312c_phy_cfg = {
.driving_updated_for_dev_dis = 0xf,
.use_default_parameter = false,
.is_double_sensitivity_mode = true,
+ .vstatus_offset = 0,
+ .vstatus_busy = PHY_VSTS_BUSY,
+ .new_reg_req = PHY_NEW_REG_REQ,
};
static const struct phy_cfg rtd1619b_phy_cfg = {
@@ -1231,6 +1259,9 @@ static const struct phy_cfg rtd1619b_phy_cfg = {
.driving_updated_for_dev_dis = 0x8,
.use_default_parameter = false,
.is_double_sensitivity_mode = true,
+ .vstatus_offset = 0,
+ .vstatus_busy = PHY_VSTS_BUSY,
+ .new_reg_req = PHY_NEW_REG_REQ,
};
static const struct phy_cfg rtd1319d_phy_cfg = {
@@ -1256,6 +1287,9 @@ static const struct phy_cfg rtd1319d_phy_cfg = {
.driving_updated_for_dev_dis = 0x8,
.use_default_parameter = false,
.is_double_sensitivity_mode = true,
+ .vstatus_offset = 0,
+ .vstatus_busy = PHY_VSTS_BUSY,
+ .new_reg_req = PHY_NEW_REG_REQ,
};
static const struct phy_cfg rtd1315e_phy_cfg = {
@@ -1282,6 +1316,9 @@ static const struct phy_cfg rtd1315e_phy_cfg = {
.driving_updated_for_dev_dis = 0x8,
.use_default_parameter = false,
.is_double_sensitivity_mode = true,
+ .vstatus_offset = 0,
+ .vstatus_busy = PHY_VSTS_BUSY,
+ .new_reg_req = PHY_NEW_REG_REQ,
};
static const struct of_device_id usbphy_rtk_dt_match[] = {
--
2.53.0
^ permalink raw reply related
* [PATCH v4 2/6] phy: realtek: usb2: introduce read and write functions to driver data
From: Rustam Adilov @ 2026-04-06 18:12 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stanley Chang, linux-phy, devicetree, linux-kernel
Cc: Rustam Adilov, Michael Zavertkin
In-Reply-To: <20260406181228.25892-1-adilov@disroot.org>
RTL9607C is a big endian SoC but has little endian USB host controller and
thus, reads and writes to the reg_gusb2phyacc0 should go through
le32_to_cpu and cpu_to_le32 functions respectively. This doesn't apply to
vstatus register though.
The reason is readl/writel functions, despite the supposed little endian
byte swap, still operate with native endian. The __raw_{read,write} are
also native endianness. And so wrapping them around le32 makes a proper
byte swap from big endian to little endian.
To handle this situation, introduce read and write functions to the driver
data and create a default variation of read and write function for the
current RTD SoCs.
Adjust all instances of utmi_wait_register function to now include the read
function as one of its arguments.
Assign the existing phy configuration for RTD SoCs to the default read
and write functions.
Co-developed-by: Michael Zavertkin <misha.zavertkin@mail.ru>
Signed-off-by: Michael Zavertkin <misha.zavertkin@mail.ru>
Signed-off-by: Rustam Adilov <adilov@disroot.org>
---
drivers/phy/realtek/phy-rtk-usb2.c | 63 ++++++++++++++++++++++++------
1 file changed, 50 insertions(+), 13 deletions(-)
diff --git a/drivers/phy/realtek/phy-rtk-usb2.c b/drivers/phy/realtek/phy-rtk-usb2.c
index f5d2f0c3376a..0facd5f02e2d 100644
--- a/drivers/phy/realtek/phy-rtk-usb2.c
+++ b/drivers/phy/realtek/phy-rtk-usb2.c
@@ -67,6 +67,9 @@ struct phy_reg {
int vstatus_offset;
int vstatus_busy;
int new_reg_req;
+
+ u32 (*read)(void __iomem *reg);
+ void (*write)(u32 val, void __iomem *reg);
};
struct phy_data {
@@ -102,6 +105,9 @@ struct phy_cfg {
int vstatus_offset;
int vstatus_busy;
int new_reg_req;
+
+ u32 (*read)(void __iomem *reg);
+ void (*write)(u32 val, void __iomem *reg);
};
struct phy_parameter {
@@ -128,6 +134,16 @@ struct rtk_phy {
struct dentry *debug_dir;
};
+static u32 rtk_usb2phy_read(void __iomem *reg)
+{
+ return readl(reg);
+}
+
+static void rtk_usb2phy_write(u32 val, void __iomem *reg)
+{
+ writel(val, reg);
+}
+
/* mapping 0xE0 to 0 ... 0xE7 to 7, 0xF0 to 8 ,,, 0xF7 to 15 */
static inline int page_addr_to_array_index(u8 addr)
{
@@ -144,12 +160,13 @@ static inline u8 array_index_to_page_addr(int index)
#define PHY_IO_TIMEOUT_USEC (50000)
#define PHY_IO_DELAY_US (100)
-static inline int utmi_wait_register(void __iomem *reg, u32 mask, u32 result)
+static inline int utmi_wait_register(u32 (*read)(void __iomem *reg), void __iomem *reg, u32 mask,
+ u32 result)
{
int ret;
unsigned int val;
- ret = read_poll_timeout(readl, val, ((val & mask) == result),
+ ret = read_poll_timeout(read, val, ((val & mask) == result),
PHY_IO_DELAY_US, PHY_IO_TIMEOUT_USEC, false, reg);
if (ret) {
pr_err("%s can't program USB phy\n", __func__);
@@ -168,25 +185,25 @@ static char rtk_phy_read(struct phy_reg *phy_reg, char addr)
addr -= OFFEST_PHY_READ;
/* polling until VBusy == 0 */
- ret = utmi_wait_register(reg_gusb2phyacc0, phy_reg->vstatus_busy, 0);
+ ret = utmi_wait_register(phy_reg->read, reg_gusb2phyacc0, phy_reg->vstatus_busy, 0);
if (ret)
return (char)ret;
/* VCtrl = low nibble of addr, and set PHY_NEW_REG_REQ */
val = phy_reg->new_reg_req | (GET_LOW_NIBBLE(addr) << PHY_VCTRL_SHIFT);
- writel(val, reg_gusb2phyacc0);
- ret = utmi_wait_register(reg_gusb2phyacc0, phy_reg->vstatus_busy, 0);
+ phy_reg->write(val, reg_gusb2phyacc0);
+ ret = utmi_wait_register(phy_reg->read, reg_gusb2phyacc0, phy_reg->vstatus_busy, 0);
if (ret)
return (char)ret;
/* VCtrl = high nibble of addr, and set PHY_NEW_REG_REQ */
val = phy_reg->new_reg_req | (GET_HIGH_NIBBLE(addr) << PHY_VCTRL_SHIFT);
- writel(val, reg_gusb2phyacc0);
- ret = utmi_wait_register(reg_gusb2phyacc0, phy_reg->vstatus_busy, 0);
+ phy_reg->write(val, reg_gusb2phyacc0);
+ ret = utmi_wait_register(phy_reg->read, reg_gusb2phyacc0, phy_reg->vstatus_busy, 0);
if (ret)
return (char)ret;
- val = readl(reg_gusb2phyacc0);
+ val = phy_reg->read(reg_gusb2phyacc0);
return (char)(val & PHY_REG_DATA_MASK);
}
@@ -202,23 +219,23 @@ static int rtk_phy_write(struct phy_reg *phy_reg, char addr, char data)
/* write data to VStatusOut2 (data output to phy) */
writel((u32)data << shift_bits, reg_wrap_vstatus + phy_reg->vstatus_offset);
- ret = utmi_wait_register(reg_gusb2phyacc0, phy_reg->vstatus_busy, 0);
+ ret = utmi_wait_register(phy_reg->read, reg_gusb2phyacc0, phy_reg->vstatus_busy, 0);
if (ret)
return ret;
/* VCtrl = low nibble of addr, set PHY_NEW_REG_REQ */
val = phy_reg->new_reg_req | (GET_LOW_NIBBLE(addr) << PHY_VCTRL_SHIFT);
- writel(val, reg_gusb2phyacc0);
- ret = utmi_wait_register(reg_gusb2phyacc0, phy_reg->vstatus_busy, 0);
+ phy_reg->write(val, reg_gusb2phyacc0);
+ ret = utmi_wait_register(phy_reg->read, reg_gusb2phyacc0, phy_reg->vstatus_busy, 0);
if (ret)
return ret;
/* VCtrl = high nibble of addr, set PHY_NEW_REG_REQ */
val = phy_reg->new_reg_req | (GET_HIGH_NIBBLE(addr) << PHY_VCTRL_SHIFT);
- writel(val, reg_gusb2phyacc0);
- ret = utmi_wait_register(reg_gusb2phyacc0, phy_reg->vstatus_busy, 0);
+ phy_reg->write(val, reg_gusb2phyacc0);
+ ret = utmi_wait_register(phy_reg->read, reg_gusb2phyacc0, phy_reg->vstatus_busy, 0);
if (ret)
return ret;
@@ -984,6 +1001,8 @@ static int parse_phy_data(struct rtk_phy *rtk_phy)
phy_parameter->phy_reg.vstatus_offset = phy_cfg->vstatus_offset;
phy_parameter->phy_reg.vstatus_busy = phy_cfg->vstatus_busy;
phy_parameter->phy_reg.new_reg_req = phy_cfg->new_reg_req;
+ phy_parameter->phy_reg.read = phy_cfg->read;
+ phy_parameter->phy_reg.write = phy_cfg->write;
if (of_property_read_bool(np, "realtek,inverse-hstx-sync-clock"))
phy_parameter->inverse_hstx_sync_clock = true;
@@ -1098,6 +1117,8 @@ static const struct phy_cfg rtd1295_phy_cfg = {
.vstatus_offset = 0,
.vstatus_busy = PHY_VSTS_BUSY,
.new_reg_req = PHY_NEW_REG_REQ,
+ .read = rtk_usb2phy_read,
+ .write = rtk_usb2phy_write,
};
static const struct phy_cfg rtd1395_phy_cfg = {
@@ -1125,6 +1146,8 @@ static const struct phy_cfg rtd1395_phy_cfg = {
.vstatus_offset = 0,
.vstatus_busy = PHY_VSTS_BUSY,
.new_reg_req = PHY_NEW_REG_REQ,
+ .read = rtk_usb2phy_read,
+ .write = rtk_usb2phy_write,
};
static const struct phy_cfg rtd1395_phy_cfg_2port = {
@@ -1152,6 +1175,8 @@ static const struct phy_cfg rtd1395_phy_cfg_2port = {
.vstatus_offset = 0,
.vstatus_busy = PHY_VSTS_BUSY,
.new_reg_req = PHY_NEW_REG_REQ,
+ .read = rtk_usb2phy_read,
+ .write = rtk_usb2phy_write,
};
static const struct phy_cfg rtd1619_phy_cfg = {
@@ -1177,6 +1202,8 @@ static const struct phy_cfg rtd1619_phy_cfg = {
.vstatus_offset = 0,
.vstatus_busy = PHY_VSTS_BUSY,
.new_reg_req = PHY_NEW_REG_REQ,
+ .read = rtk_usb2phy_read,
+ .write = rtk_usb2phy_write,
};
static const struct phy_cfg rtd1319_phy_cfg = {
@@ -1206,6 +1233,8 @@ static const struct phy_cfg rtd1319_phy_cfg = {
.vstatus_offset = 0,
.vstatus_busy = PHY_VSTS_BUSY,
.new_reg_req = PHY_NEW_REG_REQ,
+ .read = rtk_usb2phy_read,
+ .write = rtk_usb2phy_write,
};
static const struct phy_cfg rtd1312c_phy_cfg = {
@@ -1234,6 +1263,8 @@ static const struct phy_cfg rtd1312c_phy_cfg = {
.vstatus_offset = 0,
.vstatus_busy = PHY_VSTS_BUSY,
.new_reg_req = PHY_NEW_REG_REQ,
+ .read = rtk_usb2phy_read,
+ .write = rtk_usb2phy_write,
};
static const struct phy_cfg rtd1619b_phy_cfg = {
@@ -1262,6 +1293,8 @@ static const struct phy_cfg rtd1619b_phy_cfg = {
.vstatus_offset = 0,
.vstatus_busy = PHY_VSTS_BUSY,
.new_reg_req = PHY_NEW_REG_REQ,
+ .read = rtk_usb2phy_read,
+ .write = rtk_usb2phy_write,
};
static const struct phy_cfg rtd1319d_phy_cfg = {
@@ -1290,6 +1323,8 @@ static const struct phy_cfg rtd1319d_phy_cfg = {
.vstatus_offset = 0,
.vstatus_busy = PHY_VSTS_BUSY,
.new_reg_req = PHY_NEW_REG_REQ,
+ .read = rtk_usb2phy_read,
+ .write = rtk_usb2phy_write,
};
static const struct phy_cfg rtd1315e_phy_cfg = {
@@ -1319,6 +1354,8 @@ static const struct phy_cfg rtd1315e_phy_cfg = {
.vstatus_offset = 0,
.vstatus_busy = PHY_VSTS_BUSY,
.new_reg_req = PHY_NEW_REG_REQ,
+ .read = rtk_usb2phy_read,
+ .write = rtk_usb2phy_write,
};
static const struct of_device_id usbphy_rtk_dt_match[] = {
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox