[RFCv2: PATCH 1/2] mtd: mediatek: device tree docs for MTK Smart Device Gen1 NAND

[Jorge Ramirez-Ortiz]

On 03/29/2016 03:58 AM, Boris Brezillon wrote:
> On Sat, 26 Mar 2016 14:38:31 -0400
> Jorge Ramirez-Ortiz <jorge.ramirez-ortiz at linaro.org> wrote:
>
>> On 03/22/2016 09:52 AM, Boris Brezillon wrote:
>>>>> +		compatible = "mediatek,mt2701-nfc";
>>>>> +		reg = <0 0x1100d000 0 0x1000>;
>>>>> +		interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_LOW>;
>>>>> +		clocks = <&pericfg CLK_PERI_NFI>,
>>>>> +			 <&pericfg CLK_PERI_NFI_PAD>;
>>>>> +		clock-names = "nfi_clk", "pad_clk";
>>>>> +		nand-on-flash-bbt;
>>>>> +		status = "disabled";
>>>>> +		mediatek,ecc-controller = <&bch>;
>>> Now that 2 different drivers use the same way to link the ECC engine
>>> and the NAND controller we can think about defining a generic property
>>> (ecc-engine ?), and provide a generic framework.
>>>
>>> The generic framework part is not something I'm asking right now, but I
>>> think we should start using a generic property here.
>>>
>> we have done all the changes required for v3 except this one.
>> so please let me check my understanding before going ahead: are you suggesting
>> that we replace "mediatek,ecc-controller" for "ecc-engine" (even though this
>> generic property doesn't exist yet)?
>>
>> and then afterwards, generate another patch-set set to define and document
>> "ecc-engine"?
> Yes, that's the idea, though the NAND controller aspect is not yet
> documented in Documentation/devicetree/bindings/mtd/nand.txt, and
> ecc-engine is supposed to be attached to the NAND controller node.
>
> I'll send a patch to further document the NAND chip, NAND controller
> description concepts in this generic NAND DT bindings doc (as suggested
> by Brian), and let you document this ecc-engine property.
>

ok I'll hold v3 -we have it ready already- until we have done this bit
(hopefully it wont take long).


>