linux.git/drivers/mtd/mtdcore.c, branch v4.5

mtd: merge MTD development from v4.4 into for-v4.5 development

2016-01-06T00:05:56+00:00

Small conflict between some bugfixes for 4.4 and some refactoring for
4.5.

Signed-off-by: Brian Norris

mtd: fix cmdlinepart parser, early naming for auto-filled MTD

2016-01-04T18:54:18+00:00

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 
Signed-off-by: Brian Norris 
Cc: Heiko Schocher 
Cc: Frans Klaver

mtd: partitions: support a cleanup callback for parsers

2015-12-09T22:57:44+00:00

If partition parsers need to clean up their resources, we shouldn't
assume that all memory will fit in a single kmalloc() that the caller
can kfree(). We should allow the parser to provide a proper cleanup
routine.

Note that this means we need to keep a hold on the parser's module for a
bit longer, and release it later with mtd_part_parser_put().

Alongside this, define a default callback that we'll automatically use
if the parser doesn't provide one, so we can still retain the old
behavior.

Signed-off-by: Brian Norris 
Reviewed-by: Boris Brezillon

mtd: partitions: pass around 'mtd_partitions' wrapper struct

2015-12-09T18:22:09+00:00

For some of the core partitioning code, it helps to keep info about the
parsed partition (and who parsed them) together in one place.

Signed-off-by: Brian Norris

mtd: partitions: remove kmemdup()

2015-12-09T18:22:06+00:00

The use of kmemdup() complicates the error handling a bit. We don't
actually need to allocate new memory, since this reference is treated as
const, and it is copied into new memory by the partition registration
code anyway. So remove it.

Signed-off-by: Brian Norris 
Reviewed-by: Boris Brezillon

Merge v4.4-rc1 into MTD development

2015-11-16T04:31:29+00:00

Sync up with the upstream development.

Signed-off-by: Brian Norris

mtd: grab a reference to the MTD of_node before registering it

2015-11-12T18:09:55+00:00

We now stick the device node representing the current MTD (if any) into
sysfs, so let's make sure we have a reference to it before doing that.

Suggested-by: Boris Brezillon 
Signed-off-by: Brian Norris 
Reviewed-by: Boris Brezillon

Merge branch 'akpm' (patches from Andrew)

2015-11-07T22:32:45+00:00

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 : (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
  ...

mm, page_alloc: distinguish between being unable to sleep, unwilling to sleep and avoiding waking kswapd

2015-11-07T01:50:42+00:00

__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 
Acked-by: Vlastimil Babka 
Acked-by: Michal Hocko 
Acked-by: Johannes Weiner 
Cc: Christoph Lameter 
Cc: David Rientjes 
Cc: Vitaly Wool 
Cc: Rik van Riel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mtd: don't WARN about overloaded users of mtd->reboot_notifier.notifier_call

2015-11-06T17:33:15+00:00

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 
Signed-off-by: Brian Norris 
Cc: Jesper Nilsson 
Cc: linux-cris-kernel@axis.com
Tested-by: Ezequiel Garcia 
Tested-by: Guenter Roeck 
Signed-off-by: Brian Norris