From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id BF539C54EBE for ; Tue, 10 Jan 2023 08:05:56 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 648D9DB6C; Tue, 10 Jan 2023 09:05:03 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 648D9DB6C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1673337953; bh=I7nbKR+l0kqrShtf58ShsC2D94pYmdQ7dPyZz/Il4Vo=; h=Date:From:To:Subject:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc:From; b=W4FgI8fZqJsezXY+sXHaNJg8Hzm3Y0DMdPgsHwou68gR7TnQ8wSfGbg+fRGFU/3I/ Sg/8Puz48tzQWvV44cY58SAY58JVarWN+tqdGTaDawEMSkEc6Hfdo3ABsH4uRxJ9LX 1SGFK1eRL4JI+wGBlK6LYqqEAjjMdCxGoVL0zjlE= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 1E6D0F804BD; Tue, 10 Jan 2023 09:05:03 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 5B7D3F804C1; Tue, 10 Jan 2023 09:05:01 +0100 (CET) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id F22B4F8026A for ; Tue, 10 Jan 2023 09:04:53 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz F22B4F8026A Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key, unprotected) header.d=bootlin.com header.i=@bootlin.com header.a=rsa-sha256 header.s=gm1 header.b=ov0pvxlH Received: (Authenticated sender: herve.codina@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id B0355240002; Tue, 10 Jan 2023 08:04:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1673337893; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ld//437bDkASopb9h7+9poDloE57liYuwe18eXbKN8w=; b=ov0pvxlHlJUeYGpbOxfh3TlbG/6hyno/7b2AXf0AjpdSSuzkiap+N5k0H2PaOicUlgstfi PnIyO5WTKv+yhKA0Bc9xlkuKHckPcDQ+Df02Yqae7X8QO3DgiDahUe1TRLKHUCAGzqmaPR 7Q4MxMrdYq1UoDOvZOywXHjr8g/Iw+sZZd4VjUTATlRBX6IQScWT87sydVl3axe3BtXyfK 704goO65ZlkADey+Oe9wu+yQEBuJlJz5iGPO41bFpshj2KrTjwcblrZJMDVYLTrpEHu/6T sh218R49M4FEe4qLow6/+PHeb+00midD9UpiXNTK7VLMHZ2q6Ql01BrNjHsolg== Date: Tue, 10 Jan 2023 09:04:45 +0100 From: Herve Codina To: Krzysztof Kozlowski Subject: Re: [PATCH v2 01/10] dt-bindings: soc: fsl: cpm_qe: Add TSA controller Message-ID: <20230110090445.2dc61b51@bootlin.com> In-Reply-To: <427e0775-c576-e293-f590-b9840b936884@linaro.org> References: <20230106163746.439717-1-herve.codina@bootlin.com> <20230106163746.439717-2-herve.codina@bootlin.com> <427e0775-c576-e293-f590-b9840b936884@linaro.org> Organization: Bootlin X-Mailer: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org, Fabio Estevam , linux-kernel@vger.kernel.org, Thomas Petazzoni , Xiubo Li , Michael Ellerman , Takashi Iwai , Nicholas Piggin , Liam Girdwood , Rob Herring , Li Yang , Nicolin Chen , linuxppc-dev@lists.ozlabs.org, Mark Brown , Christophe Leroy , Krzysztof Kozlowski , Shengjiu Wang , linux-arm-kernel@lists.infradead.org, Qiang Zhao Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" Hi Krzysztof, On Sun, 8 Jan 2023 16:10:38 +0100 Krzysztof Kozlowski wrote: [...] > > + '#size-cells': > > + const: 0 > > + > > +patternProperties: > > + "^tdm@[0-1]$": =20 >=20 > Use consistent quotes - either ' or " Ok, I will change on v3. I will also change them on the other bindings present in the series. >=20 > > + description: > > + The TDM managed by this controller > > + type: object > > + > > + properties: > > + reg: > > + minimum: 0 > > + maximum: 1 > > + description: > > + The TDM number for this TDM, 0 for TDMa and 1 for TDMb > > + > > + fsl,common-rxtx-pins: > > + $ref: /schemas/types.yaml#/definitions/flag > > + description: > > + Use common pins for both transmit and receive =20 >=20 > What are the "common" pins? Without this property device is using > uncommon pins? This does not make sense... Common in the "shared" sense. The hardware can use dedicated pins for Tx clock, Tx sync, Rx clock and Rx sync or use only 2 pins, Tx/Rx clock and Rx/Rx sync. Without the property, we use the 4 pins and with the property, we use 2 pins. >=20 > > + > > + clocks: true > > + clock-names: true =20 >=20 > Both need constraints. The constraints are present later in the file as the number of clocks depends on the 'fsl,common-rxtx-pins' property. I will remove these two lines in the v3 series as they are not needed. 'clocks' and 'clock-names' are handled in the conditional part. >=20 [...] > > + > > + fsl,rx-frame-sync-delay: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + enum: [0, 1, 2, 3] > > + default: 0 > > + description: | > > + Receive frame sync delay. =20 >=20 > Delay in what units? The unit is a number of bits. I will rename to fsl,rx-frame-sync-delay-bits and change the description to 'Receive frame sync delay in number of bits' I will do also the same for fsl,tx-frame-sync-delay property. >=20 > > + Indicates the delay between the Rx sync and the first bit of= the > > + Rx frame. 0 for no bit delay. 1, 2 or 3 for 1, 2 or 3 bits d= elay. > > + > > + fsl,tx-frame-sync-delay: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + enum: [0, 1, 2, 3] > > + default: 0 > > + description: | > > + Transmit frame sync delay. > > + Indicates the delay between the Tx sync and the first bit of= the > > + Tx frame. 0 for no bit delay. 1, 2 or 3 for 1, 2 or 3 bits d= elay. > > + > > + fsl,clock-falling-edge: > > + $ref: /schemas/types.yaml#/definitions/flag > > + description: | > > + Data is sent on falling edge of the clock (and received on t= he > > + rising edge). > > + If 'clock-falling-edge' is not present, data is sent on the > > + rising edge (and received on the falling edge). > > + > > + fsl,fsync-rising-edge: > > + $ref: /schemas/types.yaml#/definitions/flag > > + description: > > + Frame sync pulses are sampled with the rising edge of the ch= annel > > + clock. If 'fsync-rising-edge' is not present, pulses are sam= ple > > + with e falling edge. > > + > > + fsl,double-speed-clock: > > + $ref: /schemas/types.yaml#/definitions/flag > > + description: > > + The channel clock is twice the data rate. > > + > > + fsl,grant-mode: > > + $ref: /schemas/types.yaml#/definitions/flag > > + description: > > + Grant mode enabled. =20 >=20 > This we know from property name. You need to describe what it is and > what it does. Instead of describing it, I will simply remove the property (I should have done already). I cannot test the 'grant mode' enabled with my hardware and so I prefer keeping it disabled. This property, if needed, could be add later setting it optional with default to 'disabled'. >=20 > > + > > + tx_ts_routes: =20 >=20 > No underscores, missing vendor prefix. Indeed, will be change to fsl,tx-ts-routes (idem for rx_ts_routes). >=20 > > + $ref: /schemas/types.yaml#/definitions/uint32-matrix > > + description: | > > + A list of tupple that indicates the Tx time-slots routes. > > + tx_ts_routes =3D > > + < 2 0 0>, /* The first 2 time slots are not used */ > > + < 3 1 0>, /* The next 3 ones are route to SCC2 */ > > + < 4 0 0>, /* The next 4 ones are not used */ > > + < 2 2 0>; /* The nest 2 ones are route to SCC3 */ > > + items: > > + items: > > + - description: > > + The number of time-slots > > + minimum: 1 > > + maximum: 64 > > + - description: | > > + The source serial interface (dt-bindings/soc/fsl-tsa.h > > + defines these values) > > + - 0: No destination > > + - 1: SCC2 > > + - 2: SCC3 > > + - 3: SCC4 > > + - 4: SMC1 > > + - 5: SMC2 > > + enum: [0, 1, 2, 3, 4, 5] > > + - description: > > + The route flags (reserved) =20 >=20 > Why part of binding is reserved? The 'reserved' part will be removed in v3. Same for the rx route table. >=20 > > + const: 0 > > + minItems: 1 > > + maxItems: 64 > > + > > + rx_ts_routes: > > + $ref: /schemas/types.yaml#/definitions/uint32-matrix > > + description: | > > + A list of tupple that indicates the Rx time-slots routes. > > + tx_ts_routes =3D > > + < 2 0 0>, /* The first 2 time slots are not used */ > > + < 3 1 0>, /* The next 3 ones are route from SCC2 */ > > + < 4 0 0>, /* The next 4 ones are not used */ > > + < 2 2 0>; /* The nest 2 ones are route from SCC3 */ > > + items: > > + items: > > + - description: > > + The number of time-slots > > + minimum: 1 > > + maximum: 64 > > + - description: | > > + The destination serial interface (dt-bindings/soc/fsl-= tsa.h > > + defines these values) > > + - 0: No destination > > + - 1: SCC2 > > + - 2: SCC3 > > + - 3: SCC4 > > + - 4: SMC1 > > + - 5: SMC2 > > + enum: [0, 1, 2, 3, 4, 5] > > + - description: > > + The route flags (reserved) > > + const: 0 > > + minItems: 1 > > + maxItems: 64 > > + > > + allOf: > > + - if: > > + properties: > > + fsl,common-rxtx-pins: > > + type: 'null' =20 >=20 > What is this exactly? If check for property present, it's wrong. Should > be test if it is in required. Yes, it was a check for the property presence. If we not use the 'fsl,common-rxtx-pins', we need 4 clocks. If we use the 'fsl,common-rxtx-pins', we need 2 clocks (Rx part and Tx part use the same CLK and SYNC clocks). How can I describe this ? Is the check for the property presence incorrect ? Should I always describe 4 clocks even if only 2 are used ? >=20 > > + then: > > + properties: > > + clocks: > > + items: > > + - description: External clock connected to L1RSYNC pin > > + - description: External clock connected to L1RCLK pin > > + - description: External clock connected to L1TSYNC pin > > + - description: External clock connected to L1TCLK pin > > + clock-names: > > + items: > > + - const: l1rsync > > + - const: l1rclk > > + - const: l1tsync > > + - const: l1tclk > > + else: > > + properties: > > + clocks: > > + items: > > + - description: External clock connected to L1RSYNC pin > > + - description: External clock connected to L1RCLK pin > > + clock-names: > > + items: > > + - const: l1rsync > > + - const: l1rclk > > + > > + required: > > + - reg > > + - clocks > > + - clock-names > > + > > +required: > > + - compatible > > + - reg > > + - reg-names > > + - '#address-cells' > > + - '#size-cells' > > + > > +additionalProperties: false > > + > > +examples: > > + - | > > + #include > > + > > + tsa@ae0 { > > + compatible =3D "fsl,mpc885-tsa", "fsl,cpm1-tsa"; > > + reg =3D <0xae0 0x10>, > > + <0xc00 0x200>; > > + reg-names =3D "si_regs", "si_ram"; > > + > > + #address-cells =3D <1>; > > + #size-cells =3D <0>; > > + > > + tdm@0 { > > + /* TDMa */ > > + reg =3D <0>; > > + > > + clocks =3D <&clk_l1rsynca>, <&clk_l1rclka>; > > + clock-names =3D "l1rsync", "l1rclk"; > > + > > + fsl,common-rxtx-pins; > > + fsl,fsync-rising-edge; > > + > > + tx_ts_routes =3D < 2 0 0>, /* TS 0..1 */ > > + < 24 FSL_CPM_TSA_SCC4 0>, /* TS 2..25 */ > > + < 1 0 0>, /* TS 26 */ > > + < 5 FSL_CPM_TSA_SCC3 0>; /* TS 27..31 */ > > + > > + rx_ts_routes =3D < 2 0 0>, /* TS 0..1 */ > > + < 24 FSL_CPM_TSA_SCC4 0>, /* 2..25 */ > > + < 1 0 0>, /* TS 26 */ > > + < 5 FSL_CPM_TSA_SCC3 0>; /* TS 27..31 */ > > + }; > > + }; > > diff --git a/include/dt-bindings/soc/fsl-tsa.h b/include/dt-bindings/so= c/fsl-tsa.h > > new file mode 100644 > > index 000000000000..9d09468694a2 > > --- /dev/null > > +++ b/include/dt-bindings/soc/fsl-tsa.h =20 >=20 > Filename should match binding filename. Right, I will rename to fsl,tsa.h >=20 > > @@ -0,0 +1,15 @@ > > +/* SPDX-License-Identifier: GPL-2.0-or-later OR MIT */ =20 >=20 > A bit weird license... cannot be the same as binding? Yes, will be change to GPL-2.0-only OR BSD-2-Clause >=20 > > + > > +#ifndef __DT_BINDINGS_SOC_FSL_TSA_H > > +#define __DT_BINDINGS_SOC_FSL_TSA_H > > + > > +#define FSL_CPM_TSA_NU 0 /* Pseuso Cell Id for not used item */ =20 >=20 > Why defining unused IDs in binding header? These are IDs, not some > hardware/register values. It is the binding value for 'No destination' in the tx and rx route table. This binding value means 'not used' or 'discard' the time-slot. The data related to an item in the routing table with this value will be discarded and not used. >=20 > > +#define FSL_CPM_TSA_SCC2 1 > > +#define FSL_CPM_TSA_SCC3 2 > > +#define FSL_CPM_TSA_SCC4 3 > > +#define FSL_CPM_TSA_SMC1 4 > > +#define FSL_CPM_TSA_SMC2 5 > > + > > +#define FSL_CPM_TSA_NBCELL 6 =20 >=20 > Drop. Ok, will be removed in v3. >=20 > > + > > +#endif =20 >=20 > Best regards, > Krzysztof >=20 Thanks for your review. Best regards, Herv=C3=A9 --=20 Herv=C3=A9 Codina, Bootlin Embedded Linux and Kernel engineering https://bootlin.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8BF42C61DB3 for ; Tue, 10 Jan 2023 08:06:30 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Nrk0h5tqBz3cfh for ; Tue, 10 Jan 2023 19:06:28 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=bootlin.com header.i=@bootlin.com header.a=rsa-sha256 header.s=gm1 header.b=ov0pvxlH; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=bootlin.com (client-ip=2001:4b98:dc4:8::221; helo=relay1-d.mail.gandi.net; envelope-from=herve.codina@bootlin.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=bootlin.com header.i=@bootlin.com header.a=rsa-sha256 header.s=gm1 header.b=ov0pvxlH; dkim-atps=neutral Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Nrjz70GVgz3bk8 for ; Tue, 10 Jan 2023 19:05:03 +1100 (AEDT) Received: (Authenticated sender: herve.codina@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id B0355240002; Tue, 10 Jan 2023 08:04:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1673337893; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ld//437bDkASopb9h7+9poDloE57liYuwe18eXbKN8w=; b=ov0pvxlHlJUeYGpbOxfh3TlbG/6hyno/7b2AXf0AjpdSSuzkiap+N5k0H2PaOicUlgstfi PnIyO5WTKv+yhKA0Bc9xlkuKHckPcDQ+Df02Yqae7X8QO3DgiDahUe1TRLKHUCAGzqmaPR 7Q4MxMrdYq1UoDOvZOywXHjr8g/Iw+sZZd4VjUTATlRBX6IQScWT87sydVl3axe3BtXyfK 704goO65ZlkADey+Oe9wu+yQEBuJlJz5iGPO41bFpshj2KrTjwcblrZJMDVYLTrpEHu/6T sh218R49M4FEe4qLow6/+PHeb+00midD9UpiXNTK7VLMHZ2q6Ql01BrNjHsolg== Date: Tue, 10 Jan 2023 09:04:45 +0100 From: Herve Codina To: Krzysztof Kozlowski Subject: Re: [PATCH v2 01/10] dt-bindings: soc: fsl: cpm_qe: Add TSA controller Message-ID: <20230110090445.2dc61b51@bootlin.com> In-Reply-To: <427e0775-c576-e293-f590-b9840b936884@linaro.org> References: <20230106163746.439717-1-herve.codina@bootlin.com> <20230106163746.439717-2-herve.codina@bootlin.com> <427e0775-c576-e293-f590-b9840b936884@linaro.org> Organization: Bootlin X-Mailer: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, alsa-devel@alsa-project.org, Fabio Estevam , linux-kernel@vger.kernel.org, Thomas Petazzoni , Xiubo Li , Takashi Iwai , Nicholas Piggin , Liam Girdwood , Rob Herring , Li Yang , Nicolin Chen , linuxppc-dev@lists.ozlabs.org, Mark Brown , Krzysztof Kozlowski , Jaroslav Kysela , Shengjiu Wang , linux-arm-kernel@lists.infradead.org, Qiang Zhao Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Hi Krzysztof, On Sun, 8 Jan 2023 16:10:38 +0100 Krzysztof Kozlowski wrote: [...] > > + '#size-cells': > > + const: 0 > > + > > +patternProperties: > > + "^tdm@[0-1]$": =20 >=20 > Use consistent quotes - either ' or " Ok, I will change on v3. I will also change them on the other bindings present in the series. >=20 > > + description: > > + The TDM managed by this controller > > + type: object > > + > > + properties: > > + reg: > > + minimum: 0 > > + maximum: 1 > > + description: > > + The TDM number for this TDM, 0 for TDMa and 1 for TDMb > > + > > + fsl,common-rxtx-pins: > > + $ref: /schemas/types.yaml#/definitions/flag > > + description: > > + Use common pins for both transmit and receive =20 >=20 > What are the "common" pins? Without this property device is using > uncommon pins? This does not make sense... Common in the "shared" sense. The hardware can use dedicated pins for Tx clock, Tx sync, Rx clock and Rx sync or use only 2 pins, Tx/Rx clock and Rx/Rx sync. Without the property, we use the 4 pins and with the property, we use 2 pins. >=20 > > + > > + clocks: true > > + clock-names: true =20 >=20 > Both need constraints. The constraints are present later in the file as the number of clocks depends on the 'fsl,common-rxtx-pins' property. I will remove these two lines in the v3 series as they are not needed. 'clocks' and 'clock-names' are handled in the conditional part. >=20 [...] > > + > > + fsl,rx-frame-sync-delay: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + enum: [0, 1, 2, 3] > > + default: 0 > > + description: | > > + Receive frame sync delay. =20 >=20 > Delay in what units? The unit is a number of bits. I will rename to fsl,rx-frame-sync-delay-bits and change the description to 'Receive frame sync delay in number of bits' I will do also the same for fsl,tx-frame-sync-delay property. >=20 > > + Indicates the delay between the Rx sync and the first bit of= the > > + Rx frame. 0 for no bit delay. 1, 2 or 3 for 1, 2 or 3 bits d= elay. > > + > > + fsl,tx-frame-sync-delay: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + enum: [0, 1, 2, 3] > > + default: 0 > > + description: | > > + Transmit frame sync delay. > > + Indicates the delay between the Tx sync and the first bit of= the > > + Tx frame. 0 for no bit delay. 1, 2 or 3 for 1, 2 or 3 bits d= elay. > > + > > + fsl,clock-falling-edge: > > + $ref: /schemas/types.yaml#/definitions/flag > > + description: | > > + Data is sent on falling edge of the clock (and received on t= he > > + rising edge). > > + If 'clock-falling-edge' is not present, data is sent on the > > + rising edge (and received on the falling edge). > > + > > + fsl,fsync-rising-edge: > > + $ref: /schemas/types.yaml#/definitions/flag > > + description: > > + Frame sync pulses are sampled with the rising edge of the ch= annel > > + clock. If 'fsync-rising-edge' is not present, pulses are sam= ple > > + with e falling edge. > > + > > + fsl,double-speed-clock: > > + $ref: /schemas/types.yaml#/definitions/flag > > + description: > > + The channel clock is twice the data rate. > > + > > + fsl,grant-mode: > > + $ref: /schemas/types.yaml#/definitions/flag > > + description: > > + Grant mode enabled. =20 >=20 > This we know from property name. You need to describe what it is and > what it does. Instead of describing it, I will simply remove the property (I should have done already). I cannot test the 'grant mode' enabled with my hardware and so I prefer keeping it disabled. This property, if needed, could be add later setting it optional with default to 'disabled'. >=20 > > + > > + tx_ts_routes: =20 >=20 > No underscores, missing vendor prefix. Indeed, will be change to fsl,tx-ts-routes (idem for rx_ts_routes). >=20 > > + $ref: /schemas/types.yaml#/definitions/uint32-matrix > > + description: | > > + A list of tupple that indicates the Tx time-slots routes. > > + tx_ts_routes =3D > > + < 2 0 0>, /* The first 2 time slots are not used */ > > + < 3 1 0>, /* The next 3 ones are route to SCC2 */ > > + < 4 0 0>, /* The next 4 ones are not used */ > > + < 2 2 0>; /* The nest 2 ones are route to SCC3 */ > > + items: > > + items: > > + - description: > > + The number of time-slots > > + minimum: 1 > > + maximum: 64 > > + - description: | > > + The source serial interface (dt-bindings/soc/fsl-tsa.h > > + defines these values) > > + - 0: No destination > > + - 1: SCC2 > > + - 2: SCC3 > > + - 3: SCC4 > > + - 4: SMC1 > > + - 5: SMC2 > > + enum: [0, 1, 2, 3, 4, 5] > > + - description: > > + The route flags (reserved) =20 >=20 > Why part of binding is reserved? The 'reserved' part will be removed in v3. Same for the rx route table. >=20 > > + const: 0 > > + minItems: 1 > > + maxItems: 64 > > + > > + rx_ts_routes: > > + $ref: /schemas/types.yaml#/definitions/uint32-matrix > > + description: | > > + A list of tupple that indicates the Rx time-slots routes. > > + tx_ts_routes =3D > > + < 2 0 0>, /* The first 2 time slots are not used */ > > + < 3 1 0>, /* The next 3 ones are route from SCC2 */ > > + < 4 0 0>, /* The next 4 ones are not used */ > > + < 2 2 0>; /* The nest 2 ones are route from SCC3 */ > > + items: > > + items: > > + - description: > > + The number of time-slots > > + minimum: 1 > > + maximum: 64 > > + - description: | > > + The destination serial interface (dt-bindings/soc/fsl-= tsa.h > > + defines these values) > > + - 0: No destination > > + - 1: SCC2 > > + - 2: SCC3 > > + - 3: SCC4 > > + - 4: SMC1 > > + - 5: SMC2 > > + enum: [0, 1, 2, 3, 4, 5] > > + - description: > > + The route flags (reserved) > > + const: 0 > > + minItems: 1 > > + maxItems: 64 > > + > > + allOf: > > + - if: > > + properties: > > + fsl,common-rxtx-pins: > > + type: 'null' =20 >=20 > What is this exactly? If check for property present, it's wrong. Should > be test if it is in required. Yes, it was a check for the property presence. If we not use the 'fsl,common-rxtx-pins', we need 4 clocks. If we use the 'fsl,common-rxtx-pins', we need 2 clocks (Rx part and Tx part use the same CLK and SYNC clocks). How can I describe this ? Is the check for the property presence incorrect ? Should I always describe 4 clocks even if only 2 are used ? >=20 > > + then: > > + properties: > > + clocks: > > + items: > > + - description: External clock connected to L1RSYNC pin > > + - description: External clock connected to L1RCLK pin > > + - description: External clock connected to L1TSYNC pin > > + - description: External clock connected to L1TCLK pin > > + clock-names: > > + items: > > + - const: l1rsync > > + - const: l1rclk > > + - const: l1tsync > > + - const: l1tclk > > + else: > > + properties: > > + clocks: > > + items: > > + - description: External clock connected to L1RSYNC pin > > + - description: External clock connected to L1RCLK pin > > + clock-names: > > + items: > > + - const: l1rsync > > + - const: l1rclk > > + > > + required: > > + - reg > > + - clocks > > + - clock-names > > + > > +required: > > + - compatible > > + - reg > > + - reg-names > > + - '#address-cells' > > + - '#size-cells' > > + > > +additionalProperties: false > > + > > +examples: > > + - | > > + #include > > + > > + tsa@ae0 { > > + compatible =3D "fsl,mpc885-tsa", "fsl,cpm1-tsa"; > > + reg =3D <0xae0 0x10>, > > + <0xc00 0x200>; > > + reg-names =3D "si_regs", "si_ram"; > > + > > + #address-cells =3D <1>; > > + #size-cells =3D <0>; > > + > > + tdm@0 { > > + /* TDMa */ > > + reg =3D <0>; > > + > > + clocks =3D <&clk_l1rsynca>, <&clk_l1rclka>; > > + clock-names =3D "l1rsync", "l1rclk"; > > + > > + fsl,common-rxtx-pins; > > + fsl,fsync-rising-edge; > > + > > + tx_ts_routes =3D < 2 0 0>, /* TS 0..1 */ > > + < 24 FSL_CPM_TSA_SCC4 0>, /* TS 2..25 */ > > + < 1 0 0>, /* TS 26 */ > > + < 5 FSL_CPM_TSA_SCC3 0>; /* TS 27..31 */ > > + > > + rx_ts_routes =3D < 2 0 0>, /* TS 0..1 */ > > + < 24 FSL_CPM_TSA_SCC4 0>, /* 2..25 */ > > + < 1 0 0>, /* TS 26 */ > > + < 5 FSL_CPM_TSA_SCC3 0>; /* TS 27..31 */ > > + }; > > + }; > > diff --git a/include/dt-bindings/soc/fsl-tsa.h b/include/dt-bindings/so= c/fsl-tsa.h > > new file mode 100644 > > index 000000000000..9d09468694a2 > > --- /dev/null > > +++ b/include/dt-bindings/soc/fsl-tsa.h =20 >=20 > Filename should match binding filename. Right, I will rename to fsl,tsa.h >=20 > > @@ -0,0 +1,15 @@ > > +/* SPDX-License-Identifier: GPL-2.0-or-later OR MIT */ =20 >=20 > A bit weird license... cannot be the same as binding? Yes, will be change to GPL-2.0-only OR BSD-2-Clause >=20 > > + > > +#ifndef __DT_BINDINGS_SOC_FSL_TSA_H > > +#define __DT_BINDINGS_SOC_FSL_TSA_H > > + > > +#define FSL_CPM_TSA_NU 0 /* Pseuso Cell Id for not used item */ =20 >=20 > Why defining unused IDs in binding header? These are IDs, not some > hardware/register values. It is the binding value for 'No destination' in the tx and rx route table. This binding value means 'not used' or 'discard' the time-slot. The data related to an item in the routing table with this value will be discarded and not used. >=20 > > +#define FSL_CPM_TSA_SCC2 1 > > +#define FSL_CPM_TSA_SCC3 2 > > +#define FSL_CPM_TSA_SCC4 3 > > +#define FSL_CPM_TSA_SMC1 4 > > +#define FSL_CPM_TSA_SMC2 5 > > + > > +#define FSL_CPM_TSA_NBCELL 6 =20 >=20 > Drop. Ok, will be removed in v3. >=20 > > + > > +#endif =20 >=20 > Best regards, > Krzysztof >=20 Thanks for your review. Best regards, Herv=C3=A9 --=20 Herv=C3=A9 Codina, Bootlin Embedded Linux and Kernel engineering https://bootlin.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1244AC54EBE for ; Tue, 10 Jan 2023 08:06:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Uiw4QETBIUjZ23ZIrj4Ke8X+gIgxdz/gCH3sQNFFnFA=; b=TqXGkSOhBs7IQr PC+PzuZoy/WsHrR0S1Qi6T/fpXxCjXl1ce4ui3TI0YFjLnVBaGSQxDTRz6kwajzhgEGxEwtrjM0U9 l3MqtnqfCsa68WwKT56ErSNQMcJRG58d51xZyT7Bwd+qmZjSt00i2fKbh1nUl1+uE0OX39+XkEtwH Ype6KZCDhl92l8k9Ti6x4xk44+zvZG2lTm3iSfD+dB2NjBEVSU2kkc6aOzexSouxYSGxpIj3y+iKx OBoQ7w0Hk+NzTzydNH2/kTE4QSiv+lSfLobDg0w/S/Vtj+PoR3jkpc9tHyUrbckRBu/cGyC0G0btH VkfqYnUFjg/Q992TlrgA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pF9d1-005hBl-0W; Tue, 10 Jan 2023 08:05:03 +0000 Received: from relay1-d.mail.gandi.net ([217.70.183.193]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pF9cw-005h8S-Sq for linux-arm-kernel@lists.infradead.org; Tue, 10 Jan 2023 08:05:01 +0000 Received: (Authenticated sender: herve.codina@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id B0355240002; Tue, 10 Jan 2023 08:04:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1673337893; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ld//437bDkASopb9h7+9poDloE57liYuwe18eXbKN8w=; b=ov0pvxlHlJUeYGpbOxfh3TlbG/6hyno/7b2AXf0AjpdSSuzkiap+N5k0H2PaOicUlgstfi PnIyO5WTKv+yhKA0Bc9xlkuKHckPcDQ+Df02Yqae7X8QO3DgiDahUe1TRLKHUCAGzqmaPR 7Q4MxMrdYq1UoDOvZOywXHjr8g/Iw+sZZd4VjUTATlRBX6IQScWT87sydVl3axe3BtXyfK 704goO65ZlkADey+Oe9wu+yQEBuJlJz5iGPO41bFpshj2KrTjwcblrZJMDVYLTrpEHu/6T sh218R49M4FEe4qLow6/+PHeb+00midD9UpiXNTK7VLMHZ2q6Ql01BrNjHsolg== Date: Tue, 10 Jan 2023 09:04:45 +0100 From: Herve Codina To: Krzysztof Kozlowski Cc: Li Yang , Rob Herring , Krzysztof Kozlowski , Liam Girdwood , Mark Brown , Christophe Leroy , Michael Ellerman , Nicholas Piggin , Qiang Zhao , Jaroslav Kysela , Takashi Iwai , Shengjiu Wang , Xiubo Li , Fabio Estevam , Nicolin Chen , linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org, Thomas Petazzoni Subject: Re: [PATCH v2 01/10] dt-bindings: soc: fsl: cpm_qe: Add TSA controller Message-ID: <20230110090445.2dc61b51@bootlin.com> In-Reply-To: <427e0775-c576-e293-f590-b9840b936884@linaro.org> References: <20230106163746.439717-1-herve.codina@bootlin.com> <20230106163746.439717-2-herve.codina@bootlin.com> <427e0775-c576-e293-f590-b9840b936884@linaro.org> Organization: Bootlin X-Mailer: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230110_000459_248393_593A3A12 X-CRM114-Status: GOOD ( 38.82 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org SGkgS3J6eXN6dG9mLAoKT24gU3VuLCA4IEphbiAyMDIzIDE2OjEwOjM4ICswMTAwCktyenlzenRv ZiBLb3psb3dza2kgPGtyenlzenRvZi5rb3psb3dza2lAbGluYXJvLm9yZz4gd3JvdGU6CgpbLi4u XQoKPiA+ICsgICcjc2l6ZS1jZWxscyc6Cj4gPiArICAgIGNvbnN0OiAwCj4gPiArCj4gPiArcGF0 dGVyblByb3BlcnRpZXM6Cj4gPiArICAiXnRkbUBbMC0xXSQiOiAgCj4gCj4gVXNlIGNvbnNpc3Rl bnQgcXVvdGVzIC0gZWl0aGVyICcgb3IgIgoKT2ssIEkgd2lsbCBjaGFuZ2Ugb24gdjMuCkkgd2ls bCBhbHNvIGNoYW5nZSB0aGVtIG9uIHRoZSBvdGhlciBiaW5kaW5ncyBwcmVzZW50IGluIHRoZQpz ZXJpZXMuCgo+IAo+ID4gKyAgICBkZXNjcmlwdGlvbjoKPiA+ICsgICAgICBUaGUgVERNIG1hbmFn ZWQgYnkgdGhpcyBjb250cm9sbGVyCj4gPiArICAgIHR5cGU6IG9iamVjdAo+ID4gKwo+ID4gKyAg ICBwcm9wZXJ0aWVzOgo+ID4gKyAgICAgIHJlZzoKPiA+ICsgICAgICAgIG1pbmltdW06IDAKPiA+ ICsgICAgICAgIG1heGltdW06IDEKPiA+ICsgICAgICAgIGRlc2NyaXB0aW9uOgo+ID4gKyAgICAg ICAgICBUaGUgVERNIG51bWJlciBmb3IgdGhpcyBURE0sIDAgZm9yIFRETWEgYW5kIDEgZm9yIFRE TWIKPiA+ICsKPiA+ICsgICAgICBmc2wsY29tbW9uLXJ4dHgtcGluczoKPiA+ICsgICAgICAgICRy ZWY6IC9zY2hlbWFzL3R5cGVzLnlhbWwjL2RlZmluaXRpb25zL2ZsYWcKPiA+ICsgICAgICAgIGRl c2NyaXB0aW9uOgo+ID4gKyAgICAgICAgICBVc2UgY29tbW9uIHBpbnMgZm9yIGJvdGggdHJhbnNt aXQgYW5kIHJlY2VpdmUgIAo+IAo+IFdoYXQgYXJlIHRoZSAiY29tbW9uIiBwaW5zPyBXaXRob3V0 IHRoaXMgcHJvcGVydHkgZGV2aWNlIGlzIHVzaW5nCj4gdW5jb21tb24gcGlucz8gVGhpcyBkb2Vz IG5vdCBtYWtlIHNlbnNlLi4uCgpDb21tb24gaW4gdGhlICJzaGFyZWQiIHNlbnNlLgpUaGUgaGFy ZHdhcmUgY2FuIHVzZSBkZWRpY2F0ZWQgcGlucyBmb3IgVHggY2xvY2ssIFR4IHN5bmMsClJ4IGNs b2NrIGFuZCBSeCBzeW5jIG9yIHVzZSBvbmx5IDIgcGlucywgVHgvUnggY2xvY2sgYW5kClJ4L1J4 IHN5bmMuCgpXaXRob3V0IHRoZSBwcm9wZXJ0eSwgd2UgdXNlIHRoZSA0IHBpbnMgYW5kIHdpdGgg dGhlIHByb3BlcnR5LAp3ZSB1c2UgMiBwaW5zLgoKPiAKPiA+ICsKPiA+ICsgICAgICBjbG9ja3M6 IHRydWUKPiA+ICsgICAgICBjbG9jay1uYW1lczogdHJ1ZSAgCj4gCj4gQm90aCBuZWVkIGNvbnN0 cmFpbnRzLgoKVGhlIGNvbnN0cmFpbnRzIGFyZSBwcmVzZW50IGxhdGVyIGluIHRoZSBmaWxlIGFz IHRoZSBudW1iZXIKb2YgY2xvY2tzIGRlcGVuZHMgb24gdGhlICdmc2wsY29tbW9uLXJ4dHgtcGlu cycgcHJvcGVydHkuCgpJIHdpbGwgcmVtb3ZlIHRoZXNlIHR3byBsaW5lcyBpbiB0aGUgdjMgc2Vy aWVzIGFzIHRoZXkgYXJlCm5vdCBuZWVkZWQuICdjbG9ja3MnIGFuZCAnY2xvY2stbmFtZXMnIGFy ZSBoYW5kbGVkIGluIHRoZQpjb25kaXRpb25hbCBwYXJ0LgoKPiAKWy4uLl0KPiA+ICsKPiA+ICsg ICAgICBmc2wscngtZnJhbWUtc3luYy1kZWxheToKPiA+ICsgICAgICAgICRyZWY6IC9zY2hlbWFz L3R5cGVzLnlhbWwjL2RlZmluaXRpb25zL3VpbnQzMgo+ID4gKyAgICAgICAgZW51bTogWzAsIDEs IDIsIDNdCj4gPiArICAgICAgICBkZWZhdWx0OiAwCj4gPiArICAgICAgICBkZXNjcmlwdGlvbjog fAo+ID4gKyAgICAgICAgICBSZWNlaXZlIGZyYW1lIHN5bmMgZGVsYXkuICAKPiAKPiBEZWxheSBp biB3aGF0IHVuaXRzPwoKVGhlIHVuaXQgaXMgYSBudW1iZXIgb2YgYml0cy4KSSB3aWxsIHJlbmFt ZSB0byBmc2wscngtZnJhbWUtc3luYy1kZWxheS1iaXRzIGFuZCBjaGFuZ2UgdGhlIGRlc2NyaXB0 aW9uCnRvICdSZWNlaXZlIGZyYW1lIHN5bmMgZGVsYXkgaW4gbnVtYmVyIG9mIGJpdHMnCgpJIHdp bGwgZG8gYWxzbyB0aGUgc2FtZSBmb3IgZnNsLHR4LWZyYW1lLXN5bmMtZGVsYXkgcHJvcGVydHku Cgo+IAo+ID4gKyAgICAgICAgICBJbmRpY2F0ZXMgdGhlIGRlbGF5IGJldHdlZW4gdGhlIFJ4IHN5 bmMgYW5kIHRoZSBmaXJzdCBiaXQgb2YgdGhlCj4gPiArICAgICAgICAgIFJ4IGZyYW1lLiAwIGZv ciBubyBiaXQgZGVsYXkuIDEsIDIgb3IgMyBmb3IgMSwgMiBvciAzIGJpdHMgZGVsYXkuCj4gPiAr Cj4gPiArICAgICAgZnNsLHR4LWZyYW1lLXN5bmMtZGVsYXk6Cj4gPiArICAgICAgICAkcmVmOiAv c2NoZW1hcy90eXBlcy55YW1sIy9kZWZpbml0aW9ucy91aW50MzIKPiA+ICsgICAgICAgIGVudW06 IFswLCAxLCAyLCAzXQo+ID4gKyAgICAgICAgZGVmYXVsdDogMAo+ID4gKyAgICAgICAgZGVzY3Jp cHRpb246IHwKPiA+ICsgICAgICAgICAgVHJhbnNtaXQgZnJhbWUgc3luYyBkZWxheS4KPiA+ICsg ICAgICAgICAgSW5kaWNhdGVzIHRoZSBkZWxheSBiZXR3ZWVuIHRoZSBUeCBzeW5jIGFuZCB0aGUg Zmlyc3QgYml0IG9mIHRoZQo+ID4gKyAgICAgICAgICBUeCBmcmFtZS4gMCBmb3Igbm8gYml0IGRl bGF5LiAxLCAyIG9yIDMgZm9yIDEsIDIgb3IgMyBiaXRzIGRlbGF5Lgo+ID4gKwo+ID4gKyAgICAg IGZzbCxjbG9jay1mYWxsaW5nLWVkZ2U6Cj4gPiArICAgICAgICAkcmVmOiAvc2NoZW1hcy90eXBl cy55YW1sIy9kZWZpbml0aW9ucy9mbGFnCj4gPiArICAgICAgICBkZXNjcmlwdGlvbjogfAo+ID4g KyAgICAgICAgICBEYXRhIGlzIHNlbnQgb24gZmFsbGluZyBlZGdlIG9mIHRoZSBjbG9jayAoYW5k IHJlY2VpdmVkIG9uIHRoZQo+ID4gKyAgICAgICAgICByaXNpbmcgZWRnZSkuCj4gPiArICAgICAg ICAgIElmICdjbG9jay1mYWxsaW5nLWVkZ2UnIGlzIG5vdCBwcmVzZW50LCBkYXRhIGlzIHNlbnQg b24gdGhlCj4gPiArICAgICAgICAgIHJpc2luZyBlZGdlIChhbmQgcmVjZWl2ZWQgb24gdGhlIGZh bGxpbmcgZWRnZSkuCj4gPiArCj4gPiArICAgICAgZnNsLGZzeW5jLXJpc2luZy1lZGdlOgo+ID4g KyAgICAgICAgJHJlZjogL3NjaGVtYXMvdHlwZXMueWFtbCMvZGVmaW5pdGlvbnMvZmxhZwo+ID4g KyAgICAgICAgZGVzY3JpcHRpb246Cj4gPiArICAgICAgICAgIEZyYW1lIHN5bmMgcHVsc2VzIGFy ZSBzYW1wbGVkIHdpdGggdGhlIHJpc2luZyBlZGdlIG9mIHRoZSBjaGFubmVsCj4gPiArICAgICAg ICAgIGNsb2NrLiBJZiAnZnN5bmMtcmlzaW5nLWVkZ2UnIGlzIG5vdCBwcmVzZW50LCBwdWxzZXMg YXJlIHNhbXBsZQo+ID4gKyAgICAgICAgICB3aXRoIGUgZmFsbGluZyBlZGdlLgo+ID4gKwo+ID4g KyAgICAgIGZzbCxkb3VibGUtc3BlZWQtY2xvY2s6Cj4gPiArICAgICAgICAkcmVmOiAvc2NoZW1h cy90eXBlcy55YW1sIy9kZWZpbml0aW9ucy9mbGFnCj4gPiArICAgICAgICBkZXNjcmlwdGlvbjoK PiA+ICsgICAgICAgICAgVGhlIGNoYW5uZWwgY2xvY2sgaXMgdHdpY2UgdGhlIGRhdGEgcmF0ZS4K PiA+ICsKPiA+ICsgICAgICBmc2wsZ3JhbnQtbW9kZToKPiA+ICsgICAgICAgICRyZWY6IC9zY2hl bWFzL3R5cGVzLnlhbWwjL2RlZmluaXRpb25zL2ZsYWcKPiA+ICsgICAgICAgIGRlc2NyaXB0aW9u Ogo+ID4gKyAgICAgICAgICBHcmFudCBtb2RlIGVuYWJsZWQuICAKPiAKPiBUaGlzIHdlIGtub3cg ZnJvbSBwcm9wZXJ0eSBuYW1lLiBZb3UgbmVlZCB0byBkZXNjcmliZSB3aGF0IGl0IGlzIGFuZAo+ IHdoYXQgaXQgZG9lcy4KCkluc3RlYWQgb2YgZGVzY3JpYmluZyBpdCwgSSB3aWxsIHNpbXBseSBy ZW1vdmUgdGhlIHByb3BlcnR5IChJIHNob3VsZApoYXZlIGRvbmUgYWxyZWFkeSkuCkkgY2Fubm90 IHRlc3QgdGhlICdncmFudCBtb2RlJyBlbmFibGVkIHdpdGggbXkgaGFyZHdhcmUgYW5kIHNvCkkg cHJlZmVyIGtlZXBpbmcgaXQgZGlzYWJsZWQuClRoaXMgcHJvcGVydHksIGlmIG5lZWRlZCwgY291 bGQgYmUgYWRkIGxhdGVyIHNldHRpbmcgaXQgb3B0aW9uYWwKd2l0aCBkZWZhdWx0IHRvICdkaXNh YmxlZCcuCgo+IAo+ID4gKwo+ID4gKyAgICAgIHR4X3RzX3JvdXRlczogIAo+IAo+IE5vIHVuZGVy c2NvcmVzLCBtaXNzaW5nIHZlbmRvciBwcmVmaXguCgpJbmRlZWQsIHdpbGwgYmUgY2hhbmdlIHRv IGZzbCx0eC10cy1yb3V0ZXMgKGlkZW0gZm9yIHJ4X3RzX3JvdXRlcykuCgo+IAo+ID4gKyAgICAg ICAgJHJlZjogL3NjaGVtYXMvdHlwZXMueWFtbCMvZGVmaW5pdGlvbnMvdWludDMyLW1hdHJpeAo+ ID4gKyAgICAgICAgZGVzY3JpcHRpb246IHwKPiA+ICsgICAgICAgICAgQSBsaXN0IG9mIHR1cHBs ZSB0aGF0IGluZGljYXRlcyB0aGUgVHggdGltZS1zbG90cyByb3V0ZXMuCj4gPiArICAgICAgICAg ICAgdHhfdHNfcm91dGVzID0KPiA+ICsgICAgICAgICAgICAgICA8IDIgMCAwPiwgLyogVGhlIGZp cnN0IDIgdGltZSBzbG90cyBhcmUgbm90IHVzZWQgKi8KPiA+ICsgICAgICAgICAgICAgICA8IDMg MSAwPiwgLyogVGhlIG5leHQgMyBvbmVzIGFyZSByb3V0ZSB0byBTQ0MyICovCj4gPiArICAgICAg ICAgICAgICAgPCA0IDAgMD4sIC8qIFRoZSBuZXh0IDQgb25lcyBhcmUgbm90IHVzZWQgKi8KPiA+ ICsgICAgICAgICAgICAgICA8IDIgMiAwPjsgLyogVGhlIG5lc3QgMiBvbmVzIGFyZSByb3V0ZSB0 byBTQ0MzICovCj4gPiArICAgICAgICBpdGVtczoKPiA+ICsgICAgICAgICAgaXRlbXM6Cj4gPiAr ICAgICAgICAgICAgLSBkZXNjcmlwdGlvbjoKPiA+ICsgICAgICAgICAgICAgICAgVGhlIG51bWJl ciBvZiB0aW1lLXNsb3RzCj4gPiArICAgICAgICAgICAgICBtaW5pbXVtOiAxCj4gPiArICAgICAg ICAgICAgICBtYXhpbXVtOiA2NAo+ID4gKyAgICAgICAgICAgIC0gZGVzY3JpcHRpb246IHwKPiA+ ICsgICAgICAgICAgICAgICAgVGhlIHNvdXJjZSBzZXJpYWwgaW50ZXJmYWNlIChkdC1iaW5kaW5n cy9zb2MvZnNsLXRzYS5oCj4gPiArICAgICAgICAgICAgICAgIGRlZmluZXMgdGhlc2UgdmFsdWVz KQo+ID4gKyAgICAgICAgICAgICAgICAgLSAwOiBObyBkZXN0aW5hdGlvbgo+ID4gKyAgICAgICAg ICAgICAgICAgLSAxOiBTQ0MyCj4gPiArICAgICAgICAgICAgICAgICAtIDI6IFNDQzMKPiA+ICsg ICAgICAgICAgICAgICAgIC0gMzogU0NDNAo+ID4gKyAgICAgICAgICAgICAgICAgLSA0OiBTTUMx Cj4gPiArICAgICAgICAgICAgICAgICAtIDU6IFNNQzIKPiA+ICsgICAgICAgICAgICAgIGVudW06 IFswLCAxLCAyLCAzLCA0LCA1XQo+ID4gKyAgICAgICAgICAgIC0gZGVzY3JpcHRpb246Cj4gPiAr ICAgICAgICAgICAgICAgIFRoZSByb3V0ZSBmbGFncyAocmVzZXJ2ZWQpICAKPiAKPiBXaHkgcGFy dCBvZiBiaW5kaW5nIGlzIHJlc2VydmVkPwoKVGhlICdyZXNlcnZlZCcgcGFydCB3aWxsIGJlIHJl bW92ZWQgaW4gdjMuClNhbWUgZm9yIHRoZSByeCByb3V0ZSB0YWJsZS4KCj4gCj4gPiArICAgICAg ICAgICAgICBjb25zdDogMAo+ID4gKyAgICAgICAgbWluSXRlbXM6IDEKPiA+ICsgICAgICAgIG1h eEl0ZW1zOiA2NAo+ID4gKwo+ID4gKyAgICAgIHJ4X3RzX3JvdXRlczoKPiA+ICsgICAgICAgICRy ZWY6IC9zY2hlbWFzL3R5cGVzLnlhbWwjL2RlZmluaXRpb25zL3VpbnQzMi1tYXRyaXgKPiA+ICsg ICAgICAgIGRlc2NyaXB0aW9uOiB8Cj4gPiArICAgICAgICAgIEEgbGlzdCBvZiB0dXBwbGUgdGhh dCBpbmRpY2F0ZXMgdGhlIFJ4IHRpbWUtc2xvdHMgcm91dGVzLgo+ID4gKyAgICAgICAgICAgIHR4 X3RzX3JvdXRlcyA9Cj4gPiArICAgICAgICAgICAgICAgPCAyIDAgMD4sIC8qIFRoZSBmaXJzdCAy IHRpbWUgc2xvdHMgYXJlIG5vdCB1c2VkICovCj4gPiArICAgICAgICAgICAgICAgPCAzIDEgMD4s IC8qIFRoZSBuZXh0IDMgb25lcyBhcmUgcm91dGUgZnJvbSBTQ0MyICovCj4gPiArICAgICAgICAg ICAgICAgPCA0IDAgMD4sIC8qIFRoZSBuZXh0IDQgb25lcyBhcmUgbm90IHVzZWQgKi8KPiA+ICsg ICAgICAgICAgICAgICA8IDIgMiAwPjsgLyogVGhlIG5lc3QgMiBvbmVzIGFyZSByb3V0ZSBmcm9t IFNDQzMgKi8KPiA+ICsgICAgICAgIGl0ZW1zOgo+ID4gKyAgICAgICAgICBpdGVtczoKPiA+ICsg ICAgICAgICAgICAtIGRlc2NyaXB0aW9uOgo+ID4gKyAgICAgICAgICAgICAgICBUaGUgbnVtYmVy IG9mIHRpbWUtc2xvdHMKPiA+ICsgICAgICAgICAgICAgIG1pbmltdW06IDEKPiA+ICsgICAgICAg ICAgICAgIG1heGltdW06IDY0Cj4gPiArICAgICAgICAgICAgLSBkZXNjcmlwdGlvbjogfAo+ID4g KyAgICAgICAgICAgICAgICBUaGUgZGVzdGluYXRpb24gc2VyaWFsIGludGVyZmFjZSAoZHQtYmlu ZGluZ3Mvc29jL2ZzbC10c2EuaAo+ID4gKyAgICAgICAgICAgICAgICBkZWZpbmVzIHRoZXNlIHZh bHVlcykKPiA+ICsgICAgICAgICAgICAgICAgIC0gMDogTm8gZGVzdGluYXRpb24KPiA+ICsgICAg ICAgICAgICAgICAgIC0gMTogU0NDMgo+ID4gKyAgICAgICAgICAgICAgICAgLSAyOiBTQ0MzCj4g PiArICAgICAgICAgICAgICAgICAtIDM6IFNDQzQKPiA+ICsgICAgICAgICAgICAgICAgIC0gNDog U01DMQo+ID4gKyAgICAgICAgICAgICAgICAgLSA1OiBTTUMyCj4gPiArICAgICAgICAgICAgICBl bnVtOiBbMCwgMSwgMiwgMywgNCwgNV0KPiA+ICsgICAgICAgICAgICAtIGRlc2NyaXB0aW9uOgo+ ID4gKyAgICAgICAgICAgICAgICBUaGUgcm91dGUgZmxhZ3MgKHJlc2VydmVkKQo+ID4gKyAgICAg ICAgICAgICAgY29uc3Q6IDAKPiA+ICsgICAgICAgIG1pbkl0ZW1zOiAxCj4gPiArICAgICAgICBt YXhJdGVtczogNjQKPiA+ICsKPiA+ICsgICAgYWxsT2Y6Cj4gPiArICAgICAgLSBpZjoKPiA+ICsg ICAgICAgICAgcHJvcGVydGllczoKPiA+ICsgICAgICAgICAgICBmc2wsY29tbW9uLXJ4dHgtcGlu czoKPiA+ICsgICAgICAgICAgICAgIHR5cGU6ICdudWxsJyAgCj4gCj4gV2hhdCBpcyB0aGlzIGV4 YWN0bHk/IElmIGNoZWNrIGZvciBwcm9wZXJ0eSBwcmVzZW50LCBpdCdzIHdyb25nLiBTaG91bGQK PiBiZSB0ZXN0IGlmIGl0IGlzIGluIHJlcXVpcmVkLgoKWWVzLCBpdCB3YXMgYSBjaGVjayBmb3Ig dGhlIHByb3BlcnR5IHByZXNlbmNlLgoKSWYgd2Ugbm90IHVzZSB0aGUgJ2ZzbCxjb21tb24tcnh0 eC1waW5zJywgd2UgbmVlZCA0IGNsb2Nrcy4KSWYgd2UgdXNlIHRoZSAnZnNsLGNvbW1vbi1yeHR4 LXBpbnMnLCB3ZSBuZWVkIDIgY2xvY2tzIChSeCBwYXJ0IGFuZCBUeApwYXJ0IHVzZSB0aGUgc2Ft ZSBDTEsgYW5kIFNZTkMgY2xvY2tzKS4KCkhvdyBjYW4gSSBkZXNjcmliZSB0aGlzID8KSXMgdGhl IGNoZWNrIGZvciB0aGUgcHJvcGVydHkgcHJlc2VuY2UgaW5jb3JyZWN0ID8KClNob3VsZCBJIGFs d2F5cyBkZXNjcmliZSA0IGNsb2NrcyBldmVuIGlmIG9ubHkgMiBhcmUgdXNlZCA/Cgo+IAo+ID4g KyAgICAgICAgdGhlbjoKPiA+ICsgICAgICAgICAgcHJvcGVydGllczoKPiA+ICsgICAgICAgICAg ICBjbG9ja3M6Cj4gPiArICAgICAgICAgICAgICBpdGVtczoKPiA+ICsgICAgICAgICAgICAgICAg LSBkZXNjcmlwdGlvbjogRXh0ZXJuYWwgY2xvY2sgY29ubmVjdGVkIHRvIEwxUlNZTkMgcGluCj4g PiArICAgICAgICAgICAgICAgIC0gZGVzY3JpcHRpb246IEV4dGVybmFsIGNsb2NrIGNvbm5lY3Rl ZCB0byBMMVJDTEsgcGluCj4gPiArICAgICAgICAgICAgICAgIC0gZGVzY3JpcHRpb246IEV4dGVy bmFsIGNsb2NrIGNvbm5lY3RlZCB0byBMMVRTWU5DIHBpbgo+ID4gKyAgICAgICAgICAgICAgICAt IGRlc2NyaXB0aW9uOiBFeHRlcm5hbCBjbG9jayBjb25uZWN0ZWQgdG8gTDFUQ0xLIHBpbgo+ID4g KyAgICAgICAgICAgIGNsb2NrLW5hbWVzOgo+ID4gKyAgICAgICAgICAgICAgaXRlbXM6Cj4gPiAr ICAgICAgICAgICAgICAgIC0gY29uc3Q6IGwxcnN5bmMKPiA+ICsgICAgICAgICAgICAgICAgLSBj b25zdDogbDFyY2xrCj4gPiArICAgICAgICAgICAgICAgIC0gY29uc3Q6IGwxdHN5bmMKPiA+ICsg ICAgICAgICAgICAgICAgLSBjb25zdDogbDF0Y2xrCj4gPiArICAgICAgICBlbHNlOgo+ID4gKyAg ICAgICAgICBwcm9wZXJ0aWVzOgo+ID4gKyAgICAgICAgICAgIGNsb2NrczoKPiA+ICsgICAgICAg ICAgICAgIGl0ZW1zOgo+ID4gKyAgICAgICAgICAgICAgICAtIGRlc2NyaXB0aW9uOiBFeHRlcm5h bCBjbG9jayBjb25uZWN0ZWQgdG8gTDFSU1lOQyBwaW4KPiA+ICsgICAgICAgICAgICAgICAgLSBk ZXNjcmlwdGlvbjogRXh0ZXJuYWwgY2xvY2sgY29ubmVjdGVkIHRvIEwxUkNMSyBwaW4KPiA+ICsg ICAgICAgICAgICBjbG9jay1uYW1lczoKPiA+ICsgICAgICAgICAgICAgIGl0ZW1zOgo+ID4gKyAg ICAgICAgICAgICAgICAtIGNvbnN0OiBsMXJzeW5jCj4gPiArICAgICAgICAgICAgICAgIC0gY29u c3Q6IGwxcmNsawo+ID4gKwo+ID4gKyAgICByZXF1aXJlZDoKPiA+ICsgICAgICAtIHJlZwo+ID4g KyAgICAgIC0gY2xvY2tzCj4gPiArICAgICAgLSBjbG9jay1uYW1lcwo+ID4gKwo+ID4gK3JlcXVp cmVkOgo+ID4gKyAgLSBjb21wYXRpYmxlCj4gPiArICAtIHJlZwo+ID4gKyAgLSByZWctbmFtZXMK PiA+ICsgIC0gJyNhZGRyZXNzLWNlbGxzJwo+ID4gKyAgLSAnI3NpemUtY2VsbHMnCj4gPiArCj4g PiArYWRkaXRpb25hbFByb3BlcnRpZXM6IGZhbHNlCj4gPiArCj4gPiArZXhhbXBsZXM6Cj4gPiAr ICAtIHwKPiA+ICsgICAgI2luY2x1ZGUgPGR0LWJpbmRpbmdzL3NvYy9mc2wtdHNhLmg+Cj4gPiAr Cj4gPiArICAgIHRzYUBhZTAgewo+ID4gKyAgICAgICAgY29tcGF0aWJsZSA9ICJmc2wsbXBjODg1 LXRzYSIsICJmc2wsY3BtMS10c2EiOwo+ID4gKyAgICAgICAgcmVnID0gPDB4YWUwIDB4MTA+LAo+ ID4gKyAgICAgICAgICAgICAgPDB4YzAwIDB4MjAwPjsKPiA+ICsgICAgICAgIHJlZy1uYW1lcyA9 ICJzaV9yZWdzIiwgInNpX3JhbSI7Cj4gPiArCj4gPiArICAgICAgICAjYWRkcmVzcy1jZWxscyA9 IDwxPjsKPiA+ICsgICAgICAgICNzaXplLWNlbGxzID0gPDA+Owo+ID4gKwo+ID4gKyAgICAgICAg dGRtQDAgewo+ID4gKyAgICAgICAgICAgIC8qIFRETWEgKi8KPiA+ICsgICAgICAgICAgICByZWcg PSA8MD47Cj4gPiArCj4gPiArICAgICAgICAgICAgY2xvY2tzID0gPCZjbGtfbDFyc3luY2E+LCA8 JmNsa19sMXJjbGthPjsKPiA+ICsgICAgICAgICAgICBjbG9jay1uYW1lcyA9ICJsMXJzeW5jIiwg ImwxcmNsayI7Cj4gPiArCj4gPiArICAgICAgICAgICAgZnNsLGNvbW1vbi1yeHR4LXBpbnM7Cj4g PiArICAgICAgICAgICAgZnNsLGZzeW5jLXJpc2luZy1lZGdlOwo+ID4gKwo+ID4gKyAgICAgICAg ICAgIHR4X3RzX3JvdXRlcyA9IDwgMiAwIDA+LCAgICAgICAgICAgICAgICAgLyogVFMgMC4uMSAq Lwo+ID4gKyAgICAgICAgICAgICAgICAgICAgICAgICAgIDwgMjQgRlNMX0NQTV9UU0FfU0NDNCAw PiwgLyogVFMgMi4uMjUgKi8KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICA8IDEgMCAw PiwgICAgICAgICAgICAgICAgIC8qIFRTIDI2ICovCj4gPiArICAgICAgICAgICAgICAgICAgICAg ICAgICAgPCA1IEZTTF9DUE1fVFNBX1NDQzMgMD47ICAvKiBUUyAyNy4uMzEgKi8KPiA+ICsKPiA+ ICsgICAgICAgICAgICByeF90c19yb3V0ZXMgPSA8IDIgMCAwPiwgICAgICAgICAgICAgICAgIC8q IFRTIDAuLjEgKi8KPiA+ICsgICAgICAgICAgICAgICAgICAgICAgICAgICA8IDI0IEZTTF9DUE1f VFNBX1NDQzQgMD4sIC8qIDIuLjI1ICovCj4gPiArICAgICAgICAgICAgICAgICAgICAgICAgICAg PCAxIDAgMD4sICAgICAgICAgICAgICAgICAvKiBUUyAyNiAqLwo+ID4gKyAgICAgICAgICAgICAg ICAgICAgICAgICAgIDwgNSBGU0xfQ1BNX1RTQV9TQ0MzIDA+OyAgLyogVFMgMjcuLjMxICovCj4g PiArICAgICAgICB9Owo+ID4gKyAgICB9Owo+ID4gZGlmZiAtLWdpdCBhL2luY2x1ZGUvZHQtYmlu ZGluZ3Mvc29jL2ZzbC10c2EuaCBiL2luY2x1ZGUvZHQtYmluZGluZ3Mvc29jL2ZzbC10c2EuaAo+ ID4gbmV3IGZpbGUgbW9kZSAxMDA2NDQKPiA+IGluZGV4IDAwMDAwMDAwMDAwMC4uOWQwOTQ2ODY5 NGEyCj4gPiAtLS0gL2Rldi9udWxsCj4gPiArKysgYi9pbmNsdWRlL2R0LWJpbmRpbmdzL3NvYy9m c2wtdHNhLmggIAo+IAo+IEZpbGVuYW1lIHNob3VsZCBtYXRjaCBiaW5kaW5nIGZpbGVuYW1lLgoK UmlnaHQsIEkgd2lsbCByZW5hbWUgdG8gZnNsLHRzYS5oCgo+IAo+ID4gQEAgLTAsMCArMSwxNSBA QAo+ID4gKy8qIFNQRFgtTGljZW5zZS1JZGVudGlmaWVyOiBHUEwtMi4wLW9yLWxhdGVyIE9SIE1J VCAqLyAgCj4gCj4gQSBiaXQgd2VpcmQgbGljZW5zZS4uLiBjYW5ub3QgYmUgdGhlIHNhbWUgYXMg YmluZGluZz8KClllcywgd2lsbCBiZSBjaGFuZ2UgdG8gR1BMLTIuMC1vbmx5IE9SIEJTRC0yLUNs YXVzZQoKPiAKPiA+ICsKPiA+ICsjaWZuZGVmIF9fRFRfQklORElOR1NfU09DX0ZTTF9UU0FfSAo+ ID4gKyNkZWZpbmUgX19EVF9CSU5ESU5HU19TT0NfRlNMX1RTQV9ICj4gPiArCj4gPiArI2RlZmlu ZSBGU0xfQ1BNX1RTQV9OVQkJMAkvKiBQc2V1c28gQ2VsbCBJZCBmb3Igbm90IHVzZWQgaXRlbSAq LyAgCj4gCj4gV2h5IGRlZmluaW5nIHVudXNlZCBJRHMgaW4gYmluZGluZyBoZWFkZXI/IFRoZXNl IGFyZSBJRHMsIG5vdCBzb21lCj4gaGFyZHdhcmUvcmVnaXN0ZXIgdmFsdWVzLgoKSXQgaXMgdGhl IGJpbmRpbmcgdmFsdWUgZm9yICdObyBkZXN0aW5hdGlvbicgaW4gdGhlIHR4IGFuZCByeCByb3V0 ZSB0YWJsZS4KVGhpcyBiaW5kaW5nIHZhbHVlIG1lYW5zICdub3QgdXNlZCcgb3IgJ2Rpc2NhcmQn IHRoZSB0aW1lLXNsb3QuClRoZSBkYXRhIHJlbGF0ZWQgdG8gYW4gaXRlbSBpbiB0aGUgcm91dGlu ZyB0YWJsZSB3aXRoIHRoaXMgdmFsdWUKd2lsbCBiZSBkaXNjYXJkZWQgYW5kIG5vdCB1c2VkLgoK PiAKPiA+ICsjZGVmaW5lIEZTTF9DUE1fVFNBX1NDQzIJMQo+ID4gKyNkZWZpbmUgRlNMX0NQTV9U U0FfU0NDMwkyCj4gPiArI2RlZmluZSBGU0xfQ1BNX1RTQV9TQ0M0CTMKPiA+ICsjZGVmaW5lIEZT TF9DUE1fVFNBX1NNQzEJNAo+ID4gKyNkZWZpbmUgRlNMX0NQTV9UU0FfU01DMgk1Cj4gPiArCj4g PiArI2RlZmluZSBGU0xfQ1BNX1RTQV9OQkNFTEwJNiAgCj4gCj4gRHJvcC4KCk9rLCB3aWxsIGJl IHJlbW92ZWQgaW4gdjMuCgo+IAo+ID4gKwo+ID4gKyNlbmRpZiAgCj4gCj4gQmVzdCByZWdhcmRz LAo+IEtyenlzenRvZgo+IAoKVGhhbmtzIGZvciB5b3VyIHJldmlldy4KCkJlc3QgcmVnYXJkcywK SGVydsOpCgoKLS0gCkhlcnbDqSBDb2RpbmEsIEJvb3RsaW4KRW1iZWRkZWQgTGludXggYW5kIEtl cm5lbCBlbmdpbmVlcmluZwpodHRwczovL2Jvb3RsaW4uY29tCgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlz dApsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJh ZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4E081C46467 for ; Tue, 10 Jan 2023 08:05:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230440AbjAJIF3 (ORCPT ); Tue, 10 Jan 2023 03:05:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39520 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230020AbjAJIE7 (ORCPT ); Tue, 10 Jan 2023 03:04:59 -0500 Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0501B3C736; Tue, 10 Jan 2023 00:04:54 -0800 (PST) Received: (Authenticated sender: herve.codina@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id B0355240002; Tue, 10 Jan 2023 08:04:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1673337893; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ld//437bDkASopb9h7+9poDloE57liYuwe18eXbKN8w=; b=ov0pvxlHlJUeYGpbOxfh3TlbG/6hyno/7b2AXf0AjpdSSuzkiap+N5k0H2PaOicUlgstfi PnIyO5WTKv+yhKA0Bc9xlkuKHckPcDQ+Df02Yqae7X8QO3DgiDahUe1TRLKHUCAGzqmaPR 7Q4MxMrdYq1UoDOvZOywXHjr8g/Iw+sZZd4VjUTATlRBX6IQScWT87sydVl3axe3BtXyfK 704goO65ZlkADey+Oe9wu+yQEBuJlJz5iGPO41bFpshj2KrTjwcblrZJMDVYLTrpEHu/6T sh218R49M4FEe4qLow6/+PHeb+00midD9UpiXNTK7VLMHZ2q6Ql01BrNjHsolg== Date: Tue, 10 Jan 2023 09:04:45 +0100 From: Herve Codina To: Krzysztof Kozlowski Cc: Li Yang , Rob Herring , Krzysztof Kozlowski , Liam Girdwood , Mark Brown , Christophe Leroy , Michael Ellerman , Nicholas Piggin , Qiang Zhao , Jaroslav Kysela , Takashi Iwai , Shengjiu Wang , Xiubo Li , Fabio Estevam , Nicolin Chen , linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org, Thomas Petazzoni Subject: Re: [PATCH v2 01/10] dt-bindings: soc: fsl: cpm_qe: Add TSA controller Message-ID: <20230110090445.2dc61b51@bootlin.com> In-Reply-To: <427e0775-c576-e293-f590-b9840b936884@linaro.org> References: <20230106163746.439717-1-herve.codina@bootlin.com> <20230106163746.439717-2-herve.codina@bootlin.com> <427e0775-c576-e293-f590-b9840b936884@linaro.org> Organization: Bootlin X-Mailer: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hi Krzysztof, On Sun, 8 Jan 2023 16:10:38 +0100 Krzysztof Kozlowski wrote: [...] > > + '#size-cells': > > + const: 0 > > + > > +patternProperties: > > + "^tdm@[0-1]$": =20 >=20 > Use consistent quotes - either ' or " Ok, I will change on v3. I will also change them on the other bindings present in the series. >=20 > > + description: > > + The TDM managed by this controller > > + type: object > > + > > + properties: > > + reg: > > + minimum: 0 > > + maximum: 1 > > + description: > > + The TDM number for this TDM, 0 for TDMa and 1 for TDMb > > + > > + fsl,common-rxtx-pins: > > + $ref: /schemas/types.yaml#/definitions/flag > > + description: > > + Use common pins for both transmit and receive =20 >=20 > What are the "common" pins? Without this property device is using > uncommon pins? This does not make sense... Common in the "shared" sense. The hardware can use dedicated pins for Tx clock, Tx sync, Rx clock and Rx sync or use only 2 pins, Tx/Rx clock and Rx/Rx sync. Without the property, we use the 4 pins and with the property, we use 2 pins. >=20 > > + > > + clocks: true > > + clock-names: true =20 >=20 > Both need constraints. The constraints are present later in the file as the number of clocks depends on the 'fsl,common-rxtx-pins' property. I will remove these two lines in the v3 series as they are not needed. 'clocks' and 'clock-names' are handled in the conditional part. >=20 [...] > > + > > + fsl,rx-frame-sync-delay: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + enum: [0, 1, 2, 3] > > + default: 0 > > + description: | > > + Receive frame sync delay. =20 >=20 > Delay in what units? The unit is a number of bits. I will rename to fsl,rx-frame-sync-delay-bits and change the description to 'Receive frame sync delay in number of bits' I will do also the same for fsl,tx-frame-sync-delay property. >=20 > > + Indicates the delay between the Rx sync and the first bit of= the > > + Rx frame. 0 for no bit delay. 1, 2 or 3 for 1, 2 or 3 bits d= elay. > > + > > + fsl,tx-frame-sync-delay: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + enum: [0, 1, 2, 3] > > + default: 0 > > + description: | > > + Transmit frame sync delay. > > + Indicates the delay between the Tx sync and the first bit of= the > > + Tx frame. 0 for no bit delay. 1, 2 or 3 for 1, 2 or 3 bits d= elay. > > + > > + fsl,clock-falling-edge: > > + $ref: /schemas/types.yaml#/definitions/flag > > + description: | > > + Data is sent on falling edge of the clock (and received on t= he > > + rising edge). > > + If 'clock-falling-edge' is not present, data is sent on the > > + rising edge (and received on the falling edge). > > + > > + fsl,fsync-rising-edge: > > + $ref: /schemas/types.yaml#/definitions/flag > > + description: > > + Frame sync pulses are sampled with the rising edge of the ch= annel > > + clock. If 'fsync-rising-edge' is not present, pulses are sam= ple > > + with e falling edge. > > + > > + fsl,double-speed-clock: > > + $ref: /schemas/types.yaml#/definitions/flag > > + description: > > + The channel clock is twice the data rate. > > + > > + fsl,grant-mode: > > + $ref: /schemas/types.yaml#/definitions/flag > > + description: > > + Grant mode enabled. =20 >=20 > This we know from property name. You need to describe what it is and > what it does. Instead of describing it, I will simply remove the property (I should have done already). I cannot test the 'grant mode' enabled with my hardware and so I prefer keeping it disabled. This property, if needed, could be add later setting it optional with default to 'disabled'. >=20 > > + > > + tx_ts_routes: =20 >=20 > No underscores, missing vendor prefix. Indeed, will be change to fsl,tx-ts-routes (idem for rx_ts_routes). >=20 > > + $ref: /schemas/types.yaml#/definitions/uint32-matrix > > + description: | > > + A list of tupple that indicates the Tx time-slots routes. > > + tx_ts_routes =3D > > + < 2 0 0>, /* The first 2 time slots are not used */ > > + < 3 1 0>, /* The next 3 ones are route to SCC2 */ > > + < 4 0 0>, /* The next 4 ones are not used */ > > + < 2 2 0>; /* The nest 2 ones are route to SCC3 */ > > + items: > > + items: > > + - description: > > + The number of time-slots > > + minimum: 1 > > + maximum: 64 > > + - description: | > > + The source serial interface (dt-bindings/soc/fsl-tsa.h > > + defines these values) > > + - 0: No destination > > + - 1: SCC2 > > + - 2: SCC3 > > + - 3: SCC4 > > + - 4: SMC1 > > + - 5: SMC2 > > + enum: [0, 1, 2, 3, 4, 5] > > + - description: > > + The route flags (reserved) =20 >=20 > Why part of binding is reserved? The 'reserved' part will be removed in v3. Same for the rx route table. >=20 > > + const: 0 > > + minItems: 1 > > + maxItems: 64 > > + > > + rx_ts_routes: > > + $ref: /schemas/types.yaml#/definitions/uint32-matrix > > + description: | > > + A list of tupple that indicates the Rx time-slots routes. > > + tx_ts_routes =3D > > + < 2 0 0>, /* The first 2 time slots are not used */ > > + < 3 1 0>, /* The next 3 ones are route from SCC2 */ > > + < 4 0 0>, /* The next 4 ones are not used */ > > + < 2 2 0>; /* The nest 2 ones are route from SCC3 */ > > + items: > > + items: > > + - description: > > + The number of time-slots > > + minimum: 1 > > + maximum: 64 > > + - description: | > > + The destination serial interface (dt-bindings/soc/fsl-= tsa.h > > + defines these values) > > + - 0: No destination > > + - 1: SCC2 > > + - 2: SCC3 > > + - 3: SCC4 > > + - 4: SMC1 > > + - 5: SMC2 > > + enum: [0, 1, 2, 3, 4, 5] > > + - description: > > + The route flags (reserved) > > + const: 0 > > + minItems: 1 > > + maxItems: 64 > > + > > + allOf: > > + - if: > > + properties: > > + fsl,common-rxtx-pins: > > + type: 'null' =20 >=20 > What is this exactly? If check for property present, it's wrong. Should > be test if it is in required. Yes, it was a check for the property presence. If we not use the 'fsl,common-rxtx-pins', we need 4 clocks. If we use the 'fsl,common-rxtx-pins', we need 2 clocks (Rx part and Tx part use the same CLK and SYNC clocks). How can I describe this ? Is the check for the property presence incorrect ? Should I always describe 4 clocks even if only 2 are used ? >=20 > > + then: > > + properties: > > + clocks: > > + items: > > + - description: External clock connected to L1RSYNC pin > > + - description: External clock connected to L1RCLK pin > > + - description: External clock connected to L1TSYNC pin > > + - description: External clock connected to L1TCLK pin > > + clock-names: > > + items: > > + - const: l1rsync > > + - const: l1rclk > > + - const: l1tsync > > + - const: l1tclk > > + else: > > + properties: > > + clocks: > > + items: > > + - description: External clock connected to L1RSYNC pin > > + - description: External clock connected to L1RCLK pin > > + clock-names: > > + items: > > + - const: l1rsync > > + - const: l1rclk > > + > > + required: > > + - reg > > + - clocks > > + - clock-names > > + > > +required: > > + - compatible > > + - reg > > + - reg-names > > + - '#address-cells' > > + - '#size-cells' > > + > > +additionalProperties: false > > + > > +examples: > > + - | > > + #include > > + > > + tsa@ae0 { > > + compatible =3D "fsl,mpc885-tsa", "fsl,cpm1-tsa"; > > + reg =3D <0xae0 0x10>, > > + <0xc00 0x200>; > > + reg-names =3D "si_regs", "si_ram"; > > + > > + #address-cells =3D <1>; > > + #size-cells =3D <0>; > > + > > + tdm@0 { > > + /* TDMa */ > > + reg =3D <0>; > > + > > + clocks =3D <&clk_l1rsynca>, <&clk_l1rclka>; > > + clock-names =3D "l1rsync", "l1rclk"; > > + > > + fsl,common-rxtx-pins; > > + fsl,fsync-rising-edge; > > + > > + tx_ts_routes =3D < 2 0 0>, /* TS 0..1 */ > > + < 24 FSL_CPM_TSA_SCC4 0>, /* TS 2..25 */ > > + < 1 0 0>, /* TS 26 */ > > + < 5 FSL_CPM_TSA_SCC3 0>; /* TS 27..31 */ > > + > > + rx_ts_routes =3D < 2 0 0>, /* TS 0..1 */ > > + < 24 FSL_CPM_TSA_SCC4 0>, /* 2..25 */ > > + < 1 0 0>, /* TS 26 */ > > + < 5 FSL_CPM_TSA_SCC3 0>; /* TS 27..31 */ > > + }; > > + }; > > diff --git a/include/dt-bindings/soc/fsl-tsa.h b/include/dt-bindings/so= c/fsl-tsa.h > > new file mode 100644 > > index 000000000000..9d09468694a2 > > --- /dev/null > > +++ b/include/dt-bindings/soc/fsl-tsa.h =20 >=20 > Filename should match binding filename. Right, I will rename to fsl,tsa.h >=20 > > @@ -0,0 +1,15 @@ > > +/* SPDX-License-Identifier: GPL-2.0-or-later OR MIT */ =20 >=20 > A bit weird license... cannot be the same as binding? Yes, will be change to GPL-2.0-only OR BSD-2-Clause >=20 > > + > > +#ifndef __DT_BINDINGS_SOC_FSL_TSA_H > > +#define __DT_BINDINGS_SOC_FSL_TSA_H > > + > > +#define FSL_CPM_TSA_NU 0 /* Pseuso Cell Id for not used item */ =20 >=20 > Why defining unused IDs in binding header? These are IDs, not some > hardware/register values. It is the binding value for 'No destination' in the tx and rx route table. This binding value means 'not used' or 'discard' the time-slot. The data related to an item in the routing table with this value will be discarded and not used. >=20 > > +#define FSL_CPM_TSA_SCC2 1 > > +#define FSL_CPM_TSA_SCC3 2 > > +#define FSL_CPM_TSA_SCC4 3 > > +#define FSL_CPM_TSA_SMC1 4 > > +#define FSL_CPM_TSA_SMC2 5 > > + > > +#define FSL_CPM_TSA_NBCELL 6 =20 >=20 > Drop. Ok, will be removed in v3. >=20 > > + > > +#endif =20 >=20 > Best regards, > Krzysztof >=20 Thanks for your review. Best regards, Herv=C3=A9 --=20 Herv=C3=A9 Codina, Bootlin Embedded Linux and Kernel engineering https://bootlin.com