* Re: [PATCH 1/2] dt-bindings: clock: Drop incorrect usage of double '::'
From: Conor Dooley @ 2026-06-22 16:50 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Peter Griffin, Alim Akhtar, Michael Turquette,
Stephen Boyd, Brian Masney, Sylwester Nawrocki, Chanwoo Choi,
Sam Protsenko, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Andi Shyti, Georgi Djakov, Lee Jones, Pavel Machek, Hans Verkuil,
Mauro Carvalho Chehab, Ulf Hansson, Peter Rosin, Vinod Koul,
Neil Armstrong, Linus Walleij, Geert Uytterhoeven, Magnus Damm,
Sebastian Reichel, Javier Martinez Canillas, Liam Girdwood,
Mark Brown, Greg Kroah-Hartman, Jiri Slaby, Srinivas Kandagatla,
Bartlomiej Zolnierkiewicz, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Jonathan Marek, Taniya Das, Robert Marko,
Christian Marangi, Stephan Gerhold, Adam Skladowski,
Sireesh Kodali, Barnabas Czeman, Imran Shaik,
Sricharan Ramabadhran, Anusha Rao, Luo Jie, Tomasz Figa,
Chanho Park, Sunyeal Hong, Shin Son, Krishna Manikandan,
Jacek Anaszewski, Jaehoon Chung, Marek Szyprowski, Alina Yu,
Andy Gross, Niklas Söderlund, Wesley Cheng, linux-arm-msm,
devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-clk, dri-devel, freedreno, linux-i2c, linux-pm, linux-leds,
linux-media, linux-mmc, linux-phy, linux-gpio, linux-renesas-soc,
linux-serial, linux-sound, linux-usb
In-Reply-To: <20260622101606.485961-3-krzysztof.kozlowski@oss.qualcomm.com>
[-- Attachment #1.1: Type: text/plain, Size: 583 bytes --]
On Mon, Jun 22, 2026 at 12:16:07PM +0200, Krzysztof Kozlowski wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
>
> Cleanup existing code, so the confusing style won't be re-used in new
> contributions.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 112 bytes --]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 0/6] Additional regulator support for the Qualcomm SGMII SerDes PHY
From: Loic Poulain @ 2026-06-22 14:08 UTC (permalink / raw)
To: Mohd Ayaan Anwar
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bartosz Golaszewski,
Bjorn Andersson, Konrad Dybcio, Wasim Nazir, Mohd Ayaan Anwar,
Yijie Yang, linux-arm-msm, linux-phy, devicetree, linux-kernel,
Konrad Dybcio
In-Reply-To: <20251124-sgmiieth_serdes_regulator-v1-0-73ae8f9cbe2a@oss.qualcomm.com>
Hi,
On Mon, Nov 24, 2025 at 10:26 AM Mohd Ayaan Anwar
<mohd.anwar@oss.qualcomm.com> wrote:
>
> This patch series addresses a SerDes power-up failure observed on the
> QCS8300 Ride board using the phy-qcom-sgmii-eth driver. The issue occurs
> because the SerDes PHY requires both L5A and L4A regulators to be
> enabled during initialization. If either one of them is disabled, the
> status register does not reset, and the Ethernet interface fails to come
> up due to a timeout:
>
> [ 77.105651] qcom-dwmac-sgmii-phy 8909000.phy: QSERDES_COM_C_READY_STATUS timed-out
> [ 77.113447] qcom-ethqos 23040000.ethernet eth0: __stmmac_open: Serdes powerup failed
>
> Presumably, the issue is not seen on all users of this PHY because both
> regulators are often shared with other peripherals. However, the power
> rail schematics for boards using this SerDes PHY show that it is
> supplied by both L5A (1.2V) and L4A (0.9V) regulators.
>
> This series has been tested on the QCS8300 Ride board, and the reported
> issue was resolved. All Monaco and Lemans derivative boards require this
> new configuration as they use the same SerDes PHY.
>
> Signed-off-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
This appears to be a real issue, but I haven’t seen a new version of
the series or any response to the feedback so far. Could you please
follow up on this?
> ---
> Mohd Ayaan Anwar (6):
> dt-bindings: phy: describe additional regulator for Qualcomm SGMII PHY
> arm64: dts: qcom: lemans-evk: add additional SerDes PHY regulator
> arm64: dts: qcom: lemans-ride-common: add additional SerDes PHY regulators
> arm64: dts: qcom: monaco-evk: fix the SerDes PHY regulators
> arm64: dts: qcom: qcs8300-ride: add additional SerDes PHY regulator
> phy: qcom: sgmii-eth: add second regulator support
>
> .../bindings/phy/qcom,sa8775p-dwmac-sgmii-phy.yaml | 4 ++++
> arch/arm64/boot/dts/qcom/lemans-evk.dts | 1 +
> arch/arm64/boot/dts/qcom/lemans-ride-common.dtsi | 4 ++++
> arch/arm64/boot/dts/qcom/monaco-evk.dts | 3 ++-
> arch/arm64/boot/dts/qcom/qcs8300-ride.dts | 2 ++
> drivers/phy/qualcomm/phy-qcom-sgmii-eth.c | 24 +++++++++++++++++++++-
> 6 files changed, 36 insertions(+), 2 deletions(-)
> ---
> base-commit: 0f2995693867bfb26197b117cd55624ddc57582f
> change-id: 20251124-sgmiieth_serdes_regulator-027fc6b15216
>
> Best regards,
> --
> Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
>
>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: Drop incorrect usage of double '::'
From: Krzysztof Kozlowski @ 2026-06-22 13:23 UTC (permalink / raw)
To: sashiko-reviews
Cc: neil.armstrong, vkoul, dri-devel, robh, conor+dt, linux-phy,
olteanv, devicetree, wsa+renesas
In-Reply-To: <20260622101959.37DB41F00A3D@smtp.kernel.org>
On 22/06/2026 12:19, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] Unintended replacement of BNF notation `::=` with `:=`.
> --
>
> commit a9fdd0b065eb5b6394a9c33ffba0fd5194e80115
> Author: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> dt-bindings: Drop incorrect usage of double '::'
>
> This commit cleans up device tree binding schemas by removing the redundant
> double colons at the end of descriptions inside YAML literal style blocks.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
>
>> diff --git a/Documentation/devicetree/bindings/mux/mux-consumer.yaml b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
>> index 9e2d78a78e409..769243a2bf046 100644
>> --- a/Documentation/devicetree/bindings/mux/mux-consumer.yaml
>> +++ b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
>> @@ -13,8 +13,8 @@ description: |
>> Mux controller consumers should specify a list of mux controllers that they
>> want to use with a property containing a 'mux-ctrl-list':
>>
>> - mux-ctrl-list ::= <single-mux-ctrl> [mux-ctrl-list]
>> - single-mux-ctrl ::= <mux-ctrl-phandle> [mux-ctrl-specifier]
>> + mux-ctrl-list := <single-mux-ctrl> [mux-ctrl-list]
>> + single-mux-ctrl := <mux-ctrl-phandle> [mux-ctrl-specifier]
>
> [Severity: Low]
> Does this unintentionally change the standard Backus-Naur Form (BNF) ::=
> operator to :=? It looks like a global search-and-replace for :: might
I wasn't sure about that... and indeed this should not be changed. I
will send a v2.
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: Drop incorrect usage of double '::'
From: Niklas Söderlund @ 2026-06-22 11:08 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Peter Griffin, Alim Akhtar, Michael Turquette,
Stephen Boyd, Brian Masney, Sylwester Nawrocki, Chanwoo Choi,
Sam Protsenko, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Andi Shyti, Georgi Djakov, Lee Jones, Pavel Machek, Hans Verkuil,
Mauro Carvalho Chehab, Ulf Hansson, Peter Rosin, Vinod Koul,
Neil Armstrong, Linus Walleij, Geert Uytterhoeven, Magnus Damm,
Sebastian Reichel, Javier Martinez Canillas, Liam Girdwood,
Mark Brown, Greg Kroah-Hartman, Jiri Slaby, Srinivas Kandagatla,
Bartlomiej Zolnierkiewicz, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Jonathan Marek, Taniya Das, Robert Marko,
Christian Marangi, Stephan Gerhold, Adam Skladowski,
Sireesh Kodali, Barnabas Czeman, Imran Shaik,
Sricharan Ramabadhran, Anusha Rao, Luo Jie, Tomasz Figa,
Chanho Park, Sunyeal Hong, Shin Son, Krishna Manikandan,
Jacek Anaszewski, Jaehoon Chung, Marek Szyprowski, Alina Yu,
Andy Gross, Wesley Cheng, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel, linux-samsung-soc, linux-clk, dri-devel,
freedreno, linux-i2c, linux-pm, linux-leds, linux-media,
linux-mmc, linux-phy, linux-gpio, linux-renesas-soc, linux-serial,
linux-sound, linux-usb
In-Reply-To: <20260622101606.485961-4-krzysztof.kozlowski@oss.qualcomm.com>
Hi Krzysztof,
Thanks for your work.
On 2026-06-22 12:16:08 +0200, Krzysztof Kozlowski wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
>
> Cleanup existing code, so the confusing style won't be re-used in new
> contributions.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
For the two Renesas bindings,
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
>
> ---
>
> Intention for this patch is to go via Rob's tree.
> ---
> .../devicetree/bindings/arm/qcom-soc.yaml | 4 ++--
> .../devicetree/bindings/arm/qcom.yaml | 4 ++--
> .../bindings/arm/samsung/samsung-soc.yaml | 4 ++--
> .../display/msm/dsi-controller-main.yaml | 20 +++++++++----------
> .../display/samsung/samsung,fimd.yaml | 4 ++--
> .../bindings/i2c/samsung,s3c2410-i2c.yaml | 2 +-
> .../interconnect/qcom,msm8998-bwmon.yaml | 2 +-
> .../interconnect/samsung,exynos-bus.yaml | 14 ++++++-------
> .../bindings/leds/qcom,pm8058-led.yaml | 4 ++--
> .../bindings/leds/skyworks,aat1290.yaml | 6 +++---
> .../bindings/media/cec/cec-gpio.yaml | 2 +-
> .../bindings/mmc/samsung,exynos-dw-mshc.yaml | 2 +-
> .../devicetree/bindings/mux/mux-consumer.yaml | 4 ++--
> .../bindings/phy/samsung,mipi-video-phy.yaml | 4 ++--
> .../bindings/phy/samsung,usb2-phy.yaml | 2 +-
> .../bindings/phy/samsung,usb3-drd-phy.yaml | 2 +-
> .../bindings/pinctrl/samsung,pinctrl.yaml | 2 +-
> .../bindings/power/renesas,rcar-sysc.yaml | 2 +-
> .../bindings/power/reset/restart-handler.yaml | 8 ++++----
> .../bindings/regulator/maxim,max77802.yaml | 4 ++--
> .../bindings/regulator/richtek,rtq2208.yaml | 2 +-
> .../bindings/serial/qcom,msm-uartdm.yaml | 2 +-
> .../devicetree/bindings/slimbus/slimbus.yaml | 4 ++--
> .../bindings/soc/qcom/qcom,apr-services.yaml | 2 +-
> .../bindings/soc/qcom/qcom,rpmh-rsc.yaml | 8 ++++----
> .../bindings/soc/qcom/qcom,wcnss.yaml | 2 +-
> .../bindings/soc/renesas/renesas-soc.yaml | 4 ++--
> .../bindings/sound/qcom,q6asm-dais.yaml | 2 +-
> .../thermal/samsung,exynos-thermal.yaml | 4 ++--
> .../devicetree/bindings/usb/qcom,dwc3.yaml | 12 +++++------
> .../bindings/usb/qcom,snps-dwc3.yaml | 12 +++++------
> 31 files changed, 75 insertions(+), 75 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/qcom-soc.yaml b/Documentation/devicetree/bindings/arm/qcom-soc.yaml
> index 27261039d56f..37fdd5a080b7 100644
> --- a/Documentation/devicetree/bindings/arm/qcom-soc.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom-soc.yaml
> @@ -11,10 +11,10 @@ maintainers:
>
> description: |
> Guidelines for new compatibles for SoC blocks/components.
> - When adding new compatibles in new bindings, use the format::
> + When adding new compatibles in new bindings, use the format:
> qcom,SoC-IP
>
> - For example::
> + For example:
> qcom,sdm845-llcc-bwmon
>
> When adding new compatibles to existing bindings, use the format in the
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> index 50cc18a6ec5e..667607ae2c32 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> @@ -1215,7 +1215,7 @@ properties:
> items:
> items:
> - description: |
> - MSM chipset ID - an exact match value consisting of two bitfields::
> + MSM chipset ID - an exact match value consisting of two bitfields:
> - bits 0-15 - The unique MSM chipset ID
> - bits 16-31 - Reserved; should be 0
> - description: |
> @@ -1241,7 +1241,7 @@ properties:
> - items:
> - items:
> - description: |
> - Board ID consisting of three bitfields::
> + Board ID consisting of three bitfields:
> - bits 31-24 - Unused
> - bits 23-16 - Platform Version Major
> - bits 15-8 - Platform Version Minor
> diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml
> index 653f85997643..ab000befe76d 100644
> --- a/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml
> +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml
> @@ -11,10 +11,10 @@ maintainers:
>
> description: |
> Guidelines for new compatibles for SoC blocks/components.
> - When adding new compatibles in new bindings, use the format::
> + When adding new compatibles in new bindings, use the format:
> samsung,SoC-IP
>
> - For example::
> + For example:
> samsung,exynos5433-cmu-isp
>
> select:
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
> index dbc0613e427e..395425a70db8 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
> @@ -73,16 +73,16 @@ properties:
>
> clocks:
> description: |
> - Several clocks are used, depending on the variant. Typical ones are::
> - - bus:: Display AHB clock.
> - - byte:: Display byte clock.
> - - byte_intf:: Display byte interface clock.
> - - core:: Display core clock.
> - - core_mss:: Core MultiMedia SubSystem clock.
> - - iface:: Display AXI clock.
> - - mdp_core:: MDP Core clock.
> - - mnoc:: MNOC clock
> - - pixel:: Display pixel clock.
> + Several clocks are used, depending on the variant. Typical ones are:
> + - bus: Display AHB clock.
> + - byte: Display byte clock.
> + - byte_intf: Display byte interface clock.
> + - core: Display core clock.
> + - core_mss: Core MultiMedia SubSystem clock.
> + - iface: Display AXI clock.
> + - mdp_core: MDP Core clock.
> + - mnoc: MNOC clock
> + - pixel: Display pixel clock.
> minItems: 3
> maxItems: 12
>
> diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml
> index ff685031bb2c..729705f419bb 100644
> --- a/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml
> +++ b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml
> @@ -41,7 +41,7 @@ properties:
> additionalProperties: false
> description: |
> Timing configuration for lcd i80 interface support.
> - The parameters are defined as::
> + The parameters are defined as:
> VCLK(internal) __|??????|_____|??????|_____|??????|_____|??????|_____|??
> : : : : :
> Address Output --:<XXXXXXXXXXX:XXXXXXXXXXXX:XXXXXXXXXXXX:XXXXXXXXXXXX:XX
> @@ -132,7 +132,7 @@ patternProperties:
> "^port@[0-4]+$":
> $ref: /schemas/graph.yaml#/properties/port
> description: |
> - Contains ports with port with index::
> + Contains ports with port with index:
> 0 - for CAMIF0 input,
> 1 - for CAMIF1 input,
> 2 - for CAMIF2 input,
> diff --git a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
> index a2ddc6803617..07600b49f2f9 100644
> --- a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
> +++ b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
> @@ -35,7 +35,7 @@ properties:
>
> gpios:
> description: |
> - The order of the GPIOs should be the following:: <SDA, SCL>. The GPIO
> + The order of the GPIOs should be the following: <SDA, SCL>. The GPIO
> specifier depends on the gpio controller. Required in all cases except
> for "samsung,s3c2440-hdmiphy-i2c" whose input/output lines are
> permanently wired to the respective client.
> diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
> index ff64225e8281..e002e70580f9 100644
> --- a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
> +++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
> @@ -13,7 +13,7 @@ description: |
> Bandwidth Monitor measures current throughput on buses between various NoC
> fabrics and provides information when it crosses configured thresholds.
>
> - Certain SoCs might have more than one Bandwidth Monitors, for example on SDM845::
> + Certain SoCs might have more than one Bandwidth Monitors, for example on SDM845:
> - Measuring the bandwidth between CPUs and Last Level Cache Controller -
> called just BWMON,
> - Measuring the bandwidth between Last Level Cache Controller and memory
> diff --git a/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml b/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
> index 5e26e48c7217..0203959c8995 100644
> --- a/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
> +++ b/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
> @@ -23,7 +23,7 @@ description: |
> The each AXI bus has the owned source clock but, has not the only owned power
> line. The power line might be shared among one more sub-blocks. So, we can
> divide into two type of device as the role of each sub-block. There are two
> - type of bus devices as following::
> + type of bus devices as following:
> - parent bus device
> - passive bus device
>
> @@ -44,8 +44,8 @@ description: |
> able to support the bus frequency for all Exynos SoCs.
>
> Detailed correlation between sub-blocks and power line according
> - to Exynos SoC::
> - - In case of Exynos3250, there are two power line as following::
> + to Exynos SoC:
> + - In case of Exynos3250, there are two power line as following:
> VDD_MIF |--- DMC (Dynamic Memory Controller)
>
> VDD_INT |--- LEFTBUS (parent device)
> @@ -89,7 +89,7 @@ description: |
> |L5 |200000 |200000 |400000 |300000 | ||1000000 |
> ----------------------------------------------------------
>
> - - In case of Exynos4210, there is one power line as following::
> + - In case of Exynos4210, there is one power line as following:
> VDD_INT |--- DMC (parent device, Dynamic Memory Controller)
> |--- LEFTBUS
> |--- PERIL
> @@ -106,7 +106,7 @@ description: |
> |--- LCD0
> |--- LCD1
>
> - - In case of Exynos4x12, there are two power line as following::
> + - In case of Exynos4x12, there are two power line as following:
> VDD_MIF |--- DMC (Dynamic Memory Controller)
>
> VDD_INT |--- LEFTBUS (parent device)
> @@ -124,7 +124,7 @@ description: |
> |--- LCD0
> |--- ISP
>
> - - In case of Exynos5422, there are two power line as following::
> + - In case of Exynos5422, there are two power line as following:
> VDD_MIF |--- DREX 0 (parent device, DRAM EXpress controller)
> |--- DREX 1
>
> @@ -143,7 +143,7 @@ description: |
> |--- FSYS
> |--- FSYS2
>
> - - In case of Exynos5433, there is VDD_INT power line as following::
> + - In case of Exynos5433, there is VDD_INT power line as following:
> VDD_INT |--- G2D (parent device)
> |--- MSCL
> |--- GSCL
> diff --git a/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml b/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml
> index b409b2a8b5c5..5165bfddcd54 100644
> --- a/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml
> +++ b/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml
> @@ -10,10 +10,10 @@ maintainers:
> - Krzysztof Kozlowski <krzk@kernel.org>
>
> description: |
> - The Qualcomm PM8058 contains an LED block for up to six LEDs:: three normal
> + The Qualcomm PM8058 contains an LED block for up to six LEDs: three normal
> LEDs, two "flash" LEDs and one "keypad backlight" LED. The names are quoted
> because sometimes these LED drivers are used for wildly different things than
> - flash or keypad backlight:: their names are more of a suggestion than a
> + flash or keypad backlight: their names are more of a suggestion than a
> hard-wired usecase.
>
> Hardware-wise the different LEDs support slightly different output currents.
> diff --git a/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml b/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml
> index a6aaa92dbccd..65576dfdca11 100644
> --- a/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml
> +++ b/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml
> @@ -11,7 +11,7 @@ maintainers:
> - Krzysztof Kozlowski <krzk@kernel.org>
>
> description: |
> - The device is controlled through two pins:: FL_EN and EN_SET. The pins when,
> + The device is controlled through two pins: FL_EN and EN_SET. The pins when,
> asserted high, enable flash strobe and movie mode (max 1/2 of flash current)
> respectively. In order to add a capability of selecting the strobe signal
> source (e.g. CPU or camera sensor) there is an additional switch required,
> @@ -39,11 +39,11 @@ properties:
> flash-max-microamp:
> description: |
> Maximum flash LED supply current can be calculated using following
> - formula:: I = 1A * 162 kOhm / Rset.
> + formula: I = 1A * 162 kOhm / Rset.
>
> flash-max-timeout-us:
> description: |
> - Maximum flash timeout can be calculated using following formula::
> + Maximum flash timeout can be calculated using following formula:
> T = 8.82 * 10^9 * Ct.
>
> required:
> diff --git a/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml b/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml
> index 582c6c9cae48..21118e4bae0f 100644
> --- a/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml
> +++ b/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml
> @@ -14,7 +14,7 @@ description: |
> hooked up to a pull-up GPIO line and - optionally - the HPD line is hooked up
> to another GPIO line.
>
> - Please note:: the maximum voltage for the CEC line is 3.63V, for the HPD and
> + Please note: the maximum voltage for the CEC line is 3.63V, for the HPD and
> 5V lines it is 5.3V. So you may need some sort of level conversion
> circuitry when connecting them to a GPIO line.
>
> diff --git a/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
> index 27c4060f2f91..223fcc9f651f 100644
> --- a/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
> +++ b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
> @@ -85,7 +85,7 @@ properties:
> description: |
> The value of CIU TX and RX clock phase shift value for HS400 mode
> operation.
> - Valid values for SDR and DDR CIU clock timing::
> + Valid values for SDR and DDR CIU clock timing:
> - valid value for tx phase shift and rx phase shift is 0 to 7.
> - when CIU clock divider value is set to 3, all possible 8 phase shift
> values can be used.
> diff --git a/Documentation/devicetree/bindings/mux/mux-consumer.yaml b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
> index 9e2d78a78e40..769243a2bf04 100644
> --- a/Documentation/devicetree/bindings/mux/mux-consumer.yaml
> +++ b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
> @@ -13,8 +13,8 @@ description: |
> Mux controller consumers should specify a list of mux controllers that they
> want to use with a property containing a 'mux-ctrl-list':
>
> - mux-ctrl-list ::= <single-mux-ctrl> [mux-ctrl-list]
> - single-mux-ctrl ::= <mux-ctrl-phandle> [mux-ctrl-specifier]
> + mux-ctrl-list := <single-mux-ctrl> [mux-ctrl-list]
> + single-mux-ctrl := <mux-ctrl-phandle> [mux-ctrl-specifier]
> mux-ctrl-phandle : phandle to mux controller node
> mux-ctrl-specifier : array of #mux-control-cells specifying the
> given mux controller (controller specific)
> diff --git a/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
> index 16967ef8e9ec..87b6a35b2626 100644
> --- a/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
> @@ -13,14 +13,14 @@ maintainers:
>
> description: |
> For samsung,s5pv210-mipi-video-phy compatible PHYs the second cell in the
> - PHY specifier identifies the PHY and its meaning is as follows::
> + PHY specifier identifies the PHY and its meaning is as follows:
> 0 - MIPI CSIS 0,
> 1 - MIPI DSIM 0,
> 2 - MIPI CSIS 1,
> 3 - MIPI DSIM 1.
>
> samsung,exynos5420-mipi-video-phy and samsung,exynos5433-mipi-video-phy
> - support additional fifth PHY::
> + support additional fifth PHY:
> 4 - MIPI CSIS 2.
>
> properties:
> diff --git a/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml
> index d9f22a801cbf..7db7605a82e2 100644
> --- a/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml
> @@ -14,7 +14,7 @@ maintainers:
> description: |
> The first phandle argument in the PHY specifier identifies the PHY, its
> meaning is compatible dependent. For the currently supported SoCs (Exynos4210
> - and Exynos4212) it is as follows::
> + and Exynos4212) it is as follows:
> 0 - USB device ("device"),
> 1 - USB host ("host"),
> 2 - HSIC0 ("hsic0"),
> diff --git a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
> index 4562e0468f4f..a1b3d9e6a094 100644
> --- a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
> @@ -14,7 +14,7 @@ maintainers:
> description: |
> For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
> compatible PHYs, the second cell in the PHY specifier identifies the
> - PHY id, which is interpreted as follows::
> + PHY id, which is interpreted as follows:
> 0 - UTMI+ type phy,
> 1 - PIPE3 type phy.
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
> index 7b006009ca0e..5e35686eeed3 100644
> --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
> @@ -18,7 +18,7 @@ description: |
> All the pin controller nodes should be represented in the aliases node using
> the following format 'pinctrl{n}' where n is a unique number for the alias.
>
> - The controller supports three types of interrupts::
> + The controller supports three types of interrupts:
> - External GPIO interrupts (see interrupts property in pin controller node);
>
> - External wake-up interrupts - multiplexed (capable of waking up the system
> diff --git a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml
> index 347571e2545a..b67aa170b2c1 100644
> --- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml
> +++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml
> @@ -13,7 +13,7 @@ maintainers:
> description: |
> The R-Car (RZ/G) System Controller provides power management for the CPU
> cores and various coprocessors.
> - The power domain IDs for consumers are defined in header files::
> + The power domain IDs for consumers are defined in header files:
> include/dt-bindings/power/r8*-sysc.h
>
> properties:
> diff --git a/Documentation/devicetree/bindings/power/reset/restart-handler.yaml b/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
> index 965a834a3dbe..00c00ec5ec81 100644
> --- a/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
> +++ b/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
> @@ -18,12 +18,12 @@ properties:
> priority:
> $ref: /schemas/types.yaml#/definitions/uint32
> description: |
> - A priority ranging from 0 to 255 according to the following guidelines::
> - 0:: Restart handler of last resort, with limited restart capabilities.
> - 128:: Typical, default restart handler; use if no other restart handler
> + A priority ranging from 0 to 255 according to the following guidelines:
> + 0: Restart handler of last resort, with limited restart capabilities.
> + 128: Typical, default restart handler; use if no other restart handler
> is expected to be available, and/or if restart functionality is
> sufficient to restart the entire system.
> - 255:: Highest priority restart handler, will preempt all other restart handlers.
> + 255: Highest priority restart handler, will preempt all other restart handlers.
> minimum: 0
> maximum: 255
>
> diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml
> index b704f05ea454..b886495c1396 100644
> --- a/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml
> +++ b/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml
> @@ -22,13 +22,13 @@ description: |
>
> Certain regulators support "regulator-initial-mode" and "regulator-mode".
> The valid modes list is defined in the dt-bindings/regulator/maxim,max77802.h
> - and their meaning is::
> + and their meaning is:
> 1 - Normal regulator voltage output mode.
> 3 - Low Power which reduces the quiescent current down to only 1uA
>
> The standard "regulator-mode" property can only be used for regulators that
> support changing their mode to Low Power Mode during suspend. These
> - regulators are:: bucks 2-4 and LDOs 1-35. Also, it only takes effect if the
> + regulators are: bucks 2-4 and LDOs 1-35. Also, it only takes effect if the
> regulator has been enabled for the given suspend state using
> "regulator-on-in-suspend" and has not been disabled for that state using
> "regulator-off-in-suspend".
> diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
> index 022c1f197364..b0aa38edf8c2 100644
> --- a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
> +++ b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
> @@ -21,7 +21,7 @@ description: |
> conduction mode (FCCM).
>
> The definition of modes is in the datasheet which is available in below link
> - and their meaning is::
> + and their meaning is:
> 0 - Auto mode for power saving, which reducing the switching frequency at light load condition
> to maintain high frequency.
> 1 - FCCM to meet the strict voltage regulation accuracy, which keeping constant switching frequency.
> diff --git a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml
> index 788ef5c1c446..bc967ead2350 100644
> --- a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml
> +++ b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml
> @@ -17,7 +17,7 @@ description: |
> software perspective it's mostly compatible with the MSM serial UART except
> that it supports reading and writing multiple characters at a time.
>
> - Note:: Aliases may be defined to ensure the correct ordering of the UARTs.
> + Note: Aliases may be defined to ensure the correct ordering of the UARTs.
> The alias serialN will result in the UART being assigned port N. If any
> serialN alias exists, then an alias must exist for each enabled UART. The
> serialN aliases should be in a .dts file instead of in a .dtsi file.
> diff --git a/Documentation/devicetree/bindings/slimbus/slimbus.yaml b/Documentation/devicetree/bindings/slimbus/slimbus.yaml
> index 5a941610ce4e..3910327c8ded 100644
> --- a/Documentation/devicetree/bindings/slimbus/slimbus.yaml
> +++ b/Documentation/devicetree/bindings/slimbus/slimbus.yaml
> @@ -29,7 +29,7 @@ patternProperties:
> description: |
> Every SLIMbus controller node can contain zero or more child nodes
> representing slave devices on the bus. Every SLIMbus slave device is
> - uniquely determined by the enumeration address containing 4 fields::
> + uniquely determined by the enumeration address containing 4 fields:
> Manufacturer ID, Product code, Device index, and Instance value for the
> device.
>
> @@ -48,7 +48,7 @@ patternProperties:
> reg:
> maxItems: 1
> description: |
> - Pair of (device index, instande ID), where::
> + Pair of (device index, instande ID), where:
> - Device index, which uniquely identifies multiple devices within a
> single component.
> - Instance ID, can be used for the cases where multiple devices of
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml
> index bdf482db32aa..b663be3ea5a1 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml
> @@ -40,7 +40,7 @@ properties:
> $ref: /schemas/types.yaml#/definitions/string-array
> description: |
> Protection domain service name and path for APR service (if supported).
> - Possible values are::
> + Possible values are:
> "avs/audio", "msm/adsp/audio_pd".
> "kernel/elf_loader", "msm/modem/wlan_pd".
> "tms/servreg", "msm/adsp/audio_pd".
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
> index 26d9bc773ec5..1889139a3f7a 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
> @@ -23,7 +23,7 @@ description: |
> with a few variations that are captured by the properties here.
>
> A TCS may be triggered from Linux or triggered by the F/W after all the CPUs
> - have powered off to facilitate idle power saving. TCS could be classified as::
> + have powered off to facilitate idle power saving. TCS could be classified as:
> ACTIVE - Triggered by Linux
> SLEEP - Triggered by F/W
> WAKE - Triggered by F/W
> @@ -76,7 +76,7 @@ properties:
> items:
> items:
> - description: |
> - TCS type::
> + TCS type:
> - ACTIVE_TCS
> - SLEEP_TCS
> - WAKE_TCS
> @@ -152,7 +152,7 @@ examples:
> - |
> // For a TCS whose RSC base address is 0x179C0000 and is at a DRV id of
> // 2, the register offsets for DRV2 start at 0D00, the register
> - // calculations are like this::
> + // calculations are like this:
> // DRV0: 0x179C0000
> // DRV2: 0x179C0000 + 0x10000 = 0x179D0000
> // DRV2: 0x179C0000 + 0x10000 * 2 = 0x179E0000
> @@ -182,7 +182,7 @@ examples:
> - |
> // For a TCS whose RSC base address is 0xAF20000 and is at DRV id of 0, the
> // register offsets for DRV0 start at 01C00, the register calculations are
> - // like this::
> + // like this:
> // DRV0: 0xAF20000
> // TCS-OFFSET: 0x1C00
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml
> index 4fcae6bedfff..72a7f8cb09ba 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml
> @@ -28,7 +28,7 @@ properties:
> $ref: /schemas/types.yaml#/definitions/phandle
> description: |
> Reference to a node specifying the wcnss "ccu" and "dxe" register blocks.
> - The node must be compatible with one of the following::
> + The node must be compatible with one of the following:
> - qcom,riva"
> - qcom,pronto"
>
> diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml
> index 5ddd31f30f26..57c9d3c57021 100644
> --- a/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml
> +++ b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml
> @@ -12,10 +12,10 @@ maintainers:
>
> description: |
> Guidelines for new compatibles for SoC blocks/components.
> - When adding new compatibles in new bindings, use the format::
> + When adding new compatibles in new bindings, use the format:
> renesas,SoC-IP
>
> - For example::
> + For example:
> renesas,r8a77965-csi2
>
> When adding new compatibles to existing bindings, use the format in the
> diff --git a/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml b/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml
> index 47a105a97ecf..bc8c8ba24f9c 100644
> --- a/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml
> +++ b/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml
> @@ -45,7 +45,7 @@ patternProperties:
> $ref: /schemas/types.yaml#/definitions/uint32
> enum: [0, 1, 2]
> description: |
> - The direction of the dai stream::
> + The direction of the dai stream:
> - Q6ASM_DAI_TX_RX (0) for both tx and rx
> - Q6ASM_DAI_TX (1) for only tx (Capture/Encode)
> - Q6ASM_DAI_RX (2) for only rx (Playback/Decode)
> diff --git a/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml b/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml
> index 29a08b0729ee..3f333db72a71 100644
> --- a/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml
> +++ b/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml
> @@ -40,7 +40,7 @@ properties:
> description: |
> The Exynos TMU supports generating interrupts when reaching given
> temperature thresholds. Number of supported thermal trip points depends
> - on the SoC (only first trip points defined in DT will be configured)::
> + on the SoC (only first trip points defined in DT will be configured):
> - most of SoC: 4
> - samsung,exynos5433-tmu: 8
> - samsung,exynos7-tmu: 8
> @@ -52,7 +52,7 @@ properties:
> - description: |
> Shared TMU registers.
>
> - Note:: On Exynos5420, the TRIMINFO register is misplaced for TMU
> + Note: On Exynos5420, the TRIMINFO register is misplaced for TMU
> channels 2, 3 and 4 Use "samsung,exynos5420-tmu-ext-triminfo" in
> cases, there is a misplaced register, also provide clock to access
> that base.
> diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
> index a7f58114c02e..90daee616880 100644
> --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
> +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
> @@ -92,14 +92,14 @@ properties:
>
> clocks:
> description: |
> - Several clocks are used, depending on the variant. Typical ones are::
> - - cfg_noc:: System Config NOC clock.
> - - core:: Master/Core clock, has to be >= 125 MHz for SS operation and >=
> + Several clocks are used, depending on the variant. Typical ones are:
> + - cfg_noc: System Config NOC clock.
> + - core: Master/Core clock, has to be >= 125 MHz for SS operation and >=
> 60MHz for HS operation.
> - - iface:: System bus AXI clock.
> - - sleep:: Sleep clock, used for wakeup when USB3 core goes into low
> + - iface: System bus AXI clock.
> + - sleep: Sleep clock, used for wakeup when USB3 core goes into low
> power mode (U3).
> - - mock_utmi:: Mock utmi clock needed for ITP/SOF generation in host
> + - mock_utmi: Mock utmi clock needed for ITP/SOF generation in host
> mode. Its frequency should be 19.2MHz.
> minItems: 1
> maxItems: 9
> diff --git a/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
> index 8201656b41ed..d99af9f413d0 100644
> --- a/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
> +++ b/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
> @@ -87,14 +87,14 @@ properties:
>
> clocks:
> description: |
> - Several clocks are used, depending on the variant. Typical ones are::
> - - cfg_noc:: System Config NOC clock.
> - - core:: Master/Core clock, has to be >= 125 MHz for SS operation and >=
> + Several clocks are used, depending on the variant. Typical ones are:
> + - cfg_noc: System Config NOC clock.
> + - core: Master/Core clock, has to be >= 125 MHz for SS operation and >=
> 60MHz for HS operation.
> - - iface:: System bus AXI clock.
> - - sleep:: Sleep clock, used for wakeup when USB3 core goes into low
> + - iface: System bus AXI clock.
> + - sleep: Sleep clock, used for wakeup when USB3 core goes into low
> power mode (U3).
> - - mock_utmi:: Mock utmi clock needed for ITP/SOF generation in host
> + - mock_utmi: Mock utmi clock needed for ITP/SOF generation in host
> mode. Its frequency should be 19.2MHz.
> minItems: 1
> maxItems: 9
> --
> 2.53.0
>
--
Kind Regards,
Niklas Söderlund
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: Drop incorrect usage of double '::'
From: Mark Brown @ 2026-06-22 10:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Peter Griffin, Alim Akhtar, Michael Turquette,
Stephen Boyd, Brian Masney, Sylwester Nawrocki, Chanwoo Choi,
Sam Protsenko, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Andi Shyti, Georgi Djakov, Lee Jones, Pavel Machek, Hans Verkuil,
Mauro Carvalho Chehab, Ulf Hansson, Peter Rosin, Vinod Koul,
Neil Armstrong, Linus Walleij, Geert Uytterhoeven, Magnus Damm,
Sebastian Reichel, Javier Martinez Canillas, Liam Girdwood,
Greg Kroah-Hartman, Jiri Slaby, Srinivas Kandagatla,
Bartlomiej Zolnierkiewicz, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Jonathan Marek, Taniya Das, Robert Marko,
Christian Marangi, Stephan Gerhold, Adam Skladowski,
Sireesh Kodali, Barnabas Czeman, Imran Shaik,
Sricharan Ramabadhran, Anusha Rao, Luo Jie, Tomasz Figa,
Chanho Park, Sunyeal Hong, Shin Son, Krishna Manikandan,
Jacek Anaszewski, Jaehoon Chung, Marek Szyprowski, Alina Yu,
Andy Gross, Niklas Söderlund, Wesley Cheng, linux-arm-msm,
devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-clk, dri-devel, freedreno, linux-i2c, linux-pm, linux-leds,
linux-media, linux-mmc, linux-phy, linux-gpio, linux-renesas-soc,
linux-serial, linux-sound, linux-usb
In-Reply-To: <20260622101606.485961-4-krzysztof.kozlowski@oss.qualcomm.com>
[-- Attachment #1.1: Type: text/plain, Size: 334 bytes --]
On Mon, Jun 22, 2026 at 12:16:08PM +0200, Krzysztof Kozlowski wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
Acked-by: Mark Brown <broonie@kernel.org>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 112 bytes --]
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: Drop incorrect usage of double '::'
From: Geert Uytterhoeven @ 2026-06-22 10:32 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Peter Griffin, Alim Akhtar, Michael Turquette,
Stephen Boyd, Brian Masney, Sylwester Nawrocki, Chanwoo Choi,
Sam Protsenko, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Andi Shyti, Georgi Djakov, Lee Jones, Pavel Machek, Hans Verkuil,
Mauro Carvalho Chehab, Ulf Hansson, Peter Rosin, Vinod Koul,
Neil Armstrong, Linus Walleij, Geert Uytterhoeven, Magnus Damm,
Sebastian Reichel, Javier Martinez Canillas, Liam Girdwood,
Mark Brown, Greg Kroah-Hartman, Jiri Slaby, Srinivas Kandagatla,
Bartlomiej Zolnierkiewicz, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Jonathan Marek, Taniya Das, Robert Marko,
Christian Marangi, Stephan Gerhold, Adam Skladowski,
Sireesh Kodali, Barnabas Czeman, Imran Shaik,
Sricharan Ramabadhran, Anusha Rao, Luo Jie, Tomasz Figa,
Chanho Park, Sunyeal Hong, Shin Son, Krishna Manikandan,
Jacek Anaszewski, Jaehoon Chung, Marek Szyprowski, Alina Yu,
Andy Gross, Niklas Söderlund, Wesley Cheng, linux-arm-msm,
devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-clk, dri-devel, freedreno, linux-i2c, linux-pm, linux-leds,
linux-media, linux-mmc, linux-phy, linux-gpio, linux-renesas-soc,
linux-serial, linux-sound, linux-usb
In-Reply-To: <20260622101606.485961-4-krzysztof.kozlowski@oss.qualcomm.com>
On Mon, 22 Jun 2026 at 12:16, Krzysztof Kozlowski
<krzysztof.kozlowski@oss.qualcomm.com> wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
>
> Cleanup existing code, so the confusing style won't be re-used in new
> contributions.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Intention for this patch is to go via Rob's tree.
> .../bindings/power/renesas,rcar-sysc.yaml | 2 +-
> .../bindings/soc/renesas/renesas-soc.yaml | 4 ++--
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> # renesas
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: Drop incorrect usage of double '::'
From: sashiko-bot @ 2026-06-22 10:19 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: neil.armstrong, vkoul, dri-devel, robh, conor+dt, linux-phy,
olteanv, devicetree, wsa+renesas
In-Reply-To: <20260622101606.485961-4-krzysztof.kozlowski@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Unintended replacement of BNF notation `::=` with `:=`.
--
commit a9fdd0b065eb5b6394a9c33ffba0fd5194e80115
Author: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
dt-bindings: Drop incorrect usage of double '::'
This commit cleans up device tree binding schemas by removing the redundant
double colons at the end of descriptions inside YAML literal style blocks.
Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> diff --git a/Documentation/devicetree/bindings/mux/mux-consumer.yaml b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
> index 9e2d78a78e409..769243a2bf046 100644
> --- a/Documentation/devicetree/bindings/mux/mux-consumer.yaml
> +++ b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
> @@ -13,8 +13,8 @@ description: |
> Mux controller consumers should specify a list of mux controllers that they
> want to use with a property containing a 'mux-ctrl-list':
>
> - mux-ctrl-list ::= <single-mux-ctrl> [mux-ctrl-list]
> - single-mux-ctrl ::= <mux-ctrl-phandle> [mux-ctrl-specifier]
> + mux-ctrl-list := <single-mux-ctrl> [mux-ctrl-list]
> + single-mux-ctrl := <mux-ctrl-phandle> [mux-ctrl-specifier]
[Severity: Low]
Does this unintentionally change the standard Backus-Naur Form (BNF) ::=
operator to :=? It looks like a global search-and-replace for :: might
have accidentally caught these BNF production rules.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260622101606.485961-3-krzysztof.kozlowski@oss.qualcomm.com?part=2
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH 2/2] dt-bindings: Drop incorrect usage of double '::'
From: Krzysztof Kozlowski @ 2026-06-22 10:16 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Peter Griffin, Alim Akhtar, Michael Turquette,
Stephen Boyd, Brian Masney, Sylwester Nawrocki, Chanwoo Choi,
Sam Protsenko, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Andi Shyti, Georgi Djakov, Lee Jones, Pavel Machek, Hans Verkuil,
Mauro Carvalho Chehab, Ulf Hansson, Peter Rosin, Vinod Koul,
Neil Armstrong, Linus Walleij, Geert Uytterhoeven, Magnus Damm,
Sebastian Reichel, Javier Martinez Canillas, Liam Girdwood,
Mark Brown, Greg Kroah-Hartman, Jiri Slaby, Srinivas Kandagatla,
Bartlomiej Zolnierkiewicz, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Jonathan Marek, Taniya Das, Robert Marko,
Christian Marangi, Stephan Gerhold, Adam Skladowski,
Sireesh Kodali, Barnabas Czeman, Imran Shaik,
Sricharan Ramabadhran, Anusha Rao, Luo Jie, Tomasz Figa,
Chanho Park, Sunyeal Hong, Shin Son, Krishna Manikandan,
Jacek Anaszewski, Jaehoon Chung, Marek Szyprowski, Alina Yu,
Andy Gross, Niklas Söderlund, Wesley Cheng, linux-arm-msm,
devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-clk, dri-devel, freedreno, linux-i2c, linux-pm, linux-leds,
linux-media, linux-mmc, linux-phy, linux-gpio, linux-renesas-soc,
linux-serial, linux-sound, linux-usb
Cc: Krzysztof Kozlowski
In-Reply-To: <20260622101606.485961-3-krzysztof.kozlowski@oss.qualcomm.com>
There is no use of double colon '::' in YAML. OTOH, the literal style
block, e.g. using '|' treats all characters as content [1] therefore
single use of ':' in descriptions is perfectly fine, whenever '|' is
used.
Cleanup existing code, so the confusing style won't be re-used in new
contributions.
Link: https://yaml.org/spec/1.2.2/#literal-style [1]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Intention for this patch is to go via Rob's tree.
---
.../devicetree/bindings/arm/qcom-soc.yaml | 4 ++--
.../devicetree/bindings/arm/qcom.yaml | 4 ++--
.../bindings/arm/samsung/samsung-soc.yaml | 4 ++--
.../display/msm/dsi-controller-main.yaml | 20 +++++++++----------
.../display/samsung/samsung,fimd.yaml | 4 ++--
.../bindings/i2c/samsung,s3c2410-i2c.yaml | 2 +-
.../interconnect/qcom,msm8998-bwmon.yaml | 2 +-
.../interconnect/samsung,exynos-bus.yaml | 14 ++++++-------
.../bindings/leds/qcom,pm8058-led.yaml | 4 ++--
.../bindings/leds/skyworks,aat1290.yaml | 6 +++---
.../bindings/media/cec/cec-gpio.yaml | 2 +-
.../bindings/mmc/samsung,exynos-dw-mshc.yaml | 2 +-
.../devicetree/bindings/mux/mux-consumer.yaml | 4 ++--
.../bindings/phy/samsung,mipi-video-phy.yaml | 4 ++--
.../bindings/phy/samsung,usb2-phy.yaml | 2 +-
.../bindings/phy/samsung,usb3-drd-phy.yaml | 2 +-
.../bindings/pinctrl/samsung,pinctrl.yaml | 2 +-
.../bindings/power/renesas,rcar-sysc.yaml | 2 +-
.../bindings/power/reset/restart-handler.yaml | 8 ++++----
.../bindings/regulator/maxim,max77802.yaml | 4 ++--
.../bindings/regulator/richtek,rtq2208.yaml | 2 +-
.../bindings/serial/qcom,msm-uartdm.yaml | 2 +-
.../devicetree/bindings/slimbus/slimbus.yaml | 4 ++--
.../bindings/soc/qcom/qcom,apr-services.yaml | 2 +-
.../bindings/soc/qcom/qcom,rpmh-rsc.yaml | 8 ++++----
.../bindings/soc/qcom/qcom,wcnss.yaml | 2 +-
.../bindings/soc/renesas/renesas-soc.yaml | 4 ++--
.../bindings/sound/qcom,q6asm-dais.yaml | 2 +-
.../thermal/samsung,exynos-thermal.yaml | 4 ++--
.../devicetree/bindings/usb/qcom,dwc3.yaml | 12 +++++------
.../bindings/usb/qcom,snps-dwc3.yaml | 12 +++++------
31 files changed, 75 insertions(+), 75 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/qcom-soc.yaml b/Documentation/devicetree/bindings/arm/qcom-soc.yaml
index 27261039d56f..37fdd5a080b7 100644
--- a/Documentation/devicetree/bindings/arm/qcom-soc.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom-soc.yaml
@@ -11,10 +11,10 @@ maintainers:
description: |
Guidelines for new compatibles for SoC blocks/components.
- When adding new compatibles in new bindings, use the format::
+ When adding new compatibles in new bindings, use the format:
qcom,SoC-IP
- For example::
+ For example:
qcom,sdm845-llcc-bwmon
When adding new compatibles to existing bindings, use the format in the
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 50cc18a6ec5e..667607ae2c32 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -1215,7 +1215,7 @@ properties:
items:
items:
- description: |
- MSM chipset ID - an exact match value consisting of two bitfields::
+ MSM chipset ID - an exact match value consisting of two bitfields:
- bits 0-15 - The unique MSM chipset ID
- bits 16-31 - Reserved; should be 0
- description: |
@@ -1241,7 +1241,7 @@ properties:
- items:
- items:
- description: |
- Board ID consisting of three bitfields::
+ Board ID consisting of three bitfields:
- bits 31-24 - Unused
- bits 23-16 - Platform Version Major
- bits 15-8 - Platform Version Minor
diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml
index 653f85997643..ab000befe76d 100644
--- a/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml
+++ b/Documentation/devicetree/bindings/arm/samsung/samsung-soc.yaml
@@ -11,10 +11,10 @@ maintainers:
description: |
Guidelines for new compatibles for SoC blocks/components.
- When adding new compatibles in new bindings, use the format::
+ When adding new compatibles in new bindings, use the format:
samsung,SoC-IP
- For example::
+ For example:
samsung,exynos5433-cmu-isp
select:
diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index dbc0613e427e..395425a70db8 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -73,16 +73,16 @@ properties:
clocks:
description: |
- Several clocks are used, depending on the variant. Typical ones are::
- - bus:: Display AHB clock.
- - byte:: Display byte clock.
- - byte_intf:: Display byte interface clock.
- - core:: Display core clock.
- - core_mss:: Core MultiMedia SubSystem clock.
- - iface:: Display AXI clock.
- - mdp_core:: MDP Core clock.
- - mnoc:: MNOC clock
- - pixel:: Display pixel clock.
+ Several clocks are used, depending on the variant. Typical ones are:
+ - bus: Display AHB clock.
+ - byte: Display byte clock.
+ - byte_intf: Display byte interface clock.
+ - core: Display core clock.
+ - core_mss: Core MultiMedia SubSystem clock.
+ - iface: Display AXI clock.
+ - mdp_core: MDP Core clock.
+ - mnoc: MNOC clock
+ - pixel: Display pixel clock.
minItems: 3
maxItems: 12
diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml
index ff685031bb2c..729705f419bb 100644
--- a/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml
+++ b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml
@@ -41,7 +41,7 @@ properties:
additionalProperties: false
description: |
Timing configuration for lcd i80 interface support.
- The parameters are defined as::
+ The parameters are defined as:
VCLK(internal) __|??????|_____|??????|_____|??????|_____|??????|_____|??
: : : : :
Address Output --:<XXXXXXXXXXX:XXXXXXXXXXXX:XXXXXXXXXXXX:XXXXXXXXXXXX:XX
@@ -132,7 +132,7 @@ patternProperties:
"^port@[0-4]+$":
$ref: /schemas/graph.yaml#/properties/port
description: |
- Contains ports with port with index::
+ Contains ports with port with index:
0 - for CAMIF0 input,
1 - for CAMIF1 input,
2 - for CAMIF2 input,
diff --git a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
index a2ddc6803617..07600b49f2f9 100644
--- a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml
@@ -35,7 +35,7 @@ properties:
gpios:
description: |
- The order of the GPIOs should be the following:: <SDA, SCL>. The GPIO
+ The order of the GPIOs should be the following: <SDA, SCL>. The GPIO
specifier depends on the gpio controller. Required in all cases except
for "samsung,s3c2440-hdmiphy-i2c" whose input/output lines are
permanently wired to the respective client.
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
index ff64225e8281..e002e70580f9 100644
--- a/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
+++ b/Documentation/devicetree/bindings/interconnect/qcom,msm8998-bwmon.yaml
@@ -13,7 +13,7 @@ description: |
Bandwidth Monitor measures current throughput on buses between various NoC
fabrics and provides information when it crosses configured thresholds.
- Certain SoCs might have more than one Bandwidth Monitors, for example on SDM845::
+ Certain SoCs might have more than one Bandwidth Monitors, for example on SDM845:
- Measuring the bandwidth between CPUs and Last Level Cache Controller -
called just BWMON,
- Measuring the bandwidth between Last Level Cache Controller and memory
diff --git a/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml b/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
index 5e26e48c7217..0203959c8995 100644
--- a/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
+++ b/Documentation/devicetree/bindings/interconnect/samsung,exynos-bus.yaml
@@ -23,7 +23,7 @@ description: |
The each AXI bus has the owned source clock but, has not the only owned power
line. The power line might be shared among one more sub-blocks. So, we can
divide into two type of device as the role of each sub-block. There are two
- type of bus devices as following::
+ type of bus devices as following:
- parent bus device
- passive bus device
@@ -44,8 +44,8 @@ description: |
able to support the bus frequency for all Exynos SoCs.
Detailed correlation between sub-blocks and power line according
- to Exynos SoC::
- - In case of Exynos3250, there are two power line as following::
+ to Exynos SoC:
+ - In case of Exynos3250, there are two power line as following:
VDD_MIF |--- DMC (Dynamic Memory Controller)
VDD_INT |--- LEFTBUS (parent device)
@@ -89,7 +89,7 @@ description: |
|L5 |200000 |200000 |400000 |300000 | ||1000000 |
----------------------------------------------------------
- - In case of Exynos4210, there is one power line as following::
+ - In case of Exynos4210, there is one power line as following:
VDD_INT |--- DMC (parent device, Dynamic Memory Controller)
|--- LEFTBUS
|--- PERIL
@@ -106,7 +106,7 @@ description: |
|--- LCD0
|--- LCD1
- - In case of Exynos4x12, there are two power line as following::
+ - In case of Exynos4x12, there are two power line as following:
VDD_MIF |--- DMC (Dynamic Memory Controller)
VDD_INT |--- LEFTBUS (parent device)
@@ -124,7 +124,7 @@ description: |
|--- LCD0
|--- ISP
- - In case of Exynos5422, there are two power line as following::
+ - In case of Exynos5422, there are two power line as following:
VDD_MIF |--- DREX 0 (parent device, DRAM EXpress controller)
|--- DREX 1
@@ -143,7 +143,7 @@ description: |
|--- FSYS
|--- FSYS2
- - In case of Exynos5433, there is VDD_INT power line as following::
+ - In case of Exynos5433, there is VDD_INT power line as following:
VDD_INT |--- G2D (parent device)
|--- MSCL
|--- GSCL
diff --git a/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml b/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml
index b409b2a8b5c5..5165bfddcd54 100644
--- a/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml
+++ b/Documentation/devicetree/bindings/leds/qcom,pm8058-led.yaml
@@ -10,10 +10,10 @@ maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
description: |
- The Qualcomm PM8058 contains an LED block for up to six LEDs:: three normal
+ The Qualcomm PM8058 contains an LED block for up to six LEDs: three normal
LEDs, two "flash" LEDs and one "keypad backlight" LED. The names are quoted
because sometimes these LED drivers are used for wildly different things than
- flash or keypad backlight:: their names are more of a suggestion than a
+ flash or keypad backlight: their names are more of a suggestion than a
hard-wired usecase.
Hardware-wise the different LEDs support slightly different output currents.
diff --git a/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml b/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml
index a6aaa92dbccd..65576dfdca11 100644
--- a/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml
+++ b/Documentation/devicetree/bindings/leds/skyworks,aat1290.yaml
@@ -11,7 +11,7 @@ maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
description: |
- The device is controlled through two pins:: FL_EN and EN_SET. The pins when,
+ The device is controlled through two pins: FL_EN and EN_SET. The pins when,
asserted high, enable flash strobe and movie mode (max 1/2 of flash current)
respectively. In order to add a capability of selecting the strobe signal
source (e.g. CPU or camera sensor) there is an additional switch required,
@@ -39,11 +39,11 @@ properties:
flash-max-microamp:
description: |
Maximum flash LED supply current can be calculated using following
- formula:: I = 1A * 162 kOhm / Rset.
+ formula: I = 1A * 162 kOhm / Rset.
flash-max-timeout-us:
description: |
- Maximum flash timeout can be calculated using following formula::
+ Maximum flash timeout can be calculated using following formula:
T = 8.82 * 10^9 * Ct.
required:
diff --git a/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml b/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml
index 582c6c9cae48..21118e4bae0f 100644
--- a/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml
+++ b/Documentation/devicetree/bindings/media/cec/cec-gpio.yaml
@@ -14,7 +14,7 @@ description: |
hooked up to a pull-up GPIO line and - optionally - the HPD line is hooked up
to another GPIO line.
- Please note:: the maximum voltage for the CEC line is 3.63V, for the HPD and
+ Please note: the maximum voltage for the CEC line is 3.63V, for the HPD and
5V lines it is 5.3V. So you may need some sort of level conversion
circuitry when connecting them to a GPIO line.
diff --git a/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
index 27c4060f2f91..223fcc9f651f 100644
--- a/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
+++ b/Documentation/devicetree/bindings/mmc/samsung,exynos-dw-mshc.yaml
@@ -85,7 +85,7 @@ properties:
description: |
The value of CIU TX and RX clock phase shift value for HS400 mode
operation.
- Valid values for SDR and DDR CIU clock timing::
+ Valid values for SDR and DDR CIU clock timing:
- valid value for tx phase shift and rx phase shift is 0 to 7.
- when CIU clock divider value is set to 3, all possible 8 phase shift
values can be used.
diff --git a/Documentation/devicetree/bindings/mux/mux-consumer.yaml b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
index 9e2d78a78e40..769243a2bf04 100644
--- a/Documentation/devicetree/bindings/mux/mux-consumer.yaml
+++ b/Documentation/devicetree/bindings/mux/mux-consumer.yaml
@@ -13,8 +13,8 @@ description: |
Mux controller consumers should specify a list of mux controllers that they
want to use with a property containing a 'mux-ctrl-list':
- mux-ctrl-list ::= <single-mux-ctrl> [mux-ctrl-list]
- single-mux-ctrl ::= <mux-ctrl-phandle> [mux-ctrl-specifier]
+ mux-ctrl-list := <single-mux-ctrl> [mux-ctrl-list]
+ single-mux-ctrl := <mux-ctrl-phandle> [mux-ctrl-specifier]
mux-ctrl-phandle : phandle to mux controller node
mux-ctrl-specifier : array of #mux-control-cells specifying the
given mux controller (controller specific)
diff --git a/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
index 16967ef8e9ec..87b6a35b2626 100644
--- a/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml
@@ -13,14 +13,14 @@ maintainers:
description: |
For samsung,s5pv210-mipi-video-phy compatible PHYs the second cell in the
- PHY specifier identifies the PHY and its meaning is as follows::
+ PHY specifier identifies the PHY and its meaning is as follows:
0 - MIPI CSIS 0,
1 - MIPI DSIM 0,
2 - MIPI CSIS 1,
3 - MIPI DSIM 1.
samsung,exynos5420-mipi-video-phy and samsung,exynos5433-mipi-video-phy
- support additional fifth PHY::
+ support additional fifth PHY:
4 - MIPI CSIS 2.
properties:
diff --git a/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml
index d9f22a801cbf..7db7605a82e2 100644
--- a/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml
@@ -14,7 +14,7 @@ maintainers:
description: |
The first phandle argument in the PHY specifier identifies the PHY, its
meaning is compatible dependent. For the currently supported SoCs (Exynos4210
- and Exynos4212) it is as follows::
+ and Exynos4212) it is as follows:
0 - USB device ("device"),
1 - USB host ("host"),
2 - HSIC0 ("hsic0"),
diff --git a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
index 4562e0468f4f..a1b3d9e6a094 100644
--- a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml
@@ -14,7 +14,7 @@ maintainers:
description: |
For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy
compatible PHYs, the second cell in the PHY specifier identifies the
- PHY id, which is interpreted as follows::
+ PHY id, which is interpreted as follows:
0 - UTMI+ type phy,
1 - PIPE3 type phy.
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
index 7b006009ca0e..5e35686eeed3 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
@@ -18,7 +18,7 @@ description: |
All the pin controller nodes should be represented in the aliases node using
the following format 'pinctrl{n}' where n is a unique number for the alias.
- The controller supports three types of interrupts::
+ The controller supports three types of interrupts:
- External GPIO interrupts (see interrupts property in pin controller node);
- External wake-up interrupts - multiplexed (capable of waking up the system
diff --git a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml
index 347571e2545a..b67aa170b2c1 100644
--- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml
+++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.yaml
@@ -13,7 +13,7 @@ maintainers:
description: |
The R-Car (RZ/G) System Controller provides power management for the CPU
cores and various coprocessors.
- The power domain IDs for consumers are defined in header files::
+ The power domain IDs for consumers are defined in header files:
include/dt-bindings/power/r8*-sysc.h
properties:
diff --git a/Documentation/devicetree/bindings/power/reset/restart-handler.yaml b/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
index 965a834a3dbe..00c00ec5ec81 100644
--- a/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
+++ b/Documentation/devicetree/bindings/power/reset/restart-handler.yaml
@@ -18,12 +18,12 @@ properties:
priority:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
- A priority ranging from 0 to 255 according to the following guidelines::
- 0:: Restart handler of last resort, with limited restart capabilities.
- 128:: Typical, default restart handler; use if no other restart handler
+ A priority ranging from 0 to 255 according to the following guidelines:
+ 0: Restart handler of last resort, with limited restart capabilities.
+ 128: Typical, default restart handler; use if no other restart handler
is expected to be available, and/or if restart functionality is
sufficient to restart the entire system.
- 255:: Highest priority restart handler, will preempt all other restart handlers.
+ 255: Highest priority restart handler, will preempt all other restart handlers.
minimum: 0
maximum: 255
diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml
index b704f05ea454..b886495c1396 100644
--- a/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml
+++ b/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml
@@ -22,13 +22,13 @@ description: |
Certain regulators support "regulator-initial-mode" and "regulator-mode".
The valid modes list is defined in the dt-bindings/regulator/maxim,max77802.h
- and their meaning is::
+ and their meaning is:
1 - Normal regulator voltage output mode.
3 - Low Power which reduces the quiescent current down to only 1uA
The standard "regulator-mode" property can only be used for regulators that
support changing their mode to Low Power Mode during suspend. These
- regulators are:: bucks 2-4 and LDOs 1-35. Also, it only takes effect if the
+ regulators are: bucks 2-4 and LDOs 1-35. Also, it only takes effect if the
regulator has been enabled for the given suspend state using
"regulator-on-in-suspend" and has not been disabled for that state using
"regulator-off-in-suspend".
diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
index 022c1f197364..b0aa38edf8c2 100644
--- a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
+++ b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
@@ -21,7 +21,7 @@ description: |
conduction mode (FCCM).
The definition of modes is in the datasheet which is available in below link
- and their meaning is::
+ and their meaning is:
0 - Auto mode for power saving, which reducing the switching frequency at light load condition
to maintain high frequency.
1 - FCCM to meet the strict voltage regulation accuracy, which keeping constant switching frequency.
diff --git a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml
index 788ef5c1c446..bc967ead2350 100644
--- a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml
+++ b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.yaml
@@ -17,7 +17,7 @@ description: |
software perspective it's mostly compatible with the MSM serial UART except
that it supports reading and writing multiple characters at a time.
- Note:: Aliases may be defined to ensure the correct ordering of the UARTs.
+ Note: Aliases may be defined to ensure the correct ordering of the UARTs.
The alias serialN will result in the UART being assigned port N. If any
serialN alias exists, then an alias must exist for each enabled UART. The
serialN aliases should be in a .dts file instead of in a .dtsi file.
diff --git a/Documentation/devicetree/bindings/slimbus/slimbus.yaml b/Documentation/devicetree/bindings/slimbus/slimbus.yaml
index 5a941610ce4e..3910327c8ded 100644
--- a/Documentation/devicetree/bindings/slimbus/slimbus.yaml
+++ b/Documentation/devicetree/bindings/slimbus/slimbus.yaml
@@ -29,7 +29,7 @@ patternProperties:
description: |
Every SLIMbus controller node can contain zero or more child nodes
representing slave devices on the bus. Every SLIMbus slave device is
- uniquely determined by the enumeration address containing 4 fields::
+ uniquely determined by the enumeration address containing 4 fields:
Manufacturer ID, Product code, Device index, and Instance value for the
device.
@@ -48,7 +48,7 @@ patternProperties:
reg:
maxItems: 1
description: |
- Pair of (device index, instande ID), where::
+ Pair of (device index, instande ID), where:
- Device index, which uniquely identifies multiple devices within a
single component.
- Instance ID, can be used for the cases where multiple devices of
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml
index bdf482db32aa..b663be3ea5a1 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,apr-services.yaml
@@ -40,7 +40,7 @@ properties:
$ref: /schemas/types.yaml#/definitions/string-array
description: |
Protection domain service name and path for APR service (if supported).
- Possible values are::
+ Possible values are:
"avs/audio", "msm/adsp/audio_pd".
"kernel/elf_loader", "msm/modem/wlan_pd".
"tms/servreg", "msm/adsp/audio_pd".
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
index 26d9bc773ec5..1889139a3f7a 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,rpmh-rsc.yaml
@@ -23,7 +23,7 @@ description: |
with a few variations that are captured by the properties here.
A TCS may be triggered from Linux or triggered by the F/W after all the CPUs
- have powered off to facilitate idle power saving. TCS could be classified as::
+ have powered off to facilitate idle power saving. TCS could be classified as:
ACTIVE - Triggered by Linux
SLEEP - Triggered by F/W
WAKE - Triggered by F/W
@@ -76,7 +76,7 @@ properties:
items:
items:
- description: |
- TCS type::
+ TCS type:
- ACTIVE_TCS
- SLEEP_TCS
- WAKE_TCS
@@ -152,7 +152,7 @@ examples:
- |
// For a TCS whose RSC base address is 0x179C0000 and is at a DRV id of
// 2, the register offsets for DRV2 start at 0D00, the register
- // calculations are like this::
+ // calculations are like this:
// DRV0: 0x179C0000
// DRV2: 0x179C0000 + 0x10000 = 0x179D0000
// DRV2: 0x179C0000 + 0x10000 * 2 = 0x179E0000
@@ -182,7 +182,7 @@ examples:
- |
// For a TCS whose RSC base address is 0xAF20000 and is at DRV id of 0, the
// register offsets for DRV0 start at 01C00, the register calculations are
- // like this::
+ // like this:
// DRV0: 0xAF20000
// TCS-OFFSET: 0x1C00
#include <dt-bindings/interrupt-controller/arm-gic.h>
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml
index 4fcae6bedfff..72a7f8cb09ba 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,wcnss.yaml
@@ -28,7 +28,7 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle
description: |
Reference to a node specifying the wcnss "ccu" and "dxe" register blocks.
- The node must be compatible with one of the following::
+ The node must be compatible with one of the following:
- qcom,riva"
- qcom,pronto"
diff --git a/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml
index 5ddd31f30f26..57c9d3c57021 100644
--- a/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml
+++ b/Documentation/devicetree/bindings/soc/renesas/renesas-soc.yaml
@@ -12,10 +12,10 @@ maintainers:
description: |
Guidelines for new compatibles for SoC blocks/components.
- When adding new compatibles in new bindings, use the format::
+ When adding new compatibles in new bindings, use the format:
renesas,SoC-IP
- For example::
+ For example:
renesas,r8a77965-csi2
When adding new compatibles to existing bindings, use the format in the
diff --git a/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml b/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml
index 47a105a97ecf..bc8c8ba24f9c 100644
--- a/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,q6asm-dais.yaml
@@ -45,7 +45,7 @@ patternProperties:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2]
description: |
- The direction of the dai stream::
+ The direction of the dai stream:
- Q6ASM_DAI_TX_RX (0) for both tx and rx
- Q6ASM_DAI_TX (1) for only tx (Capture/Encode)
- Q6ASM_DAI_RX (2) for only rx (Playback/Decode)
diff --git a/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml b/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml
index 29a08b0729ee..3f333db72a71 100644
--- a/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml
@@ -40,7 +40,7 @@ properties:
description: |
The Exynos TMU supports generating interrupts when reaching given
temperature thresholds. Number of supported thermal trip points depends
- on the SoC (only first trip points defined in DT will be configured)::
+ on the SoC (only first trip points defined in DT will be configured):
- most of SoC: 4
- samsung,exynos5433-tmu: 8
- samsung,exynos7-tmu: 8
@@ -52,7 +52,7 @@ properties:
- description: |
Shared TMU registers.
- Note:: On Exynos5420, the TRIMINFO register is misplaced for TMU
+ Note: On Exynos5420, the TRIMINFO register is misplaced for TMU
channels 2, 3 and 4 Use "samsung,exynos5420-tmu-ext-triminfo" in
cases, there is a misplaced register, also provide clock to access
that base.
diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
index a7f58114c02e..90daee616880 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml
@@ -92,14 +92,14 @@ properties:
clocks:
description: |
- Several clocks are used, depending on the variant. Typical ones are::
- - cfg_noc:: System Config NOC clock.
- - core:: Master/Core clock, has to be >= 125 MHz for SS operation and >=
+ Several clocks are used, depending on the variant. Typical ones are:
+ - cfg_noc: System Config NOC clock.
+ - core: Master/Core clock, has to be >= 125 MHz for SS operation and >=
60MHz for HS operation.
- - iface:: System bus AXI clock.
- - sleep:: Sleep clock, used for wakeup when USB3 core goes into low
+ - iface: System bus AXI clock.
+ - sleep: Sleep clock, used for wakeup when USB3 core goes into low
power mode (U3).
- - mock_utmi:: Mock utmi clock needed for ITP/SOF generation in host
+ - mock_utmi: Mock utmi clock needed for ITP/SOF generation in host
mode. Its frequency should be 19.2MHz.
minItems: 1
maxItems: 9
diff --git a/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
index 8201656b41ed..d99af9f413d0 100644
--- a/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
+++ b/Documentation/devicetree/bindings/usb/qcom,snps-dwc3.yaml
@@ -87,14 +87,14 @@ properties:
clocks:
description: |
- Several clocks are used, depending on the variant. Typical ones are::
- - cfg_noc:: System Config NOC clock.
- - core:: Master/Core clock, has to be >= 125 MHz for SS operation and >=
+ Several clocks are used, depending on the variant. Typical ones are:
+ - cfg_noc: System Config NOC clock.
+ - core: Master/Core clock, has to be >= 125 MHz for SS operation and >=
60MHz for HS operation.
- - iface:: System bus AXI clock.
- - sleep:: Sleep clock, used for wakeup when USB3 core goes into low
+ - iface: System bus AXI clock.
+ - sleep: Sleep clock, used for wakeup when USB3 core goes into low
power mode (U3).
- - mock_utmi:: Mock utmi clock needed for ITP/SOF generation in host
+ - mock_utmi: Mock utmi clock needed for ITP/SOF generation in host
mode. Its frequency should be 19.2MHz.
minItems: 1
maxItems: 9
--
2.53.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: clock: Drop incorrect usage of double '::'
From: Krzysztof Kozlowski @ 2026-06-22 10:16 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Peter Griffin, Alim Akhtar, Michael Turquette,
Stephen Boyd, Brian Masney, Sylwester Nawrocki, Chanwoo Choi,
Sam Protsenko, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Inki Dae, Seung-Woo Kim, Kyungmin Park,
Andi Shyti, Georgi Djakov, Lee Jones, Pavel Machek, Hans Verkuil,
Mauro Carvalho Chehab, Ulf Hansson, Peter Rosin, Vinod Koul,
Neil Armstrong, Linus Walleij, Geert Uytterhoeven, Magnus Damm,
Sebastian Reichel, Javier Martinez Canillas, Liam Girdwood,
Mark Brown, Greg Kroah-Hartman, Jiri Slaby, Srinivas Kandagatla,
Bartlomiej Zolnierkiewicz, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Jonathan Marek, Taniya Das, Robert Marko,
Christian Marangi, Stephan Gerhold, Adam Skladowski,
Sireesh Kodali, Barnabas Czeman, Imran Shaik,
Sricharan Ramabadhran, Anusha Rao, Luo Jie, Tomasz Figa,
Chanho Park, Sunyeal Hong, Shin Son, Krishna Manikandan,
Jacek Anaszewski, Jaehoon Chung, Marek Szyprowski, Alina Yu,
Andy Gross, Niklas Söderlund, Wesley Cheng, linux-arm-msm,
devicetree, linux-kernel, linux-arm-kernel, linux-samsung-soc,
linux-clk, dri-devel, freedreno, linux-i2c, linux-pm, linux-leds,
linux-media, linux-mmc, linux-phy, linux-gpio, linux-renesas-soc,
linux-serial, linux-sound, linux-usb
Cc: Krzysztof Kozlowski
There is no use of double colon '::' in YAML. OTOH, the literal style
block, e.g. using '|' treats all characters as content [1] therefore
single use of ':' in descriptions is perfectly fine, whenever '|' is
used.
Cleanup existing code, so the confusing style won't be re-used in new
contributions.
Link: https://yaml.org/spec/1.2.2/#literal-style [1]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
I split the patches to avoid bounces from mailing list due to email size.
This can go via clock tree (no dependencies)... or both could go via
Rob's tree.
---
.../devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-apq8064.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-apq8084.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-ipq6018.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-ipq8064.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-mdm9607.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-mdm9615.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-msm8660.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-msm8909.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-msm8916.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-msm8953.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-msm8974.yaml | 2 +-
.../devicetree/bindings/clock/qcom,gcc-sdm660.yaml | 2 +-
Documentation/devicetree/bindings/clock/qcom,gpucc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,ipq5018-gcc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,ipq9574-gcc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,qca8k-nsscc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml | 2 +-
Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml | 2 +-
.../devicetree/bindings/clock/qcom,sm8350-videocc.yaml | 2 +-
Documentation/devicetree/bindings/clock/qcom,videocc.yaml | 2 +-
.../devicetree/bindings/clock/samsung,exynos5260-clock.yaml | 6 +++---
.../devicetree/bindings/clock/samsung,exynos5410-clock.yaml | 2 +-
.../devicetree/bindings/clock/samsung,exynos5433-clock.yaml | 2 +-
.../devicetree/bindings/clock/samsung,exynos7-clock.yaml | 2 +-
.../devicetree/bindings/clock/samsung,exynos850-clock.yaml | 2 +-
.../bindings/clock/samsung,exynosautov9-clock.yaml | 2 +-
.../bindings/clock/samsung,exynosautov920-clock.yaml | 2 +-
.../devicetree/bindings/clock/samsung,s5pv210-clock.yaml | 2 +-
32 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
index 53a5ab319159..6863db9bd092 100644
--- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm display clock control module provides the clocks, resets and power
domains on SM8150/SM8250/SM8350.
- See also::
+ See also:
include/dt-bindings/clock/qcom,dispcc-sm8150.h
include/dt-bindings/clock/qcom,dispcc-sm8250.h
include/dt-bindings/clock/qcom,dispcc-sm8350.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml
index 27df7e3e5bf3..68532244901e 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on APQ8064.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8960.h
include/dt-bindings/reset/qcom,gcc-msm8960.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml
index 0a0a26d9beab..1c022e75fd71 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8084.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on APQ8084.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-apq8084.h
include/dt-bindings/reset/qcom,gcc-apq8084.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq6018.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq6018.yaml
index 4d2614d4f368..c7fb84438db7 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq6018.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq6018.yaml
@@ -15,7 +15,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on IPQ6018.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-ipq6018.h
include/dt-bindings/reset/qcom,gcc-ipq6018.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml
index a71557395c01..b4d3175780bc 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on IPQ8064.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064)
include/dt-bindings/reset/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064)
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9607.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9607.yaml
index d7da30b0e7ee..0a7be7583bdd 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9607.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9607.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-mdm9607.h
allOf:
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9615.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9615.yaml
index 418dea31eb62..0656d5ee448d 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9615.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-mdm9615.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-mdm9615.h
allOf:
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8660.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8660.yaml
index e03b6d0acdb6..70c9da1f35c2 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8660.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8660.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks and resets on
MSM8660
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8660.h
include/dt-bindings/reset/qcom,gcc-msm8660.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml
index ce1f5a60bd8c..2edb6c251d99 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8909.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on MSM8909, MSM8917 or QM215.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8909.h
include/dt-bindings/clock/qcom,gcc-msm8917.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8916.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8916.yaml
index 258b6b93deca..af4b639ea8c3 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8916.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8916.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on MSM8916 or MSM8939.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8916.h
include/dt-bindings/clock/qcom,gcc-msm8939.h
include/dt-bindings/reset/qcom,gcc-msm8916.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml
index ced3118c8580..fc0360554f68 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8953.yaml
@@ -15,7 +15,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on MSM8937, MSM8940, MSM8953 or SDM439.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8917.h
include/dt-bindings/clock/qcom,gcc-msm8953.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8974.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8974.yaml
index 929fafc84c19..378dfe7854ac 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-msm8974.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-msm8974.yaml
@@ -15,7 +15,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on MSM8974 (all variants) and MSM8226.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974)
include/dt-bindings/reset/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974)
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sdm660.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sdm660.yaml
index 724ce0491118..72aaf699cf70 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc-sdm660.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sdm660.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on SDM630, SDM636 and SDM660
- See also::
+ See also:
include/dt-bindings/clock/qcom,gcc-sdm660.h (qcom,gcc-sdm630 and qcom,gcc-sdm660)
$ref: qcom,gcc.yaml#
diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
index 4cdff6161bf0..3ac4419009a9 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm graphics clock control module provides the clocks, resets and power
domains on Qualcomm SoCs.
- See also::
+ See also:
include/dt-bindings/clock/qcom,gpucc-sdm845.h
include/dt-bindings/clock/qcom,gpucc-sa8775p.h
include/dt-bindings/clock/qcom,gpucc-sc7180.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml
index 489d0fc5607c..9925b931ecad 100644
--- a/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,ipq5018-gcc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on IPQ5018
- See also::
+ See also:
include/dt-bindings/clock/qcom,ipq5018-gcc.h
include/dt-bindings/reset/qcom,ipq5018-gcc.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
index 27ae9938febc..5b128fa841aa 100644
--- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm global clock control module provides the clocks, resets and power
domains on IPQ9574
- See also::
+ See also:
include/dt-bindings/clock/qcom,ipq9574-gcc.h
include/dt-bindings/reset/qcom,ipq9574-gcc.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml b/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml
index 61473385da2d..3da10c364a85 100644
--- a/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,qca8k-nsscc.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm NSS clock control module provides the clocks and resets
on QCA8386(switch mode)/QCA8084(PHY mode)
- See also::
+ See also:
include/dt-bindings/clock/qcom,qca8k-nsscc.h
include/dt-bindings/reset/qcom,qca8k-nsscc.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml
index 734880805c1b..bedbdabef672 100644
--- a/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,qcm2290-gpucc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm graphics clock control module provides the clocks, resets and power
domains on Qualcomm SoCs.
- See also::
+ See also:
include/dt-bindings/clock/qcom,qcm2290-gpucc.h
properties:
diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
index ab97d4b7dba8..b6c835bfd0d9 100644
--- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.yaml
@@ -12,7 +12,7 @@ maintainers:
description: |
The clock enumerators are defined in <dt-bindings/clock/qcom,rpmcc.h> and
- come in pairs:: FOO_CLK followed by FOO_A_CLK. The latter clock is
+ come in pairs: FOO_CLK followed by FOO_A_CLK. The latter clock is
an "active" clock, which means that the consumer only care that the clock is
available when the apps CPU subsystem is active, i.e. not suspended or in
deep idle. If it is important that the clock keeps running during system
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml
index 99ab9106009f..fd06ac9bceb9 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sc7280-lpasscorecc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm LPASS core and audio clock control module provides the clocks and
power domains on SC7280.
- See also::
+ See also:
include/dt-bindings/clock/qcom,lpasscorecc-sc7280.h
include/dt-bindings/clock/qcom,lpassaudiocc-sc7280.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml
index 273d66e245c5..f235b4e24cc7 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sc8280xp-lpasscc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm LPASS core and audio clock control module provides the clocks,
and reset on SC8280XP.
- See also::
+ See also:
include/dt-bindings/clock/qcom,lpasscc-sc8280xp.h
properties:
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml
index 8cbab3fbb660..d7e1938b5e1b 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm6115-lpasscc.yaml
@@ -14,7 +14,7 @@ description: |
Qualcomm LPASS core and audio clock controllers provide audio-related resets
on SM6115 and its derivatives.
- See also::
+ See also:
include/dt-bindings/clock/qcom,sm6115-lpasscc.h
properties:
diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml
index 5c2ecec0624e..a986ab4ce7c7 100644
--- a/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,sm8350-videocc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm video clock control module provides the clocks, resets and power
domains on Qualcomm SoCs.
- See also::
+ See also:
include/dt-bindings/clock/qcom,videocc-sm8350.h
include/dt-bindings/reset/qcom,videocc-sm8350.h
diff --git a/Documentation/devicetree/bindings/clock/qcom,videocc.yaml b/Documentation/devicetree/bindings/clock/qcom,videocc.yaml
index f4ff9acef9d5..124d259fc85e 100644
--- a/Documentation/devicetree/bindings/clock/qcom,videocc.yaml
+++ b/Documentation/devicetree/bindings/clock/qcom,videocc.yaml
@@ -13,7 +13,7 @@ description: |
Qualcomm video clock control module provides the clocks, resets and power
domains on Qualcomm SoCs.
- See also::
+ See also:
include/dt-bindings/clock/qcom,sm6350-videocc.h
include/dt-bindings/clock/qcom,videocc-sc7180.h
include/dt-bindings/clock/qcom,videocc-sc7280.h
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml
index b05f83533e3d..56ab972c3da5 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos5260-clock.yaml
@@ -14,17 +14,17 @@ maintainers:
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
- name::
+ name:
- "fin_pll" - PLL input clock from XXTI
- "xrtcxti" - input clock from XRTCXTI
- "ioclk_pcm_extclk" - pcm external operation clock
- "ioclk_spdif_extclk" - spdif external operation clock
- "ioclk_i2s_cdclk" - i2s0 codec clock
- Phy clocks::
+ Phy clocks:
There are several clocks which are generated by specific PHYs. These clocks
are fed into the clock controller and then routed to the hardware blocks.
- These clocks are defined as fixed clocks in the driver with following names::
+ These clocks are defined as fixed clocks in the driver with following names:
- "phyclk_dptx_phy_ch3_txd_clk" - dp phy clock for channel 3
- "phyclk_dptx_phy_ch2_txd_clk" - dp phy clock for channel 2
- "phyclk_dptx_phy_ch1_txd_clk" - dp phy clock for channel 1
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml
index b737c9d35a1c..1d907dd8fbf1 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos5410-clock.yaml
@@ -14,7 +14,7 @@ maintainers:
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
- name::
+ name:
- "fin_pll" - PLL input clock from XXTI
All available clocks are defined as preprocessor macros in
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml
index 3f9326e09f79..8a289f1e2ace 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos5433-clock.yaml
@@ -14,7 +14,7 @@ maintainers:
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
- name::
+ name:
- "oscclk" - PLL input clock from XXTI
All available clocks are defined as preprocessor macros in
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml
index c137c6744ef9..a51cd4fafb41 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos7-clock.yaml
@@ -14,7 +14,7 @@ maintainers:
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
- name::
+ name:
- "fin_pll" - PLL input clock from XXTI
All available clocks are defined as preprocessor macros in
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml
index cdc5ded59fe5..68c2fd318765 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynos850-clock.yaml
@@ -17,7 +17,7 @@ description: |
Exynos850 clock controller is comprised of several CMU units, generating
clocks for different domains. Those CMU units are modeled as separate device
tree nodes, and might depend on each other. Root clocks in that clock tree are
- two external clocks:: OSCCLK (26 MHz) and RTCCLK (32768 Hz). Those external
+ two external clocks: OSCCLK (26 MHz) and RTCCLK (32768 Hz). Those external
clocks must be defined as fixed-rate clocks in dts.
CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml
index 32f39e543b36..e9d17d48b4f3 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynosautov9-clock.yaml
@@ -17,7 +17,7 @@ description: |
Exynos Auto v9 clock controller is comprised of several CMU units, generating
clocks for different domains. Those CMU units are modeled as separate device
tree nodes, and might depend on each other. Root clocks in that clock tree are
- two external clocks:: OSCCLK/XTCXO (26 MHz) and RTCCLK/XrtcXTI (32768 Hz).
+ two external clocks: OSCCLK/XTCXO (26 MHz) and RTCCLK/XrtcXTI (32768 Hz).
The external OSCCLK must be defined as fixed-rate clock in dts.
CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
diff --git a/Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml
index 6b1fc61a2ff9..475db824d4d3 100644
--- a/Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,exynosautov920-clock.yaml
@@ -17,7 +17,7 @@ description: |
ExynosAuto v920 clock controller is comprised of several CMU units, generating
clocks for different domains. Those CMU units are modeled as separate device
tree nodes, and might depend on each other. Root clocks in that clock tree are
- two external clocks:: OSCCLK/XTCXO (38.4 MHz) and RTCCLK/XrtcXTI (32768 Hz).
+ two external clocks: OSCCLK/XTCXO (38.4 MHz) and RTCCLK/XrtcXTI (32768 Hz).
The external OSCCLK must be defined as fixed-rate clock in dts.
CMU_TOP is a top-level CMU, where all base clocks are prepared using PLLs and
diff --git a/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml b/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml
index 67a33665cf00..b1617d96d3fb 100644
--- a/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/samsung,s5pv210-clock.yaml
@@ -14,7 +14,7 @@ maintainers:
description: |
Expected external clocks, defined in DTS as fixed-rate clocks with a matching
- name::
+ name:
- "xxti" - external crystal oscillator connected to XXTI and XXTO pins of
the SoC,
- "xusbxti" - external crystal oscillator connected to XUSBXTI and XUSBXTO
--
2.53.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* Re: [PATCH v3 1/2] dt-bindings: phy: qcom,usb-hs-phy: add qcom,hs-drv-slope
From: Krzysztof Kozlowski @ 2026-06-22 9:21 UTC (permalink / raw)
To: Herman van Hazendonk
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Philipp Zabel, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt, linux-arm-msm,
linux-phy, devicetree, linux-kernel, llvm, konrad.dybcio,
dmitry.baryshkov
In-Reply-To: <20260616-submit-phy-usb-hs-vendor-init-seq-v3-1-7d21fb1d1484@herrie.org>
On Tue, Jun 16, 2026 at 03:26:53PM +0200, Herman van Hazendonk wrote:
> The MSM8x60 / APQ8060 PHY needs three vendor ULPI register tweaks for
> stable USB operation: pre-emphasis level, CDR auto-reset and SE1
> gating in registers 0x32 and 0x36. A survey of MSM8x60-class
> downstream board files (Qualcomm SURF/FFA/Fluid/Dragon, Samsung
> Galaxy S2 family, Sony Xperia, HTC and HP TouchPad) shows that those
> three values are identical across every reference board and can be
> hardcoded in the driver behind the existing
> qcom,usb-hs-phy-msm8660 compatible.
>
> The only board-specific value is the 4-bit HS driver slope in bits
> [3:0] of register 0x32:
>
> HP TouchPad 5
> HTC MSM8660 ports 1
> Qualcomm / Samsung / Sony reference boards 0 (silicon default)
>
> Add a qcom,hs-drv-slope property carrying that 4-bit value, valid
> only on the qcom,usb-hs-phy-msm8660 variant. When the property is
> absent the driver leaves the silicon default in place, matching the
> behaviour of the Qualcomm reference platform.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 4/4] phy: ti-pipe3: Fix clock leak in init error path
From: sashiko-bot @ 2026-06-22 9:06 UTC (permalink / raw)
To: Hongling Zeng; +Cc: vkoul, neil.armstrong, olteanv, linux-phy
In-Reply-To: <1782118512967996.3955.seg@mailgw.kylinos.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Undocumented code and behavior change in SATA DPLL lock check
--
commit f36ec24b5d21c1b1acd7d71c309954221f9b2ccb
Author: Hongling Zeng <zenghongling@kylinos.cn>
phy: ti-pipe3: Fix clock leak in init error path
When regmap_update_bits() fails in ti_pipe3_init() for PCIe mode,
the function returns the error without calling ti_pipe3_disable_clocks().
This patch adds proper clock cleanup in the PCIe error path.
Closes: https://lore.kernel.org/all/20260518023657.41852C2BCB0@smtp.kernel.org/
> diff --git a/drivers/phy/ti/phy-ti-pipe3.c b/drivers/phy/ti/phy-ti-pipe3.c
> --- a/drivers/phy/ti/phy-ti-pipe3.c
> +++ b/drivers/phy/ti/phy-ti-pipe3.c
[ ... ]
> @@ -531,8 +533,9 @@ static int ti_pipe3_init(struct phy *x)
>
> /* SATA has issues if re-programmed when locked */
> val = ti_pipe3_readl(phy->pll_ctrl_base, PLL_STATUS);
> - if ((val & PLL_LOCK) && phy->mode == PIPE3_MODE_SATA)
> - return ret;
> + if ((val & PLL_LOCK) && phy->mode == PIPE3_MODE_SATA) {
> + return 0;
> + }
[Severity: Medium]
The commit message mentions adding clock cleanup for the PCIe error path,
but this modifies the SATA DPLL lock check to return 0 instead of ret.
Right above this block, ret can be assigned an error value when
bringing the DPLL out of IDLE:
if (val & PLL_IDLE) {
val &= ~PLL_IDLE;
ti_pipe3_writel(phy->pll_ctrl_base, PLL_CONFIGURATION2, val);
ret = ti_pipe3_dpll_wait_lock(phy);
}
If ti_pipe3_dpll_wait_lock() fails and returns -EBUSY, but the subsequent
read of PLL_STATUS shows PLL_LOCK is set, does this change unintentionally
mask the error by returning 0?
Could the commit message be updated to describe this if the behavior change
was intentional?
>
> /* Program the DPLL */
> ret = ti_pipe3_dpll_program(phy);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619030214.1779043-1-zenghongling@kylinos.cn?part=4
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 0/6] phy: realtek: usb2: support for RTL9607C USB2 PHY
From: Rustam Adilov @ 2026-06-20 11:49 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stanley Chang, Philipp Zabel, linux-phy, devicetree,
linux-kernel
In-Reply-To: <20260520175728.720877-1-adilov@disroot.org>
Hello,
Just a gentle reminder as this patch series has been sitting idle
for month already. I do know there are a couple of reviews sent
by sashiko AI but they are only about pre-existing issues which
has nothing to do with this patch series.
And the issue about "[High] - The driver attempts to access the
PHY's memory-mapped registers in `probe()` before the newly introduced
reset control is deasserted" is not the case because rtl9607_phy_cfg
contains the [4] = {0xe4, 0x6a} in page0 and thus doesn't trigger
phy memory reads during probe (in update_dc_driving_level).
Best,
Rustam
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 16/23] phy: rockchip: usbdp: Drop DP HPD handling
From: sashiko-bot @ 2026-06-19 16:00 UTC (permalink / raw)
To: Sebastian Reichel
Cc: conor+dt, olteanv, neil.armstrong, linux-phy, vkoul, devicetree,
robh
In-Reply-To: <20260619-rockchip-usbdp-cleanup-v6-16-3bb1f54b3f35@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Potential Use-After-Free of the `udphy` struct when the driver is unbound, triggered by active Type-C consumers.
--
commit 709452eb1097435563d2642eb88ed81ae54361f2
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
phy: rockchip: usbdp: Drop DP HPD handling
This patch drops the HPD handling logic from the USBDP PHY. The registers
involved require the display controller power domain being enabled and thus
the HPD signal should be handled by the displayport controller itself.
> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index b75c190a4311f..383e68b245060 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
[ ... ]
> @@ -1333,6 +1291,14 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
> struct rk_udphy *udphy = typec_mux_get_drvdata(mux);
> u8 mode;
>
> + /*
> + * Ignore mux events not involving DP AltMode, because
> + * the mode field is being reused, e.g. state->mode == 4
> + * could be either TYPEC_MODE_USB4 or TYPEC_DP_STATE_C.
> + */
> + if (!state->alt || state->alt->svid != USB_TYPEC_DP_SID)
> + return 0;
> +
> mutex_lock(&udphy->mutex);
[Severity: High]
This is a pre-existing issue, but could this code lead to a use-after-free
of the udphy struct when the driver is unbound?
The udphy structure is allocated using devm_kzalloc() in rk_udphy_probe(),
tying its lifetime to the device's binding lifecycle.
On driver unbind, devres calls typec_mux_unregister() and
typec_switch_unregister(), which run device_unregister(), and then frees
udphy.
However, device_unregister() only drops the core reference. If a Type-C
consumer (like the tcpm port driver) holds a reference to these Type-C
devices via fwnode_typec_mux_get(), the mux_dev and sw_dev objects stay
alive.
The consumer can still asynchronously invoke rk_udphy_typec_mux_set() or
rk_udphy_orien_sw_set() after the phy driver has been unbound.
Because udphy has already been freed by devres, does this mean any
subsequent call will dereference the freed udphy pointer when attempting to
lock udphy->mutex here, potentially resulting in memory corruption?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com?part=16
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 21/23] phy: rockchip: usbdp: Support going from DP-only mode to USB mode
From: sashiko-bot @ 2026-06-19 15:57 UTC (permalink / raw)
To: Sebastian Reichel
Cc: linux-phy, olteanv, devicetree, conor+dt, neil.armstrong, robh,
vkoul
In-Reply-To: <20260619-rockchip-usbdp-cleanup-v6-21-3bb1f54b3f35@collabora.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] The `usb_in_use` flag is bypassed if `phy_init` is called while the PHY is in a DP-only mode, permanently breaking USB functionality for subsequent adapter swaps.
- [High] The fix fails to restore USB functionality when transitioning from a DP-only adapter to a pure USB Type-C device.
- [High] The `!(old_mode & UDPHY_MODE_USB)` check in `rk_udphy_typec_mux_set()` erroneously fails because `rk_udphy_orien_sw_set()` preemptively modifies the mode during unplug/replug.
- [Medium] If `rk_udphy_power_on()` fails during a type-C mux transition, `udphy->mode` remains permanently updated, preventing future retries from restoring USB power.
--
commit fe9deaf95e7e3b871d382c46e07c07e56534ca4d
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
phy: rockchip: usbdp: Support going from DP-only mode to USB mode
This patch adds support for restoring USB functionality when a DP-only
adapter is unplugged and replaced with an adapter supporting USB, working
around the USB controller keeping the PHY enabled.
> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index 81aae3bc57476..7f26b74cb5151 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
[ ... ]
> @@ -1287,7 +1293,13 @@ static int rk_udphy_usb3_phy_init(struct phy *phy)
> return 0;
> }
>
> - return rk_udphy_power_on(udphy, UDPHY_MODE_USB);
> + ret = rk_udphy_power_on(udphy, UDPHY_MODE_USB);
> + if (ret)
> + return ret;
> +
> + udphy->usb_in_use = true;
[Severity: High]
Does this early return logic introduce a regression that prevents the flag
from being set if the system boots with a DP-only adapter?
If phy_init is called when the current mode lacks USB, it takes the early
return visible in the context above and skips executing
udphy->usb_in_use = true.
When a DP+USB adapter is later plugged in, udphy->usb_in_use will be false,
and the newly added restoration logic in rk_udphy_typec_mux_set() will
silently skip powering on the USB PHY.
> +
> + return 0;
> }
[ ... ]
> @@ -1315,6 +1329,7 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
> struct typec_mux_state *state)
> {
> struct rk_udphy *udphy = typec_mux_get_drvdata(mux);
> + u8 old_mode;
>
> /*
> * Ignore mux events not involving DP AltMode, because
[Severity: High]
Is there a regression here where pure USB adapters bypass this restoration
logic entirely?
The code just below this in rk_udphy_typec_mux_set() aborts for non-DP
events:
if (!state->alt || state->alt->svid != USB_TYPEC_DP_SID)
return 0;
If a pure USB Type-C device is connected after a DP-only adapter,
rk_udphy_orien_sw_set() updates the default mapping to UDPHY_MODE_DP_USB,
but rk_udphy_typec_mux_set() is never triggered. Since the USB controller
keeps the PHY logically enabled without calling phy_init again, the USB PHY
would remain powered off.
> @@ -1326,8 +1341,20 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
>
> guard(mutex)(&udphy->mutex);
>
> + old_mode = udphy->mode;
> +
> rk_udphy_set_typec_state(udphy, state->mode);
>
> + /*
> + * If the new mode includes USB but the old one didn't (e.g. leaving
> + * DP-only), and the USB PHY was already initialized by the USB
> + * controller, we need to power on the USB side now since no
> + * subsequent phy_init call will come from the controller.
> + */
> + if ((udphy->mode & UDPHY_MODE_USB) && !(old_mode & UDPHY_MODE_USB) &&
[Severity: High]
Does this introduce a regression where old_mode already includes
UDPHY_MODE_USB during an unplug/replug sequence?
When unplugging a DP-only adapter and plugging in a DP+USB adapter,
rk_udphy_orien_sw_set() is called first and unconditionally sets
udphy->mode to UDPHY_MODE_DP_USB.
When rk_udphy_typec_mux_set() is called moments later, old_mode = udphy->mode
will capture UDPHY_MODE_DP_USB. The check !(old_mode & UDPHY_MODE_USB)
would then evaluate to false, causing the USB PHY restoration to be skipped.
> + udphy->usb_in_use && !udphy->hs)
> + return rk_udphy_power_on(udphy, UDPHY_MODE_USB);
[Severity: Medium]
If rk_udphy_power_on() fails here, does it leave udphy->mode permanently
updated without a rollback?
rk_udphy_set_typec_state() modifies udphy->mode before this power-on
attempt. If rk_udphy_power_on() returns an error, the mode retains the USB
bit. If the Type-C subsystem retries the switch later, old_mode will now
include the USB bit, which would permanently prevent future retries from
passing the restoration check.
> +
> return 0;
> }
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com?part=21
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 18/23] phy: rockchip: usbdp: Re-init the PHY on orientation change
From: sashiko-bot @ 2026-06-19 15:53 UTC (permalink / raw)
To: Sebastian Reichel
Cc: vkoul, olteanv, devicetree, linux-phy, neil.armstrong, robh,
conor+dt
In-Reply-To: <20260619-rockchip-usbdp-cleanup-v6-18-3bb1f54b3f35@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing Hardware Initialization
--
commit 2a50b346fcf7d166779e0cb198d3572f5bdd300c
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
phy: rockchip: usbdp: Re-init the PHY on orientation change
This commit updates the cable orientation configuration to re-initialize
the PHY when the orientation changes. It sets a flag to trigger the
re-initialization to prevent DisplayPort functionality from breaking on
reverse cable plugs.
> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index c210aaeb283a5..402f3cafcf0ae 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
[ ... ]
> @@ -622,6 +622,7 @@ static int rk_udphy_orien_sw_set(struct typec_switch_dev *sw,
> enum typec_orientation orien)
> {
> struct rk_udphy *udphy = typec_switch_get_drvdata(sw);
> + bool flipped = orien == TYPEC_ORIENTATION_REVERSE;
>
> mutex_lock(&udphy->mutex);
>
> @@ -633,7 +634,10 @@ static int rk_udphy_orien_sw_set(struct typec_switch_dev *sw,
> goto unlock_ret;
> }
>
> - udphy->flip = orien == TYPEC_ORIENTATION_REVERSE;
> + if (udphy->flip != flipped)
> + udphy->phy_needs_reinit = true;
[Severity: High]
This is a pre-existing issue, but does setting udphy->phy_needs_reinit = true
here actually trigger a hardware update for pure USB3 connections?
When a device is plugged in, the hardware lane muxing is typically updated
inside rk_udphy_init(), which is called conditionally by rk_udphy_power_on().
However, looking at the phy_ops struct for USB3:
static const struct phy_ops rk_udphy_usb3_phy_ops = {
.init = rk_udphy_usb3_phy_init,
.exit = rk_udphy_usb3_phy_exit,
.owner = THIS_MODULE,
};
Because rk_udphy_usb3_phy_ops omits the .power_on callback, and the DWC3
controller only calls .init once during probe, the USB subsystem won't
trigger the PHY re-initialization required to apply the orientation changes.
Will the phy_needs_reinit flag remain set indefinitely, causing pure USB3
devices to fail to link at SuperSpeed if plugged in the reverse orientation?
> +
> + udphy->flip = flipped;
> rk_udphy_set_typec_default_mapping(udphy);
> rk_udphy_usb_bvalid_enable(udphy, true);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com?part=18
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 07/23] phy: rockchip: usbdp: Keep clocks running on PHY re-init
From: sashiko-bot @ 2026-06-19 15:50 UTC (permalink / raw)
To: Sebastian Reichel
Cc: devicetree, neil.armstrong, robh, vkoul, olteanv, linux-phy,
conor+dt
In-Reply-To: <20260619-rockchip-usbdp-cleanup-v6-7-3bb1f54b3f35@collabora.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] The Type-C mux callback completely ignores non-DP AltMode events, failing to reset lane mapping on AltMode exit.
- [High] Asynchronous `udphy->mode` updates cause `phy_exit` and `phy_power_off` to skip teardown, resulting in permanent clock and reset leaks.
--
commit ea283780e749d528861fc2fe55f998d22454a53b
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
phy: rockchip: usbdp: Keep clocks running on PHY re-init
When a mode change is required rk_udphy_power_on() disables
the clocks and then calls rk_udphy_setup(), which then enables
all the clocks again before continuing with rk_udphy_init().
Considering that rk_udphy_init() does assert the reset lines,
re-enabling the clocks is just delaying things. Avoid it by
directly calling rk_udphy_init().
> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index 6dff4dfc9363e..c05ee65a9f73a 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -1011,8 +1011,7 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
> if (udphy->mode == UDPHY_MODE_DP)
> rk_udphy_u3_port_disable(udphy, true);
>
> - rk_udphy_disable(udphy);
> - ret = rk_udphy_setup(udphy);
> + ret = rk_udphy_init(udphy);
[Severity: High]
This is a pre-existing issue, but the Type-C mux callback completely ignores
non-DP AltMode events, failing to reset lane mapping on AltMode exit.
When exiting DP AltMode (e.g., via sysfs or renegotiation without a physical
cable unplug), the Type-C subsystem calls typec_mux_set() with state->mode =
TYPEC_STATE_SAFE or TYPEC_STATE_USB and state->alt = NULL.
However, rk_udphy_typec_mux_set() immediately returns 0 if !state->alt:
drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_typec_mux_set() {
...
if (!state->alt || state->alt->svid != USB_TYPEC_DP_SID)
return 0;
...
}
Does this leave udphy->mode stuck in the previous DP configuration (e.g.,
UDPHY_MODE_DP with 4 DP lanes), which breaks subsequent USB3 initialization
because rk_udphy_usb3_phy_init() checks udphy->mode and skips powering on
the U3 port?
[Severity: High]
This is a pre-existing issue, but asynchronous udphy->mode updates cause
phy_exit() and phy_power_off() to skip teardown, resulting in permanent clock
and reset leaks.
udphy->mode tracks the target hardware mux state and is updated asynchronously
by Type-C events. However, rk_udphy_usb3_phy_exit() checks this current
udphy->mode rather than the initialized state (udphy->status) to decide
whether to power off:
drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_usb3_phy_exit() {
...
/* DP only or high-speed */
if (!(udphy->mode & UDPHY_MODE_USB) || udphy->hs)
return 0;
...
}
The phy_power_off() implementation also suffers from this flaw,
short-circuiting before it can update udphy->status and tear down resources:
drivers/phy/rockchip/phy-rockchip-usbdp.c:rk_udphy_power_off() {
...
if (!(udphy->mode & mode)) {
dev_info(udphy->dev, "mode 0x%02x is not support\n", mode);
return;
}
...
}
If the Type-C mux switches from a DP+USB mode to a DP-only mode while USB3
is active, UDPHY_MODE_USB is cleared from udphy->mode. When the USB3
controller later shuts down and calls phy_exit(), rk_udphy_usb3_phy_exit()
sees the bit missing and returns 0 early, skipping rk_udphy_power_off().
This prevents UDPHY_MODE_USB from being cleared from udphy->status. When the
DP controller subsequently calls phy_power_off(), udphy->status remains
non-zero, skipping rk_udphy_disable().
Since there is no driver removal cleanup fallback, do the clock enable
references get permanently leaked?
> if (ret)
> return ret;
> udphy->mode_change = false;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com?part=7
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 02/23] phy: rockchip: usbdp: Update mode_change after error handling
From: sashiko-bot @ 2026-06-19 15:49 UTC (permalink / raw)
To: Sebastian Reichel
Cc: vkoul, robh, devicetree, neil.armstrong, linux-phy, conor+dt,
olteanv
In-Reply-To: <20260619-rockchip-usbdp-cleanup-v6-2-3bb1f54b3f35@collabora.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [Critical] System crash due to concurrent MMIO access after PHY reinitialization failure.
- [High] State desync and resource leak in PHY mode tracking during Type-C role transitions.
--
commit e7082d92230eb75aff8a9e06c20d96b4d548e34c
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
Subject: phy: rockchip: usbdp: Update mode_change after error handling
If rk_udphy_init() or rk_udphy_setup() fails, the reinit will not be
tried again. Fix this by only updating the variable after all potential
errors have been handled.
Link: https://lore.kernel.org/linux-phy/20260612163835.8D5471F000E9@smtp.kernel.org/
> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index fba35510d88ce..a5ffdf7a6e76b 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -1000,15 +1000,14 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
> }
>
> if (udphy->status == UDPHY_MODE_NONE) {
[Severity: High]
This isn't a bug introduced by this patch, but I have a question about how
PHY mode transitions are tracked when the Type-C mux switches from a state
with USB (like DP+USB) to a state without it (like DP-only).
In this scenario, the mode variable gets updated, but the USB flag is not
cleared from the status field. Later, when the USB subsystem calls
rk_udphy_usb3_phy_exit(), it sees that the current mode lacks the USB flag
and returns early. This bypasses rk_udphy_power_off().
Does this mean the USB flag is permanently leaked in the status field? If
the remaining DP consumer subsequently powers off, it seems the status would
still contain the USB flag, preventing the driver from properly shutting
down the hardware and leaving APB clocks active.
> ret = rk_udphy_setup(udphy);
> if (ret)
> return ret;
>
> if (udphy->mode & UDPHY_MODE_USB)
> rk_udphy_u3_port_disable(udphy, false);
> - } else if (udphy->mode_change) {
> udphy->mode_change = false;
> + } else if (udphy->mode_change) {
> udphy->status = UDPHY_MODE_NONE;
> if (udphy->mode == UDPHY_MODE_DP)
> rk_udphy_u3_port_disable(udphy, true);
> @@ -1017,6 +1016,7 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
> ret = rk_udphy_setup(udphy);
> if (ret)
> return ret;
[Severity: Critical]
This is a pre-existing issue, but what happens if the setup or init fails
here during a Type-C orientation change?
If rk_udphy_init() fails due to something like an LCPLL lock timeout, it
asserts all resets, including the APB resets, before returning the error.
This function then propagates that error, but it doesn't restore the prior
state of sibling PHYs (like DP) which might already be active.
Since the DP framework would still consider the PHY active, could it
subsequently invoke rk_udphy_dp_phy_configure()? If that happens and it
attempts MMIO access to the PMA regmap while the APB bus reset is still
asserted, would this trigger a bus hang and a kernel panic?
> + udphy->mode_change = false;
> }
>
> udphy->status |= mode;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com?part=2
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 11/23] phy: rockchip: usbdp: Support single-lane DP
From: sashiko-bot @ 2026-06-19 15:48 UTC (permalink / raw)
To: Sebastian Reichel
Cc: linux-phy, robh, devicetree, conor+dt, vkoul, neil.armstrong,
olteanv
In-Reply-To: <20260619-rockchip-usbdp-cleanup-v6-11-3bb1f54b3f35@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The devicetree bindings schema for 'rockchip,dp-lane-mux' was not updated to allow single-item arrays, which will cause dtbs_check validation errors when using the newly added single-lane DP feature.
--
commit 1f02bccf35aefcbe053f784a52330f63bbd49988
Author: Zhang Yubing <yubing.zhang@rock-chips.com>
phy: rockchip: usbdp: Support single-lane DP
This commit implements support for using a single DisplayPort lane in the
Rockchip USB/DP PHY driver. It updates the lane configuration and devicetree
parsing logic to handle single-lane setups.
> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index 2ff05ef6eeacd..a87cb5c0596e7 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
[ ... ]
> @@ -897,7 +884,7 @@ static int rk_udphy_parse_lane_mux_data(struct rk_udphy *udphy)
> return 0;
> }
>
> - if (num_lanes != 2 && num_lanes != 4)
> + if (num_lanes != 1 && num_lanes != 2 && num_lanes != 4)
> return dev_err_probe(udphy->dev, -EINVAL,
> "invalid number of lane mux\n");
[Severity: Low]
Does this change also require an update to the devicetree bindings schema?
It looks like Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml
still restricts rockchip,dp-lane-mux to a minimum of 2 items:
rockchip,dp-lane-mux:
$ref: /schemas/types.yaml#/definitions/uint32-array
minItems: 2
maxItems: 4
Could this cause dtbs_check validation errors when valid device trees start
using the new 1-lane configuration?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com?part=11
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 05/23] phy: rockchip: usbdp: Drop seamless DP takeover
From: sashiko-bot @ 2026-06-19 15:47 UTC (permalink / raw)
To: Sebastian Reichel
Cc: robh, conor+dt, olteanv, neil.armstrong, vkoul, linux-phy,
devicetree
In-Reply-To: <20260619-rockchip-usbdp-cleanup-v6-5-3bb1f54b3f35@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Unhandled error from reset deassertion leads to unsafe MMIO access
--
commit 8eeae98a635eaf9514a2125a383fcc16fe03b51d
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
phy: rockchip: usbdp: Drop seamless DP takeover
This commit removes the seamless DisplayPort takeover feature if the
bootloader had already enabled DP. The DRM stack currently does not support
this and the code will leak clock resources on module removal.
Closes: https://lore.kernel.org/linux-phy/20260612164107.C7DB21F000E9@smtp.kernel.org/
> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index 2845a012eafcc..ffe39c968c70c 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -936,9 +936,9 @@ static int rk_udphy_get_initial_status(struct rk_udphy *udphy)
>
> regmap_read(udphy->pma_regmap, CMN_LANE_MUX_AND_EN_OFFSET, &value);
[Severity: High]
This is a pre-existing issue, but is it safe to ignore the return value of
rk_udphy_reset_deassert_all() which is called immediately before this
regmap_read() in rk_udphy_get_initial_status()?
If the reset deassertion fails, the peripheral block could still be held
in reset. On ARM architectures, performing MMIO access to a block that is
actively held in reset can trigger an asynchronous external abort (SError),
leading to an immediate kernel panic.
Could this be updated to verify the return value, clean up enabled
resources like clocks, and propagate the error? The same pattern appears
in rk_udphy_init() where rk_udphy_reset_deassert() is ignored just before
calling regmap_multi_reg_write() for the PMA block.
> if (FIELD_GET(CMN_DP_LANE_MUX_ALL, value) && FIELD_GET(CMN_DP_LANE_EN_ALL, value))
> - udphy->status = UDPHY_MODE_DP;
> - else
> - rk_udphy_disable(udphy);
> + dev_dbg(udphy->dev, "Started with DP PHY pre-enabled; seamless takeover unsupported\n");
> +
> + rk_udphy_disable(udphy);
>
> return 0;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com?part=5
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v6 04/23] phy: rockchip: usbdp: Fix devm_clk_bulk_get_all check
From: sashiko-bot @ 2026-06-19 15:43 UTC (permalink / raw)
To: Sebastian Reichel
Cc: conor+dt, vkoul, devicetree, olteanv, neil.armstrong, linux-phy,
robh
In-Reply-To: <20260619-rockchip-usbdp-cleanup-v6-4-3bb1f54b3f35@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The device tree parsing logic is vulnerable to a NULL pointer dereference if 'clock-names' is missing or incomplete.
--
commit 5e5a7a4f6db0a44a4bac43001ea4d179c3798c6d
Author: Sebastian Reichel <sebastian.reichel@collabora.com>
phy: rockchip: usbdp: Fix devm_clk_bulk_get_all check
This commit fixes the return value check for devm_clk_bulk_get_all()
so that deferred probe errors are properly propagated instead of being
masked.
Link: https://lore.kernel.org/linux-phy/20260612164107.C7DB21F000E9@smtp.kernel.org/
> diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> index 12dfdd470a782..2845a012eafcc 100644
> --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
> +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
> @@ -427,8 +427,8 @@ static int rk_udphy_clk_init(struct rk_udphy *udphy, struct device *dev)
> int i;
>
> udphy->num_clks = devm_clk_bulk_get_all(dev, &udphy->clks);
> - if (udphy->num_clks < 1)
> - return -ENODEV;
> + if (udphy->num_clks < 0)
> + return udphy->num_clks;
>
> /* used for configure phy reference clock frequency */
> for (i = 0; i < udphy->num_clks; i++) {
[Severity: High]
This is a pre-existing issue, but could this cause a null pointer dereference
if the device tree is missing the 'clock-names' property?
Looking at devm_clk_bulk_get_all(), it relies on of_clk_bulk_get(), which
initializes clks[i].id to a null pointer. If the device tree specifies
'clocks' but omits 'clock-names' (or has fewer names than clocks), the id
field appears to remain null.
Since strncmp() does not safely handle null pointers, passing it directly
might trigger an oops during driver probe:
rk_udphy_clk_init()
devm_clk_bulk_get_all()
// udphy->clks[i].id is potentially null
...
strncmp(udphy->clks[i].id, "refclk", 6)
Would it make sense to verify udphy->clks[i].id is valid before comparing it?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com?part=4
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v6 18/23] phy: rockchip: usbdp: Re-init the PHY on orientation change
From: Sebastian Reichel @ 2026-06-19 15:29 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, Sebastian Reichel
In-Reply-To: <20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com>
Changing the cable orientation reconfigures the lane muxing, which
requires re-initializing the PHY. Without this DP functionality
breaks, if the cable is re-plugged with swapped orientation.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index c210aaeb283a..402f3cafcf0a 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -622,6 +622,7 @@ static int rk_udphy_orien_sw_set(struct typec_switch_dev *sw,
enum typec_orientation orien)
{
struct rk_udphy *udphy = typec_switch_get_drvdata(sw);
+ bool flipped = orien == TYPEC_ORIENTATION_REVERSE;
mutex_lock(&udphy->mutex);
@@ -633,7 +634,10 @@ static int rk_udphy_orien_sw_set(struct typec_switch_dev *sw,
goto unlock_ret;
}
- udphy->flip = orien == TYPEC_ORIENTATION_REVERSE;
+ if (udphy->flip != flipped)
+ udphy->phy_needs_reinit = true;
+
+ udphy->flip = flipped;
rk_udphy_set_typec_default_mapping(udphy);
rk_udphy_usb_bvalid_enable(udphy, true);
--
2.53.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v6 21/23] phy: rockchip: usbdp: Support going from DP-only mode to USB mode
From: Sebastian Reichel @ 2026-06-19 15:29 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, Sebastian Reichel
In-Reply-To: <20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com>
When a USB-C adapter, which maps all Superspeed lanes to DP is plugged
in, the USB support is disabled in the PHY. When the adapter is
unplugged and a different adapter with USB functionality is plugged in
afterwards, USB functionality is not restored as the USB controller
keeps the PHY enabled for the entire time.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 29 ++++++++++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index 81aae3bc5747..7f26b74cb515 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -178,6 +178,7 @@ struct rk_udphy {
/* utilized for USB */
bool hs; /* flag for high-speed */
+ bool usb_in_use;
/* utilized for DP */
struct gpio_desc *sbu1_dc_gpio;
@@ -1015,6 +1016,10 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
ret = rk_udphy_init(udphy);
if (ret)
return ret;
+
+ if (udphy->mode & UDPHY_MODE_USB)
+ rk_udphy_u3_port_disable(udphy, false);
+
udphy->phy_needs_reinit = false;
}
@@ -1278,6 +1283,7 @@ static const struct phy_ops rk_udphy_dp_phy_ops = {
static int rk_udphy_usb3_phy_init(struct phy *phy)
{
struct rk_udphy *udphy = phy_get_drvdata(phy);
+ int ret;
guard(mutex)(&udphy->mutex);
@@ -1287,7 +1293,13 @@ static int rk_udphy_usb3_phy_init(struct phy *phy)
return 0;
}
- return rk_udphy_power_on(udphy, UDPHY_MODE_USB);
+ ret = rk_udphy_power_on(udphy, UDPHY_MODE_USB);
+ if (ret)
+ return ret;
+
+ udphy->usb_in_use = true;
+
+ return 0;
}
static int rk_udphy_usb3_phy_exit(struct phy *phy)
@@ -1296,6 +1308,8 @@ static int rk_udphy_usb3_phy_exit(struct phy *phy)
guard(mutex)(&udphy->mutex);
+ udphy->usb_in_use = false;
+
/* DP only or high-speed */
if (!(udphy->mode & UDPHY_MODE_USB) || udphy->hs)
return 0;
@@ -1315,6 +1329,7 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
struct typec_mux_state *state)
{
struct rk_udphy *udphy = typec_mux_get_drvdata(mux);
+ u8 old_mode;
/*
* Ignore mux events not involving DP AltMode, because
@@ -1326,8 +1341,20 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
guard(mutex)(&udphy->mutex);
+ old_mode = udphy->mode;
+
rk_udphy_set_typec_state(udphy, state->mode);
+ /*
+ * If the new mode includes USB but the old one didn't (e.g. leaving
+ * DP-only), and the USB PHY was already initialized by the USB
+ * controller, we need to power on the USB side now since no
+ * subsequent phy_init call will come from the controller.
+ */
+ if ((udphy->mode & UDPHY_MODE_USB) && !(old_mode & UDPHY_MODE_USB) &&
+ udphy->usb_in_use && !udphy->hs)
+ return rk_udphy_power_on(udphy, UDPHY_MODE_USB);
+
return 0;
}
--
2.53.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v6 16/23] phy: rockchip: usbdp: Drop DP HPD handling
From: Sebastian Reichel @ 2026-06-19 15:29 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, Sebastian Reichel
In-Reply-To: <20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com>
Drop the HPD handling logic from the USBDP PHY. The registers involved
require the display controller power domain being enabled and thus the
HPD signal should be handled by the displayport controller itself.
Apart from that the HPD handling as it is done here is incorrect and
misses hotplug events happening after the USB-C connector (e.g. when
a USB-C to HDMI adapter is involved and the HDMI cable is replugged).
Proper USB-C DP HPD support requires some restructuring of the DP
controller driver, which will happen independent of this patch. The
mainline kernel does not yet support USB-C DP AltMode on RK3588 and
RK3576, so it is fine to drop this code without adding the counterpart
in the DRM in an atomic change.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 85 ++++---------------------------
1 file changed, 9 insertions(+), 76 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index b75c190a4311..383e68b24506 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -128,7 +128,6 @@ struct rk_udphy_grf_cfg {
struct rk_udphy_vogrf_cfg {
/* vo-grf */
- struct rk_udphy_grf_reg hpd_trigger;
u32 dp_lane_reg;
};
@@ -186,14 +185,11 @@ struct rk_udphy {
u32 dp_lane_sel[4];
u32 dp_aux_dout_sel;
u32 dp_aux_din_sel;
- bool dp_sink_hpd_sel;
- bool dp_sink_hpd_cfg;
unsigned int link_rate;
unsigned int lanes;
u8 bw;
int id;
- bool dp_in_use;
int dp_lanes;
/* PHY const config */
@@ -579,19 +575,6 @@ static void rk_udphy_dp_lane_enable(struct rk_udphy *udphy, int dp_lanes)
CMN_DP_CMN_RSTN, FIELD_PREP(CMN_DP_CMN_RSTN, 0x0));
}
-static void rk_udphy_dp_hpd_event_trigger(struct rk_udphy *udphy, bool hpd)
-{
- const struct rk_udphy_cfg *cfg = udphy->cfgs;
-
- udphy->dp_sink_hpd_sel = true;
- udphy->dp_sink_hpd_cfg = hpd;
-
- if (!udphy->dp_in_use)
- return;
-
- rk_udphy_grfreg_write(udphy->vogrf, &cfg->vogrfcfg[udphy->id].hpd_trigger, hpd);
-}
-
static void rk_udphy_mode_set(struct rk_udphy *udphy, u8 mode)
{
if (udphy->mode == mode)
@@ -1024,29 +1007,6 @@ static void rk_udphy_power_off(struct rk_udphy *udphy, u8 mode)
rk_udphy_disable(udphy);
}
-static int rk_udphy_dp_phy_init(struct phy *phy)
-{
- struct rk_udphy *udphy = phy_get_drvdata(phy);
-
- mutex_lock(&udphy->mutex);
-
- udphy->dp_in_use = true;
-
- mutex_unlock(&udphy->mutex);
-
- return 0;
-}
-
-static int rk_udphy_dp_phy_exit(struct phy *phy)
-{
- struct rk_udphy *udphy = phy_get_drvdata(phy);
-
- mutex_lock(&udphy->mutex);
- udphy->dp_in_use = false;
- mutex_unlock(&udphy->mutex);
- return 0;
-}
-
static int rk_udphy_dp_phy_power_on(struct phy *phy)
{
struct rk_udphy *udphy = phy_get_drvdata(phy);
@@ -1278,8 +1238,6 @@ static int rk_udphy_dp_phy_configure(struct phy *phy,
}
static const struct phy_ops rk_udphy_dp_phy_ops = {
- .init = rk_udphy_dp_phy_init,
- .exit = rk_udphy_dp_phy_exit,
.power_on = rk_udphy_dp_phy_power_on,
.power_off = rk_udphy_dp_phy_power_off,
.configure = rk_udphy_dp_phy_configure,
@@ -1333,6 +1291,14 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
struct rk_udphy *udphy = typec_mux_get_drvdata(mux);
u8 mode;
+ /*
+ * Ignore mux events not involving DP AltMode, because
+ * the mode field is being reused, e.g. state->mode == 4
+ * could be either TYPEC_MODE_USB4 or TYPEC_DP_STATE_C.
+ */
+ if (!state->alt || state->alt->svid != USB_TYPEC_DP_SID)
+ return 0;
+
mutex_lock(&udphy->mutex);
switch (state->mode) {
@@ -1364,22 +1330,7 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
break;
}
- if (state->alt && state->alt->svid == USB_TYPEC_DP_SID) {
- struct typec_displayport_data *data = state->data;
-
- if (!data) {
- rk_udphy_dp_hpd_event_trigger(udphy, false);
- } else if (data->status & DP_STATUS_IRQ_HPD) {
- rk_udphy_dp_hpd_event_trigger(udphy, false);
- usleep_range(750, 800);
- rk_udphy_dp_hpd_event_trigger(udphy, true);
- } else if (data->status & DP_STATUS_HPD_STATE) {
- rk_udphy_mode_set(udphy, mode);
- rk_udphy_dp_hpd_event_trigger(udphy, true);
- } else {
- rk_udphy_dp_hpd_event_trigger(udphy, false);
- }
- }
+ rk_udphy_mode_set(udphy, mode);
mutex_unlock(&udphy->mutex);
return 0;
@@ -1535,20 +1486,6 @@ static int rk_udphy_probe(struct platform_device *pdev)
return 0;
}
-static int __maybe_unused rk_udphy_resume(struct device *dev)
-{
- struct rk_udphy *udphy = dev_get_drvdata(dev);
-
- if (udphy->dp_sink_hpd_sel)
- rk_udphy_dp_hpd_event_trigger(udphy, udphy->dp_sink_hpd_cfg);
-
- return 0;
-}
-
-static const struct dev_pm_ops rk_udphy_pm_ops = {
- SET_LATE_SYSTEM_SLEEP_PM_OPS(NULL, rk_udphy_resume)
-};
-
static const char * const rk_udphy_rst_list[] = {
"init", "cmn", "lane", "pcs_apb", "pma_apb"
};
@@ -1572,7 +1509,6 @@ static const struct rk_udphy_cfg rk3576_udphy_cfgs = {
},
.vogrfcfg = {
{
- .hpd_trigger = RK_UDPHY_GEN_GRF_REG(0x0000, 11, 10, 1, 3),
.dp_lane_reg = 0x0000,
},
},
@@ -1613,11 +1549,9 @@ static const struct rk_udphy_cfg rk3588_udphy_cfgs = {
},
.vogrfcfg = {
{
- .hpd_trigger = RK_UDPHY_GEN_GRF_REG(0x0000, 11, 10, 1, 3),
.dp_lane_reg = 0x0000,
},
{
- .hpd_trigger = RK_UDPHY_GEN_GRF_REG(0x0008, 11, 10, 1, 3),
.dp_lane_reg = 0x0008,
},
},
@@ -1653,7 +1587,6 @@ static struct platform_driver rk_udphy_driver = {
.driver = {
.name = "rockchip-usbdp-phy",
.of_match_table = rk_udphy_dt_match,
- .pm = &rk_udphy_pm_ops,
},
};
module_platform_driver(rk_udphy_driver);
--
2.53.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v6 20/23] phy: rockchip: usbdp: Use guard functions for mutex
From: Sebastian Reichel @ 2026-06-19 15:29 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, Sebastian Reichel
In-Reply-To: <20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com>
Convert the driver to use guard functions for mutex handling as
a small cleanup. There is a small functional change in the DP PHY
power up function, which no longer sleeps if the internal powerup
code returns an error. This is not a problem as the sleep is only
relevant for successful power-up.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 54 +++++++++++++------------------
1 file changed, 23 insertions(+), 31 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index 46ab9fb45ca4..81aae3bc5747 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -10,6 +10,7 @@
#include <dt-bindings/phy/phy.h>
#include <linux/bitfield.h>
#include <linux/bits.h>
+#include <linux/cleanup.h>
#include <linux/clk.h>
#include <linux/delay.h>
#include <linux/gpio.h>
@@ -652,14 +653,15 @@ static int rk_udphy_orien_sw_set(struct typec_switch_dev *sw,
struct rk_udphy *udphy = typec_switch_get_drvdata(sw);
bool flipped = orien == TYPEC_ORIENTATION_REVERSE;
- mutex_lock(&udphy->mutex);
+ guard(mutex)(&udphy->mutex);
if (orien == TYPEC_ORIENTATION_NONE) {
gpiod_set_value_cansleep(udphy->sbu1_dc_gpio, 0);
gpiod_set_value_cansleep(udphy->sbu2_dc_gpio, 0);
/* unattached */
rk_udphy_usb_bvalid_enable(udphy, false);
- goto unlock_ret;
+
+ return 0;
}
if (udphy->flip != flipped)
@@ -669,8 +671,6 @@ static int rk_udphy_orien_sw_set(struct typec_switch_dev *sw,
rk_udphy_set_typec_default_mapping(udphy);
rk_udphy_usb_bvalid_enable(udphy, true);
-unlock_ret:
- mutex_unlock(&udphy->mutex);
return 0;
}
@@ -1044,26 +1044,25 @@ static int rk_udphy_dp_phy_power_on(struct phy *phy)
struct rk_udphy *udphy = phy_get_drvdata(phy);
int ret;
- mutex_lock(&udphy->mutex);
+ scoped_guard(mutex, &udphy->mutex) {
+ phy_set_bus_width(phy, udphy->dp_lanes);
- phy_set_bus_width(phy, udphy->dp_lanes);
-
- ret = rk_udphy_power_on(udphy, UDPHY_MODE_DP);
- if (ret)
- goto unlock;
+ ret = rk_udphy_power_on(udphy, UDPHY_MODE_DP);
+ if (ret)
+ return ret;
- rk_udphy_dp_lane_enable(udphy, udphy->dp_lanes);
+ rk_udphy_dp_lane_enable(udphy, udphy->dp_lanes);
- rk_udphy_dp_lane_select(udphy);
+ rk_udphy_dp_lane_select(udphy);
+ }
-unlock:
- mutex_unlock(&udphy->mutex);
/*
* If data send by aux channel too fast after phy power on,
* the aux may be not ready which will cause aux error. Adding
* delay to avoid this issue.
*/
usleep_range(10000, 11000);
+
return ret;
}
@@ -1071,10 +1070,10 @@ static int rk_udphy_dp_phy_power_off(struct phy *phy)
{
struct rk_udphy *udphy = phy_get_drvdata(phy);
- mutex_lock(&udphy->mutex);
+ guard(mutex)(&udphy->mutex);
+
rk_udphy_dp_lane_enable(udphy, 0);
rk_udphy_power_off(udphy, UDPHY_MODE_DP);
- mutex_unlock(&udphy->mutex);
return 0;
}
@@ -1279,35 +1278,30 @@ static const struct phy_ops rk_udphy_dp_phy_ops = {
static int rk_udphy_usb3_phy_init(struct phy *phy)
{
struct rk_udphy *udphy = phy_get_drvdata(phy);
- int ret = 0;
- mutex_lock(&udphy->mutex);
+ guard(mutex)(&udphy->mutex);
+
/* DP only or high-speed, disable U3 port */
if (!(udphy->mode & UDPHY_MODE_USB) || udphy->hs) {
rk_udphy_u3_port_disable(udphy, true);
- goto unlock;
+ return 0;
}
- ret = rk_udphy_power_on(udphy, UDPHY_MODE_USB);
-
-unlock:
- mutex_unlock(&udphy->mutex);
- return ret;
+ return rk_udphy_power_on(udphy, UDPHY_MODE_USB);
}
static int rk_udphy_usb3_phy_exit(struct phy *phy)
{
struct rk_udphy *udphy = phy_get_drvdata(phy);
- mutex_lock(&udphy->mutex);
+ guard(mutex)(&udphy->mutex);
+
/* DP only or high-speed */
if (!(udphy->mode & UDPHY_MODE_USB) || udphy->hs)
- goto unlock;
+ return 0;
rk_udphy_power_off(udphy, UDPHY_MODE_USB);
-unlock:
- mutex_unlock(&udphy->mutex);
return 0;
}
@@ -1330,12 +1324,10 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
if (!state->alt || state->alt->svid != USB_TYPEC_DP_SID)
return 0;
- mutex_lock(&udphy->mutex);
+ guard(mutex)(&udphy->mutex);
rk_udphy_set_typec_state(udphy, state->mode);
- mutex_unlock(&udphy->mutex);
-
return 0;
}
--
2.53.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v6 15/23] phy: rockchip: usbdp: Register DP aux bridge
From: Sebastian Reichel @ 2026-06-19 15:29 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, Sebastian Reichel
In-Reply-To: <20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com>
Add support to use USB-C connectors with the DP altmode helper code on
devicetree based platforms. To get this working there must be a DRM
bridge chain from the DisplayPort controller to the USB-C connector.
E.g. on Rockchip RK3576:
root@rk3576 # cat /sys/kernel/debug/dri/0/encoder-0/bridges
bridge[0]: dw_dp_bridge_funcs
refcount: 7
type: [10] DP
OF: /soc/dp@27e40000:rockchip,rk3576-dp
ops: [0x47] detect edid hpd
bridge[1]: drm_aux_bridge_funcs
refcount: 4
type: [0] Unknown
OF: /soc/phy@2b010000:rockchip,rk3576-usbdp-phy
ops: [0x0]
bridge[2]: drm_aux_hpd_bridge_funcs
refcount: 5
type: [10] DP
OF: /soc/i2c@2ac50000/typec-portc@22/connector:usb-c-connector
ops: [0x4] hpd
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/Kconfig | 2 ++
drivers/phy/rockchip/phy-rockchip-usbdp.c | 14 ++++++++++++++
2 files changed, 16 insertions(+)
diff --git a/drivers/phy/rockchip/Kconfig b/drivers/phy/rockchip/Kconfig
index 14698571b607..39759bb2fa1d 100644
--- a/drivers/phy/rockchip/Kconfig
+++ b/drivers/phy/rockchip/Kconfig
@@ -136,8 +136,10 @@ config PHY_ROCKCHIP_USBDP
tristate "Rockchip USBDP COMBO PHY Driver"
depends on ARCH_ROCKCHIP && OF
depends on TYPEC
+ depends on DRM || DRM=n
select GENERIC_PHY
select USB_COMMON
+ select DRM_AUX_BRIDGE if DRM_BRIDGE
help
Enable this to support the Rockchip USB3.0/DP combo PHY with
Samsung IP block. This is required for USB3 support on RK3588.
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index da769790df98..b75c190a4311 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -6,6 +6,7 @@
* Copyright (C) 2024 Collabora Ltd
*/
+#include <drm/bridge/aux-bridge.h>
#include <dt-bindings/phy/phy.h>
#include <linux/bitfield.h>
#include <linux/bits.h>
@@ -1438,6 +1439,7 @@ static int rk_udphy_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct phy_provider *phy_provider;
+ struct fwnode_handle *dp_aux_ep;
struct resource *res;
struct rk_udphy *udphy;
void __iomem *base;
@@ -1496,6 +1498,18 @@ static int rk_udphy_probe(struct platform_device *pdev)
return ret;
}
+ /*
+ * Only register the DRM bridge, if the DP aux channel is connected.
+ * Some boards use the USBDP PHY only for its USB3 capabilities.
+ */
+ dp_aux_ep = fwnode_graph_get_endpoint_by_id(dev_fwnode(dev), 3, 0, 0);
+ if (dp_aux_ep) {
+ ret = drm_aux_bridge_register(dev);
+ fwnode_handle_put(dp_aux_ep);
+ if (ret)
+ return ret;
+ }
+
udphy->phy_u3 = devm_phy_create(dev, dev->of_node, &rk_udphy_usb3_phy_ops);
if (IS_ERR(udphy->phy_u3)) {
ret = PTR_ERR(udphy->phy_u3);
--
2.53.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ 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