Re: [PATCH for-4.5 v2] mtd: nand: assign reasonable default name for NAND drivers

From: Brian Norris
Date: Wed Jan 06 2016 - 17:53:46 EST


On Tue, Jan 05, 2016 at 10:39:45AM -0800, Brian Norris wrote:
> Commits such as commit 853f1c58c4b2 ("mtd: nand: omap2: show parent
> device structure in sysfs") attempt to rely on the core MTD code to set
> the MTD name based on the parent device. However, nand_base tries to set
> a different default name according to the flash name (e.g., extracted
> from the ONFI parameter page), which means NAND drivers will never make
> use of the MTD defaults. This is not the intention of commit
> 853f1c58c4b2.
>
> This results in problems when trying to use the cmdline partition
> parser, since the MTD name is different than expected. Let's fix this by
> providing a default NAND name, where possible.
>
> Note that this is not really a great default name in the long run, since
> this means that if there are multiple MTDs attached to the same
> controller device, they will have the same name. But that is an existing
> issue and requires future work on a better controller vs. flash chip
> abstraction to fix properly.
>
> Fixes: 853f1c58c4b2 ("mtd: nand: omap2: show parent device structure in sysfs")
> Reported-by: Heiko Schocher <hs@xxxxxxx>
> Signed-off-by: Brian Norris <computersforpeace@xxxxxxxxx>
> Reviewed-by: Boris Brezillon <boris.brezillon@xxxxxxxxxxxxxxxxxx>
> Tested-by: Heiko Schocher <hs@xxxxxxx>
> Cc: Heiko Schocher <hs@xxxxxxx>
> Cc: Frans Klaver <fransklaver@xxxxxxxxx>
> Cc: <stable@xxxxxxxxxxxxxxx>
> ---
> v2:
> * target 4.5, as 4.4 is getting late
> * add -stable tags
> * move assignment directly into nand_scan_ident() (nand_set_defaults() has a
> slightly different purpose and gets reused, so it's not as good of a
> candidate)

Applied to l2-mtd.git, for 4.5 (+ stable)
--
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/