Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 13 Jul 2023 17:17:15 +0200 (CEST)
From:   Richard Weinberger <richard@nod.at>
To:     Miquel Raynal <miquel.raynal@bootlin.com>
Cc:     Johan Jonker <jbx6244@gmail.com>,
        Vignesh Raghavendra <vigneshr@ti.com>, heiko@sntech.de,
        linux-mtd <linux-mtd@lists.infradead.org>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
        linux-rockchip@lists.infradead.org,
        yifeng zhao <yifeng.zhao@rock-chips.com>
Message-ID: <1618382560.2326931.1689261435022.JavaMail.zimbra@nod.at>
In-Reply-To: <20230712154142.3c49d782@xps-13>
References: <0047fc52-bc45-a768-8bdd-c0f12cddc17e@gmail.com> <457c1da7-61dc-2a56-4f86-47413795138c@gmail.com> <20230704171348.5eee98f7@xps-13> <3af40582-d350-8eac-8639-10c285964c49@gmail.com> <20230712154142.3c49d782@xps-13>
Subject: Re: [PATCH v3 3/3] mtd: rawnand: rockchip-nand-controller: add
 skipbbt option
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8BIT
Thread-Topic: rawnand: rockchip-nand-controller: add skipbbt option
Thread-Index: ROgfjDoY10Wn2JoZkeBFpS1VV4xmgg==
Precedence: bulk

----- Ursprüngliche Mail -----
> 
>> > For the boot I think I proposed a DT property. I don't remember how far
>> > the discussion went.
>> 
>> Is there a web link of that discussion?
> 
> https://lore.kernel.org/linux-mtd/20230609104426.3901df54@xps-13/
> 
> Maybe the term "DT property" did not appear but that's what I had in
> mind :-) I don't know if it must be a chip or a partition property.
> 
> Richard, here is where I would like your feedback, I am kind of opposed
> to a "skip_bbt" module parameter. It's not a strong opinion, if you
> think it's fine I'm open.
> 
> I would rather prefer a DT property which says "do not use the
> standard pattern".

Yes, please no new module parameters. A module parameter should only affect
the behavior of the driver itself (e.g. debug mode) but not be device specific.
We made this mistake in the past too often. :-(
A single driver can serve more devices. Therefore IMHO controlling this via DT
makes perfectly sense.

Thanks,
//richard