[PATCH 1/2] mtd: move code reading DT specified part probes to the common place

[Boris Brezillon]

On Fri, 31 Mar 2017 09:42:13 +0200
Boris Brezillon <boris.brezillon at free-electrons.com> wrote:

> Hi Rafal,
> 
> On Thu, 30 Mar 2017 23:53:31 +0200
> Rafał Miłecki <zajec5 at gmail.com> wrote:
> 
> > From: Rafał Miłecki <rafal at milecki.pl>
> > 
> > Handling (creating) partitions for flash devices requires using a proper
> > driver that will read partition table (out of somewhere). We can't
> > simply try all existing drivers one by one, so MTD subsystem allows
> > drivers to specify a list of applicable part probes.
> > 
> > So far physmap_of was the only driver with support for linux,part-probe
> > DT property. Other ones had list or probes hardcoded which wasn't making
> > them really flexible. It prevented using common flash drivers on
> > platforms that required some specific partition table access.  
> 
> I agree that having each flash device driver specify the set of
> partition parsers it supports is a bad idea (most of the time,
> partition table format are devicetype agnostic). On the other hand, I'm
> not a big fan of this property, and I would prefer a solution where all
> parsers are tested on each MTD device.
> But testing all parsers sequentially is not a perfect solution either
> because it increases boot-time and you can't really define the order in
> which partition parsers are tested (which means that if you have 2
> different partition table in 2 different format, you can't choose the
> one that has precedence on the other).
> 
> I guess I can live with this "linux,part-probe" property, even if,
> as the names implies, it's not really describing hardware, and as
> such, does not have its place in DT :-P.
> 
> > 
> > This commit moves support for mentioned DT property to the common place
> > so it can be reused by other drivers.  
> 
> This property does not seem to be documented. Can you add a patch
> documenting it in Documentation/devicetree/bindings/mtd/common.txt and
> Cc the DT maintainers.

Please ignore this comment, it's already done in patch 2 :).

> Only then we'll see if this property is
> acceptable for them.
>