Re: Adding subpage support to NAND driver -- backwards compatibility concerns

[Richard Weinberger]

Am 24.04.2015 um 01:13 schrieb Iwo Mergler:
> On Fri, 24 Apr 2015 05:30:55 +1000
> Richard Weinberger <richard@xxxxxx> wrote:
> 
>> Am 23.04.2015 um 20:39 schrieb Josh Cartwright:
> 
>>> Is there no metadata in the UBI data structures in flash that
>>> indicate the min IO boundary?  Assuming no, is another option to,
>>> at the time of attach, try both the min IO access size, and, if
>>> that doesn't work, try the page size?
>>
>> Correct. UBI has no information about that.
>> If you add subpage support to the driver I'd make it opt-in such that
>> existing setups won't break.
> 
> I'm wondering, given that EC headers contain vid header offset
> and data offset fields, shouldn't UBI be able to deduce at attach
> time what the relevant parameters are on a partition?

UBI double checks that offset. If the vid header offset does not
match the run-time computed offset UBI will detect that in
validate_ec_hdr().

So, yes it could automatically deduce it at attach time but it does not
for safety reasons. UBI computes the values from the data provided by
the MTD, if the image does not match it stops.
If it would blindly trust the image it could happen that you operate on your
MTD with a wrong page size.

> Something along the lines of using the parameters of the first
> PEB with valid EC header, then balking if another EC header is
> encountered with different info. As long as MTD allows the
> so deduced minimum access size, it seems safe.
> 
> This could help enormously in situations like this, where
> MTD drivers experience sudden bursts of improvement.

Agreed. UBI could be more intelligent. If UBI can be sure that
the parameters deduced from the on-flash image are safe with
respect to the parameters provided by MTD it could continue.

Maybe Artem can give us more details on that as he designed it.

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/