| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20230131084449.445a4d2f@bootlin.com>
Date: Tue, 31 Jan 2023 08:44:49 +0100
From: Herve Codina <herve.codina@...tlin.com>
To: Rob Herring <robh@...nel.org>
Cc: Li Yang <leoyang.li@....com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>,
Christophe Leroy <christophe.leroy@...roup.eu>,
Michael Ellerman <mpe@...erman.id.au>,
Nicholas Piggin <npiggin@...il.com>,
Qiang Zhao <qiang.zhao@....com>,
Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>,
Shengjiu Wang <shengjiu.wang@...il.com>,
Xiubo Li <Xiubo.Lee@...il.com>,
Fabio Estevam <festevam@...il.com>,
Nicolin Chen <nicoleotsuka@...il.com>,
linuxppc-dev@...ts.ozlabs.org,
linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, alsa-devel@...a-project.org,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v4 01/10] dt-bindings: soc: fsl: cpm_qe: Add TSA
controller
On Mon, 30 Jan 2023 12:27:44 -0600
Hi Rob,
Rob Herring <robh@...nel.org> wrote:
> On Thu, Jan 26, 2023 at 09:32:13AM +0100, Herve Codina wrote:
> > Add support for the time slot assigner (TSA)
> > available in some PowerQUICC SoC such as MPC885
> > or MPC866.
> >
> > Signed-off-by: Herve Codina <herve.codina@...tlin.com>
> > ---
> > .../bindings/soc/fsl/cpm_qe/fsl,tsa.yaml | 261 ++++++++++++++++++
>
> fsl,cpm1-tsa.yaml
Right, will be change in next iteration.
>
> > include/dt-bindings/soc/fsl,tsa.h | 13 +
> > 2 files changed, 274 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,tsa.yaml
> > create mode 100644 include/dt-bindings/soc/fsl,tsa.h
> >
> > diff --git a/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,tsa.yaml b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,tsa.yaml
> > new file mode 100644
> > index 000000000000..d027d4c3cf10
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/soc/fsl/cpm_qe/fsl,tsa.yaml
> > @@ -0,0 +1,261 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/soc/fsl/cpm_qe/fsl,tsa.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: PowerQUICC CPM Time-slot assigner (TSA) controller
> > +
> > +maintainers:
> > + - Herve Codina <herve.codina@...tlin.com>
> > +
> > +description:
> > + The TSA is the time-slot assigner that can be found on some PowerQUICC SoC.
> > + Its purpose is to route some TDM time-slots to other internal serial
> > + controllers.
> > +
> > +properties:
> > + compatible:
> > + items:
> > + - enum:
> > + - fsl,mpc885-tsa
> > + - fsl,mpc866-tsa
> > + - const: fsl,cpm1-tsa
> > +
> > + reg:
> > + items:
> > + - description: SI (Serial Interface) register base
> > + - description: SI RAM base
> > +
> > + reg-names:
> > + items:
> > + - const: si_regs
> > + - const: si_ram
> > +
> > + '#address-cells':
> > + const: 1
> > +
> > + '#size-cells':
> > + const: 0
> > +
> > + '#serial-cells':
>
> Not a standard property. What's this for? #.*-cells applies to a
> specific pattern of properties.
A TSA consumer, such as QMC in this series, can have a phandle with an
argument that points to this TSA node. For instance, in the QMC
node, we have:
fsl,tsa-serial = <&tsa FSL_CPM_TSA_SCC4>;
The #serial-cells property in TSA specify the presence of this argument.
What do you think if I add the following description:
'#serial-cells':
const: 1
description:
TSA consumers that use a phandle to TSA need to pass the serial
identifier with this phandle (defined in dt-bindings/soc/fsl,tsa.h).
For instance "fsl,tsa-serial = <&tsa FSL_CPM_TSA_SCC4>;".
>
>
> > + const: 1
> > +
> > +patternProperties:
> > + '^tdm@[0-1]$':
> > + description:
> > + The TDM managed by this controller
> > + type: object
> > +
> > + additionalProperties: false
> > +
> > + 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:
> > + The hardware can use four dedicated pins for Tx clock, Tx sync, Rx
> > + clock and Rx sync or use only two pins, Tx/Rx clock and Tx/Rx sync.
> > + Without the 'fsl,common-rxtx-pins' property, the four pins are used.
> > + With the 'fsl,common-rxtx-pins' property, two pins are used.
> > +
> > + clocks:
> > + minItems: 2
> > + 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:
> > + minItems: 2
> > + items:
> > + - const: l1rsync
> > + - const: l1rclk
> > + - const: l1tsync
> > + - const: l1tclk
> > +
> > + fsl,diagnostic-mode:
> > + $ref: /schemas/types.yaml#/definitions/string
> > + enum: [disabled, echo, internal-loopback, control-loopback]
>
> Seems like you would want userspace control of this, not have to make
> firmware changes and reboot to change.
I don't plan to give userspace control of this diagnostic mode.
When I need to use this diagnostic mode, I plan to set this property
in DT and reboot the system.
>
> > + default: disabled
> > + description: |
> > + The diagnostic mode can be used to diagnose some communication issues.
> > + It should not be set (or set to 'disabled') when diagnostic is not
> > + needed.
> > + Diagnostic mode:
> > + - disabled:
> > + Diagnostic disabled (ie. normal operation)
> > + - echo:
> > + Automatic echo. Rx data is resent on Tx.
> > + - internal-loopback:
> > + The TDM transmitter is connected to the receiver. Data appears
> > + on Tx pin.
> > + - control-loopback:
> > + The TDM transmitter is connected to the receiver. The Tx pin is
> > + disconnected.
> > +
> > + fsl,rx-frame-sync-delay-bits:
> > + enum: [0, 1, 2, 3]
> > + default: 0
> > + description: |
> > + Receive frame sync delay in number of bits.
> > + 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 delay.
> > +
> > + fsl,tx-frame-sync-delay-bits:
> > + enum: [0, 1, 2, 3]
> > + default: 0
> > + description: |
> > + Transmit frame sync delay in number of bits.
> > + 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 delay.
> > +
> > + fsl,clock-falling-edge:
> > + $ref: /schemas/types.yaml#/definitions/flag
> > + description:
> > + Data is sent on falling edge of the clock (and received on the 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 channel
> > + clock. If 'fsync-rising-edge' is not present, pulses are sampled with
> > + the falling edge.
> > +
> > + fsl,double-speed-clock:
> > + $ref: /schemas/types.yaml#/definitions/flag
> > + description:
> > + The channel clock is twice the data rate.
> > +
> > + fsl,tx-ts-routes:
> > + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> > + description: |
> > + A list of tupple that indicates the Tx time-slots routes.
>
> tuple
Will be fixed in next iteration.
>
> > + tx_ts_routes =
>
> Not the property name. Put an example in the example(s).
Oups, should be fsl,tx-ts-routes.
An example is already present in the example section.
I will remove this example from the description in the next iteration.
>
> > + < 2 0 >, /* The first 2 time slots are not used */
> > + < 3 1 >, /* The next 3 ones are route to SCC2 */
> > + < 4 0 >, /* The next 4 ones are not used */
> > + < 2 2 >; /* 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]
> > + minItems: 1
> > + maxItems: 64
> > +
> > + fsl,rx-ts-routes:
>
> You could make these a pattern instead of duplicating the constraints:
>
> '^fsl,[rt]x-ts-routes$'
Yes, I will use the pattern to handle tx and rx.
As mentionned in fsl,tx-ts-routes, I will remove the example from the
description as examples are already present in the example section.
>
> > + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> > + description: |
> > + A list of tupple that indicates the Rx time-slots routes.
> > + tx_ts_routes =
> > + < 2 0 >, /* The first 2 time slots are not used */
> > + < 3 1 >, /* The next 3 ones are route from SCC2 */
> > + < 4 0 >, /* The next 4 ones are not used */
> > + < 2 2 >; /* 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]
> > + minItems: 1
> > + maxItems: 64
> > +
> > + allOf:
> > + # If fsl,common-rxtx-pins is present, only 2 clocks are needed.
> > + # Else, the 4 clocks must be present.
> > + - if:
> > + required:
> > + - fsl,common-rxtx-pins
> > + then:
> > + properties:
> > + clocks:
> > + maxItems: 2
> > + clock-names:
> > + maxItems: 2
> > + else:
> > + properties:
> > + clocks:
> > + minItems: 4
> > + clock-names:
> > + minItems: 4
> > +
> > + required:
> > + - reg
> > + - clocks
> > + - clock-names
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - reg-names
> > + - '#address-cells'
> > + - '#size-cells'
> > + - '#serial-cells'
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/soc/fsl,tsa.h>
> > +
> > + tsa@ae0 {
> > + compatible = "fsl,mpc885-tsa", "fsl,cpm1-tsa";
> > + reg = <0xae0 0x10>,
> > + <0xc00 0x200>;
> > + reg-names = "si_regs", "si_ram";
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + #serial-cells = <1>;
> > +
> > + tdm@0 {
> > + /* TDMa */
> > + reg = <0>;
> > +
> > + clocks = <&clk_l1rsynca>, <&clk_l1rclka>;
> > + clock-names = "l1rsync", "l1rclk";
> > +
> > + fsl,common-rxtx-pins;
> > + fsl,fsync-rising-edge;
> > +
> > + fsl,tx-ts-routes = < 2 0 >, /* TS 0..1 */
> > + < 24 FSL_CPM_TSA_SCC4 >, /* TS 2..25 */
> > + < 1 0 >, /* TS 26 */
> > + < 5 FSL_CPM_TSA_SCC3 >; /* TS 27..31 */
> > +
> > + fsl,rx-ts-routes = < 2 0 >, /* TS 0..1 */
> > + < 24 FSL_CPM_TSA_SCC4 >, /* 2..25 */
> > + < 1 0 >, /* TS 26 */
> > + < 5 FSL_CPM_TSA_SCC3 >; /* TS 27..31 */
> > + };
> > + };
> > diff --git a/include/dt-bindings/soc/fsl,tsa.h b/include/dt-bindings/soc/fsl,tsa.h
> > new file mode 100644
> > index 000000000000..2cc44e867dbe
> > --- /dev/null
> > +++ b/include/dt-bindings/soc/fsl,tsa.h
> > @@ -0,0 +1,13 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause */
> > +
> > +#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 */
> > +#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
> > +
> > +#endif
> > --
> > 2.39.0
> >
Thanks for the review,
Hervé
--
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Powered by blists - more mailing lists