The TI specific compatible should be followed by the generic
"cdns,qspi-nor" compatible.
Signed-off-by: Pratyush Yadav <redacted>
---
arch/arm64/boot/dts/ti/k3-j7200-mcu-wakeup.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The TI specific compatible should be followed by the generic
"cdns,qspi-nor" compatible.
Signed-off-by: Pratyush Yadav <redacted>
---
arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
The TI specific compatible should be followed by the generic
"cdns,qspi-nor" compatible.
Signed-off-by: Pratyush Yadav <redacted>
---
arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Ramuthevar Vadivel Murugan <redacted>
There is no way as of now to have a parent or bus defining properties
for child nodes. For now, avoid it in the example to silence warnings on
dt_schema_check. We can figure out how to deal with actual dts files
later.
Signed-off-by: Ramuthevar Vadivel Murugan <redacted>
Signed-off-by: Pratyush Yadav <redacted>
[p.yadav@ti.com: Fix how compatible is defined, make reset optional, fix
minor typos, remove subnode properties in example, update commit
message.]
---
.../bindings/spi/cadence-quadspi.txt | 68 ---------
.../bindings/spi/cdns,qspi-nor.yaml | 143 ++++++++++++++++++
2 files changed, 143 insertions(+), 68 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/spi/cadence-quadspi.txt
create mode 100644 Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
@@ -1,68 +0,0 @@-* Cadence Quad SPI controller--Required properties:-- compatible : should be one of the following:- Generic default - "cdns,qspi-nor".- For TI 66AK2G SoC - "ti,k2g-qspi", "cdns,qspi-nor".- For TI AM654 SoC - "ti,am654-ospi", "cdns,qspi-nor".- For Intel LGM SoC - "intel,lgm-qspi", "cdns,qspi-nor".-- reg : Contains two entries, each of which is a tuple consisting of a- physical address and length. The first entry is the address and- length of the controller register set. The second entry is the- address and length of the QSPI Controller data area.-- interrupts : Unit interrupt specifier for the controller interrupt.-- clocks : phandle to the Quad SPI clock.-- cdns,fifo-depth : Size of the data FIFO in words.-- cdns,fifo-width : Bus width of the data FIFO in bytes.-- cdns,trigger-address : 32-bit indirect AHB trigger address.--Optional properties:-- cdns,is-decoded-cs : Flag to indicate whether decoder is used or not.-- cdns,rclk-en : Flag to indicate that QSPI return clock is used to latch- the read data rather than the QSPI clock. Make sure that QSPI return- clock is populated on the board before using this property.--Optional subnodes:-Subnodes of the Cadence Quad SPI controller are spi slave nodes with additional-custom properties:-- cdns,read-delay : Delay for read capture logic, in clock cycles-- cdns,tshsl-ns : Delay in nanoseconds for the length that the master- mode chip select outputs are de-asserted between- transactions.-- cdns,tsd2d-ns : Delay in nanoseconds between one chip select being- de-activated and the activation of another.-- cdns,tchsh-ns : Delay in nanoseconds between last bit of current- transaction and deasserting the device chip select- (qspi_n_ss_out).-- cdns,tslch-ns : Delay in nanoseconds between setting qspi_n_ss_out low- and first bit transfer.-- resets : Must contain an entry for each entry in reset-names.- See ../reset/reset.txt for details.-- reset-names : Must include either "qspi" and/or "qspi-ocp".--Example:-- qspi: spi@ff705000 {- compatible = "cdns,qspi-nor";- #address-cells = <1>;- #size-cells = <0>;- reg = <0xff705000 0x1000>,- <0xffa00000 0x1000>;- interrupts = <0 151 4>;- clocks = <&qspi_clk>;- cdns,is-decoded-cs;- cdns,fifo-depth = <128>;- cdns,fifo-width = <4>;- cdns,trigger-address = <0x00000000>;- resets = <&rst QSPI_RESET>, <&rst QSPI_OCP_RESET>;- reset-names = "qspi", "qspi-ocp";-- flash0: n25q00@0 {- ...- cdns,read-delay = <4>;- cdns,tshsl-ns = <50>;- cdns,tsd2d-ns = <50>;- cdns,tchsh-ns = <4>;- cdns,tslch-ns = <4>;- };- };
@@ -0,0 +1,143 @@+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)+%YAML1.2+---+$id:http://devicetree.org/schemas/spi/cdns,qspi-nor.yaml#+$schema:http://devicetree.org/meta-schemas/core.yaml#++title:Cadence Quad SPI controller++maintainers:+-Pratyush Yadav <p.yadav@ti.com>++allOf:+-$ref:spi-controller.yaml#++properties:+compatible:+oneOf:+-items:+-enum:+-ti,k2g-qspi+-ti,am654-ospi+-intel,lgm-qspi+-const:cdns,qspi-nor+-const:cdns,qspi-nor++reg:+items:+-description:the controller register set+-description:the controller data area++interrupts:+maxItems:1++clocks:+maxItems:1++cdns,fifo-depth:+description:+Size of the data FIFO in words.+$ref:"/schemas/types.yaml#/definitions/uint32"+enum:[128,256]+default:128++cdns,fifo-width:+$ref:/schemas/types.yaml#/definitions/uint32+description:+Bus width of the data FIFO in bytes.+default:4++cdns,trigger-address:+$ref:/schemas/types.yaml#/definitions/uint32+description:+32-bit indirect AHB trigger address.++cdns,is-decoded-cs:+type:boolean+description:+Flag to indicate whether decoder is used to select different chip select+for different memory regions.++cdns,rclk-en:+type:boolean+description:+Flag to indicate that QSPI return clock is used to latch the read+data rather than the QSPI clock. Make sure that QSPI return clock+is populated on the board before using this property.++resets:+maxItems:2++reset-names:+minItems:1+maxItems:2+items:+enum:[qspi,qspi-ocp]++# subnode's properties+patternProperties:+"@[0-9a-f]+$":+type:object+description:+Flash device uses the below defined properties in the subnode.++properties:+cdns,read-delay:+$ref:/schemas/types.yaml#/definitions/uint32+description:+Delay for read capture logic, in clock cycles.++cdns,tshsl-ns:+description:+Delay in nanoseconds for the length that the master mode chip select+outputs are de-asserted between transactions.++cdns,tsd2d-ns:+description:+Delay in nanoseconds between one chip select being de-activated+and the activation of another.++cdns,tchsh-ns:+description:+Delay in nanoseconds between last bit of current transaction and+deasserting the device chip select (qspi_n_ss_out).++cdns,tslch-ns:+description:+Delay in nanoseconds between setting qspi_n_ss_out low and+first bit transfer.++required:+-compatible+-reg+-interrupts+-clocks+-cdns,fifo-depth+-cdns,fifo-width+-cdns,trigger-address+-'#address-cells'+-'#size-cells'++unevaluatedProperties:false++examples:+-|+qspi:spi@ff705000 {+compatible = "cdns,qspi-nor";+#address-cells = <1>;+#size-cells = <0>;+reg = <0xff705000 0x1000>,+<0xffa00000 0x1000>;+interrupts = <0 151 4>;+clocks = <&qspi_clk>;+cdns,fifo-depth = <128>;+cdns,fifo-width = <4>;+cdns,trigger-address = <0x00000000>;+resets = <&rst 0x1>, <&rst 0x2>;+reset-names = "qspi", "qspi-ocp";++flash@0 {+compatible = "jedec,spi-nor";+reg = <0x0>;+};+};
From: Rob Herring <robh@kernel.org> Date: 2021-03-27 18:37:34
On Fri, Mar 26, 2021 at 06:30:34PM +0530, Pratyush Yadav wrote:
From: Ramuthevar Vadivel Murugan <redacted>
There is no way as of now to have a parent or bus defining properties
for child nodes. For now, avoid it in the example to silence warnings on
dt_schema_check. We can figure out how to deal with actual dts files
later.
Signed-off-by: Ramuthevar Vadivel Murugan <redacted>
Signed-off-by: Pratyush Yadav <redacted>
[p.yadav@ti.com: Fix how compatible is defined, make reset optional, fix
minor typos, remove subnode properties in example, update commit
message.]
---
.../bindings/spi/cadence-quadspi.txt | 68 ---------
.../bindings/spi/cdns,qspi-nor.yaml | 143 ++++++++++++++++++
2 files changed, 143 insertions(+), 68 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/spi/cadence-quadspi.txt
create mode 100644 Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
@@ -0,0 +1,143 @@+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)+%YAML1.2+---+$id:http://devicetree.org/schemas/spi/cdns,qspi-nor.yaml#+$schema:http://devicetree.org/meta-schemas/core.yaml#++title:Cadence Quad SPI controller++maintainers:+-Pratyush Yadav <p.yadav@ti.com>++allOf:+-$ref:spi-controller.yaml#++properties:+compatible:+oneOf:+-items:+-enum:+-ti,k2g-qspi+-ti,am654-ospi+-intel,lgm-qspi+-const:cdns,qspi-nor+-const:cdns,qspi-nor++reg:+items:+-description:the controller register set+-description:the controller data area++interrupts:+maxItems:1++clocks:+maxItems:1++cdns,fifo-depth:+description:+Size of the data FIFO in words.+$ref:"/schemas/types.yaml#/definitions/uint32"+enum:[128,256]+default:128++cdns,fifo-width:+$ref:/schemas/types.yaml#/definitions/uint32+description:+Bus width of the data FIFO in bytes.+default:4
I assume there's some constraints on this?
With that,
Reviewed-by: Rob Herring <robh@kernel.org>
+
+ cdns,trigger-address:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ 32-bit indirect AHB trigger address.
+
+ cdns,is-decoded-cs:
+ type: boolean
+ description:
+ Flag to indicate whether decoder is used to select different chip select
+ for different memory regions.
+
+ cdns,rclk-en:
+ type: boolean
+ description:
+ Flag to indicate that QSPI return clock is used to latch the read
+ data rather than the QSPI clock. Make sure that QSPI return clock
+ is populated on the board before using this property.
+
+ resets:
+ maxItems: 2
+
+ reset-names:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum: [ qspi, qspi-ocp ]
+
+# subnode's properties
+patternProperties:
+ "@[0-9a-f]+$":
+ type: object
+ description:
+ Flash device uses the below defined properties in the subnode.
+
+ properties:
+ cdns,read-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Delay for read capture logic, in clock cycles.
+
+ cdns,tshsl-ns:
+ description:
+ Delay in nanoseconds for the length that the master mode chip select
+ outputs are de-asserted between transactions.
+
+ cdns,tsd2d-ns:
+ description:
+ Delay in nanoseconds between one chip select being de-activated
+ and the activation of another.
+
+ cdns,tchsh-ns:
+ description:
+ Delay in nanoseconds between last bit of current transaction and
+ deasserting the device chip select (qspi_n_ss_out).
+
+ cdns,tslch-ns:
+ description:
+ Delay in nanoseconds between setting qspi_n_ss_out low and
+ first bit transfer.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - cdns,fifo-depth
+ - cdns,fifo-width
+ - cdns,trigger-address
+ - '#address-cells'
+ - '#size-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ qspi: spi@ff705000 {
+ compatible = "cdns,qspi-nor";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xff705000 0x1000>,
+ <0xffa00000 0x1000>;
+ interrupts = <0 151 4>;
+ clocks = <&qspi_clk>;
+ cdns,fifo-depth = <128>;
+ cdns,fifo-width = <4>;
+ cdns,trigger-address = <0x00000000>;
+ resets = <&rst 0x1>, <&rst 0x2>;
+ reset-names = "qspi", "qspi-ocp";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ };
+ };
--
2.30.0
On Fri, Mar 26, 2021 at 06:30:34PM +0530, Pratyush Yadav wrote:
quoted
From: Ramuthevar Vadivel Murugan <redacted>
There is no way as of now to have a parent or bus defining properties
for child nodes. For now, avoid it in the example to silence warnings on
dt_schema_check. We can figure out how to deal with actual dts files
later.
Signed-off-by: Ramuthevar Vadivel Murugan <redacted>
Signed-off-by: Pratyush Yadav <redacted>
[p.yadav@ti.com: Fix how compatible is defined, make reset optional, fix
minor typos, remove subnode properties in example, update commit
message.]
---
.../bindings/spi/cadence-quadspi.txt | 68 ---------
.../bindings/spi/cdns,qspi-nor.yaml | 143 ++++++++++++++++++
2 files changed, 143 insertions(+), 68 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/spi/cadence-quadspi.txt
create mode 100644 Documentation/devicetree/bindings/spi/cdns,qspi-nor.yaml
@@ -0,0 +1,143 @@+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)+%YAML1.2+---+$id:http://devicetree.org/schemas/spi/cdns,qspi-nor.yaml#+$schema:http://devicetree.org/meta-schemas/core.yaml#++title:Cadence Quad SPI controller++maintainers:+-Pratyush Yadav <p.yadav@ti.com>++allOf:+-$ref:spi-controller.yaml#++properties:+compatible:+oneOf:+-items:+-enum:+-ti,k2g-qspi+-ti,am654-ospi+-intel,lgm-qspi+-const:cdns,qspi-nor+-const:cdns,qspi-nor++reg:+items:+-description:the controller register set+-description:the controller data area++interrupts:+maxItems:1++clocks:+maxItems:1++cdns,fifo-depth:+description:+Size of the data FIFO in words.+$ref:"/schemas/types.yaml#/definitions/uint32"+enum:[128,256]+default:128++cdns,fifo-width:+$ref:/schemas/types.yaml#/definitions/uint32+description:+Bus width of the data FIFO in bytes.+default:4
I assume there's some constraints on this?
IIUC this is a matter of how the peripheral is implemented and there are
no clear constraints. Different implementations can use different bus
widths for the SRAM bus but I don't see any mention of minimum or
maximum values. FWIW, all users in the kernel use a 4 byte bus.
With that,
Reviewed-by: Rob Herring <robh@kernel.org>
Thanks.
quoted
+
+ cdns,trigger-address:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ 32-bit indirect AHB trigger address.
+
+ cdns,is-decoded-cs:
+ type: boolean
+ description:
+ Flag to indicate whether decoder is used to select different chip select
+ for different memory regions.
+
+ cdns,rclk-en:
+ type: boolean
+ description:
+ Flag to indicate that QSPI return clock is used to latch the read
+ data rather than the QSPI clock. Make sure that QSPI return clock
+ is populated on the board before using this property.
+
+ resets:
+ maxItems: 2
+
+ reset-names:
+ minItems: 1
+ maxItems: 2
+ items:
+ enum: [ qspi, qspi-ocp ]
+
+# subnode's properties
+patternProperties:
+ "@[0-9a-f]+$":
+ type: object
+ description:
+ Flash device uses the below defined properties in the subnode.
+
+ properties:
+ cdns,read-delay:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Delay for read capture logic, in clock cycles.
+
+ cdns,tshsl-ns:
+ description:
+ Delay in nanoseconds for the length that the master mode chip select
+ outputs are de-asserted between transactions.
+
+ cdns,tsd2d-ns:
+ description:
+ Delay in nanoseconds between one chip select being de-activated
+ and the activation of another.
+
+ cdns,tchsh-ns:
+ description:
+ Delay in nanoseconds between last bit of current transaction and
+ deasserting the device chip select (qspi_n_ss_out).
+
+ cdns,tslch-ns:
+ description:
+ Delay in nanoseconds between setting qspi_n_ss_out low and
+ first bit transfer.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - cdns,fifo-depth
+ - cdns,fifo-width
+ - cdns,trigger-address
+ - '#address-cells'
+ - '#size-cells'
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ qspi: spi@ff705000 {
+ compatible = "cdns,qspi-nor";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0xff705000 0x1000>,
+ <0xffa00000 0x1000>;
+ interrupts = <0 151 4>;
+ clocks = <&qspi_clk>;
+ cdns,fifo-depth = <128>;
+ cdns,fifo-width = <4>;
+ cdns,trigger-address = <0x00000000>;
+ resets = <&rst 0x1>, <&rst 0x2>;
+ reset-names = "qspi", "qspi-ocp";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ };
+ };
--
2.30.0
From: Mark Brown <broonie@kernel.org> Date: 2021-03-31 19:12:33
On Fri, Mar 26, 2021 at 06:30:34PM +0530, Pratyush Yadav wrote:
From: Ramuthevar Vadivel Murugan <redacted>
There is no way as of now to have a parent or bus defining properties
for child nodes. For now, avoid it in the example to silence warnings on
dt_schema_check. We can figure out how to deal with actual dts files
later.
Please submit patches using subject lines reflecting the style for the
subsystem, this makes it easier for people to identify relevant patches.
Look at what existing commits in the area you're changing are doing and
make sure your subject lines visually resemble what they're doing.
There's no need to resubmit to fix this alone.
On Fri, Mar 26, 2021 at 06:30:34PM +0530, Pratyush Yadav wrote:
quoted
From: Ramuthevar Vadivel Murugan <redacted>
There is no way as of now to have a parent or bus defining properties
for child nodes. For now, avoid it in the example to silence warnings on
dt_schema_check. We can figure out how to deal with actual dts files
later.
Please submit patches using subject lines reflecting the style for the
subsystem, this makes it easier for people to identify relevant patches.
Look at what existing commits in the area you're changing are doing and
make sure your subject lines visually resemble what they're doing.
There's no need to resubmit to fix this alone.
I did take a look by running git log on
Documentation/devicetree/bindings/spi/ and there is no single style
being used. Using "dt-bindings: spi:" is a popular choice. Some other
commits just use "spi:". And then some use "spi: dt-bindings:". The last
commit to touch cadence-quadspi.txt (fcebca39938f) used the prefix
"dt-bindings: spi:".
So on the prefix front I think the subject is good enough. Of course, if
you have any other preference then it can be re-worded but let's first
be clear on what the expectation is. And then let's make sure to apply
it to all future patches uniformly. This way future contributors won't
have to take a guess on what the expected prefix is.
Apart from the prefix is there anything else to improve? IMHO the
subject is good enough but I'm open to suggestions.
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
+ cdns,fifo-depth:
+ description:
+ Size of the data FIFO in words.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 128, 256 ]
+ default: 128
+
+ cdns,fifo-width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Bus width of the data FIFO in bytes.
+ default: 4
I assume there's some constraints on this?
IIUC this is a matter of how the peripheral is implemented and there are
no clear constraints. Different implementations can use different bus
widths for the SRAM bus but I don't see any mention of minimum or
maximum values. FWIW, all users in the kernel use a 4 byte bus.
IMO a safe constraint would be to set a range of 1 to 4 (8/16/24/32 bit
wide) given this represents SRAM bus width. Binding can always be
updated if there exists an implementation with higher SRAM bus
width/fifo-width (although that's highly unlikely given there are no
such examples today).
But leaving it open ended with range of 0 to UINT_MAX sounds incorrect
to me.
quoted
With that,
Reviewed-by: Rob Herring <robh@kernel.org>
+ cdns,fifo-depth:
+ description:
+ Size of the data FIFO in words.
+ $ref: "/schemas/types.yaml#/definitions/uint32"
+ enum: [ 128, 256 ]
+ default: 128
+
+ cdns,fifo-width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Bus width of the data FIFO in bytes.
+ default: 4
I assume there's some constraints on this?
IIUC this is a matter of how the peripheral is implemented and there are
no clear constraints. Different implementations can use different bus
widths for the SRAM bus but I don't see any mention of minimum or
maximum values. FWIW, all users in the kernel use a 4 byte bus.
IMO a safe constraint would be to set a range of 1 to 4 (8/16/24/32 bit
wide) given this represents SRAM bus width. Binding can always be
updated if there exists an implementation with higher SRAM bus
width/fifo-width (although that's highly unlikely given there are no
such examples today).
But leaving it open ended with range of 0 to UINT_MAX sounds incorrect
to me.
Ok. Will respin.
quoted
quoted
With that,
Reviewed-by: Rob Herring <robh@kernel.org>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[4/4] dt-bindings: spi: Convert cadence-quadspi.txt to cadence-quadspi.yaml
commit: e54338004c032b0bb556c7a56db8688454b6587e
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
From: Mark Brown <broonie@kernel.org> Date: 2021-04-01 18:07:29
On Thu, Apr 01, 2021 at 01:09:32AM +0530, Pratyush Yadav wrote:
I did take a look by running git log on
Documentation/devicetree/bindings/spi/ and there is no single style
being used. Using "dt-bindings: spi:" is a popular choice. Some other
commits just use "spi:". And then some use "spi: dt-bindings:". The last
commit to touch cadence-quadspi.txt (fcebca39938f) used the prefix
"dt-bindings: spi:".
Yes, lots of people pick unfortunate subject lines for DT patches - that
doesn't mean it's good. I'm looking to see spi: same as for all other
SPI patches.
So on the prefix front I think the subject is good enough. Of course, if
you have any other preference then it can be re-worded but let's first
be clear on what the expectation is. And then let's make sure to apply
it to all future patches uniformly. This way future contributors won't
have to take a guess on what the expected prefix is.
I do edit some percentage of patches, but some do slip through for
various reasons. There's also some things that just get completely
missed, especially if there isn't also a code patch nearby.
Apart from the prefix is there anything else to improve? IMHO the
subject is good enough but I'm open to suggestions.
Hi Pratyush Yadav,
I have applied the following to branch ti-k3-dts-next on [1].
Thank you!
[1/4] arm64: dts: ti: k3-j721e-mcu: Fix ospi compatible
commit: f1b6f6e7f595ed66ba5f5d628df3d259218d584b
[2/4] arm64: dts: ti: k3-j7200-mcu: Fix ospi compatible
commit: 0e941f496a8bdc47d34199c17f81b09b0dbe14ae
[3/4] arm64: dts: ti: k3-am64-main: Fix ospi compatible
commit: 112e5934ff3a7505e583365213a27f990922b76b
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent up the chain during
the next merge window (or sooner if it is a relevant bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
[1] git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux.git
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
On Thu, Apr 01, 2021 at 01:09:32AM +0530, Pratyush Yadav wrote:
quoted
I did take a look by running git log on
Documentation/devicetree/bindings/spi/ and there is no single style
being used. Using "dt-bindings: spi:" is a popular choice. Some other
commits just use "spi:". And then some use "spi: dt-bindings:". The last
commit to touch cadence-quadspi.txt (fcebca39938f) used the prefix
"dt-bindings: spi:".
Yes, lots of people pick unfortunate subject lines for DT patches - that
doesn't mean it's good. I'm looking to see spi: same as for all other
SPI patches.
All right. "spi: dt-bindings:" it is from now on.
quoted
So on the prefix front I think the subject is good enough. Of course, if
you have any other preference then it can be re-worded but let's first
be clear on what the expectation is. And then let's make sure to apply
it to all future patches uniformly. This way future contributors won't
have to take a guess on what the expected prefix is.
I do edit some percentage of patches, but some do slip through for
various reasons. There's also some things that just get completely
missed, especially if there isn't also a code patch nearby.
quoted
Apart from the prefix is there anything else to improve? IMHO the
subject is good enough but I'm open to suggestions.
There was the thing with constraints.
Will send a follow up patch to add the constraints that Vignesh
suggested.
--
Regards,
Pratyush Yadav
Texas Instruments Inc.