On Mon, May 12, 2014 at 04:18:41PM -0300, Ezequiel Garcia wrote: > On 12 May 11:01 AM, Brian Norris wrote: > > On Fri, Mar 21, 2014 at 08:34:49AM -0300, Ezequiel Garcia wrote: > > > Also, if there is an ONFI-specified minimum ECC strength requirement, > > > and the DT-specified ECC strength is weaker, print a warning and try to > > > select a strength compatible with the ONFI requirement. > > > > Are you sure you want to override? That seems contrary to the idea of a > > DT property for specifying ECC. But maybe you have a good reason? > > > > Actually, on IRC discussions you enforced the idea that the kernel shouldn't > allow a weaker ECC strength than the datasheet (ONFI or ID table) specified. > Hence, following your request, the implementation considers such devicetree > setting as illegal and tries to find another one. Hmm, I don't recall saying that exactly, although I might have said something similar that could have been misconstrued as such. I mostly recall discussing setting the ECC strength *without* device tree (as pxa3xx_nand currently does), which is a different case, since we don't have any outside input. But anyway... > > If you'd rather just warn the user, it's possible we could move that to > > common code in nand_base.c. > > > > Now that you mention this, I think you're right: it's very stupid to try to > match an ECC scheme, different from the requested. > > So, we either just warn the user (nosily) or we fail to probe the driver. > If you ask me, I'd say let's just WARN() and let the user take the blame. ...yes, I (regardless of what "IRC Brian" said!) think that is the correct approach when given an ECC scheme via device-tree. We should honor it, and blame the user loudly. Brian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
