[RFC] mtd: virt-concat: define duplicate partition handling

[Pengpeng Hou <pengpeng@iscas.ac.cn>]

mtd_device_parse_register() contains compatibility handling for drivers that
call it more than once, while its comment notes that partition parsing can
register the same partitions again.

When CONFIG_MTD_PARTITIONED_MASTER is disabled and the first call finds
partitions, the master itself is not registered before parsing. A later call
can therefore reach partition parsing again.

With CONFIG_MTD_VIRT_CONCAT, each newly allocated partition whose OF node
belongs to a virtual concatenation reaches mtd_virt_concat_add(). That
function appends the partition based only on the OF node and increments
num_subdev without checking whether the node was already added or whether
the fixed subdev[] array is full.

A repeated parse can therefore append the same node again. If all configured
slots were already populated, the append is out of bounds. If other members
are still missing, the duplicate can make num_subdev reach the configured
count with the wrong membership.

A local bounds check does not seem sufficient for a correct patch:

  - concat_node_list and the concat population state are global, but node
    creation, addition, join creation and destruction have no common
    serialization.
  - mtd_virt_concat_add() returns bool. false means both "not a concat
    member" and "not added". Returning false for a duplicate makes
    add_mtd_partitions() register it as an ordinary partition, while returning
    true without storing it would leak the newly allocated partition.
  - join creation and destruction call back into MTD registration helpers, so
    a driver-global mutex must have a carefully defined scope to avoid
    recursive locking.

My current view is that the fix needs both a serialization contract for the
global virtual-concat state and a tri-state add result, so the caller can
distinguish "not a member" from a duplicate or capacity error and free the
new partition on error.

Would you prefer this serialization to live inside mtd_virt_concat, or should
the MTD registration layer serialize the node-create/partition-add/join
transaction? I have not attached a patch because choosing either scope
without agreement would encode a new lifetime and error-handling contract.