Commit 807f16d4db95 ("mtd: core: set some defaults when dev.parent is
set") attempted to provide some default settings for MTDs that
 (a) assign the parent device and
 (b) don't provide their own name or owner

However, this isn't a perfect drop-in replacement for the boilerplate
found in some drivers, because the MTD name is used by partition
parsers like cmdlinepart, but the name isn't set until add_mtd_device(),
after the parsing is completed. This means cmdlinepart sees a NULL name
and therefore will not work properly.

Fix this by moving the default name and owner assignment to be first in
the MTD registration process.

[Note: this does not fix all reported issues, particularly with NAND
drivers. Will require an additional fix for drivers/mtd/nand/]

Fixes: 807f16d4db95 ("mtd: core: set some defaults when dev.parent is set")
Reported-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Frans Klaver <fransklaver@gmail.com>

Merge second patch-bomb from Andrew Morton:

 - most of the rest of MM

 - procfs

 - lib/ updates

 - printk updates

 - bitops infrastructure tweaks

 - checkpatch updates

 - nilfs2 update

 - signals

 - various other misc bits: coredump, seqfile, kexec, pidns, zlib, ipc,
   dma-debug, dma-mapping, ...

* emailed patches from Andrew Morton <akpm@linux-foundation.org>: (102 commits)
  ipc,msg: drop dst nil validation in copy_msg
  include/linux/zutil.h: fix usage example of zlib_adler32()
  panic: release stale console lock to always get the logbuf printed out
  dma-debug: check nents in dma_sync_sg*
  dma-mapping: tidy up dma_parms default handling
  pidns: fix set/getpriority and ioprio_set/get in PRIO_USER mode
  kexec: use file name as the output message prefix
  fs, seqfile: always allow oom killer
  seq_file: reuse string_escape_str()
  fs/seq_file: use seq_* helpers in seq_hex_dump()
  coredump: change zap_threads() and zap_process() to use for_each_thread()
  coredump: ensure all coredumping tasks have SIGNAL_GROUP_COREDUMP
  signal: remove jffs2_garbage_collect_thread()->allow_signal(SIGCONT)
  signal: introduce kernel_signal_stop() to fix jffs2_garbage_collect_thread()
  signal: turn dequeue_signal_lock() into kernel_dequeue_signal()
  signals: kill block_all_signals() and unblock_all_signals()
  nilfs2: fix gcc uninitialized-variable warnings in powerpc build
  nilfs2: fix gcc unused-but-set-variable warnings
  MAINTAINERS: nilfs2: add header file for tracing
  nilfs2: add tracepoints for analyzing reading and writing metadata files
  ...

__GFP_WAIT has been used to identify atomic context in callers that hold
spinlocks or are in interrupts.  They are expected to be high priority and
have access one of two watermarks lower than "min" which can be referred
to as the "atomic reserve".  __GFP_HIGH users get access to the first
lower watermark and can be called the "high priority reserve".

Over time, callers had a requirement to not block when fallback options
were available.  Some have abused __GFP_WAIT leading to a situation where
an optimisitic allocation with a fallback option can access atomic
reserves.

This patch uses __GFP_ATOMIC to identify callers that are truely atomic,
cannot sleep and have no alternative.  High priority users continue to use
__GFP_HIGH.  __GFP_DIRECT_RECLAIM identifies callers that can sleep and
are willing to enter direct reclaim.  __GFP_KSWAPD_RECLAIM to identify
callers that want to wake kswapd for background reclaim.  __GFP_WAIT is
redefined as a caller that is willing to enter direct reclaim and wake
kswapd for background reclaim.

This patch then converts a number of sites

o __GFP_ATOMIC is used by callers that are high priority and have memory
  pools for those requests. GFP_ATOMIC uses this flag.

o Callers that have a limited mempool to guarantee forward progress clear
  __GFP_DIRECT_RECLAIM but keep __GFP_KSWAPD_RECLAIM. bio allocations fall
  into this category where kswapd will still be woken but atomic reserves
  are not used as there is a one-entry mempool to guarantee progress.

o Callers that are checking if they are non-blocking should use the
  helper gfpflags_allow_blocking() where possible. This is because
  checking for __GFP_WAIT as was done historically now can trigger false
  positives. Some exceptions like dm-crypt.c exist where the code intent
  is clearer if __GFP_DIRECT_RECLAIM is used instead of the helper due to
  flag manipulations.

o Callers that built their own GFP flags instead of starting with GFP_KERNEL
  and friends now also need to specify __GFP_KSWAPD_RECLAIM.

The first key hazard to watch out for is callers that removed __GFP_WAIT
and was depending on access to atomic reserves for inconspicuous reasons.
In some cases it may be appropriate for them to use __GFP_HIGH.

The second key hazard is callers that assembled their own combination of
GFP flags instead of starting with something like GFP_KERNEL.  They may
now wish to specify __GFP_KSWAPD_RECLAIM.  It's almost certainly harmless
if it's missed in most cases as other activity will wake kswapd.

Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Vitaly Wool <vitalywool@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

There are multiple types of users of mtd->reboot_notifier.notifier_call:

(1) A while back, the cfi_cmdset_000{1,2} chip drivers implemented a
reboot notifier to (on a best effort basis) attempt to reset their flash
chips before rebooting.

(2) More recently, we implemented a common _reboot() hook so that MTD
drivers (particularly, NAND flash) could better halt I/O operations
without having to reimplement the same notifier boilerplate.

Currently, the WARN_ONCE() condition here was written to handle (2), but
at the same time it mis-diagnosed case (1) as an already-registered MTD.
Let's fix this by having the WARN_ONCE() condition better imitate the
condition that immediately follows it. (Wow, I don't know how I missed
that one.)

(Side note: Unfortunately, we can't yet combine the reboot notifier code
for (1) and (2) with a patch like [1], because some users of (1) also
use mtdconcat, and so the mtd_info struct from cfi_cmdset_000{1,2} won't
actually get registered with mtdcore, and therefore their reboot
notifier won't get registered.)

[1] http://patchwork.ozlabs.org/patch/417981/

Suggested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Jesper Nilsson <jespern@axis.com>
Cc: linux-cris-kernel@axis.com
Tested-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

Due to wrong assumption in ofpart ofpart fails on Exynos on SPI chips
with no partitions because the subnode containing controller data
confuses the ofpart parser.

Thus compiling in ofpart support automatically fails probing any SPI NOR
flash without partitions on Exynos.

Compiling in a partitioning scheme should not cause probe of otherwise
valid device to fail.

Instead, let's do the following:
 * try parsers until one succeeds
 * if no parser succeeds, report the first error we saw
 * even in the failure case, allow MTD to probe, with fallback
   partitions or no partitions at all -- the master device will still be
   registered

Issue report and comments initially by Michal Suchanek.

Reported-by: Michal Suchanek <hramrach@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

When CONFIG_MTD_PARTITIONED_MASTER=y, it is fatal to call
mtd_device_parse_register() twice on the same MTD, as we try to register
the same device/kobject multipile times.

When CONFIG_MTD_PARTITIONED_MASTER=n, calling
mtd_device_parse_register() is more of just a nuisance, as we can mostly
navigate around any conflicting actions.

But anyway, doing so is a Bad Thing (TM), and we should complain loudly
for any drivers that try to do this.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Richard Weinberger <richard@nod.at>

Since commit 3efe41be224c ("mtd: implement common reboot notifier
boilerplate"), we might try to register a reboot notifier for an MTD
that failed to register. Let's avoid this by making the error path
clearer.

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reviewed-by: Richard Weinberger <richard@nod.at>

If a parent device is set, add_mtd_device() has enough knowledge to fill
in some sane default values for the module name and owner. Do so if they
aren't already set.

Signed-off-by: Frans Klaver <fransklaver@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

add_mtd_device() has a comment suggesting that the caller should have
set dev.parent. This is required to have the parent device symlink show
up in sysfs, but not for proper operation of the mtd device itself.
Currently we have five drivers registering mtd devices during module
initialization, so they don't actually provide a parent device to link
to. That means we cannot WARN_ON() here, as it would trigger false
positives.

Make the comment a bit less firm in its assertion that dev.parent should
be set.

Signed-off-by: Frans Klaver <fransklaver@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>

Destroy mtd_idr on module_exit, reclaiming the allocated memory.

This was detected by the following semantic patch (written by Luis Rodriguez
<mcgrof@suse.com>)
<SmPL>
@ defines_module_init @
declarer name module_init, module_exit;
declarer name DEFINE_IDR;
identifier init;
@@

module_init(init);

@ defines_module_exit @
identifier exit;
@@

module_exit(exit);

@ declares_idr depends on defines_module_init && defines_module_exit @
identifier idr;
@@

DEFINE_IDR(idr);

@ on_exit_calls_destroy depends on declares_idr && defines_module_exit @
identifier declares_idr.idr, defines_module_exit.exit;
@@

exit(void)
{
 ...
  idr_destroy(&idr);
  ...
}

@ missing_module_idr_destroy depends on declares_idr && defines_module_exit && !on_exit_calls_destroy @
identifier declares_idr.idr, defines_module_exit.exit;
@@

exit(void)
{
 ...
 +idr_destroy(&idr);
}
</SmPL>

Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>