From: William Zhang <william.zhang@broadcom.com>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Broadcom Kernel List <bcm-kernel-feedback-list@broadcom.com>,
Linux MTD List <linux-mtd@lists.infradead.org>,
f.fainelli@gmail.com, rafal@milecki.pl, kursad.oney@broadcom.com,
joel.peshkin@broadcom.com, computersforpeace@gmail.com,
anand.gore@broadcom.com, dregan@mail.com,
kamal.dasu@broadcom.com, tomer.yacoby@broadcom.com,
dan.beygelman@broadcom.com, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Vignesh Raghavendra <vigneshr@ti.com>,
Richard Weinberger <richard@nod.at>,
Kamal Dasu <kdasu.kdev@gmail.com>,
Rob Herring <robh+dt@kernel.org>
Subject: Re: [PATCH 05/12] dt-bindings: mtd: brcmnand: Updates for bcmbca SoCs
Date: Wed, 7 Jun 2023 13:01:56 -0700 [thread overview]
Message-ID: <84e97108-29d4-5103-14f4-03e3c0eba165@broadcom.com> (raw)
In-Reply-To: <20230607101452.4c265d7e@xps-13>
[-- Attachment #1: Type: text/plain, Size: 7620 bytes --]
Hi Miquel,
On 06/07/2023 01:14 AM, Miquel Raynal wrote:
> Hi William,
>
> william.zhang@broadcom.com wrote on Tue, 6 Jun 2023 16:12:45 -0700:
>
>> Use new compatiable brcm,nand-bcmbca to support BCMBCA broadband
>> product. The old compatible string is still kept in the driver so old
>> dtb can still work.
>>
>> Add brcm,nand-use-wp property to have an option for disabling this
>> feature on broadband board design that does not use write protection.
>> Add brcm,nand-ecc-use-strap to get ecc setting from board strap for
>> broadband board designs because they do not specify ecc setting in dts
>> but rather using the strap setting.
>>
>> Remove the requirement of interrupts and interrupt-names properties to
>> reflect the driver code.
>>
>> This patch also includes a few minor fixes to the BCM63xx compatibles
>> and add myself to the list of maintainers.
>>
>> Signed-off-by: William Zhang <william.zhang@broadcom.com>
>> ---
>>
>> .../bindings/mtd/brcm,brcmnand.yaml | 64 +++++++++++++------
>> 1 file changed, 43 insertions(+), 21 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml
>> index 1571024aa119..1fe1c166a9db 100644
>> --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml
>> +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml
>> @@ -9,6 +9,7 @@ title: Broadcom STB NAND Controller
>> maintainers:
>> - Brian Norris <computersforpeace@gmail.com>
>> - Kamal Dasu <kdasu.kdev@gmail.com>
>> + - William Zhang <william.zhang@broadcom.com>
>>
>> description: |
>> The Broadcom Set-Top Box NAND controller supports low-level access to raw NAND
>> @@ -18,9 +19,10 @@ description: |
>> supports basic PROGRAM and READ functions, among other features.
>>
>> This controller was originally designed for STB SoCs (BCM7xxx) but is now
>> - available on a variety of Broadcom SoCs, including some BCM3xxx, BCM63xx, and
>> - iProc/Cygnus. Its history includes several similar (but not fully register
>> - compatible) versions.
>> + available on a variety of Broadcom SoCs, including some BCM3xxx, MIPS based
>> + Broadband SoC (BCM63xx), ARM based Broadband SoC (BCMBCA) and iProc/Cygnus.
>> + Its history includes several similar (but not fully register compatible)
>> + versions.
>>
>> -- Additional SoC-specific NAND controller properties --
>>
>> @@ -53,9 +55,9 @@ properties:
>> - brcm,brcmnand-v7.2
>> - brcm,brcmnand-v7.3
>> - const: brcm,brcmnand
>> - - description: BCM63138 SoC-specific NAND controller
>> + - description: BCMBCA SoC-specific NAND controller
>> items:
>> - - const: brcm,nand-bcm63138
>> + - const: brcm,nand-bcmbca
>> - enum:
>> - brcm,brcmnand-v7.0
>> - brcm,brcmnand-v7.1
>> @@ -65,11 +67,15 @@ properties:
>> - const: brcm,nand-iproc
>> - const: brcm,brcmnand-v6.1
>> - const: brcm,brcmnand
>> - - description: BCM63168 SoC-specific NAND controller
>> + - description: BCM63xx SoC-specific NAND controller
>> items:
>> - - const: brcm,nand-bcm63168
>> - - const: brcm,nand-bcm6368
>> - - const: brcm,brcmnand-v4.0
>> + - enum:
>> + - brcm,nand-bcm63168
>> + - brcm,nand-bcm6368
>> + - enum:
>> + - brcm,brcmnand-v2.1
>> + - brcm,brcmnand-v2.2
>> + - brcm,brcmnand-v4.0
>> - const: brcm,brcmnand
>>
>> reg:
>> @@ -111,6 +117,19 @@ properties:
>> earlier versions of this core that include WP
>> type: boolean
>>
>> + brcm,nand-use-wp:
>> + description:
>> + Use this integer to indicate if board design uses
>> + controller's write protection feature and connects its
>> + NAND_WPb pin to nand chip's WP_L pin. Driver defaults to
>> + use this feature when this property does not exist.
>> + Set to 0 if WP pins are not connected and feature is not
>> + used. Set to 1 if WP pins are connected and feature is used.
>> + Set to 2 if WP pins are connected but disable this feature
>> + through driver that sets controller to output high on NAND_WPb.
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + enum: [0, 1, 2]
>
> Perhaps strings would be welcome. I'll let binding maintainers say what
> they think of it.
>
Practically there is really just use cases of 0 and 1. I could use a
bool flag but to keep consistent with the driver code and in case there
is any existing usage of 2.
>> +
>> patternProperties:
>> "^nand@[a-f0-9]$":
>> type: object
>> @@ -136,13 +155,23 @@ patternProperties:
>> layout.
>> $ref: /schemas/types.yaml#/definitions/uint32
>>
>> + brcm,nand-ecc-use-strap:
>> + description:
>> + This flag is used by the driver to get the ecc strength and
>> + spare area size from the SoC NAND boot strap setting. This
>> + is commonly used by the BCMBCA SoC board design. If ecc
>> + strength and spare area size are set by nand-ecc-strength
>> + and brcm,nand-oob-sector-size in the dts, these settings
>> + have precedence and override this flag.
>> + $ref: /schemas/types.yaml#/definitions/flag
>
> How in practice do you access the strap value? Don't you need a phandle
> over a specific area in the SoC?
>
The strap value is latched and stored in the NAND controller register so
there is no extra phandle needed.
>> +
>> allOf:
>> - $ref: nand-controller.yaml#
>> - if:
>> properties:
>> compatible:
>> contains:
>> - const: brcm,nand-bcm63138
>> + const: brcm,nand-bcmbca
>> then:
>> properties:
>> reg-names:
>> @@ -153,7 +182,9 @@ allOf:
>> properties:
>> compatible:
>> contains:
>> - const: brcm,nand-bcm6368
>> + enum:
>> + - brcm,nand-bcm63168
>> + - brcm,nand-bcm6368
>> then:
>> properties:
>> reg-names:
>> @@ -173,20 +204,12 @@ allOf:
>> - const: nand
>> - const: iproc-idm
>> - const: iproc-ext
>> - - if:
>> - properties:
>> - interrupts:
>> - minItems: 2
>> - then:
>> - required:
>> - - interrupt-names
>
> Why do you remove this? Removing "interrupts" from the required
> properties is fine, but constraining the interrupts property when it is
> relevant is still expected.
>
There is no requirement for interrupt name even if it have two
interrupts. Driver code does not use interrupt name but the interrupt
index instead.
>>
>> unevaluatedProperties: false
>>
>> required:
>> - reg
>> - reg-names
>> - - interrupts
>
> This should be done in a separate patch.
>
I thought this is also related to my update for bcmbca chips because
they don't need to interrupt and interrupt name.
>>
>> examples:
>> - |
>> @@ -215,8 +238,7 @@ examples:
>> };
>> - |
>> nand-controller@10000200 {
>> - compatible = "brcm,nand-bcm63168", "brcm,nand-bcm6368",
>> - "brcm,brcmnand-v4.0", "brcm,brcmnand";
>> + compatible = "brcm,nand-bcm6368", "brcm,brcmnand-v2.1", "brcm,brcmnand";
>> reg = <0x10000200 0x180>,
>> <0x100000b0 0x10>,
>> <0x10000600 0x200>;
>
>
> Thanks,
> Miquèl
>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4212 bytes --]
next prev parent reply other threads:[~2023-06-07 20:02 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-06 23:12 [PATCH 00/12] mtd: rawnand: brcmnand: driver and doc updates William Zhang
2023-06-06 23:12 ` [PATCH 01/12] mtd: rawnand: brcmnand: Fix ECC level field setting for v7.2 controller William Zhang
2023-06-07 8:06 ` Miquel Raynal
2023-06-06 23:12 ` [PATCH 02/12] mtd: rawnand: brcmnand: Fix potential false time out warning William Zhang
2023-06-06 23:12 ` [PATCH 03/12] mtd: rawnand: brcmnand: Fix crash during the panic_write William Zhang
2023-06-06 23:12 ` [PATCH 04/12] mtd: rawnand: brcmnand: Fix potential out-of-bounds access in oob write William Zhang
2023-06-07 8:09 ` Miquel Raynal
2023-06-06 23:12 ` [PATCH 05/12] dt-bindings: mtd: brcmnand: Updates for bcmbca SoCs William Zhang
2023-06-07 8:14 ` Miquel Raynal
2023-06-07 20:01 ` William Zhang [this message]
2023-06-09 8:58 ` Miquel Raynal
2023-06-09 19:05 ` William Zhang
2023-06-12 17:43 ` Miquel Raynal
2023-06-14 22:46 ` Rob Herring
2023-06-15 0:40 ` William Zhang
2023-06-14 22:43 ` Rob Herring
2023-06-15 0:28 ` William Zhang
2023-06-06 23:12 ` [PATCH 06/12] ARM: dts: broadcom: bcmbca: Add NAND controller node William Zhang
2023-06-06 23:12 ` [PATCH 07/12] arm64: " William Zhang
2023-06-06 23:12 ` [PATCH 08/12] mtd: rawnand: brcmnand: Rename bcm63138 nand driver William Zhang
2023-06-06 23:12 ` [PATCH 09/12] mtd: rawnand: brcmnand: Add new compatible string William Zhang
2023-06-06 23:12 ` [PATCH 10/12] mtd: rawnand: brcmnand: Add BCMBCA read data bus interface William Zhang
2023-06-07 8:20 ` Miquel Raynal
2023-06-07 20:12 ` William Zhang
2023-06-08 6:15 ` Miquel Raynal
2023-06-08 19:04 ` William Zhang
2023-06-07 8:22 ` Miquel Raynal
2023-06-07 20:24 ` William Zhang
2023-06-08 6:18 ` Miquel Raynal
2023-06-08 19:10 ` William Zhang
2023-06-09 8:35 ` Miquel Raynal
2023-06-09 19:16 ` William Zhang
2023-06-12 17:49 ` Miquel Raynal
2023-06-12 17:53 ` Miquel Raynal
2023-06-12 19:18 ` William Zhang
2023-06-13 6:42 ` Miquel Raynal
2023-06-14 0:00 ` William Zhang
2023-06-14 6:22 ` Miquel Raynal
2023-06-14 23:52 ` William Zhang
2023-06-12 19:03 ` William Zhang
2023-06-11 9:54 ` kernel test robot
2023-06-06 23:12 ` [PATCH 11/12] mtd: rawnand: brcmnand: Add support for getting ecc setting from strap William Zhang
2023-06-07 8:25 ` Miquel Raynal
2023-06-06 23:12 ` [PATCH 12/12] mtd: rawnand: brcmnand: Support write protection setting from dts William Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=84e97108-29d4-5103-14f4-03e3c0eba165@broadcom.com \
--to=william.zhang@broadcom.com \
--cc=anand.gore@broadcom.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=computersforpeace@gmail.com \
--cc=dan.beygelman@broadcom.com \
--cc=devicetree@vger.kernel.org \
--cc=dregan@mail.com \
--cc=f.fainelli@gmail.com \
--cc=joel.peshkin@broadcom.com \
--cc=kamal.dasu@broadcom.com \
--cc=kdasu.kdev@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kursad.oney@broadcom.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=rafal@milecki.pl \
--cc=richard@nod.at \
--cc=robh+dt@kernel.org \
--cc=tomer.yacoby@broadcom.com \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).