* Re: [PATCH V2 1/3] dt-bindings: dma: xilinx: Add optional resets property for ZDMA
From: Krzysztof Kozlowski @ 2026-06-22 11:02 UTC (permalink / raw)
To: Golla Nagendra
Cc: vkoul, Frank.Li, michal.simek, robh, krzk+dt, conor+dt,
jay.buddhabhatti, harini.katakam, m.tretter, radhey.shyam.pandey,
abin.joseph, kees, sakari.ailus, git, dmaengine, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260618071056.2024286-2-nagendra.golla@amd.com>
On Thu, Jun 18, 2026 at 12:40:54PM +0530, Golla Nagendra wrote:
> From: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
>
> Newer SoCs such as Versal Gen2 and Versal‑Net expose a reset line
> for ZDMA. Older SoCs do not have this provision. Add an optional
> resets property to describe this reset.
It should be then restricted further per each variant/device in
allOf:if:then: (see example-schema for syntax - ": false").
>
> Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
> Co-developed-by: Golla Nagendra <nagendra.golla@amd.com>
> Signed-off-by: Golla Nagendra <nagendra.golla@amd.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: power: limits: Describe Qualcomm SPEL hardware
From: Konrad Dybcio @ 2026-06-22 11:02 UTC (permalink / raw)
To: Manaf Meethalavalappu Pallikunhi, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Rafael J. Wysocki,
Bjorn Andersson, Konrad Dybcio, Daniel Lezcano
Cc: Gaurav Kohli, linux-arm-msm, devicetree, linux-kernel, linux-pm
In-Reply-To: <20260620-qcom_spel_driver_upstream-v2-1-a3ee6837c18f@oss.qualcomm.com>
On 6/19/26 10:39 PM, Manaf Meethalavalappu Pallikunhi wrote:
> The Qualcomm SoC Power and Electrical Limits (SPEL) provides hardware
> based power monitoring and limiting capabilities for various domains.
>
> Add a DeviceTree binding to describe the SPEL block on Qualcomm's SoC.
>
> Signed-off-by: Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@oss.qualcomm.com>
> ---
> .../bindings/power/limits/qcom,spel.yaml | 47 ++++++++++++++++++++++
> MAINTAINERS | 6 +++
> 2 files changed, 53 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/limits/qcom,spel.yaml b/Documentation/devicetree/bindings/power/limits/qcom,spel.yaml
> new file mode 100644
> index 000000000000..4c6e6cbfbfe4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/limits/qcom,spel.yaml
> @@ -0,0 +1,47 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/power/limits/qcom,spel.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm SoC Power and Electrical Limits (SPEL)
> +
> +maintainers:
> + - Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@oss.qualcomm.com>
> +
> +description:
> + The Qualcomm SPEL (SoC Power and Electrical Limits) provides hardware-based
> + power monitoring and limiting capabilities for various power domains in
> + Qualcomm SoCs.
> +
> +properties:
> + compatible:
> + const: qcom,glymur-spel
> +
> + reg:
> + maxItems: 3
> +
> + reg-names:
> + items:
> + - const: config
> + - const: constraints
> + - const: nodes
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + power-limits@ef3b000 {
> + compatible = "qcom,glymur-spel";
> + reg = <0x0ef3b000 0x1000>,
> + <0x0ef3d000 0x1000>,
Don't we need the range inbetween these two (base=0xef3c000)?
Konrad
^ permalink raw reply
* Re: [PATCH v2 2/3] powercap: qcom: Add SPEL powercap driver
From: Konrad Dybcio @ 2026-06-22 11:01 UTC (permalink / raw)
To: Manaf Meethalavalappu Pallikunhi, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Rafael J. Wysocki,
Bjorn Andersson, Konrad Dybcio, Daniel Lezcano
Cc: Gaurav Kohli, linux-arm-msm, devicetree, linux-kernel, linux-pm
In-Reply-To: <20260620-qcom_spel_driver_upstream-v2-2-a3ee6837c18f@oss.qualcomm.com>
On 6/19/26 10:39 PM, Manaf Meethalavalappu Pallikunhi wrote:
> The Qualcomm SoC Power and Electrical Limits (SPEL) provides hardware
> based power monitoring and limiting capabilities for various power
> domains including System, SoC, CPU clusters, GPU, and various other
> subsystems.
>
> The driver integrates with the Linux powercap framework, exposing SPEL
> capabilities through powercap sysfs interfaces.
>
> Signed-off-by: Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@oss.qualcomm.com>
> ---
[...]
> +#include <linux/bitfield.h>
> +#include <linux/device.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/mutex.h>
> +#include <linux/platform_device.h>
> +#include <linux/powercap.h>
> +#include <linux/slab.h>
> +#include <linux/types.h>
Please ensure all the includes are necessary
> +
> +/* SPEL register bitmasks */
> +#define ENERGY_STATUS_MASK GENMASK(31, 0)
> +
> +#define POWER_LIMIT_MASK GENMASK(14, 0)
> +#define POWER_LIMIT_ENABLE BIT(31)
> +
> +#define TIME_WINDOW_MASK_L GENMASK(14, 0)
> +#define TIME_WINDOW_MASK_H GENMASK(22, 16)
Is BIT(15) not part of this?
[...]
> +/* Domain configuration */
> +static const struct spel_domain_info domain_info[SPEL_DOMAIN_MAX] = {
> + [SPEL_DOMAIN_SYS] = { "sys", 0x40 },
> + [SPEL_DOMAIN_SOC] = { "soc", 0x00 },
> + [SPEL_DOMAIN_CL0] = { "cl0", 0x5c },
> + [SPEL_DOMAIN_CL1] = { "cl1", 0x60 },
> + [SPEL_DOMAIN_CL2] = { "cl2", 0x64 },
> + [SPEL_DOMAIN_IGPU] = { "igpu", 0x08 },
> + [SPEL_DOMAIN_DGPU] = { "dgpu", 0x44 },
> + [SPEL_DOMAIN_NSP] = { "nsp", 0x0c },
> + [SPEL_DOMAIN_MMCX] = { "mmcx", 0x10 },
> + [SPEL_DOMAIN_INFRA] = { "infra", 0x18 },
> + [SPEL_DOMAIN_DRAM] = { "dram", 0x1c },
> + [SPEL_DOMAIN_MDM] = { "mdm", 0x48 },
> + [SPEL_DOMAIN_WLAN] = { "wlan", 0x4c },
> + [SPEL_DOMAIN_USB1] = { "usb1", 0x50 },
> + [SPEL_DOMAIN_USB2] = { "usb2", 0x54 },
> + [SPEL_DOMAIN_USB3] = { "usb3", 0x58 },
> +};
I would expect that the names are going to stay common, but the offsets
will be different. This array should probably be called
glymur_domain_info[]. We may have another LUT just for names of indices
(i.e. [SPEL_DOMAIN_xxx] = "xxx")
> +
> +/**
> + * struct spel_constraint_info - Power limit constraint information
> + * @limit_offset: Register offset for power limit value
> + * @time_window_offset: Register offset for time window
> + * @supported_mask: Bit mask in capability register
> + * @domain_id: Domain this constraint applies to
> + * @pl_id: Power limit ID (PL1, PL2, etc.)
> + */
> +struct spel_constraint_info {
> + u32 limit_offset;
> + u32 time_window_offset;
> + u32 supported_mask;
> + enum spel_domain_type domain_id;
> + int pl_id;
> +};
> +
> +/* Constraint configuration */
> +static const struct spel_constraint_info constraints[] = {
> + /* SYS domain constraints */
> + { 0x10, 0x70, BIT(0), SPEL_DOMAIN_SYS, POWER_LIMIT1 },
> + { 0x14, 0x74, BIT(1), SPEL_DOMAIN_SYS, POWER_LIMIT2 },
> + { 0x18, 0x78, BIT(2), SPEL_DOMAIN_SYS, POWER_LIMIT3 },
> + { 0x1c, 0x7c, BIT(3), SPEL_DOMAIN_SYS, POWER_LIMIT4 },
> + /* SoC domain constraints */
> + { 0x00, 0x60, BIT(4), SPEL_DOMAIN_SOC, POWER_LIMIT1 },
> + { 0x04, 0x64, BIT(5), SPEL_DOMAIN_SOC, POWER_LIMIT2 },
> + { 0x08, 0x68, BIT(6), SPEL_DOMAIN_SOC, POWER_LIMIT3 },
> + { 0x0c, 0x6c, BIT(7), SPEL_DOMAIN_SOC, POWER_LIMIT4 },
> +};
Is this specific to Glymur, or SPEL-wide?
[...]
> +/**
> + * struct spel_system - SPEL system
odd tab after '-'
[...]
> + case PL_LIMIT:
> + new_val = spel_unit_xlate(sd, POWER_UNIT, value, 1);
> + if (new_val > FIELD_MAX(POWER_LIMIT_MASK))
> + return -EINVAL;
> + reg_val = (reg_val & ~POWER_LIMIT_MASK) | FIELD_PREP(POWER_LIMIT_MASK, new_val);
FIELD_MODIFY()
> +
> + /*
> + * Enable/Disable PL based on the value:
> + * - If value is 0, disable the PL (clear enable bit)
> + * - If value is non-zero, enable the PL (set enable bit)
> + */
> + if (new_val == 0)
> + reg_val &= ~POWER_LIMIT_ENABLE;
> + else
> + reg_val |= POWER_LIMIT_ENABLE;
Likewise
> +
> + writel(reg_val, reg_addr);
> + return 0;
> +
> + case PL_TIME_WINDOW:
> + /*
> + * Encode time window: upper 7 bits to [22:16], lower 15 bits to [14:0]
> + */
> + new_val = spel_unit_xlate(sd, TIME_UNIT, value, 1);
> + if (new_val > TIME_WINDOW_MAX)
> + return -EINVAL;
> + /* Read-modify-write to preserve other bits */
> + reg_val = (reg_val & ~(TIME_WINDOW_MASK_H | TIME_WINDOW_MASK_L)) |
> + FIELD_PREP(TIME_WINDOW_MASK_H, new_val >> 15) |
> + FIELD_PREP(TIME_WINDOW_MASK_L, new_val);
Also here
[...]
> +static void spel_detect_powerlimit(struct spel_domain *sd)
> +{
> + struct spel_system *sp = sd->sp;
> + u32 capabilities;
> + int i, j;
> +
> + capabilities = readl(sp->config_base + LIMITS_CAPABILITY_OFFSET);
> +
> + /*
> + * Detect power limits from hardware capabilities.
> + * Start from index 1 (POWER_LIMIT2) since PL1 is always enabled in spel_init_domains().
> + */
> + for (i = 1; i < ARRAY_SIZE(pl_names); i++) {
int i = POWER_LIMIT2
(yeah, nowadays you can finally declare the iterator inside the loop
in the kernel)
Konrad
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: arm: qcom: Document Hawi SoC and its reference boards
From: Krzysztof Kozlowski @ 2026-06-22 11:00 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260617151602.2018579-1-mukesh.ojha@oss.qualcomm.com>
On Wed, Jun 17, 2026 at 08:46:02PM +0530, Mukesh Ojha wrote:
> Add Hawi SoC and its reference boards to the Qualcomm binding.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> Changes in v2: https://lore.kernel.org/lkml/20260617080147.1657632-1-mukesh.ojha@oss.qualcomm.com/
> - Fixed the position of the Documentation.
> - Corrected the commit text.
>
> Documentation/devicetree/bindings/arm/qcom.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> index 50cc18a6ec5e..e229c0097e6f 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> @@ -303,6 +303,11 @@ properties:
> - xiaomi,sagit
> - const: qcom,msm8998
>
> + - items:
> + - enum:
> + - qcom,hawi-mtp
Normally this should be rejected on the basis of lack of user, however
this is an exception, because the soc compatible is already in use.
As an exception:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
But if ever this commit is used in argument "oh, compatible without user
was accepted here by Krzysztof, so I can do the same", I will
simply NAK such future contribution without reading the rest.
Bjorn,
Please grab this for current RC fixes.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/5] dt-bindings: arm: mediatek: Add MT8127 Amazon ford
From: Krzysztof Kozlowski @ 2026-06-22 10:57 UTC (permalink / raw)
To: Zakariya Hadrami
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, linux-watchdog
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v2-2-6859e29e72a8@proton.me>
On Wed, Jun 17, 2026 at 10:37:00PM +0900, Zakariya Hadrami wrote:
> Add entry for the MT8127 based Amazon ford tablet.
>
> Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
> ---
> Documentation/devicetree/bindings/arm/mediatek.yaml | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] interconnect: qcom: add Maili interconnect provider driver
From: Konrad Dybcio @ 2026-06-22 10:51 UTC (permalink / raw)
To: Raviteja Laggyshetty, Georgi Djakov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jingyi Wang
Cc: linux-arm-msm, linux-pm, devicetree, linux-kernel, Odelu Kukatla
In-Reply-To: <20260622-maili_icc-v2-2-18b5ac08c04f@oss.qualcomm.com>
On 6/22/26 8:34 AM, Raviteja Laggyshetty wrote:
> Add driver for the Qualcomm interconnect buses found in Maili
> based platforms. The topology consists of several NoCs that are
> controlled by a remote processor that collects the aggregated
> bandwidth for each master-slave pairs.
>
> Co-developed-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com>
> Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com>
> Signed-off-by: Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ 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: 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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] arm64: dts: tegra: CPU and cache node updates
From: Sumit Gupta @ 2026-06-22 10:44 UTC (permalink / raw)
To: treding, jonathanh, robh, krzk+dt, conor+dt, devicetree,
linux-tegra, linux-kernel
Cc: bbasu, sumitg
In-Reply-To: <20260121104536.3214101-1-sumitg@nvidia.com>
On 21/01/26 16:15, Sumit Gupta wrote:
> - Fixes for Tegra234/264 device tree CPU compatible string.
> - Populate CPU and L2 cache nodes for Tegra264.
>
> Sumit Gupta (3):
> arm64: dts: tegra234: Fix CPU compatible string to cortex-a78ae
> arm64: dts: tegra264: Fix CPU1 node unit-address
> arm64: dts: tegra264: Populate CPU and L2 cache nodes
>
> arch/arm64/boot/dts/nvidia/tegra234.dtsi | 24 +-
> arch/arm64/boot/dts/nvidia/tegra264.dtsi | 323 ++++++++++++++++++++++-
> 2 files changed, 334 insertions(+), 13 deletions(-)
>
A gentle reminder on this series, which got missed and is pending.
I have verified it still applies cleanly on top of linux-next.
Please take a look when you get a chance.
Thanks,
Sumit
^ permalink raw reply
* Re: [PATCH v3 4/5] dt-bindings: dmaengine: sun50i-a64-dma: Add allwinner,sun60i-a733-dma compatible string
From: Krzysztof Kozlowski @ 2026-06-22 10:41 UTC (permalink / raw)
To: Yuanshen Cao
Cc: conor+dt, mripard, krzk+dt, robh, samuel, wens, jernej.skrabec,
Frank.Li, vkoul, dmaengine, linux-arm-kernel, linux-sunxi,
devicetree, linux-kernel, Frank Li
In-Reply-To: <20260622-sun60i-a733-dma-v3-4-f697ef296cbc@gmail.com>
On Mon, Jun 22, 2026 at 01:36:26AM +0000, Yuanshen Cao wrote:
> Add `allwinner,sun60i-a733-dma` to the list of compatible strings for the
> `sun50i-a64-dma` dtbinding documentation.
>
> While the A733 DMA controller shares many similarities with the sun50i-a64
> DMA controller, it requires a specific configuration due to differences in:
> - Interrupt register layout and mapping.
> - Number of channels per interrupt register.
> - Support for higher (32G) address widths in LLI parameters.
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Signed-off-by: Yuanshen Cao <alex.caoys@gmail.com>
> ---
> Documentation/devicetree/bindings/dma/allwinner,sun50i-a64-dma.yaml | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 2/8] media: v4l2-fwnode: Add common helper library for 1-to-1 subdev registration
From: Laurent Pinchart @ 2026-06-22 10:39 UTC (permalink / raw)
To: Frank Li
Cc: Sakari Ailus, Mauro Carvalho Chehab, Michael Riesch, Frank Li,
Martin Kepplinger-Novakovic, Rui Miguel Silva, Purism Kernel Team,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-media, linux-kernel,
imx, devicetree, linux-arm-kernel
In-Reply-To: <ajNwgq96WRrykE5I@SMW015318>
Hi Frank,
On Wed, Jun 17, 2026 at 11:13:55PM -0500, Frank Li wrote:
> On Thu, Jun 18, 2026 at 01:36:20AM +0300, Sakari Ailus wrote:
> > On Wed, Jun 17, 2026 at 03:50:12PM -0400, Frank.Li@oss.nxp.com wrote:
> > > From: Frank Li <Frank.Li@nxp.com>
> > >
> > > Many V4L2 subdev drivers implement the same registration and media pad
> > > setup logic for simple pipelines consisting of a single sink pad and a
> > > single source pad. As a result, the same boilerplate code is duplicated
> > > across multiple drivers.
> > >
> > > Introduce a common helper library for 1-to-1 subdevs to encapsulate the
> > > registration, media entity initialization, and cleanup paths. Drivers
> > > can embed a struct v4l2_subdev_1to1 instance and use the provided helper
> > > APIs instead of open-coding the setup sequence.
> >
> > I appreciate your efforts in trying to reduce the amount of code drivers
> > need simply to get things done but I think there are a few issues with the
> > approach taken in this patch:
> >
> > - The new helpers aren't generic enough, but require two pads; one sink,
> > one source.
>
> It can cover many case already, there are many bridge type subdev. after
> glace of all code, many CSI2RX is type device. It should one kind important
> type/case, like sensors.
>
> And I plan do 1 TO N replicator driver, which duplicate 1 sink pad to N
> source pad (with/without register config), plus exist video-mux driver,
>
> It think It can cover more than 80% cases.
>
> > You could provide special helpers for just this case, but
> > right now it looks like that if there's something you need that the
> > helper assumes you don't, you can't use the helper at all. In other
> > words, more modularity would be nice.
>
> We can add it later if need, which easy to replace 1to1 API, like I did
> for sensor one.
>
> > - The new helper should work with the existing types and not add new types
> > (struct v4l2_subdev_1to1).
>
> May be save vep data into v4l2_subdev to avoid parse it every time. and
> enhence media_entity_pads_init() to avoid refer caller data.
I agree with Sakari about not introducing a new structure.
We could create a version of media_entity_pads_init() that allocates the
pads array dynamically (*not* with a devm_* function !), and free it in
media_entity_cleanup().
> >
> > - There should be a way to provide default V4L2 fwnode endpoint
> > configuration as well as to validate the obtained configuration.
>
> Do you means remote_bustype_cap_mask information get from a callback?
>
> > I don't have a good proposal to address the above but at least one way I
> > can think of making error handling easier would be to use devm_() for
> > teardown in more places we to today. That certainly does have its own
> > issues though.
>
> I tried it before, media and v4l2's clean up is not revised order of init.
> Sorry, I can't find original thread. I remember laurnet pinchart said there
> are order problem.
>
> 1 v4l2_subdev_init()
> 2. v4l2_async_subdev_nf_init()
> 3. v4l2_async_nf_register()
> 4. media_entity_pads_init()
> 5 v4l2_async_register_subdev()
>
>
> v4l2_async_unregister_subdev(sd);
> v4l2_subdev_cleanup(sd); // Not sure if it save to move to last step
> media_entity_cleanup(&sd->entity);
> v4l2_async_nf_unregister(&csi2->notifier);
> v4l2_async_nf_cleanup(&csi2->notifier);
The cleanup procedure is really bad, it's a known issue. Fixing that
involves resuming Sakari's work on life time management in V4L2.
--
Regards,
Laurent Pinchart
^ 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
^ permalink raw reply
* Re: [PATCH v2 1/7] ASoC: dt-bindings: ES8389: Add members about HPF and clock
From: Mark Brown @ 2026-06-22 10:37 UTC (permalink / raw)
To: Zhang Yi; +Cc: conor+dt, devicetree, krzk+dt, linux-sound, robh, tiwai
In-Reply-To: <20260622063318.3535-1-zhangyi@everest-semi.com>
[-- Attachment #1: Type: text/plain, Size: 1705 bytes --]
On Mon, Jun 22, 2026 at 02:33:18PM +0800, Zhang Yi wrote:
> > > + everest,mclk-src:
> > > + $ref: /schemas/types.yaml#/definitions/uint8
> > > + description:
> > > + Indicates that SCLK is used as the internal clock.
> > > + minimum: 0
> > > + maximum: 0x01
> > > + default: 0x00
> >
> > Could this be done by having a clock API property for the MCLK source
> > and then falling back to using SCLK if that's absent? That would feel
> > more natural for DT, and you'll probably want the MCLK property at some
> > point. It's also a bit more of a neutral description of the hardware,
> > future versions might switch dynamically between MCLK or SCLK based on
> > some criteria or something.
> Does the implementation below match what you described?
>
> es8389->mclk = devm_clk_get_optional(component->dev, "mclk");
> if (IS_ERR(es8389->mclk))
> es8389->mclk_src = ES8389_SCLK_PIN;
Yes.
> > > + everest,hpf-frq:
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > + description:
> > > + The frequency of HPF in Hz.
> > > + maximum: 1020
> > > + default: 16
> > Why configure this with a fixed value in the DT - it's the sort of thing
> > I'd expect to turn up as an ALSA control so the user can vary it at
> > runtime if they want to?
> I don't want users to be able to change the HPF value at any time,
> as this would affect the codec's startup.
> Or I can use SOC_SINGLE_EXT to define HPF-related controls
> and write the modified values to cache when writing to the hardware is not permitted.
Some devices have custom controls like that already, you could also
prevent writes while audio is running.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Andy Shevchenko @ 2026-06-22 10:35 UTC (permalink / raw)
To: Linus Walleij
Cc: Michael Walle, Bartosz Golaszewski, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, afaerber@suse.com,
wbg@kernel.org, mathieu.dubois-briand@bootlin.com,
lars@metafoo.de, Michael.Hennerich@analog.com, jic23@kernel.org,
nuno.sa@analog.com, andy@kernel.org, dlechner@baylibre.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org, linux-iio@vger.kernel.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰],
Yu-Chun Lin [林祐君]
In-Reply-To: <CAD++jLncD2ZjH3aedOkGNYP3FyZ=i7Pb0OcKKZKuMOPGNjM_nQ@mail.gmail.com>
On Fri, Jun 19, 2026 at 11:08:30PM +0200, Linus Walleij wrote:
> On Mon, Jun 8, 2026 at 4:41 PM Michael Walle <mwalle@kernel.org> wrote:
>
> > >>> Without an accessor like gpio_regmap_get_gpiochip(), we cannot retrieve the
> > >>> gpio_chip instantiated inside gpio-regmap.c to fulfill these requirements in our
> > >>> map() function.
> >
> > Why is gpiochip_irq_reqres() called in the first place? Isn't that
> > only called if the irq handling is set up via gc->irq.chip and not
> > via gpiochip_irqchip_add_domain() like in gpio-regmap?
>
> Not really, the gpiochip_irq_reqres() is called to mark that a
> GPIO line is used for IRQ, so the gpiolib cannot turn this
> GPIO into an output line, gpiod_direction_out() will fail
> on lines used for IRQ. So it's a failsafe.
>
> You can live without it of course, but then you don't get
> this failsafe.
So, when we instantiate our own domain in regmap GPIO, we should have those
callbacks be defined somewhere?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/9] arm64: dts: renesas: r8a774a1: Add soc: label to soc node
From: Geert Uytterhoeven @ 2026-06-22 10:35 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Rob Herring, devicetree, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260621025052.406507-1-marek.vasut+renesas@mailbox.org>
Hi Marek,
On Sun, 21 Jun 2026 at 04:51, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> Add soc: label to the /soc {} node to align the DT with r8a77951.dtsi
> which already has that soc: label. The soc: label is useful in U-Boot
> where it is used in U-Boot extras DT fragments.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
For the whole series:
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-devel for v7.3, squashed into a single
commit. Unfortunately there is no cover letter, so I will have to add
all nine Link-tags.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v6 1/4] arm64: dts: renesas: r9a09g047: Add RZ/G3E Sound support
From: Geert Uytterhoeven @ 2026-06-22 10:29 UTC (permalink / raw)
To: John Madieu
Cc: magnus.damm, robh, krzk+dt, conor+dt, linux-renesas-soc,
devicetree, linux-kernel, john.madieu, biju.das.jz
In-Reply-To: <20260619083951.3777556-2-john.madieu.xa@bp.renesas.com>
On Fri, 19 Jun 2026 at 10:40, John Madieu <john.madieu.xa@bp.renesas.com> wrote:
>
> Add the snd_rzg3e node for the RZ/G3E SoC with all sub-components:
>
> - SSI (Serial Sound Interface) units 0-9
> - SSIU (Serial Sound Interface Unit) units 0-27
> - SRC (Sample Rate Converter) units 0-9
> - CTU (Channel Transfer Unit) units 0-7
> - DVC (Digital Volume Control) units 0-1
> - MIX (Mixer) units 0-1
>
> Sub-node names follow the new RZ/G3E sound binding: unprefixed
> 'ssi', 'ssiu', 'src', 'dvc', 'mix', 'ctu' wrapper nodes instead of
> the legacy 'rcar_sound,xxx' R-Car prefix.
>
> Wire up all 5 DMA controllers (dmac0-dmac4) for each audio sub-node
> with repeated channel names, so that the DMA core can pick the first
> available controller.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> ---
>
> Chqnges:
>
> v6: No changes.
You did adjust the size of the SCU register block.
> --- a/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> @@ -912,6 +912,468 @@ rsci9: serial@12803000 {
> status = "disabled";
> };
>
> + snd_rzg3e: sound@13c00000 {
> + compatible = "renesas,r9a09g047-sound";
> + reg = <0 0x13c00000 0 0x20000>, /* SCU */
> + <0 0x13c20000 0 0x10000>, /* ADG */
> + <0 0x13c30000 0 0x1000>, /* SSIU */
> + <0 0x13c31000 0 0x1f000>, /* SSI */
> + <0 0x13c50000 0 0x10000>; /* Audio DMAC peri peri */
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Nuno Sá @ 2026-06-22 10:29 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: Jonathan Cameron, Conor Dooley, Janani Sunil, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <5u4dnsgxwcwie45f24cacyzf3dko4srhyyyhcpom6tsvhqtmpc@y7d7gmex6n7k>
On Mon, Jun 22, 2026 at 10:24:05AM +0100, Rodrigo Alencar wrote:
> On 21/06/26 15:33, Jonathan Cameron wrote:
> > On Fri, 19 Jun 2026 16:54:11 +0100
> > Nuno Sá <noname.nuno@gmail.com> wrote:
> >
> > > On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
> > > > On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> > > > > On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > > > > > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > > > > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > > > > > >
> > > > > > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > > > > > integrated precision reference.
> > > > > > > > > > > ...
> > > > > > > > > > > Probably others may comment on that, but...
> > > > > > > > > > >
> > > > > > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > > > > > >
> > > > > > > > > > > That way I suppose that an example would look like...
> > > > > > > > > > > > +
> > > > > > > > > > > > +patternProperties:
> > > > > > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > > > > > + type: object
> > > > > > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > > > > > +
> > > > > > > > > > > > + properties:
> > > > > > > > > > > > + reg:
> > > > > > > > > > > > + description: Channel number.
> > > > > > > > > > > > + minimum: 0
> > > > > > > > > > > > + maximum: 15
> > > > > > > > > > > > +
> > > > > > > > > > > > + adi,output-range-microvolt:
> > > > > > > > > > > > + description: |
> > > > > > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > > > > > + oneOf:
> > > > > > > > > > > > + - items:
> > > > > > > > > > > > + - const: 0
> > > > > > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > > > > > + - items:
> > > > > > > > > > > > + - const: -5000000
> > > > > > > > > > > > + - const: 5000000
> > > > > > > > > > > > + - items:
> > > > > > > > > > > > + - const: -10000000
> > > > > > > > > > > > + - const: 10000000
> > > > > > > > > > > > + - items:
> > > > > > > > > > > > + - const: -15000000
> > > > > > > > > > > > + - const: 15000000
> > > > > > > > > > > > + - items:
> > > > > > > > > > > > + - const: -20000000
> > > > > > > > > > > > + - const: 20000000
> > > > > > > > > > > > +
> > > > > > > > > > > > + required:
> > > > > > > > > > > > + - reg
> > > > > > > > > > > > +
> > > > > > > > > > > > + additionalProperties: false
> > > > > > > > > > > > +
> > > > > > > > > > > > +required:
> > > > > > > > > > > > + - compatible
> > > > > > > > > > > > + - reg
> > > > > > > > > > > > + - vdd-supply
> > > > > > > > > > > > + - avdd-supply
> > > > > > > > > > > > + - hvdd-supply
> > > > > > > > > > > > +
> > > > > > > > > > > > +dependencies:
> > > > > > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > > > > > +
> > > > > > > > > > > > +allOf:
> > > > > > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > > > > > +
> > > > > > > > > > > > +unevaluatedProperties: false
> > > > > > > > > > > > +
> > > > > > > > > > > > +examples:
> > > > > > > > > > > > + - |
> > > > > > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > > > > > +
> > > > > > > > > > > > + spi {
> > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > +
> > > > > > > > > > > > + dac@0 {
> > > > > > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > > > > > +
> > > > > > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > +
> > > > > > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > +
> > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > +
> > > > > > > > > > > > + channel@0 {
> > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > + };
> > > > > > > > > > > > +
> > > > > > > > > > > > + channel@1 {
> > > > > > > > > > > > + reg = <1>;
> > > > > > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > + };
> > > > > > > > > > > > +
> > > > > > > > > > > > + channel@2 {
> > > > > > > > > > > > + reg = <2>;
> > > > > > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > + };
> > > > > > > > > > > > + };
> > > > > > > > > > > > + };
> > > > > > > > > > > ...
> > > > > > > > > > >
> > > > > > > > > > > spi {
> > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > >
> > > > > > > > > > > multi-dac@0 {
> > > > > > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > > > > > reg = <0>;
> > > > > > > > > > > spi-max-frequency = <25000000>;
> > > > > > > > > > >
> > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > >
> > > > > > > > > > > dac@0 {
> > > > > > > > > > > reg = <0>;
> > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > >
> > > > > > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > >
> > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > >
> > > > > > > > > > > channel@0 {
> > > > > > > > > > > reg = <0>;
> > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > };
> > > > > > > > > > >
> > > > > > > > > > > channel@1 {
> > > > > > > > > > > reg = <1>;
> > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > };
> > > > > > > > > > >
> > > > > > > > > > > channel@2 {
> > > > > > > > > > > reg = <2>;
> > > > > > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > };
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > > dac@1 {
> > > > > > > > > > > reg = <1>;
> > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > >
> > > > > > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > > > > > >
> > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > >
> > > > > > > > > > > channel@0 {
> > > > > > > > > > > reg = <0>;
> > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > };
> > > > > > > > > > >
> > > > > > > > > > > channel@1 {
> > > > > > > > > > > reg = <1>;
> > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > };
> > > > > > > > > > > }
> > > > > > > > > > > };
> > > > > > > > > > > };
> > > > > > > > > > >
> > > > > > > > > > > then you might need something like:
> > > > > > > > > > >
> > > > > > > > > > > patternProperties:
> > > > > > > > > > > "^dac@[0-3]$":
> > > > > > > > > > >
> > > > > > > > > > > and put most of the things under this node pattern.
> > > > > > > > > > >
> > > > > > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > > > > > >
> > > > > > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > > > > > Hi Rodrigo,
> > > > > > > > > >
> > > > > > > > > > Thank you for looking at this.
> > > > > > > > > >
> > > > > > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > > > > > speculatively without a validating use case.
> > > > > > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > > > > > looking at it another way a kind of distributed SPI mux.
> > > > > > > > >
> > > > > > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > > > > > in all devices in the chain as one big SPI message.
> > > > > > > > >
> > > > > > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > > > > > longer term how to support it cleanly in SPI.
> > > > > > >
> > > > > > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > > > > > see if I can find what I am thinking of...
> > > > > >
> > > > > >
> > > > > > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > > > > > slightly different properties.
> > > > > >
> > > > > > microchip,device-addr:
> > > > > > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > enum: [0, 1, 2, 3]
> > > > > > default: 0
> > > > > >
> > > > > > and
> > > > > >
> > > > > >
> > > > > > microchip,hw-device-address:
> > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > minimum: 0
> > > > > > maximum: 3
> > > > > > description:
> > > > > > The address is set on a per-device basis by fuses in the factory,
> > > > > > configured on request. If not requested, the fuses are set for 0x1.
> > > > > > The device address is part of the device markings to avoid
> > > > > > potential confusion. This address is coded on two bits, so four possible
> > > > > > addresses are available when multiple devices are present on the same
> > > > > > SPI bus with only one Chip Select line for all devices.
> > > > > > Each device communication starts by a CS falling edge, followed by the
> > > > > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > > > > > which is first one on the wire).
> > > > > >
> > > > > > This sounds exactly like the sort of feature that you're dealing with
> > > > > > here?
> > > > > >
> > > > >
> > > > > The core idea yes but for this chip, things are a bit more annoying (but
> > > > > Janani can correct me if I'm wrong). Here, each device can, in theory,
> > > > > have it's own supplies, pins and at the very least, channels with maybe
> > > > > different scales. That is why Janani is proposing dac nodes. Given I
> > > > > honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> > > > > about solving this at the spi level.
> > > > >
> > > > > Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> > > > > together in the same bus.
> > > >
> > > > I'm definitely missing something, because that property for the
> > > > microchip devices is not impacted what else is on the bus. AFAICT, you
> > > > could have an mcp3911 and an mcp3564 on the same bus even though both
> > > > are completely different devices with different drivers. They have
> > > > individual device nodes and their own supplies etc etc. These aren't
> > > > per-channel properties on an adc or dac, they're per child device on a
> > > > spi bus.
> > >
> > > Maybe I'm the one missing something :). IIRC, spi would not allow two
> > > devices on the same CS right? Because for this chip we would need
> > > something like:
> > >
> > > spi {
> > > dac@0 {
> > > reg = <0>;
> > > adi,pin-id = <0>;
> > > };
> > >
> > > dac@1 {
> > > reg = <0>; // which seems already problematic?
> > > adi,pin-id <1>;
> > > };
> > >
> > > ...
> > >
> > > //up to 4
> > > };
> > Yeah. It's not clear to me how that works for the microchip devices
> > (I suspect it doesn't!)
> >
> > Just thinking as I type, but could we do something a bit nasty with
> > a gpio mux that doesn't actually switch but represents the GPIO being
> > shared? Given this is all tied to the spi bus that should all happen
> > under serializing locks.
> >
> > Agreed though that this would be nicer as an SPI thing that let
> > us specify that a single CS is share by multiple devices and their
> > is some other signal acting to select which one we are talking to.
> >
>
> If the device-addressing on the same chip-select is to be handled
> by the spi framework, wouldn't we lose device-specific features?
>
> I understand that this multi-device feature is there mostly to extend the
> channel count from 16 to 32, 48 or 64. I suppose the command:
>
> "MULTI DEVICE SW LDAC MODE"
>
> exists so that software can update channel values accross multiple devices.
Right! You do have a point! I agree the main driver for a feature like
this is likely to extend the channel count and effectively "aggregate"
devices.
But I would say that even with the spi solution the MULTI DEVICE stuff
should be doable (as we still need a sort of adi,pin-id property).
But yes, I do feel that the whole feature is for aggregation so seeing
one device with 32 channels is the expectation here? Rather than seeing
two devices with 16 channels.
- Nuno Sá
>
> --
> Kind regards,
>
> Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH V13 2/9] dt-bindings: iio: imu: icm42600: Add icm42607
From: Jonathan Cameron @ 2026-06-22 10:27 UTC (permalink / raw)
To: Jean-Baptiste Maneyrol
Cc: Chris Morgan, linux-iio@vger.kernel.org, andy@kernel.org,
nuno.sa@analog.com, dlechner@baylibre.com,
linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org,
heiko@sntech.de, conor+dt@kernel.org, krzk+dt@kernel.org,
robh@kernel.org, andriy.shevchenko@intel.com, Chris Morgan,
Krzysztof Kozlowski
In-Reply-To: <BE1P281MB1426C557A66945951D382EDDCEEF2@BE1P281MB1426.DEUP281.PROD.OUTLOOK.COM>
On Mon, 22 Jun 2026 09:23:28 +0000
Jean-Baptiste Maneyrol <Jean-Baptiste.Maneyrol@tdk.com> wrote:
> Hello Chris and Jonathan,
>
> concerning dt bindings, my initial understanding was that we had a file per
> driver. But here, Chris is doing a new driver for icm42607 while adding new
> bindings here.
>
> Does it means we don't have 1 binding file per driver, and there is no need
> to create a new binding file for inv_icm42607 driver?
Yes. We often combine bindings when there is a lot of duplication and
only a few device specific rules are needed to describe the new parts.
Jonathan
>
> Despite the naming, icm42607 chips are a complete new design very different
> than all other icm42600 chips. It using similar IPs for things like the FIFO,
> but all other parts are different. Especially, it doesn't use banks for
> registers access but indirect access delegated to the chip internals for
> accessing certain registers.
>
> Thanks,
> JB
>
> >From: Chris Morgan <macromorgan@hotmail.com>
> >
> >Add the ICM42607 and ICM42607P inertial measurement unit.
> >
> >This device is functionally very similar to the icm42600 series with a
> >very different register layout. The driver does not require an
> >interrupt for these specific chip revisions.
> >
> >Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> >Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> >---
> > .../bindings/iio/imu/invensense,icm42600.yaml | 18 +++++++++++++++++-
> > 1 file changed, 17 insertions(+), 1 deletion(-)
> >
> >diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
> >index 9b2af104f186..81b6e85decd5 100644
> >--- a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
> >+++ b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
> >@@ -30,6 +30,8 @@ properties:
> > - invensense,icm42600
> > - invensense,icm42602
> > - invensense,icm42605
> >+ - invensense,icm42607
> >+ - invensense,icm42607p
> > - invensense,icm42622
> > - invensense,icm42631
> > - invensense,icm42686
> >@@ -67,10 +69,24 @@ properties:
> > required:
> > - compatible
> > - reg
> >- - interrupts
> >
> > allOf:
> > - $ref: /schemas/spi/spi-peripheral-props.yaml#
> >+ - if:
> >+ properties:
> >+ compatible:
> >+ contains:
> >+ enum:
> >+ - invensense,icm42600
> >+ - invensense,icm42602
> >+ - invensense,icm42605
> >+ - invensense,icm42622
> >+ - invensense,icm42631
> >+ - invensense,icm42686
> >+ - invensense,icm42688
> >+ then:
> >+ required:
> >+ - interrupts
> >
> > unevaluatedProperties: false
> >
> >--
> >2.43.
^ permalink raw reply
* Re: [PATCH V13 2/9] dt-bindings: iio: imu: icm42600: Add icm42607
From: Jean-Baptiste Maneyrol @ 2026-06-22 9:23 UTC (permalink / raw)
To: Jonathan Cameron, Chris Morgan
Cc: linux-iio@vger.kernel.org, andy@kernel.org, nuno.sa@analog.com,
dlechner@baylibre.com, linux-rockchip@lists.infradead.org,
devicetree@vger.kernel.org, heiko@sntech.de, conor+dt@kernel.org,
krzk+dt@kernel.org, robh@kernel.org, andriy.shevchenko@intel.com,
Chris Morgan, Krzysztof Kozlowski
In-Reply-To: <20260621181804.27b44942@jic23-huawei>
Hello Chris and Jonathan,
concerning dt bindings, my initial understanding was that we had a file per
driver. But here, Chris is doing a new driver for icm42607 while adding new
bindings here.
Does it means we don't have 1 binding file per driver, and there is no need
to create a new binding file for inv_icm42607 driver?
Despite the naming, icm42607 chips are a complete new design very different
than all other icm42600 chips. It using similar IPs for things like the FIFO,
but all other parts are different. Especially, it doesn't use banks for
registers access but indirect access delegated to the chip internals for
accessing certain registers.
Thanks,
JB
>From: Chris Morgan <macromorgan@hotmail.com>
>
>Add the ICM42607 and ICM42607P inertial measurement unit.
>
>This device is functionally very similar to the icm42600 series with a
>very different register layout. The driver does not require an
>interrupt for these specific chip revisions.
>
>Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
>Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>---
> .../bindings/iio/imu/invensense,icm42600.yaml | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
>diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
>index 9b2af104f186..81b6e85decd5 100644
>--- a/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
>+++ b/Documentation/devicetree/bindings/iio/imu/invensense,icm42600.yaml
>@@ -30,6 +30,8 @@ properties:
> - invensense,icm42600
> - invensense,icm42602
> - invensense,icm42605
>+ - invensense,icm42607
>+ - invensense,icm42607p
> - invensense,icm42622
> - invensense,icm42631
> - invensense,icm42686
>@@ -67,10 +69,24 @@ properties:
> required:
> - compatible
> - reg
>- - interrupts
>
> allOf:
> - $ref: /schemas/spi/spi-peripheral-props.yaml#
>+ - if:
>+ properties:
>+ compatible:
>+ contains:
>+ enum:
>+ - invensense,icm42600
>+ - invensense,icm42602
>+ - invensense,icm42605
>+ - invensense,icm42622
>+ - invensense,icm42631
>+ - invensense,icm42686
>+ - invensense,icm42688
>+ then:
>+ required:
>+ - interrupts
>
> unevaluatedProperties: false
>
>--
>2.43.0
^ 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
^ permalink raw reply
* Re: [PATCH v6 1/4] arm64: dts: renesas: r9a09g047: Add RZ/G3E Sound support
From: Geert Uytterhoeven @ 2026-06-22 10:19 UTC (permalink / raw)
To: John Madieu
Cc: magnus.damm, robh, krzk+dt, conor+dt, linux-renesas-soc,
devicetree, linux-kernel, john.madieu, biju.das.jz
In-Reply-To: <20260619083951.3777556-2-john.madieu.xa@bp.renesas.com>
On Fri, 19 Jun 2026 at 10:40, John Madieu <john.madieu.xa@bp.renesas.com> wrote:
> Add the snd_rzg3e node for the RZ/G3E SoC with all sub-components:
>
> - SSI (Serial Sound Interface) units 0-9
> - SSIU (Serial Sound Interface Unit) units 0-27
> - SRC (Sample Rate Converter) units 0-9
> - CTU (Channel Transfer Unit) units 0-7
> - DVC (Digital Volume Control) units 0-1
> - MIX (Mixer) units 0-1
>
> Sub-node names follow the new RZ/G3E sound binding: unprefixed
> 'ssi', 'ssiu', 'src', 'dvc', 'mix', 'ctu' wrapper nodes instead of
> the legacy 'rcar_sound,xxx' R-Car prefix.
>
> Wire up all 5 DMA controllers (dmac0-dmac4) for each audio sub-node
> with repeated channel names, so that the DMA core can pick the first
> available controller.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> ---
>
> Chqnges:
>
> v6: No changes.
So same stylistic issues as v5.
No need to resend just for this (every resend consumes review time on
my side), I may fix it while applying.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v5 1/4] arm64: dts: renesas: r9a09g047: Add RZ/G3E Sound support
From: Geert Uytterhoeven @ 2026-06-22 10:16 UTC (permalink / raw)
To: John Madieu
Cc: magnus.damm, robh, krzk+dt, conor+dt, linux-renesas-soc,
devicetree, linux-kernel, biju.das.jz, john.madieu
In-Reply-To: <20260610074702.1743334-2-john.madieu.xa@bp.renesas.com>
Hi John,
On Wed, 10 Jun 2026 at 09:47, John Madieu <john.madieu.xa@bp.renesas.com> wrote:
> Add the snd_rzg3e node for the RZ/G3E SoC with all sub-components:
>
> - SSI (Serial Sound Interface) units 0-9
> - SSIU (Serial Sound Interface Unit) units 0-27
> - SRC (Sample Rate Converter) units 0-9
> - CTU (Channel Transfer Unit) units 0-7
> - DVC (Digital Volume Control) units 0-1
> - MIX (Mixer) units 0-1
>
> Sub-node names follow the new RZ/G3E sound binding: unprefixed
> 'ssi', 'ssiu', 'src', 'dvc', 'mix', 'ctu' wrapper nodes instead of
> the legacy 'rcar_sound,xxx' R-Car prefix.
>
> Wire up all 5 DMA controllers (dmac0-dmac4) for each audio sub-node
> with repeated channel names, so that the DMA core can pick the first
> available controller.
>
> Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
> ---
>
> Changes:
>
> v5:
> - Use hexadecimal CPG module clock numbers, for easier matching with the
> documentation.
> - Use hexadecimal CPG module reset numbers.
> - Lowercase the SSI reg size: 0x1F000 -> 0x1f000.
> - Extend the SCU reg region from 0x10000 to 0x20000 to cover the SCU DMAC.
> - Drop the per-line clock/reset comments now that the numbers are hex and
> the names are self-documenting, and pack clocks/resets two entries per
> line so each line lines up with its clock-names/reset-names counterpart.
Thanks for the update!
> --- a/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
> @@ -912,6 +912,468 @@ rsci9: serial@12803000 {
> status = "disabled";
> };
>
> + snd_rzg3e: sound@13c00000 {
> + compatible = "renesas,r9a09g047-sound";
> + reg = <0 0x13c00000 0 0x10000>, /* SCU */
> + <0 0x13c20000 0 0x10000>, /* ADG */
> + <0 0x13c30000 0 0x1000>, /* SSIU */
> + <0 0x13c31000 0 0x1f000>, /* SSI */
> + <0 0x13c50000 0 0x10000>; /* Audio DMAC peri peri */
> + reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
> + clocks = <&cpg CPG_MOD 0xf5>,
> + <&cpg CPG_MOD 0x181>, <&cpg CPG_MOD 0x182>,
Please align the opening braces with the previous line...
> + <&cpg CPG_MOD 0x183>, <&cpg CPG_MOD 0x184>,
> + <&cpg CPG_MOD 0x185>, <&cpg CPG_MOD 0x186>,
> + <&cpg CPG_MOD 0x187>, <&cpg CPG_MOD 0x188>,
> + <&cpg CPG_MOD 0x189>, <&cpg CPG_MOD 0x18a>,
> + <&cpg CPG_MOD 0x174>, <&cpg CPG_MOD 0x175>,
> + <&cpg CPG_MOD 0x176>, <&cpg CPG_MOD 0x177>,
> + <&cpg CPG_MOD 0x178>, <&cpg CPG_MOD 0x179>,
> + <&cpg CPG_MOD 0x17a>, <&cpg CPG_MOD 0x17b>,
> + <&cpg CPG_MOD 0x17c>, <&cpg CPG_MOD 0x17d>,
> + <&cpg CPG_MOD 0x172>, <&cpg CPG_MOD 0x173>,
> + <&cpg CPG_MOD 0x172>, <&cpg CPG_MOD 0x173>,
> + <&cpg CPG_MOD 0x170>, <&cpg CPG_MOD 0x171>,
> + <&cpg CPG_MOD 0xfb>, <&cpg CPG_MOD 0xfc>,
> + <&cpg CPG_MOD 0xfd>, <&cpg CPG_MOD 0xfa>,
> + <&cpg CPG_MOD 0x180>,
> + <&cpg CPG_MOD 0xf6>, <&cpg CPG_MOD 0xf7>,
> + <&cpg CPG_MOD 0x17e>,
> + <&cpg CPG_MOD 0x160>, <&cpg CPG_MOD 0x161>,
> + <&cpg CPG_MOD 0x162>, <&cpg CPG_MOD 0x163>,
> + <&cpg CPG_MOD 0x164>, <&cpg CPG_MOD 0x165>,
> + <&cpg CPG_MOD 0x166>, <&cpg CPG_MOD 0x167>,
> + <&cpg CPG_MOD 0x168>, <&cpg CPG_MOD 0x169>,
> + <&cpg CPG_MOD 0xf8>, <&cpg CPG_MOD 0xf9>;
> + clock-names = "ssi-all",
> + "ssi-0", "ssi-1",
... and the double quotes...
> + "ssi-2", "ssi-3",
> + "ssi-4", "ssi-5",
> + "ssi-6", "ssi-7",
> + "ssi-8", "ssi-9",
> + "src-0", "src-1",
> + "src-2", "src-3",
> + "src-4", "src-5",
> + "src-6", "src-7",
> + "src-8", "src-9",
> + "mix-0", "mix-1",
> + "ctu-0", "ctu-1",
> + "dvc-0", "dvc-1",
> + "audio-clka", "audio-clkb",
> + "audio-clkc", "audio-clki",
> + "ssif_supply",
> + "scu", "scu_x2",
> + "scu_supply",
> + "adg-ssi-0", "adg-ssi-1",
> + "adg-ssi-2", "adg-ssi-3",
> + "adg-ssi-4", "adg-ssi-5",
> + "adg-ssi-6", "adg-ssi-7",
> + "adg-ssi-8", "adg-ssi-9",
> + "audmapp", "adg";
> + power-domains = <&cpg>;
> + resets = <&cpg 0xe1>,
> + <&cpg 0xe2>, <&cpg 0xe3>,
> + <&cpg 0xe4>, <&cpg 0xe5>,
> + <&cpg 0xe6>, <&cpg 0xe7>,
> + <&cpg 0xe8>, <&cpg 0xe9>,
> + <&cpg 0xea>, <&cpg 0xeb>,
> + <&cpg 0xec>, <&cpg 0xee>,
> + <&cpg 0xed>;
> + reset-names = "ssi-all",
> + "ssi-0", "ssi-1",
... here too.
> + "ssi-2", "ssi-3",
> + "ssi-4", "ssi-5",
> + "ssi-6", "ssi-7",
> + "ssi-8", "ssi-9",
> + "scu", "adg",
> + "audmapp";
> + status = "disabled";
> +
> + ctu {
> + ctu00: ctu-0 { };
> + ctu01: ctu-1 { };
> + ctu02: ctu-2 { };
> + ctu03: ctu-3 { };
> + ctu10: ctu-4 { };
> + ctu11: ctu-5 { };
> + ctu12: ctu-6 { };
> + ctu13: ctu-7 { };
> + };
> +
> + dvc {
> + dvc0: dvc-0 {
> + dmas = <&dmac0 0x1db3>, <&dmac1 0x1db3>,
> + <&dmac2 0x1db3>, <&dmac3 0x1db3>,
> + <&dmac4 0x1db3>;
> + dma-names = "tx", "tx", "tx", "tx", "tx";
> + };
> + dvc1: dvc-1 {
> + dmas = <&dmac0 0x1db4>, <&dmac1 0x1db4>,
> + <&dmac2 0x1db4>, <&dmac3 0x1db4>,
> + <&dmac4 0x1db4>;
> + dma-names = "tx", "tx", "tx", "tx", "tx";
> + };
> + };
> +
> + mix {
> + mix0: mix-0 { };
> + mix1: mix-1 { };
> + };
> +
> + src {
> + src0: src-0 {
> + interrupts = <GIC_SPI 902 IRQ_TYPE_LEVEL_HIGH>;
> + dmas = <&dmac0 0x1d9f>, <&dmac0 0x1da9>,
> + <&dmac1 0x1d9f>, <&dmac1 0x1da9>,
> + <&dmac2 0x1d9f>, <&dmac2 0x1da9>,
> + <&dmac3 0x1d9f>, <&dmac3 0x1da9>,
> + <&dmac4 0x1d9f>, <&dmac4 0x1da9>;
> + dma-names = "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx";
These lines are way too long (checkpatch?).
[...]
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Nuno Sá @ 2026-06-22 10:17 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Conor Dooley, Janani Sunil, Rodrigo Alencar, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <20260622102722.5900592f@jic23-huawei>
On Mon, Jun 22, 2026 at 10:27:22AM +0100, Jonathan Cameron wrote:
> On Mon, 22 Jun 2026 10:07:01 +0100
> Nuno Sá <noname.nuno@gmail.com> wrote:
>
> > On Sun, Jun 21, 2026 at 07:35:42PM +0100, Conor Dooley wrote:
> > > On Sun, Jun 21, 2026 at 03:33:40PM +0100, Jonathan Cameron wrote:
> > > > On Fri, 19 Jun 2026 16:54:11 +0100
> > > > Nuno Sá <noname.nuno@gmail.com> wrote:
> > > >
> > > > > On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
> > > > > > On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> > > > > > > On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > > > > > > > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > > > > > > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > > > > > > > >
> > > > > > > > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > > > > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > > > > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > > > > > > > integrated precision reference.
> > > > > > > > > > > > > ...
> > > > > > > > > > > > > Probably others may comment on that, but...
> > > > > > > > > > > > >
> > > > > > > > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > > > > > > > >
> > > > > > > > > > > > > That way I suppose that an example would look like...
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +patternProperties:
> > > > > > > > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > > > > > > > + type: object
> > > > > > > > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + properties:
> > > > > > > > > > > > > > + reg:
> > > > > > > > > > > > > > + description: Channel number.
> > > > > > > > > > > > > > + minimum: 0
> > > > > > > > > > > > > > + maximum: 15
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + adi,output-range-microvolt:
> > > > > > > > > > > > > > + description: |
> > > > > > > > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > > > > > > > + oneOf:
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: 0
> > > > > > > > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -5000000
> > > > > > > > > > > > > > + - const: 5000000
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -10000000
> > > > > > > > > > > > > > + - const: 10000000
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -15000000
> > > > > > > > > > > > > > + - const: 15000000
> > > > > > > > > > > > > > + - items:
> > > > > > > > > > > > > > + - const: -20000000
> > > > > > > > > > > > > > + - const: 20000000
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + required:
> > > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + additionalProperties: false
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +required:
> > > > > > > > > > > > > > + - compatible
> > > > > > > > > > > > > > + - reg
> > > > > > > > > > > > > > + - vdd-supply
> > > > > > > > > > > > > > + - avdd-supply
> > > > > > > > > > > > > > + - hvdd-supply
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +dependencies:
> > > > > > > > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +allOf:
> > > > > > > > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +unevaluatedProperties: false
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > +examples:
> > > > > > > > > > > > > > + - |
> > > > > > > > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + spi {
> > > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + dac@0 {
> > > > > > > > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + channel@0 {
> > > > > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + channel@1 {
> > > > > > > > > > > > > > + reg = <1>;
> > > > > > > > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > +
> > > > > > > > > > > > > > + channel@2 {
> > > > > > > > > > > > > > + reg = <2>;
> > > > > > > > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > > + };
> > > > > > > > > > > > > ...
> > > > > > > > > > > > >
> > > > > > > > > > > > > spi {
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > multi-dac@0 {
> > > > > > > > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > spi-max-frequency = <25000000>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > dac@0 {
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@2 {
> > > > > > > > > > > > > reg = <2>;
> > > > > > > > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > > }
> > > > > > > > > > > > >
> > > > > > > > > > > > > dac@1 {
> > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > > > > #size-cells = <0>;
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@0 {
> > > > > > > > > > > > > reg = <0>;
> > > > > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > channel@1 {
> > > > > > > > > > > > > reg = <1>;
> > > > > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > > > };
> > > > > > > > > > > > > }
> > > > > > > > > > > > > };
> > > > > > > > > > > > > };
> > > > > > > > > > > > >
> > > > > > > > > > > > > then you might need something like:
> > > > > > > > > > > > >
> > > > > > > > > > > > > patternProperties:
> > > > > > > > > > > > > "^dac@[0-3]$":
> > > > > > > > > > > > >
> > > > > > > > > > > > > and put most of the things under this node pattern.
> > > > > > > > > > > > >
> > > > > > > > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > > > > > > > Hi Rodrigo,
> > > > > > > > > > > >
> > > > > > > > > > > > Thank you for looking at this.
> > > > > > > > > > > >
> > > > > > > > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > > > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > > > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > > > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > > > > > > > speculatively without a validating use case.
> > > > > > > > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > > > > > > > looking at it another way a kind of distributed SPI mux.
> > > > > > > > > > >
> > > > > > > > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > > > > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > > > > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > > > > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > > > > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > > > > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > > > > > > > in all devices in the chain as one big SPI message.
> > > > > > > > > > >
> > > > > > > > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > > > > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > > > > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > > > > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > > > > > > > longer term how to support it cleanly in SPI.
> > > > > > > > >
> > > > > > > > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > > > > > > > see if I can find what I am thinking of...
> > > > > > > >
> > > > > > > >
> > > > > > > > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > > > > > > > slightly different properties.
> > > > > > > >
> > > > > > > > microchip,device-addr:
> > > > > > > > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > > enum: [0, 1, 2, 3]
> > > > > > > > default: 0
> > > > > > > >
> > > > > > > > and
> > > > > > > >
> > > > > > > >
> > > > > > > > microchip,hw-device-address:
> > > > > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > > > minimum: 0
> > > > > > > > maximum: 3
> > > > > > > > description:
> > > > > > > > The address is set on a per-device basis by fuses in the factory,
> > > > > > > > configured on request. If not requested, the fuses are set for 0x1.
> > > > > > > > The device address is part of the device markings to avoid
> > > > > > > > potential confusion. This address is coded on two bits, so four possible
> > > > > > > > addresses are available when multiple devices are present on the same
> > > > > > > > SPI bus with only one Chip Select line for all devices.
> > > > > > > > Each device communication starts by a CS falling edge, followed by the
> > > > > > > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > > > > > > > which is first one on the wire).
> > > > > > > >
> > > > > > > > This sounds exactly like the sort of feature that you're dealing with
> > > > > > > > here?
> > > > > > > >
> > > > > > >
> > > > > > > The core idea yes but for this chip, things are a bit more annoying (but
> > > > > > > Janani can correct me if I'm wrong). Here, each device can, in theory,
> > > > > > > have it's own supplies, pins and at the very least, channels with maybe
> > > > > > > different scales. That is why Janani is proposing dac nodes. Given I
> > > > > > > honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> > > > > > > about solving this at the spi level.
> > > > > > >
> > > > > > > Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> > > > > > > together in the same bus.
> > > > > >
> > > > > > I'm definitely missing something, because that property for the
> > > > > > microchip devices is not impacted what else is on the bus. AFAICT, you
> > > > > > could have an mcp3911 and an mcp3564 on the same bus even though both
> > > > > > are completely different devices with different drivers. They have
> > > > > > individual device nodes and their own supplies etc etc. These aren't
> > > > > > per-channel properties on an adc or dac, they're per child device on a
> > > > > > spi bus.
> > > > >
> > > > > Maybe I'm the one missing something :). IIRC, spi would not allow two
> > > > > devices on the same CS right? Because for this chip we would need
> > > > > something like:
> > > > >
> > > > > spi {
> > > > > dac@0 {
> > > > > reg = <0>;
> > > > > adi,pin-id = <0>;
> > > > > };
> > > > >
> > > > > dac@1 {
> > > > > reg = <0>; // which seems already problematic?
> > > > > adi,pin-id <1>;
> > > > > };
> > > > >
> > > > > ...
> > > > >
> > > > > //up to 4
> > > > > };
> > > > Yeah. It's not clear to me how that works for the microchip devices
> > > > (I suspect it doesn't!)
> > > >
> > > > Just thinking as I type, but could we do something a bit nasty with
> > > > a gpio mux that doesn't actually switch but represents the GPIO being
> > > > shared? Given this is all tied to the spi bus that should all happen
> > > > under serializing locks.
> > > >
> > > > Agreed though that this would be nicer as an SPI thing that let
> > > > us specify that a single CS is share by multiple devices and their
> > > > is some other signal acting to select which one we are talking to.
> > >
> > > Whether it works or not, I think it is the more correct approach. Messing
> > > with gpio muxes seems completely wrong, given the chip select may not be
> > > a gpio at all.
> > >
> > > Why do you think the microchip devices won't work? Does the spi core
> > > reject multiple devices with the same chip select being registered or
> > > something like that?
> >
> > Not sure how things work atm. But I'm fairly sure it used to be like
> > that. SPI would reject devices on the same controller and CS. Now that
> > we support more than one CS per controller, not sure how things work.
> We always supported more than one per CS per controller. I guess you mean
> per device.
Obviously :)
>
> >
> > Janani, maybe you can give it a try?
>
> I think we'd need to get it to work with shared gpio proxy which maybe
> will just get set up under the hood. This used to be opt in, but seems
> that changed fairly recently so maybe some of us are working with out
> of date knowledge! I haven't played with it yet, so might not be
> that simple.
>
What I meant for Janani was basically testing two devices on the same CS
as in my pseudo DT. For the GPIO, you mean having a way to select
between devices on the same CS?
For these devices the pin id numbers get's setted up as part of the spi message
so my assumption is that all of them will receive the message but only one acks it.
- Nuno Sá
> Jonathan
>
> >
> > - Nuno Sá
> >
>
^ permalink raw reply
* Re: [PATCH 4/5] media: i2c: vd55g1: Add support for vd55g4
From: Jacopo Mondi @ 2026-06-22 10:16 UTC (permalink / raw)
To: Benjamin Mugnier
Cc: Sylvain Petinot, Sakari Ailus, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans Verkuil, linux-media,
linux-kernel, devicetree
In-Reply-To: <20260428-vd55g4_and_fixes-v1-4-4f745a83b87e@foss.st.com>
Hi Benjamin
On Tue, Apr 28, 2026 at 10:40:58AM +0200, Benjamin Mugnier wrote:
> vd55g4 is the same device as vd65g4 but outputs in monochrome instead of
> RGB. Adapt the driver structure according to this new variant, and add
> its support.
>
> Signed-off-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
> ---
> drivers/media/i2c/vd55g1.c | 110 ++++++++++++++++++++++++++++++---------------
> 1 file changed, 74 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/media/i2c/vd55g1.c b/drivers/media/i2c/vd55g1.c
> index 2c962fcb41d2..9f62fc0428a1 100644
> --- a/drivers/media/i2c/vd55g1.c
> +++ b/drivers/media/i2c/vd55g1.c
> @@ -29,11 +29,7 @@
>
> /* Register Map */
> #define VD55G1_REG_MODEL_ID CCI_REG32_LE(0x0000)
> -#define VD55G1_MODEL_ID_VD55G1 0x53354731 /* Mono */
> -#define VD55G1_MODEL_ID_VD65G4 0x53354733 /* RGB */
> -#define VD55G1_REG_REVISION CCI_REG16_LE(0x0004)
> -#define VD55G1_REVISION_CCB 0x2020
> -#define VD55G1_REVISION_BAYER 0x3030
> +#define VD55G1_REG_COLOR_VERSION CCI_REG32_LE(0x0670)
> #define VD55G1_REG_FWPATCH_REVISION CCI_REG16_LE(0x0012)
> #define VD55G1_REG_FWPATCH_START_ADDR CCI_REG8(0x2000)
> #define VD55G1_REG_SYSTEM_FSM CCI_REG8(0x001c)
> @@ -138,8 +134,39 @@
> #define VD55G1_MIPI_RATE_MIN (250 * MEGA)
> #define VD55G1_MIPI_RATE_MAX (1200 * MEGA)
>
> -#define VD55G1_MODEL_ID_NAME(id) \
> - ((id) == VD55G1_MODEL_ID_VD55G1 ? "vd55g1" : "vd65g4")
> +enum vd55g1_model_id {
> + VD55G1_MODEL_ID_2 = 0x53354731,
> + VD55G1_MODEL_ID_3 = 0x53354733,
> +};
> +
> +enum vd55g1_color_version {
> + VD55G1_COLOR_VERSION_MONO = 0x0,
> + VD55G1_COLOR_VERSION_BAYER = 0x1,
nit: you don't need to initialize the enum members here
> +};
> +
> +struct vd55g1_version {
> + char *name;
> + enum vd55g1_model_id id;
> + enum vd55g1_color_version color;
> +};
> +
> +static const struct vd55g1_version vd55g1_versions[] = {
> + {
> + .name = "vd55g1",
> + .id = VD55G1_MODEL_ID_2,
> + .color = VD55G1_COLOR_VERSION_MONO,
> + },
> + {
> + .name = "vd55g4",
> + .id = VD55G1_MODEL_ID_3,
> + .color = VD55G1_COLOR_VERSION_MONO,
> + },
> + {
> + .name = "vd65g4",
> + .id = VD55G1_MODEL_ID_3,
> + .color = VD55G1_COLOR_VERSION_BAYER,
> + },
> +};
>
> static const u8 vd55g1_patch_array[] = {
> 0x44, 0x03, 0x09, 0x02, 0xe6, 0x01, 0x42, 0x00, 0xea, 0x01, 0x42, 0x00,
> @@ -535,7 +562,7 @@ struct vd55g1_vblank_limits {
>
> struct vd55g1 {
> struct device *dev;
> - unsigned int id;
> + const struct vd55g1_version *version;
> struct v4l2_subdev sd;
> struct media_pad pad;
> struct regulator_bulk_data supplies[ARRAY_SIZE(vd55g1_supply_name)];
> @@ -628,7 +655,7 @@ static u32 vd55g1_get_fmt_code(struct vd55g1 *sensor, u32 code)
> {
> unsigned int i, j;
>
> - if (sensor->id == VD55G1_MODEL_ID_VD55G1)
> + if (sensor->version->color != VD55G1_COLOR_VERSION_BAYER)
> return code;
As pointed out in the previous patch, you seem to have 2 mono formats.
Is this still ok ?
>
> for (i = 0; i < ARRAY_SIZE(vd55g1_mbus_formats_bayer); i++) {
> @@ -1183,8 +1210,8 @@ static int vd55g1_patch(struct vd55g1 *sensor)
> u64 patch;
> int ret = 0;
>
> - /* vd55g1 needs a patch while vd65g4 does not */
> - if (sensor->id == VD55G1_MODEL_ID_VD55G1) {
> + /* Version 2 needs a patch while version 3 does not */
> + if (sensor->version->id == VD55G1_MODEL_ID_2) {
> vd55g1_write_array(sensor, VD55G1_REG_FWPATCH_START_ADDR,
> sizeof(vd55g1_patch_array),
> vd55g1_patch_array, &ret);
You might want to consider renaming vd55g1_patch_array ?
> @@ -1256,7 +1283,7 @@ static int vd55g1_enum_mbus_code(struct v4l2_subdev *sd,
> struct vd55g1 *sensor = to_vd55g1(sd);
> u32 base_code;
>
> - if (sensor->id == VD55G1_MODEL_ID_VD55G1) {
> + if (sensor->version->color != VD55G1_COLOR_VERSION_BAYER) {
> if (code->index >= ARRAY_SIZE(vd55g1_mbus_formats_mono))
> return -EINVAL;
> base_code = vd55g1_mbus_formats_mono[code->index];
> @@ -1372,7 +1399,7 @@ static int vd55g1_init_state(struct v4l2_subdev *sd,
> if (ret)
> return ret;
>
> - if (sensor->id == VD55G1_MODEL_ID_VD55G1)
> + if (sensor->version->color != VD55G1_COLOR_VERSION_BAYER)
> code = vd55g1_mbus_formats_mono[VD55G1_MBUS_CODE_IDX_DEF];
> else
> code = vd55g1_mbus_formats_bayer[VD55G1_MBUS_CODE_IDX_DEF][0];
> @@ -1659,38 +1686,48 @@ static int vd55g1_init_ctrls(struct vd55g1 *sensor)
> return ret;
> }
>
> +static const struct vd55g1_version *
> + vd55g1_get_version(enum vd55g1_model_id id,
> + enum vd55g1_color_version color)
Should you indent one tab left ?
> +{
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(vd55g1_versions); i++) {
You can declare i inside the for loop
> + if (vd55g1_versions[i].id == id &&
> + vd55g1_versions[i].color == color)
> + return &vd55g1_versions[i];
> + }
> +
> + return NULL;
> +}
> +
> static int vd55g1_detect(struct vd55g1 *sensor)
> {
> - unsigned int dt_id = (uintptr_t)device_get_match_data(sensor->dev);
> - u64 rev, id;
> - int ret;
> + const struct vd55g1_version *dt_version =
> + device_get_match_data(sensor->dev);
> + const struct vd55g1_version *version;
> + u64 color, id;
> + int ret = 0;
>
> - ret = vd55g1_read(sensor, VD55G1_REG_MODEL_ID, &id, NULL);
> + vd55g1_read(sensor, VD55G1_REG_MODEL_ID, &id, &ret);
> + vd55g1_read(sensor, VD55G1_REG_COLOR_VERSION, &color, &ret);
> if (ret)
> return ret;
>
> - if (id != VD55G1_MODEL_ID_VD55G1 && id != VD55G1_MODEL_ID_VD65G4) {
> - dev_warn(sensor->dev, "Unsupported sensor id 0x%x\n",
> - (u32)id);
> + version = vd55g1_get_version(id, color);
> + if (!version) {
> + dev_warn(sensor->dev, "Unsupported sensor version, expected %s\n",
> + dt_version->name);
> return -ENODEV;
> }
> - if (id != dt_id) {
> - dev_err(sensor->dev, "Probed sensor %s and device tree definition (%s) mismatch",
> - VD55G1_MODEL_ID_NAME(id), VD55G1_MODEL_ID_NAME(dt_id));
> + if (version->id != dt_version->id ||
> + version->color != dt_version->color) {
> + dev_err(sensor->dev, "Probed sensor version %s and device tree definition %s mismatch",
> + version->name, dt_version->name);
> return -ENODEV;
> }
> - sensor->id = id;
>
> - ret = vd55g1_read(sensor, VD55G1_REG_REVISION, &rev, NULL);
> - if (ret)
> - return ret;
> -
> - if ((id == VD55G1_MODEL_ID_VD55G1 && rev != VD55G1_REVISION_CCB) &&
> - (id == VD55G1_MODEL_ID_VD65G4 && rev != VD55G1_REVISION_BAYER)) {
> - dev_err(sensor->dev, "Unsupported sensor revision 0x%x for sensor %s\n",
> - (u16)rev, VD55G1_MODEL_ID_NAME(id));
> - return -ENODEV;
> - }
> + sensor->version = version;
>
> return 0;
> }
> @@ -2048,8 +2085,9 @@ static void vd55g1_remove(struct i2c_client *client)
> }
>
> static const struct of_device_id vd55g1_dt_ids[] = {
> - { .compatible = "st,vd55g1", .data = (void *)VD55G1_MODEL_ID_VD55G1 },
> - { .compatible = "st,vd65g4", .data = (void *)VD55G1_MODEL_ID_VD65G4 },
> + { .compatible = "st,vd55g1", .data = (void *)&vd55g1_versions[0] },
> + { .compatible = "st,vd55g4", .data = (void *)&vd55g1_versions[1] },
> + { .compatible = "st,vd65g4", .data = (void *)&vd55g1_versions[2] },
> { /* sentinel */ }
> };
All minors
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Thanks
j
> MODULE_DEVICE_TABLE(of, vd55g1_dt_ids);
>
> --
> 2.43.0
>
>
^ 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
^ 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
^ 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