[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <59e420fd-afb1-ab4c-44bd-ead160496bfd@gmail.com>
Date: Mon, 5 Dec 2016 17:11:36 +0100
From: Marek Vasut <marek.vasut@...il.com>
To: Boris Brezillon <boris.brezillon@...e-electrons.com>
Cc: Punnaiah Choudary Kalluri <punnaiah.choudary.kalluri@...inx.com>,
dwmw2@...radead.org, computersforpeace@...il.com, richard@....at,
cyrille.pitchen@...el.com, robh+dt@...nel.org,
mark.rutland@....com, linux-kernel@...r.kernel.org,
linux-mtd@...ts.infradead.org, devicetree@...r.kernel.org,
michals@...inx.com, kalluripunnaiahchoudary@...il.com,
kpc528@...il.com, Punnaiah Choudary Kalluri <punnaia@...inx.com>
Subject: Re: [PATCH v6 1/2] mtd: arasan: Add device tree binding documentation
On 12/05/2016 09:36 AM, Boris Brezillon wrote:
> On Mon, 5 Dec 2016 05:25:54 +0100
> Marek Vasut <marek.vasut@...il.com> wrote:
>
>> On 12/05/2016 05:11 AM, Punnaiah Choudary Kalluri wrote:
>>> This patch adds the dts binding document for arasan nand flash
>>> controller.
>>>
>>> Signed-off-by: Punnaiah Choudary Kalluri <punnaia@...inx.com>
>>> Acked-by: Rob Herring <robh@...nel.org>
>>> ---
>>> changes in v6:
>>> - Removed num-cs property
>>> - Separated nandchip from nand controller
>>> changes in v5:
>>> - None
>>> Changes in v4:
>>> - Added num-cs property
>>> - Added clock support
>>> Changes in v3:
>>> - None
>>> Changes in v2:
>>> - None
>>> ---
>>> .../devicetree/bindings/mtd/arasan_nfc.txt | 38 ++++++++++++++++++++++
>>> 1 file changed, 38 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/mtd/arasan_nfc.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/mtd/arasan_nfc.txt b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
>>> new file mode 100644
>>> index 0000000..dcbe7ad
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/mtd/arasan_nfc.txt
>>> @@ -0,0 +1,38 @@
>>> +Arasan Nand Flash Controller with ONFI 3.1 support
>>
>> Arasan NAND Flash ...
>>
>>> +Required properties:
>>> +- compatible: Should be "arasan,nfc-v3p10"
>>
>> This v3p10 looks like version 3 patchlevel 10, but shouldn't we have
>> some fallback option which doesn't encode IP version in the compat
>> string ?
>
> Not necessarily. Usually you define a generic compatible when you have
> other reliable means to detect the IP version (a version register for
> example).
> If you can't detect that at runtime, then providing only specific
> compatible strings is a good solution to avoid breaking the DT ABI.
Can we detect it at runtime with this hardware ?
>>
>> Also, shouldn't quirks be handled by DT props instead of effectively
>> encoding them into the compatible string ?
>
> Well, from my experience, it's better to hide as much as possible
> behind the compatible. This way, if new quirks are needed for a
> specific revision, you can update the driver without having to change
> the DT.
That's a good point, yes.
--
Best regards,
Marek Vasut
Powered by blists - more mailing lists