[PATCH v4] mtd: super: don't rely on mtdblock device minor

[Christoph Hellwig]

On Tue, May 11, 2021 at 09:17:23PM +0100, Daniel Golle wrote:
> IDE with it's 10 majors and a huge load of legacy code involved doesn't
> seem to be the prime example... I generally find *_MAJOR being
> hard-coded via pre-compiler macros and actually quite a lot of code
> seems to make assumptions about the backing driver based on the device
> major number used.

Nothing with many majors.  There are valid (but obscure) use cases
where a (new or niche) drivers wants to impersonate an old one.  And
the infrastructure allows for that.  So guessing from a major number
to a format of private data is absolutely dangerous in the long run
even if it works for trivial setups.

> Anyway, as the same shortcomming (assuming MTD_BLOCK_MAJOR is only used
> by mtdblock driver) also affects the existing code and I'm not aware
> of any other way to check the backing driver, I guess dropping that
> legacy hack is indeed the only good option left.
> 
> MTD folks: please advise if you agree that this would be the way
> forward to clean up things for part_bits != 1 to work.

So why do we even depend on the block device code for the legacy
name lookup?  Can't we just remove lookup_bdev entirely and just parse
the /dev/mtdblock name here directly without any sort of detour?