@@ -17,4 +17,5 @@ struct sharpsl_nand_platform_data {conststructmtd_ooblayout_ops*ecc_layout;structmtd_partition*partitions;unsignedintnr_partitions;+constchar*const*types;/* names of parsers to use if any */};
@@ -139,6 +139,7 @@ struct tmio_nand_data {structnand_bbt_descr*badblock_pattern;structmtd_partition*partition;unsignedintnum_partitions;+constchar*const*types;/* names of parsers to use if any */};#define FBIO_TMIO_ACC_WRITE 0x7C639300
From: Andrea Adami <hidden> Date: 2017-05-31 22:42:32
The Sharp SL Series (Zaurus) PXA handhelds have 16/64/128M of NAND flash
and share the same layout of the first 7M partition, managed by Sharp FTL.
The purpose of this self-contained patch is to add a common parser and
remove the hardcoded sizes in the board files (these devices are not yet
converted to devicetree).
Users will have benefits because the mtdparts= tag will not be necessary
anymore and they will be free to repartition the little sized flash.
The obsolete bootloader can not pass the partitioning info to modern
kernels anymore so it has to be read from flash at known logical addresses.
(see http://www.h5.dion.ne.jp/~rimemoon/zaurus/memo_006.htm )
In kernel, under arch/arm/mach-pxa we have already 8 machines:
MACH_POODLE, MACH_CORGI, MACH_SHEPERD, MACH_HUSKY, MACH_AKITA, MACH_SPITZ,
MACH_BORZOI, MACH_TOSA.
Lost after the 2.4 vendor kernel are MACH_BOXER and MACH_TERRIER.
Almost every model has different factory partitioning: add to this the
units can be repartitioned by users with userspace tools (nandlogical)
and installers for popular (back then) linux distributions.
The Parameter Area in the first (boot) partition extends from 0x00040000 to
0x0007bfff (176k) and contains two copies of the partition table:
...
0x00060000: Partition Info1 16k
0x00064000: Partition Info2 16k
0x00668000: Model 16k
...
The first 7M partition is managed by the Sharp FTL reserving 5% + 1 blocks
for wear-leveling: some blocks are remapped and one layer of translation
(logical to physical) is necessary.
There isn't much documentation about this FTL in the 2.4 sources, just the
MTD methods for reading and writing using logical addresses and the block
management (wear-leveling, use counter).
For the purpose of the MTD parser only the read part of the code was taken.
The NAND drivers that can use this parser are sharpsl.c and tmio_nand.c.
Signed-off-by: Andrea Adami <redacted>
---
drivers/mtd/Kconfig | 8 ++
drivers/mtd/Makefile | 2 +
drivers/mtd/sharpsl_ftl.c | 216 ++++++++++++++++++++++++++++++++++++++++++++++
drivers/mtd/sharpsl_ftl.h | 34 ++++++++
drivers/mtd/sharpslpart.c | 132 ++++++++++++++++++++++++++++
5 files changed, 392 insertions(+)
create mode 100644 drivers/mtd/sharpsl_ftl.c
create mode 100644 drivers/mtd/sharpsl_ftl.h
create mode 100644 drivers/mtd/sharpslpart.c
@@ -139,6 +139,7 @@ struct tmio_nand_data {structnand_bbt_descr*badblock_pattern;structmtd_partition*partition;unsignedintnum_partitions;+constchar*const*types;/* names of parsers to use if any */
Please use kerneldoc instead.
};
#define FBIO_TMIO_ACC_WRITE 0x7C639300
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
@@ -139,6 +139,7 @@ struct tmio_nand_data {structnand_bbt_descr*badblock_pattern;structmtd_partition*partition;unsignedintnum_partitions;+constchar*const*types;/* names of parsers to use if any */
Please use kerneldoc instead.
Thanks for the review.
tmio.h is not consistent and uses inline comments so I did not change the style.
Another round of patches will be necessary to sanitize the comments,
out of the scope of this little patchset.
Cheers
Andrea
quoted
};
#define FBIO_TMIO_ACC_WRITE 0x7C639300
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
@@ -139,6 +139,7 @@ struct tmio_nand_data {structnand_bbt_descr*badblock_pattern;structmtd_partition*partition;unsignedintnum_partitions;+constchar*const*types;/* names of parsers to use if any */
Please use kerneldoc instead.
Thanks for the review.
tmio.h is not consistent and uses inline comments so I did not change the style.
Another round of patches will be necessary to sanitize the comments,
out of the scope of this little patchset.
Will you do the work?
quoted
quoted
};
#define FBIO_TMIO_ACC_WRITE 0x7C639300
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
From: Brian Norris <computersforpeace@gmail.com> Date: 2017-06-09 01:30:57
Hi,
On Thu, Jun 01, 2017 at 12:40:50AM +0200, Andrea Adami wrote:
quoted hunk
The Sharp SL Series (Zaurus) PXA handhelds have 16/64/128M of NAND flash
and share the same layout of the first 7M partition, managed by Sharp FTL.
The purpose of this self-contained patch is to add a common parser and
remove the hardcoded sizes in the board files (these devices are not yet
converted to devicetree).
Users will have benefits because the mtdparts= tag will not be necessary
anymore and they will be free to repartition the little sized flash.
The obsolete bootloader can not pass the partitioning info to modern
kernels anymore so it has to be read from flash at known logical addresses.
(see http://www.h5.dion.ne.jp/~rimemoon/zaurus/memo_006.htm )
In kernel, under arch/arm/mach-pxa we have already 8 machines:
MACH_POODLE, MACH_CORGI, MACH_SHEPERD, MACH_HUSKY, MACH_AKITA, MACH_SPITZ,
MACH_BORZOI, MACH_TOSA.
Lost after the 2.4 vendor kernel are MACH_BOXER and MACH_TERRIER.
Almost every model has different factory partitioning: add to this the
units can be repartitioned by users with userspace tools (nandlogical)
and installers for popular (back then) linux distributions.
The Parameter Area in the first (boot) partition extends from 0x00040000 to
0x0007bfff (176k) and contains two copies of the partition table:
...
0x00060000: Partition Info1 16k
0x00064000: Partition Info2 16k
0x00668000: Model 16k
...
The first 7M partition is managed by the Sharp FTL reserving 5% + 1 blocks
for wear-leveling: some blocks are remapped and one layer of translation
(logical to physical) is necessary.
There isn't much documentation about this FTL in the 2.4 sources, just the
MTD methods for reading and writing using logical addresses and the block
management (wear-leveling, use counter).
For the purpose of the MTD parser only the read part of the code was taken.
The NAND drivers that can use this parser are sharpsl.c and tmio_nand.c.
Signed-off-by: Andrea Adami <redacted>
---
drivers/mtd/Kconfig | 8 ++
drivers/mtd/Makefile | 2 +
drivers/mtd/sharpsl_ftl.c | 216 ++++++++++++++++++++++++++++++++++++++++++++++
drivers/mtd/sharpsl_ftl.h | 34 ++++++++
drivers/mtd/sharpslpart.c | 132 ++++++++++++++++++++++++++++
5 files changed, 392 insertions(+)
create mode 100644 drivers/mtd/sharpsl_ftl.c
create mode 100644 drivers/mtd/sharpsl_ftl.h
create mode 100644 drivers/mtd/sharpslpart.c
+ help
+ This provides the read-only FTL logic necessary to read the partition
+ table from the NAND flash of Sharp SL Series (Zaurus) and the MTD
+ partition parser using this code.
+
comment "User Modules And Translation Layers"
#
Please do not use a static variable like this. References should be
dynamic.
Can the pointer just be passed back to the caller, and passed back to
the cleanup function when finished?
Related: do you foresee this parsing code being useful for anything
besides partitions? If not, then it seems like we should just merge the
"ftl" and "part" files. Not a requirement, but it might be cleaner.
These seems like a pretty weird form of error protection. IIUC, there
are just 3 copies of the 2-byte sequence number, and we take the first
pair that matches at least one of the others? Could use a comment above
the if/else block, to explain what the logic is. Or perhaps even some
comments at the top of the file, to roughly describe this FTL.
The 0-initialized kcalloc() is a little superfluous, since you reinit
here. I guess it's a matter of taste.
+
+ /* create physical-logical table */
+ for (block_num = 0; block_num < logical->phymax; block_num++) {
+ block_adr = block_num * mtd->erasesize;
+
+ if (mtd_block_isbad(mtd, block_adr))
+ continue;
+
+ readretry = 3;
+read_retry:
+ if (sharpsl_nand_read_oob(mtd, block_adr, mtd->oobsize, oob))
+ continue;
+
+ /* get logical block */
+ log_num = sharpsl_nand_get_logical_num(oob);
+
+ /* skip out of range and not unique values */
+ if ((int)log_num >= 0 && (log_num < logical->logmax)) {
Why the (int) cast? You should already be eliminating anything larger
than INT_MAX, because they'll be larger than logmax. You should only
need the second comparison.
What's the idea on the retries? Is this somehow supposed to make NAND
more reliable? That seems unlikely to work... Although notably, OOB is
often not covered by ECC, so maybe this is a really poor attempt at
making up for that?
Do you have any kind of validation logic, to ensure that this parser
actually matches? What if the flash was erased? Or what if somebody
managed to reformat to some other flash layout?
I suppose for many cases like that, the logical mapping will turn up
with a lot of UINT_MAX entries, and then sharpsl_nand_read_laddr() will
return -EINVAL? It'd be nice if there were some more clear sanity
checks though, if possible. Does this FTL have a header we should be
looking for?
+ if (sharpsl_nand_init_logical(master, SHARPSL_FTL_PARTITION_SIZE))
+ return -EINVAL;
+
+ /* read the two partition tables */
+ if (sharpsl_nand_read_laddr(master,
+ PARAM_BLOCK_PARTITIONINFO1,
+ sizeof(buf1), (u_char *)&buf1) ||
+ sharpsl_nand_read_laddr(master,
+ PARAM_BLOCK_PARTITIONINFO2,
+ sizeof(buf2), (u_char *)&buf2))
+ return -EINVAL;
You've failed to cleanup in the error case here:
sharpsl_nand_cleanup_logical()
Also, consider passing through the actual error code?
From: Brian Norris <computersforpeace@gmail.com> Date: 2017-06-09 01:35:28
On Thu, Jun 01, 2017 at 12:40:49AM +0200, Andrea Adami wrote:
This patchset introduces a simple partition parser for the Sharp SL
Series PXA handhelds. More details in the commit text.
I have set in cc the ARM PXA maintainers because this is the MTD part of
a planned wider patchset cleaning the Zaurus board files. The MFD maintainers
are also in cc (tmio.h change).
Changelog:
v1 initial import of 2.4 sources [1]
v2 refactor applying many suggested fixes [2]
v3 put the partition parser types in the platform data
[1] https://github.com/LinuxPDA/Sharp_FTL_2.4.20
[2] https://github.com/LinuxPDA/linux/commits/sharpslpart_v2
Andrea Adami (9):
mtd: sharpslpart: add sharpslpart MTD partition parser
mtd: nand: sharpsl.h: support partition parser types
mfd: nand: tmio.h: support partition parser types
mtd: nand: sharpsl.c: take in account partition parser types
mtd: nand: tmio_nand.c: take in account partition parser types
arm: pxa: corgi.c: remove hardcoded partitioning, use sharpslpart
parser
arm: pxa: tosa.c: remove hardcoded partitioning, use sharpslpart
parser
arm: pxa: spitz.c: remove hardcoded partitioning, use sharpslpart
parser
arm: pxa: poodle.c: remove hardcoded partitioning, use sharpslpart
parser
Barring my comments on patch 1 and Wolfram's comments on a few of the
others, for the whole series:
Reviewed-by: Brian Norris <computersforpeace@gmail.com>
Once things are fixed up, this should probably go through MTD.
Brian
I was going to ignore this earlier, but I just noticed that you handle
endianness for the magic values above, so...
shouldn't you handle endianness for the start and end fields too?
From: Andrea Adami <hidden> Date: 2017-06-20 08:52:59
Brian,
thanks for the review and for the unvaluable advices.
I have almost fixed the problems you spotted and I am almost ready to
send the new v4 of the patchset.
Some doubts are still present: I'll comment under your remarks:
On Fri, Jun 9, 2017 at 3:30 AM, Brian Norris
[off-list ref] wrote:
Hi,
On Thu, Jun 01, 2017 at 12:40:50AM +0200, Andrea Adami wrote:
quoted
The Sharp SL Series (Zaurus) PXA handhelds have 16/64/128M of NAND flash
and share the same layout of the first 7M partition, managed by Sharp FTL.
The purpose of this self-contained patch is to add a common parser and
remove the hardcoded sizes in the board files (these devices are not yet
converted to devicetree).
Users will have benefits because the mtdparts= tag will not be necessary
anymore and they will be free to repartition the little sized flash.
The obsolete bootloader can not pass the partitioning info to modern
kernels anymore so it has to be read from flash at known logical addresses.
(see http://www.h5.dion.ne.jp/~rimemoon/zaurus/memo_006.htm )
In kernel, under arch/arm/mach-pxa we have already 8 machines:
MACH_POODLE, MACH_CORGI, MACH_SHEPERD, MACH_HUSKY, MACH_AKITA, MACH_SPITZ,
MACH_BORZOI, MACH_TOSA.
Lost after the 2.4 vendor kernel are MACH_BOXER and MACH_TERRIER.
Almost every model has different factory partitioning: add to this the
units can be repartitioned by users with userspace tools (nandlogical)
and installers for popular (back then) linux distributions.
The Parameter Area in the first (boot) partition extends from 0x00040000 to
0x0007bfff (176k) and contains two copies of the partition table:
...
0x00060000: Partition Info1 16k
0x00064000: Partition Info2 16k
0x00668000: Model 16k
...
The first 7M partition is managed by the Sharp FTL reserving 5% + 1 blocks
for wear-leveling: some blocks are remapped and one layer of translation
(logical to physical) is necessary.
There isn't much documentation about this FTL in the 2.4 sources, just the
MTD methods for reading and writing using logical addresses and the block
management (wear-leveling, use counter).
For the purpose of the MTD parser only the read part of the code was taken.
The NAND drivers that can use this parser are sharpsl.c and tmio_nand.c.
Signed-off-by: Andrea Adami <redacted>
---
drivers/mtd/Kconfig | 8 ++
drivers/mtd/Makefile | 2 +
drivers/mtd/sharpsl_ftl.c | 216 ++++++++++++++++++++++++++++++++++++++++++++++
drivers/mtd/sharpsl_ftl.h | 34 ++++++++
drivers/mtd/sharpslpart.c | 132 ++++++++++++++++++++++++++++
5 files changed, 392 insertions(+)
create mode 100644 drivers/mtd/sharpsl_ftl.c
create mode 100644 drivers/mtd/sharpsl_ftl.h
create mode 100644 drivers/mtd/sharpslpart.c
+ help
+ This provides the read-only FTL logic necessary to read the partition
+ table from the NAND flash of Sharp SL Series (Zaurus) and the MTD
+ partition parser using this code.
+
comment "User Modules And Translation Layers"
#
Please do not use a static variable like this. References should be
dynamic.
Can the pointer just be passed back to the caller, and passed back to
the cleanup function when finished?
I'll fix this.
Related: do you foresee this parsing code being useful for anything
besides partitions? If not, then it seems like we should just merge the
"ftl" and "part" files. Not a requirement, but it might be cleaner.
I think it makes sense to merge back together.
It was earlier split to better expose the read-only FTL.
These seems like a pretty weird form of error protection. IIUC, there
are just 3 copies of the 2-byte sequence number, and we take the first
pair that matches at least one of the others? Could use a comment above
the if/else block, to explain what the logic is. Or perhaps even some
comments at the top of the file, to roughly describe this FTL.
I am sorry I don't know much about error correction.
No info, no comments in the 2.4 sources.
My tests did indeed show that only the first condition is matched
(good0=8 good1=9) so I'll retry and then I'll simplify the code..
+
+ /* create physical-logical table */
+ for (block_num = 0; block_num < logical->phymax; block_num++) {
+ block_adr = block_num * mtd->erasesize;
+
+ if (mtd_block_isbad(mtd, block_adr))
+ continue;
+
+ readretry = 3;
+read_retry:
+ if (sharpsl_nand_read_oob(mtd, block_adr, mtd->oobsize, oob))
+ continue;
+
+ /* get logical block */
+ log_num = sharpsl_nand_get_logical_num(oob);
+
+ /* skip out of range and not unique values */
+ if ((int)log_num >= 0 && (log_num < logical->logmax)) {
Why the (int) cast? You should already be eliminating anything larger
than INT_MAX, because they'll be larger than logmax. You should only
need the second comparison.
Fixed both.
The cast is another remnant of the (many) checks done in the old sources.
My bad I have let some superfluous code during conversion....
What's the idea on the retries? Is this somehow supposed to make NAND
more reliable? That seems unlikely to work... Although notably, OOB is
often not covered by ECC, so maybe this is a really poor attempt at
making up for that?
:)
Yes, it seems poor-man's solution but is indeed in the 2.4 sources.
Not needed (tested). Removed.
Do you have any kind of validation logic, to ensure that this parser
actually matches? What if the flash was erased? Or what if somebody
managed to reformat to some other flash layout?
The bootloader loads and launches the zImage1 found at a specific
logical address.
If mtd1 were invalid there would be no boot.
See, 10yrs ago there was an unofficial u-boot port for experienced users.
That was requiring to full-erase the nand, so removing the maintenance
and diag code
This would be the only case of modified partition layout I can think of.
I suppose for many cases like that, the logical mapping will turn up
with a lot of UINT_MAX entries, and then sharpsl_nand_read_laddr() will
return -EINVAL? It'd be nice if there were some more clear sanity
checks though, if possible. Does this FTL have a header we should be
looking for?
I was going to ignore this earlier, but I just noticed that you handle
endianness for the magic values above, so...
shouldn't you handle endianness for the start and end fields too?
quoted
+ u32 magic;
+ u32 reserved;
+};
[...]
Brian
Brian,
I have added a macro so to avoid to repeat le32_to_cpu() for each value.
This seems even to work as intended...
Note that the magics are 'texts' so they appear as BE.
Some more tests and I'll send v4 of the patch to your attention.
Thanks in advance.
Andrea
From: Brian Norris <computersforpeace@gmail.com> Date: 2017-06-20 22:05:36
Hi,
On Tue, Jun 20, 2017 at 10:52:44AM +0200, Andrea Adami wrote:
Brian,
thanks for the review and for the unvaluable advices.
I have almost fixed the problems you spotted and I am almost ready to
send the new v4 of the patchset.
Great!
Some doubts are still present: I'll comment under your remarks:
Perfect. I've trimmed, and responded to a few things. Let me know if you
hvae more questions.
On Fri, Jun 9, 2017 at 3:30 AM, Brian Norris
[off-list ref] wrote:
quoted
Hi,
On Thu, Jun 01, 2017 at 12:40:50AM +0200, Andrea Adami wrote:
quoted
The Sharp SL Series (Zaurus) PXA handhelds have 16/64/128M of NAND flash
and share the same layout of the first 7M partition, managed by Sharp FTL.
The purpose of this self-contained patch is to add a common parser and
remove the hardcoded sizes in the board files (these devices are not yet
converted to devicetree).
Users will have benefits because the mtdparts= tag will not be necessary
anymore and they will be free to repartition the little sized flash.
The obsolete bootloader can not pass the partitioning info to modern
kernels anymore so it has to be read from flash at known logical addresses.
(see http://www.h5.dion.ne.jp/~rimemoon/zaurus/memo_006.htm )
In kernel, under arch/arm/mach-pxa we have already 8 machines:
MACH_POODLE, MACH_CORGI, MACH_SHEPERD, MACH_HUSKY, MACH_AKITA, MACH_SPITZ,
MACH_BORZOI, MACH_TOSA.
Lost after the 2.4 vendor kernel are MACH_BOXER and MACH_TERRIER.
Almost every model has different factory partitioning: add to this the
units can be repartitioned by users with userspace tools (nandlogical)
and installers for popular (back then) linux distributions.
The Parameter Area in the first (boot) partition extends from 0x00040000 to
0x0007bfff (176k) and contains two copies of the partition table:
...
0x00060000: Partition Info1 16k
0x00064000: Partition Info2 16k
0x00668000: Model 16k
...
The first 7M partition is managed by the Sharp FTL reserving 5% + 1 blocks
for wear-leveling: some blocks are remapped and one layer of translation
(logical to physical) is necessary.
There isn't much documentation about this FTL in the 2.4 sources, just the
MTD methods for reading and writing using logical addresses and the block
management (wear-leveling, use counter).
For the purpose of the MTD parser only the read part of the code was taken.
The NAND drivers that can use this parser are sharpsl.c and tmio_nand.c.
Signed-off-by: Andrea Adami <redacted>
---
drivers/mtd/Kconfig | 8 ++
drivers/mtd/Makefile | 2 +
drivers/mtd/sharpsl_ftl.c | 216 ++++++++++++++++++++++++++++++++++++++++++++++
drivers/mtd/sharpsl_ftl.h | 34 ++++++++
drivers/mtd/sharpslpart.c | 132 ++++++++++++++++++++++++++++
5 files changed, 392 insertions(+)
create mode 100644 drivers/mtd/sharpsl_ftl.c
create mode 100644 drivers/mtd/sharpsl_ftl.h
create mode 100644 drivers/mtd/sharpslpart.c
These seems like a pretty weird form of error protection. IIUC, there
are just 3 copies of the 2-byte sequence number, and we take the first
pair that matches at least one of the others? Could use a comment above
the if/else block, to explain what the logic is. Or perhaps even some
comments at the top of the file, to roughly describe this FTL.
I am sorry I don't know much about error correction.
No info, no comments in the 2.4 sources.
My tests did indeed show that only the first condition is matched
(good0=8 good1=9) so I'll retry and then I'll simplify the code..
I don't think removing the secondary conditions above is a good idea; it
seems to provide some value as a backup, in case of (for example)
bitflips in the OOB. I was just commenting that it was a little strange,
and that it might be good to write up a comment based on our
understanding of this OOB header format. Either text, or some small
ASCII art. (Along the lines of "logical block number assigned to a
physical block is stored in OOB of the first page, in 3 16-bit copies
layed out as <foo>; in case of errors, we check that a 2 or more of
these copies agree. Reserved values <bar> mean <blah>.")
IOW, your job isn't just to prune down the vendor's code, but to make it
cleaner and clearer to the reader/reviewer.
...
quoted
quoted
+
+ /* create physical-logical table */
+ for (block_num = 0; block_num < logical->phymax; block_num++) {
+ block_adr = block_num * mtd->erasesize;
+
+ if (mtd_block_isbad(mtd, block_adr))
+ continue;
+
+ readretry = 3;
+read_retry:
+ if (sharpsl_nand_read_oob(mtd, block_adr, mtd->oobsize, oob))
+ continue;
+
+ /* get logical block */
+ log_num = sharpsl_nand_get_logical_num(oob);
+
+ /* skip out of range and not unique values */
+ if ((int)log_num >= 0 && (log_num < logical->logmax)) {
What's the idea on the retries? Is this somehow supposed to make NAND
more reliable? That seems unlikely to work... Although notably, OOB is
often not covered by ECC, so maybe this is a really poor attempt at
making up for that?
:)
Yes, it seems poor-man's solution but is indeed in the 2.4 sources.
Not needed (tested). Removed.
Caveat: a simple test of one or a few device(s) is not exactly
verification that this wasn't useful at all, but given we can't figure
out a proper reason for it, removing it seems prudent.
What about ret == -EUCLEAN? Do you want to handle corrected bitflips?
I have changed the checks here and have taken the code of mtdtest_read()
so to ignorer bitflips and pass the error through.
Yes, I suppose that is a fine pattern. You can't really do anything
about high numbers of bitflilps, unless you really want to add in write
support (in which case you could probably try to copy/migrate the table
to an available block).
Do you have any kind of validation logic, to ensure that this parser
actually matches? What if the flash was erased? Or what if somebody
managed to reformat to some other flash layout?
The bootloader loads and launches the zImage1 found at a specific
logical address.
If mtd1 were invalid there would be no boot.
See, 10yrs ago there was an unofficial u-boot port for experienced users.
That was requiring to full-erase the nand, so removing the maintenance
and diag code
This would be the only case of modified partition layout I can think of.
My point wasn't really just for well-handled devices, or even Sharp
devices at all. What if this partition parser ends up in the parser list
for some other random device? e.g., when we add better device tree
support for other parsers, it'll start becoming easier for arbitrary
platforms to utilize arbitrary parsers; I wouldn't expect people to want
to use this parser, but if we have a quick way to say "this doesn't
match, skip me", then that would be helpful.
Or maybe another case: what if someone utilizes some completely
different partition layout (and gets their bootloader to handle it) but
is still otherwise using the same kernel/platform support? We don't want
to waste too much time scanning for this partition table if possible.
quoted
I suppose for many cases like that, the logical mapping will turn up
with a lot of UINT_MAX entries, and then sharpsl_nand_read_laddr() will
return -EINVAL? It'd be nice if there were some more clear sanity
checks though, if possible. Does this FTL have a header we should be
looking for?