<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/mtd, branch v4.4-rc7</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>Merge tag 'upstream-4.4-rc7' of git://git.infradead.org/linux-ubifs</title>
<updated>2015-12-27T03:55:16+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2015-12-27T03:55:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3bef22eed98b53cfb3962884f14068251a5dd3f0'/>
<id>3bef22eed98b53cfb3962884f14068251a5dd3f0</id>
<content type='text'>
Pull UBI bug fixes from Richard Weinberger:
 "This contains four bug fixes for UBI"

* tag 'upstream-4.4-rc7' of git://git.infradead.org/linux-ubifs:
  mtd: ubi: don't leak e if schedule_erase() fails
  mtd: ubi: fixup error correction in do_sync_erase()
  UBI: fix use of "VID" vs. "EC" in header self-check
  UBI: fix return error code
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull UBI bug fixes from Richard Weinberger:
 "This contains four bug fixes for UBI"

* tag 'upstream-4.4-rc7' of git://git.infradead.org/linux-ubifs:
  mtd: ubi: don't leak e if schedule_erase() fails
  mtd: ubi: fixup error correction in do_sync_erase()
  UBI: fix use of "VID" vs. "EC" in header self-check
  UBI: fix return error code
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: ubi: don't leak e if schedule_erase() fails</title>
<updated>2015-12-16T21:59:03+00:00</updated>
<author>
<name>Sebastian Siewior</name>
<email>bigeasy@linutronix.de</email>
</author>
<published>2015-11-26T20:23:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=6b238de189f69dc77d660d4cce62eed15547f4c3'/>
<id>6b238de189f69dc77d660d4cce62eed15547f4c3</id>
<content type='text'>
If __erase_worker() fails to erase the EB and schedule_erase() fails as
well to do anything about it then we go RO. But that is not a reason to
leak the e argument here. Therefore clean up e.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If __erase_worker() fails to erase the EB and schedule_erase() fails as
well to do anything about it then we go RO. But that is not a reason to
leak the e argument here. Therefore clean up e.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: ubi: fixup error correction in do_sync_erase()</title>
<updated>2015-12-16T21:52:46+00:00</updated>
<author>
<name>Sebastian Siewior</name>
<email>bigeasy@linutronix.de</email>
</author>
<published>2015-11-26T20:23:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1a31b20cd81d5cbc7ec6e24cb08066009a1ca32d'/>
<id>1a31b20cd81d5cbc7ec6e24cb08066009a1ca32d</id>
<content type='text'>
Since fastmap we gained do_sync_erase(). This function can return an error
and its error handling isn't obvious. First the memory allocation for
struct ubi_work can fail and as such struct ubi_wl_entry is leaked.
However if the memory allocation succeeds then the tail function takes
care of the struct ubi_wl_entry. A free here could result in a double
free.
To make the error handling simpler, I split the tail function into one
piece which does the work and another which frees the struct ubi_work
which is passed as argument. As result do_sync_erase() can keep the
struct on stack and we get rid of one error source.

Cc: &lt;stable@vger.kernel.org&gt;
Fixes: 8199b901a ("UBI: Add fastmap support to the WL sub-system")
Signed-off-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Since fastmap we gained do_sync_erase(). This function can return an error
and its error handling isn't obvious. First the memory allocation for
struct ubi_work can fail and as such struct ubi_wl_entry is leaked.
However if the memory allocation succeeds then the tail function takes
care of the struct ubi_wl_entry. A free here could result in a double
free.
To make the error handling simpler, I split the tail function into one
piece which does the work and another which frees the struct ubi_work
which is passed as argument. As result do_sync_erase() can keep the
struct on stack and we get rid of one error source.

Cc: &lt;stable@vger.kernel.org&gt;
Fixes: 8199b901a ("UBI: Add fastmap support to the WL sub-system")
Signed-off-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>UBI: fix use of "VID" vs. "EC" in header self-check</title>
<updated>2015-12-16T21:46:26+00:00</updated>
<author>
<name>Brian Norris</name>
<email>computersforpeace@gmail.com</email>
</author>
<published>2015-11-20T22:10:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=2e69d4912f2fc9d4cd952311d58ceae1cd83057b'/>
<id>2e69d4912f2fc9d4cd952311d58ceae1cd83057b</id>
<content type='text'>
Looks like a typo, using UBI_EC_HDR_SIZE_CRC (note the "EC") to compute
the CRC for the VID header.

This shouldn't cause any functional change, as both structures are 64
bytes. Verified with:

	BUILD_BUG_ON(UBI_VID_HDR_SIZE_CRC != UBI_EC_HDR_SIZE_CRC);

Reported here:
http://lists.infradead.org/pipermail/linux-mtd/2013-September/048570.html

Reported by: Bill Pringlemeir &lt;bpringlemeir@gmail.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Looks like a typo, using UBI_EC_HDR_SIZE_CRC (note the "EC") to compute
the CRC for the VID header.

This shouldn't cause any functional change, as both structures are 64
bytes. Verified with:

	BUILD_BUG_ON(UBI_VID_HDR_SIZE_CRC != UBI_EC_HDR_SIZE_CRC);

Reported here:
http://lists.infradead.org/pipermail/linux-mtd/2013-September/048570.html

Reported by: Bill Pringlemeir &lt;bpringlemeir@gmail.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>UBI: fix return error code</title>
<updated>2015-12-16T21:45:04+00:00</updated>
<author>
<name>Sudip Mukherjee</name>
<email>sudipm.mukherjee@gmail.com</email>
</author>
<published>2015-11-20T10:14:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=97cb69dd800a471c3ee2467be3826badd9c12883'/>
<id>97cb69dd800a471c3ee2467be3826badd9c12883</id>
<content type='text'>
We are checking dfs_rootdir for error value or NULL. But in the
conditional ternary operator we returned -ENODEV if dfs_rootdir contains
an error value and returned PTR_ERR(dfs_rootdir) if dfs_rootdir is NULL.
So in the case of dfs_rootdir being NULL we actually assigned 0 to err
and returned it to the caller implying a success.
Lets return -ENODEV when dfs_rootdir is NULL else return
PTR_ERR(dfs_rootdir).

Signed-off-by: Sudip Mukherjee &lt;sudip@vectorindia.org&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We are checking dfs_rootdir for error value or NULL. But in the
conditional ternary operator we returned -ENODEV if dfs_rootdir contains
an error value and returned PTR_ERR(dfs_rootdir) if dfs_rootdir is NULL.
So in the case of dfs_rootdir being NULL we actually assigned 0 to err
and returned it to the caller implying a success.
Lets return -ENODEV when dfs_rootdir is NULL else return
PTR_ERR(dfs_rootdir).

Signed-off-by: Sudip Mukherjee &lt;sudip@vectorindia.org&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>doc: dt: mtd: partitions: add compatible property to "partitions" node</title>
<updated>2015-12-09T01:10:20+00:00</updated>
<author>
<name>Brian Norris</name>
<email>computersforpeace@gmail.com</email>
</author>
<published>2015-12-03T22:47:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e488ca9f8d4f62c2dc36bfa5c32f68e7f05ab381'/>
<id>e488ca9f8d4f62c2dc36bfa5c32f68e7f05ab381</id>
<content type='text'>
As noted here [1], there are potentially future conflicts if we try to
use MTD's "partitions" subnode to describe anything besides just the
fixed-in-the-device-tree partitions currently described in this
document. Particularly, there was a proposal to use this node for the
AFS parser too.

It can pose a (small) problem to try to differentiate the following
nodes:

	// using binding as currently specified
	partitions {
		#address-cells = &lt;x&gt;;
		#size-cells = &lt;y&gt;;
		partition@0 {
			...;
		};
	};

and

	// proposed future binding
	partitions {
		compatible = "arm,arm-flash-structure";
	};

It's especially difficult if other uses of this node start having
subnodes.

So, since the "partitions" node is new in v4.4, let's fixup the binding
before release so that it requires a compatible property, so it's much
clearer to distinguish. e.g.:

	// proposed
	partitions {
		compatible = "fixed-partitions";
		#address-cells = &lt;x&gt;;
		#size-cells = &lt;y&gt;;
		partition@0 {
			...;
		};
	};

[1] Subject: "mtd: create a partition type device tree binding"
    http://lkml.kernel.org/g/20151113220039.GA74382@google.com
    http://lists.infradead.org/pipermail/linux-mtd/2015-November/063355.html
    http://lists.infradead.org/pipermail/linux-mtd/2015-November/063364.html

Cc: Michal Suchanek &lt;hramrach@gmail.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Acked-by: Rob Herring &lt;robh@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As noted here [1], there are potentially future conflicts if we try to
use MTD's "partitions" subnode to describe anything besides just the
fixed-in-the-device-tree partitions currently described in this
document. Particularly, there was a proposal to use this node for the
AFS parser too.

It can pose a (small) problem to try to differentiate the following
nodes:

	// using binding as currently specified
	partitions {
		#address-cells = &lt;x&gt;;
		#size-cells = &lt;y&gt;;
		partition@0 {
			...;
		};
	};

and

	// proposed future binding
	partitions {
		compatible = "arm,arm-flash-structure";
	};

It's especially difficult if other uses of this node start having
subnodes.

So, since the "partitions" node is new in v4.4, let's fixup the binding
before release so that it requires a compatible property, so it's much
clearer to distinguish. e.g.:

	// proposed
	partitions {
		compatible = "fixed-partitions";
		#address-cells = &lt;x&gt;;
		#size-cells = &lt;y&gt;;
		partition@0 {
			...;
		};
	};

[1] Subject: "mtd: create a partition type device tree binding"
    http://lkml.kernel.org/g/20151113220039.GA74382@google.com
    http://lists.infradead.org/pipermail/linux-mtd/2015-November/063355.html
    http://lists.infradead.org/pipermail/linux-mtd/2015-November/063364.html

Cc: Michal Suchanek &lt;hramrach@gmail.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Acked-by: Rob Herring &lt;robh@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: ofpart: don't complain about missing 'partitions' node too loudly</title>
<updated>2015-12-04T01:50:36+00:00</updated>
<author>
<name>Brian Norris</name>
<email>computersforpeace@gmail.com</email>
</author>
<published>2015-12-03T22:26:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8c62b4e118cfa7a3c906c01d4ba2c78a5bd97531'/>
<id>8c62b4e118cfa7a3c906c01d4ba2c78a5bd97531</id>
<content type='text'>
The ofpart partition parser might be run on DT-enabled systems that
don't have any "ofpart" partition subnodes at all, since "ofpart" is in
the default parser list. So don't complain loudly on every boot.

Example: using m25p80.c with no intent to use ofpart:

&amp;spi2 {
	status = "okay";

	flash@0 {
		compatible = "jedec,spi-nor";
		reg = &lt;0&gt;;
	};
};

I see this warning:

[    0.588471] m25p80 spi2.0: gd25q32 (4096 Kbytes)
[    0.593091] spi2.0: 'partitions' subnode not found on /spi@ff130000/flash@0. Trying to parse direct subnodes as partitions.

Cc: Michal Suchanek &lt;hramrach@gmail.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The ofpart partition parser might be run on DT-enabled systems that
don't have any "ofpart" partition subnodes at all, since "ofpart" is in
the default parser list. So don't complain loudly on every boot.

Example: using m25p80.c with no intent to use ofpart:

&amp;spi2 {
	status = "okay";

	flash@0 {
		compatible = "jedec,spi-nor";
		reg = &lt;0&gt;;
	};
};

I see this warning:

[    0.588471] m25p80 spi2.0: gd25q32 (4096 Kbytes)
[    0.593091] spi2.0: 'partitions' subnode not found on /spi@ff130000/flash@0. Trying to parse direct subnodes as partitions.

Cc: Michal Suchanek &lt;hramrach@gmail.com&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: nand: fix shutdown/reboot for multi-chip systems</title>
<updated>2015-11-16T18:51:39+00:00</updated>
<author>
<name>Brian Norris</name>
<email>computersforpeace@gmail.com</email>
</author>
<published>2015-11-10T00:37:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=9ca641b0f02a3a1eedbc8c296e695326da9bbaf9'/>
<id>9ca641b0f02a3a1eedbc8c296e695326da9bbaf9</id>
<content type='text'>
If multiple NAND chips are registered to the same controller, then when
rebooting the system, the first one will grab the controller lock, while
the second will wait forever for the first one to release it. i.e., a
classic deadlock.

This problem was solved for a similar case (suspend/resume) back in
commit 6b0d9a841249 ("mtd: nand: fix multi-chip suspend problem"), and
the shutdown state really isn't much different for us, so rather than
adding a new special case to nand_get_device(), we can just overload the
FL_PM_SUSPENDED state.

Now, multiple chips can "get" the same controller lock (preventing
further I/O), while we still allow other chips to pass through
nand_shutdown().

Original report:
http://thread.gmane.org/gmane.linux.drivers.mtd/59726
http://lists.infradead.org/pipermail/linux-mtd/2015-July/059992.html

Fixes: 72ea403669c7 ("mtd: nand: added nand_shutdown")
Reported-by: Andrew E. Mileski &lt;andrewm@isoar.ca&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Cc: Scott Branden &lt;sbranden@broadcom.com&gt;
Cc: Andrew E. Mileski &lt;andrewm@isoar.ca&gt;
Acked-by: Scott Branden &lt;sbranden@broadcom.com&gt;
Reviewed-by: Boris Brezillon &lt;boris.brezillon@free-electrons.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If multiple NAND chips are registered to the same controller, then when
rebooting the system, the first one will grab the controller lock, while
the second will wait forever for the first one to release it. i.e., a
classic deadlock.

This problem was solved for a similar case (suspend/resume) back in
commit 6b0d9a841249 ("mtd: nand: fix multi-chip suspend problem"), and
the shutdown state really isn't much different for us, so rather than
adding a new special case to nand_get_device(), we can just overload the
FL_PM_SUSPENDED state.

Now, multiple chips can "get" the same controller lock (preventing
further I/O), while we still allow other chips to pass through
nand_shutdown().

Original report:
http://thread.gmane.org/gmane.linux.drivers.mtd/59726
http://lists.infradead.org/pipermail/linux-mtd/2015-July/059992.html

Fixes: 72ea403669c7 ("mtd: nand: added nand_shutdown")
Reported-by: Andrew E. Mileski &lt;andrewm@isoar.ca&gt;
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
Cc: Scott Branden &lt;sbranden@broadcom.com&gt;
Cc: Andrew E. Mileski &lt;andrewm@isoar.ca&gt;
Acked-by: Scott Branden &lt;sbranden@broadcom.com&gt;
Reviewed-by: Boris Brezillon &lt;boris.brezillon@free-electrons.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>mtd: jz4740_nand: fix build on jz4740 after removing gpio.h</title>
<updated>2015-11-16T18:48:15+00:00</updated>
<author>
<name>Brian Norris</name>
<email>computersforpeace@gmail.com</email>
</author>
<published>2015-11-11T23:36:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=96dd922c198286681fbbc15100e196e0f629e2fb'/>
<id>96dd922c198286681fbbc15100e196e0f629e2fb</id>
<content type='text'>
Fallout from commit 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h")

We see errors like this:

drivers/mtd/nand/jz4740_nand.c: In function 'jz_nand_detect_bank':
drivers/mtd/nand/jz4740_nand.c:340:9: error: 'JZ_GPIO_MEM_CS0' undeclared (first use in this function)
drivers/mtd/nand/jz4740_nand.c:340:9: note: each undeclared identifier is reported only once for each function it appears in
drivers/mtd/nand/jz4740_nand.c:359:2: error: implicit declaration of function 'jz_gpio_set_function' [-Werror=implicit-function-declaration]
drivers/mtd/nand/jz4740_nand.c:359:29: error: 'JZ_GPIO_FUNC_MEM_CS0' undeclared (first use in this function)
drivers/mtd/nand/jz4740_nand.c:399:29: error: 'JZ_GPIO_FUNC_NONE' undeclared (first use in this function)
drivers/mtd/nand/jz4740_nand.c: In function 'jz_nand_probe':
drivers/mtd/nand/jz4740_nand.c:528:13: error: 'JZ_GPIO_MEM_CS0' undeclared (first use in this function)
drivers/mtd/nand/jz4740_nand.c: In function 'jz_nand_remove':
drivers/mtd/nand/jz4740_nand.c:555:14: error: 'JZ_GPIO_MEM_CS0' undeclared (first use in this function)

Patched similarly to:

https://patchwork.linux-mips.org/patch/11089/

Fixes: 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h")
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fallout from commit 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h")

We see errors like this:

drivers/mtd/nand/jz4740_nand.c: In function 'jz_nand_detect_bank':
drivers/mtd/nand/jz4740_nand.c:340:9: error: 'JZ_GPIO_MEM_CS0' undeclared (first use in this function)
drivers/mtd/nand/jz4740_nand.c:340:9: note: each undeclared identifier is reported only once for each function it appears in
drivers/mtd/nand/jz4740_nand.c:359:2: error: implicit declaration of function 'jz_gpio_set_function' [-Werror=implicit-function-declaration]
drivers/mtd/nand/jz4740_nand.c:359:29: error: 'JZ_GPIO_FUNC_MEM_CS0' undeclared (first use in this function)
drivers/mtd/nand/jz4740_nand.c:399:29: error: 'JZ_GPIO_FUNC_NONE' undeclared (first use in this function)
drivers/mtd/nand/jz4740_nand.c: In function 'jz_nand_probe':
drivers/mtd/nand/jz4740_nand.c:528:13: error: 'JZ_GPIO_MEM_CS0' undeclared (first use in this function)
drivers/mtd/nand/jz4740_nand.c: In function 'jz_nand_remove':
drivers/mtd/nand/jz4740_nand.c:555:14: error: 'JZ_GPIO_MEM_CS0' undeclared (first use in this function)

Patched similarly to:

https://patchwork.linux-mips.org/patch/11089/

Fixes: 832f5dacfa0b ("MIPS: Remove all the uses of custom gpio.h")
Signed-off-by: Brian Norris &lt;computersforpeace@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'upstream-4.4-rc1' of git://git.infradead.org/linux-ubifs</title>
<updated>2015-11-11T00:35:06+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2015-11-11T00:35:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=01504f5e9e071f1dde1062e3be15f54d4555308f'/>
<id>01504f5e9e071f1dde1062e3be15f54d4555308f</id>
<content type='text'>
Pull UBI/UBIFS updates from Richard Weinberger:

 - access time support for UBIFS by Dongsheng Yang

 - random cleanups and bug fixes all over the place

* tag 'upstream-4.4-rc1' of git://git.infradead.org/linux-ubifs:
  ubifs: introduce UBIFS_ATIME_SUPPORT to ubifs
  ubifs: make ubifs_[get|set]xattr atomic
  UBIFS: Delete unnecessary checks before the function call "iput"
  UBI: Remove in vain semicolon
  UBI: Fastmap: Fix PEB array type
  UBIFS: Fix possible memory leak in ubifs_readdir()
  fs/ubifs: remove unnecessary new_valid_dev check
  ubi: fastmap: Implement produce_free_peb()
  UBIFS: print verbose message when rescanning a corrupted node
  UBIFS: call dbg_is_power_cut() instead of reading c-&gt;dbg-&gt;pc_happened
  UBI: drop null test before destroy functions
  UBI: Update comments to reflect UBI_METAONLY flag
  UBI: Fix debug message
  UBI: Fix typo in comment
  UBI: Fastmap: Simplify expression
  UBIFS: fix a typo in comment of ubifs_budget_req
  UBIFS: use kmemdup rather than duplicating its implementation
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull UBI/UBIFS updates from Richard Weinberger:

 - access time support for UBIFS by Dongsheng Yang

 - random cleanups and bug fixes all over the place

* tag 'upstream-4.4-rc1' of git://git.infradead.org/linux-ubifs:
  ubifs: introduce UBIFS_ATIME_SUPPORT to ubifs
  ubifs: make ubifs_[get|set]xattr atomic
  UBIFS: Delete unnecessary checks before the function call "iput"
  UBI: Remove in vain semicolon
  UBI: Fastmap: Fix PEB array type
  UBIFS: Fix possible memory leak in ubifs_readdir()
  fs/ubifs: remove unnecessary new_valid_dev check
  ubi: fastmap: Implement produce_free_peb()
  UBIFS: print verbose message when rescanning a corrupted node
  UBIFS: call dbg_is_power_cut() instead of reading c-&gt;dbg-&gt;pc_happened
  UBI: drop null test before destroy functions
  UBI: Update comments to reflect UBI_METAONLY flag
  UBI: Fix debug message
  UBI: Fix typo in comment
  UBI: Fastmap: Simplify expression
  UBIFS: fix a typo in comment of ubifs_budget_req
  UBIFS: use kmemdup rather than duplicating its implementation
</pre>
</div>
</content>
</entry>
</feed>
