Re: [PATCH v2 00/46] Nandsim facelift (part I of II)

[Boris Brezillon]

Hi Richard,

On Mon, 14 Nov 2016 17:24:18 +0100
Richard Weinberger  wrote:

> Boris,
> 
> sorry for the late answer. I was not on CC, therefore this mail was
> unnoticed by me. :-(
> 
> On Sun, Oct 16, 2016 at 6:24 PM, Boris Brezillon
>  wrote:
> > Daniel, Richard,
> >
> > On Wed, 21 Sep 2016 11:43:29 +0200
> > Daniel Walter  wrote:
> >  
> >> Changes since V1:
> >>   Incooperate feedback for nand_cleanup()
> >>   Improve commit messages  
> 
> [..-]
> 
> > I really like the new approach for 2 reasons:
> > 1/ it allows creating several NAND devs, and you can do that after the
> >module has been loaded.
> > 2/ it fixes the partial NAND detection support by allowing one to
> >describe its NAND in term of page size, eraseblock size, oob
> >size, ...
> >
> > But I'm wondering if we should not create a new driver instead of
> > trying to fix the old one (I must admit I haven't been through the 46
> > patches of this series, but last time we discussed it on IRC, Richard
> > said it actually was a complete rewrite of the nandsim driver).
> >
> > Moreover, if we specify the flash layout manually, maybe we could make
> > it an mtdsim driver instead of restricting the emulation to NAND
> > devices.
> >
> > What do you think?  
> 
> I think we don't need a completely new driver. This series just adds
> functionality to nandsim without much cost, in fact we reuse also some
> bits from nandsim.
> If we add a new nandsim alike driver we basically give up the current nandsim
> and it will die a painful death. This series tries to avoid that.

Well, the whole problem with the current nandsim driver is that it
tries to do too many things. It not only tries to emulate a NAND device,
with all its constraint (bitflips, and many more), but it also tries to
register as a NAND driver with the NAND dev detection flow, and all
the convoluted page read/write logic (with/without ECC, ...).

Life (and code) would be much easier if the emulation driver was just
trying to emulate a NAND device without registering to the NAND
framework. All you'd have to do is implement your own mtd_info hooks,
without this nandsim device state burden that is required for
->cmd_ctrl() to work properly.

Of course, adding a new driver means marking the old one as deprecated
and keeping it around for some time, but that's IMHO, cleaner than
keeping a lot of code for something that we do not want to maintain.
One example is the NAND ID detection: it is a real pain, and we have
no easy solution to support ONFI chips.
If we go for a solution where the user select all the NAND properties
manually, we get rid of this complex beast, while leaving more freedom
to test some corner cases (non-powerof2 number of blocks per die for
example).

> What we can do is splitting nandsim into three files (common, old and new).

Well, it's not really about creating new files, it's more about
maintaining things that IMO are not so useful...

Regards,

Boris

Re: [PATCH v2 00/46] Nandsim facelift (part I of II)

[Boris Brezillon]

Hi Richard,

On Mon, 14 Nov 2016 17:24:18 +0100
Richard Weinberger  wrote:

> Boris,
> 
> sorry for the late answer. I was not on CC, therefore this mail was
> unnoticed by me. :-(
> 
> On Sun, Oct 16, 2016 at 6:24 PM, Boris Brezillon
>  wrote:
> > Daniel, Richard,
> >
> > On Wed, 21 Sep 2016 11:43:29 +0200
> > Daniel Walter  wrote:
> >  
> >> Changes since V1:
> >>   Incooperate feedback for nand_cleanup()
> >>   Improve commit messages  
> 
> [..-]
> 
> > I really like the new approach for 2 reasons:
> > 1/ it allows creating several NAND devs, and you can do that after the
> >module has been loaded.
> > 2/ it fixes the partial NAND detection support by allowing one to
> >describe its NAND in term of page size, eraseblock size, oob
> >size, ...
> >
> > But I'm wondering if we should not create a new driver instead of
> > trying to fix the old one (I must admit I haven't been through the 46
> > patches of this series, but last time we discussed it on IRC, Richard
> > said it actually was a complete rewrite of the nandsim driver).
> >
> > Moreover, if we specify the flash layout manually, maybe we could make
> > it an mtdsim driver instead of restricting the emulation to NAND
> > devices.
> >
> > What do you think?  
> 
> I think we don't need a completely new driver. This series just adds
> functionality to nandsim without much cost, in fact we reuse also some
> bits from nandsim.
> If we add a new nandsim alike driver we basically give up the current nandsim
> and it will die a painful death. This series tries to avoid that.

Well, the whole problem with the current nandsim driver is that it
tries to do too many things. It not only tries to emulate a NAND device,
with all its constraint (bitflips, and many more), but it also tries to
register as a NAND driver with the NAND dev detection flow, and all
the convoluted page read/write logic (with/without ECC, ...).

Life (and code) would be much easier if the emulation driver was just
trying to emulate a NAND device without registering to the NAND
framework. All you'd have to do is implement your own mtd_info hooks,
without this nandsim device state burden that is required for
->cmd_ctrl() to work properly.

Of course, adding a new driver means marking the old one as deprecated
and keeping it around for some time, but that's IMHO, cleaner than
keeping a lot of code for something that we do not want to maintain.
One example is the NAND ID detection: it is a real pain, and we have
no easy solution to support ONFI chips.
If we go for a solution where the user select all the NAND properties
manually, we get rid of this complex beast, while leaving more freedom
to test some corner cases (non-powerof2 number of blocks per die for
example).

> What we can do is splitting nandsim into three files (common, old and new).

Well, it's not really about creating new files, it's more about
maintaining things that IMO are not so useful...

Regards,

Boris

Re: [PATCH v2 00/46] Nandsim facelift (part I of II)

[Richard Weinberger]

Boris,

sorry for the late answer. I was not on CC, therefore this mail was
unnoticed by me. :-(

On Sun, Oct 16, 2016 at 6:24 PM, Boris Brezillon
 wrote:
> Daniel, Richard,
>
> On Wed, 21 Sep 2016 11:43:29 +0200
> Daniel Walter  wrote:
>
>> Changes since V1:
>>   Incooperate feedback for nand_cleanup()
>>   Improve commit messages

[..-]

> I really like the new approach for 2 reasons:
> 1/ it allows creating several NAND devs, and you can do that after the
>module has been loaded.
> 2/ it fixes the partial NAND detection support by allowing one to
>describe its NAND in term of page size, eraseblock size, oob
>size, ...
>
> But I'm wondering if we should not create a new driver instead of
> trying to fix the old one (I must admit I haven't been through the 46
> patches of this series, but last time we discussed it on IRC, Richard
> said it actually was a complete rewrite of the nandsim driver).
>
> Moreover, if we specify the flash layout manually, maybe we could make
> it an mtdsim driver instead of restricting the emulation to NAND
> devices.
>
> What do you think?

I think we don't need a completely new driver. This series just adds
functionality to nandsim without much cost, in fact we reuse also some
bits from nandsim.
If we add a new nandsim alike driver we basically give up the current nandsim
and it will die a painful death. This series tries to avoid that.
What we can do is splitting nandsim into three files (common, old and new).

P.s: Yes, I'm aware of the fact that then I'll have to maintain the beast. ;-\

-- 
Thanks,
//richard

Re: [PATCH v2 00/46] Nandsim facelift (part I of II)

[Richard Weinberger]

Boris,

sorry for the late answer. I was not on CC, therefore this mail was
unnoticed by me. :-(

On Sun, Oct 16, 2016 at 6:24 PM, Boris Brezillon
 wrote:
> Daniel, Richard,
>
> On Wed, 21 Sep 2016 11:43:29 +0200
> Daniel Walter  wrote:
>
>> Changes since V1:
>>   Incooperate feedback for nand_cleanup()
>>   Improve commit messages

[..-]

> I really like the new approach for 2 reasons:
> 1/ it allows creating several NAND devs, and you can do that after the
>module has been loaded.
> 2/ it fixes the partial NAND detection support by allowing one to
>describe its NAND in term of page size, eraseblock size, oob
>size, ...
>
> But I'm wondering if we should not create a new driver instead of
> trying to fix the old one (I must admit I haven't been through the 46
> patches of this series, but last time we discussed it on IRC, Richard
> said it actually was a complete rewrite of the nandsim driver).
>
> Moreover, if we specify the flash layout manually, maybe we could make
> it an mtdsim driver instead of restricting the emulation to NAND
> devices.
>
> What do you think?

I think we don't need a completely new driver. This series just adds
functionality to nandsim without much cost, in fact we reuse also some
bits from nandsim.
If we add a new nandsim alike driver we basically give up the current nandsim
and it will die a painful death. This series tries to avoid that.
What we can do is splitting nandsim into three files (common, old and new).

P.s: Yes, I'm aware of the fact that then I'll have to maintain the beast. ;-\

-- 
Thanks,
//richard

Re: [PATCH v2 00/46] Nandsim facelift (part I of II)

[Boris Brezillon]

Daniel, Richard,

On Wed, 21 Sep 2016 11:43:29 +0200
Daniel Walter  wrote:

> Changes since V1:
>   Incooperate feedback for nand_cleanup()
>   Improve commit messages
> 
> 
> 
> Over a decade ago nandsim was introduced to Linux. The main purpose is having 
> a software implementation of a NAND chip for rapid prototyping systems such 
> as UBI on top of it. On
> the other hand is it also heavily used to load and inspect dumps from real 
> NAND flashes. The current design allows only having a single chip and all 
> parameters are passed as
> modules parameters. Another draw back is that it emulates all NAND chip 
> internals including command parsing, this makes it slow and error prone wrt. 
> changes in nand_base.c since
> the emulated chip is not really ONFI compliant.
> 
> This series addresses the singleton property of nandsim. It allows having 
> multiple instances which can be controlled by a new userspace tool, 
> nandsimctl. Nandsimctl works like
> losetup. You can add and remove instances with different settings.
> To allow multiple instances nandsim offers an ioctl() interface via a new 
> device file, /dev/nandsimctl, to userspace.
> 
> Currently nandsim has two backends, ram and cache. In the default backend 
> mode, ram, all data you change is stored in main memory. For smaller chips 
> this works well but becomes
> problematic when modern multi-gigabyte chips are emulated. Cache mode 
> addresses this drawback and redirects program commands to a local file. Using 
> the cache_file module parameter
> the path of the backing file can be set. When nandsim is not a module passing 
> a file name to it can lead to unexpected behavior since during kernel bootup 
> the real root filesystem
> might not be ready and nandsim will populate the cache file on the initial 
> root filesysem which is either tmpfs or worse a ramfs.
> 
> Via the new ioctl() interface a third backend mode can be used, file mode. 
> File mode works like cache file but all data (including erases and OOB data) 
> are stored on a local file.
> This file can also also be reused later. It is also possible to operate 
> nandsim in a mode to omit existing OOB data and masquerade OOB bytes to 0xFF. 
> This allows using a nanddump
> (without OOB) from a real NAND chip directly in nandsim using the file 
> backend. That way you don't have to use nandwrite or other tools to write the 
> dump into yout MTD before using
> it. You can directly attach the dump in a losetup alike way.
> 
> The ioctl() accepts all existing nandsim parameters except that in cache mode 
> you pass a file descriptor instead of a file name to nandsim. This allows 
> utilizing O_TMPFILE.
> To preserve existing behavior and no breaking any users of nandsim it is 
> still possible to specify all parameters using module parameters but these 
> parameters will only affect the
> first nandsim instance which will be automatically created upon module 
> loading. If you don't have to have a default instance and explicitly create 
> nandsim instances using
> nandsimctl pass defaults=n to the module.
> 
> There will be an additional patch series for mtd-utils containing nandsimctl.
> 
> A side effect of heavily reworking nandsim's backend internals it is now also 
> possible to create custom backends. A custom backed was added to 
> UserModeLinux. It allows directly
> booting from a nanddump using UML such that UBIFS as rootfs can be tested 
> nicely on virtual machines.
> On step ahead for MTD testing.
> 
> The series itself is less straight forward than I wanted it to be, mostly 
> because while adding new features it was needed to cleanup some parts, over 
> and over.
> 
> Part II of that series will address the chip emulation nature of nandsim. It 
> will add a second emulation mode. By default NAND chip emulation will be used 
> but to allow arbitrary
> sized MTDs a more simple mode will be added which just allocates a MTD with 
> the expected sizes instead of mocking nand_base.c.

I really like the new approach for 2 reasons:
1/ it allows creating several NAND devs, and you can do that after the
   module has been loaded.
2/ it fixes the partial NAND detection support by allowing one to
   describe its NAND in term of page size, eraseblock size, oob
   size, ...

But I'm wondering if we should not create a new driver instead of
trying to fix the old one (I must admit I haven't been through the 46
patches of this series, but last time we discussed it on IRC, Richard
said it actually was a complete rewrite of the nandsim driver).

Moreover, if we specify the flash layout manually, maybe we could make
it an mtdsim driver instead of restricting the emulation to NAND
devices.

What do you think?

Regards,

Boris

Re: [PATCH v2 00/46] Nandsim facelift (part I of II)

[Boris Brezillon]

Daniel, Richard,

On Wed, 21 Sep 2016 11:43:29 +0200
Daniel Walter  wrote:

> Changes since V1:
>   Incooperate feedback for nand_cleanup()
>   Improve commit messages
> 
> 
> 
> Over a decade ago nandsim was introduced to Linux. The main purpose is having 
> a software implementation of a NAND chip for rapid prototyping systems such 
> as UBI on top of it. On
> the other hand is it also heavily used to load and inspect dumps from real 
> NAND flashes. The current design allows only having a single chip and all 
> parameters are passed as
> modules parameters. Another draw back is that it emulates all NAND chip 
> internals including command parsing, this makes it slow and error prone wrt. 
> changes in nand_base.c since
> the emulated chip is not really ONFI compliant.
> 
> This series addresses the singleton property of nandsim. It allows having 
> multiple instances which can be controlled by a new userspace tool, 
> nandsimctl. Nandsimctl works like
> losetup. You can add and remove instances with different settings.
> To allow multiple instances nandsim offers an ioctl() interface via a new 
> device file, /dev/nandsimctl, to userspace.
> 
> Currently nandsim has two backends, ram and cache. In the default backend 
> mode, ram, all data you change is stored in main memory. For smaller chips 
> this works well but becomes
> problematic when modern multi-gigabyte chips are emulated. Cache mode 
> addresses this drawback and redirects program commands to a local file. Using 
> the cache_file module parameter
> the path of the backing file can be set. When nandsim is not a module passing 
> a file name to it can lead to unexpected behavior since during kernel bootup 
> the real root filesystem
> might not be ready and nandsim will populate the cache file on the initial 
> root filesysem which is either tmpfs or worse a ramfs.
> 
> Via the new ioctl() interface a third backend mode can be used, file mode. 
> File mode works like cache file but all data (including erases and OOB data) 
> are stored on a local file.
> This file can also also be reused later. It is also possible to operate 
> nandsim in a mode to omit existing OOB data and masquerade OOB bytes to 0xFF. 
> This allows using a nanddump
> (without OOB) from a real NAND chip directly in nandsim using the file 
> backend. That way you don't have to use nandwrite or other tools to write the 
> dump into yout MTD before using
> it. You can directly attach the dump in a losetup alike way.
> 
> The ioctl() accepts all existing nandsim parameters except that in cache mode 
> you pass a file descriptor instead of a file name to nandsim. This allows 
> utilizing O_TMPFILE.
> To preserve existing behavior and no breaking any users of nandsim it is 
> still possible to specify all parameters using module parameters but these 
> parameters will only affect the
> first nandsim instance which will be automatically created upon module 
> loading. If you don't have to have a default instance and explicitly create 
> nandsim instances using
> nandsimctl pass defaults=n to the module.
> 
> There will be an additional patch series for mtd-utils containing nandsimctl.
> 
> A side effect of heavily reworking nandsim's backend internals it is now also 
> possible to create custom backends. A custom backed was added to 
> UserModeLinux. It allows directly
> booting from a nanddump using UML such that UBIFS as rootfs can be tested 
> nicely on virtual machines.
> On step ahead for MTD testing.
> 
> The series itself is less straight forward than I wanted it to be, mostly 
> because while adding new features it was needed to cleanup some parts, over 
> and over.
> 
> Part II of that series will address the chip emulation nature of nandsim. It 
> will add a second emulation mode. By default NAND chip emulation will be used 
> but to allow arbitrary
> sized MTDs a more simple mode will be added which just allocates a MTD with 
> the expected sizes instead of mocking nand_base.c.

I really like the new approach for 2 reasons:
1/ it allows creating several NAND devs, and you can do that after the
   module has been loaded.
2/ it fixes the partial NAND detection support by allowing one to
   describe its NAND in term of page size, eraseblock size, oob
   size, ...

But I'm wondering if we should not create a new driver instead of
trying to fix the old one (I must admit I haven't been through the 46
patches of this series, but last time we discussed it on IRC, Richard
said it actually was a complete rewrite of the nandsim driver).

Moreover, if we specify the flash layout manually, maybe we could make
it an mtdsim driver instead of restricting the emulation to NAND
devices.

What do you think?

Regards,

Boris

[PATCH v2 00/46] Nandsim facelift (part I of II)

[Daniel Walter]

Changes since V1:
  Incooperate feedback for nand_cleanup()
  Improve commit messages



Over a decade ago nandsim was introduced to Linux. The main purpose is having a 
software implementation of a NAND chip for rapid prototyping systems such as 
UBI on top of it. On
the other hand is it also heavily used to load and inspect dumps from real NAND 
flashes. The current design allows only having a single chip and all parameters 
are passed as
modules parameters. Another draw back is that it emulates all NAND chip 
internals including command parsing, this makes it slow and error prone wrt. 
changes in nand_base.c since
the emulated chip is not really ONFI compliant.

This series addresses the singleton property of nandsim. It allows having 
multiple instances which can be controlled by a new userspace tool, nandsimctl. 
Nandsimctl works like
losetup. You can add and remove instances with different settings.
To allow multiple instances nandsim offers an ioctl() interface via a new 
device file, /dev/nandsimctl, to userspace.

Currently nandsim has two backends, ram and cache. In the default backend mode, 
ram, all data you change is stored in main memory. For smaller chips this works 
well but becomes
problematic when modern multi-gigabyte chips are emulated. Cache mode addresses 
this drawback and redirects program commands to a local file. Using the 
cache_file module parameter
the path of the backing file can be set. When nandsim is not a module passing a 
file name to it can lead to unexpected behavior since during kernel bootup the 
real root filesystem
might not be ready and nandsim will populate the cache file on the initial root 
filesysem which is either tmpfs or worse a ramfs.

Via the new ioctl() interface a third backend mode can be used, file mode. File 
mode works like cache file but all data (including erases and OOB data) are 
stored on a local file.
This file can also also be reused later. It is also possible to operate nandsim 
in a mode to omit existing OOB data and masquerade OOB bytes to 0xFF. This 
allows using a nanddump
(without OOB) from a real NAND chip directly in nandsim using the file backend. 
That way you don't have to use nandwrite or other tools to write the dump into 
yout MTD before using
it. You can directly attach the dump in a losetup alike way.

The ioctl() accepts all existing nandsim parameters except that in cache mode 
you pass a file descriptor instead of a file name to nandsim. This allows 
utilizing O_TMPFILE.
To preserve existing behavior and no breaking any users of nandsim it is still 
possible to specify all parameters using module parameters but these parameters 
will only affect the
first nandsim instance which will be automatically created upon module loading. 
If you don't have to have a default instance and explicitly create nandsim 
instances using
nandsimctl pass defaults=n to the module.

There will be an additional patch series for mtd-utils containing nandsimctl.

A side effect of heavily reworking nandsim's backend internals it is now also 
possible to create custom backends. A custom backed was added to UserModeLinux. 
It allows directly
booting from a nanddump using UML such that UBIFS as rootfs can be tested 
nicely on virtual machines.
On step ahead for MTD testing.

The series itself is less straight forward than I wanted it to be, mostly 
because while adding new features it was needed to cleanup some parts, over and 
over.

Part II of that series will address the chip emulation nature of nandsim. It 
will add a second emulation mode. By default NAND chip emulation will be used 
but to allow arbitrary
sized MTDs a more simple mode will be added which just allocates a MTD with the 
expected sizes instead of mocking nand_base.c.


Daniel Walter (1):
  mtd/nandsim: Add ioctl for info

Mathias Kresin (1):
  mtd: nandsim: use the existing output macros

Richard Weinberger (44):
  mtdpart: Propagate _get/put_device()
  mtd: nand: Provide nand_cleanup() function to free NAND related
resources
  mtd: Don't unconditionally unregister reboot notifier
  mtd: Don't unconditionally execute remove notifiers
  mtd: Don't print a scary message when trying to remove a busy MTD
  mtd: nandsim: Add basic control file support
  mtd: nandsim: Begin with removal of global state
  mtd: nandsim: Kill global nsmtd
  mtd: nandsim: Don't directly use module parameters
  mtd: nandsim: Add helper functions for pointer magic
  mtd: nandsim: Factor out nandsim parameters
  mtd: nandsim: Make debugfs logic multi instance capable
  mtd: nandsim: Add final logic for multiple instances
  mtd: nandsim: Add simulator id to MTD parition name
  mtd: nandsim: Introduce backend operations
  mtd: nandsim: Print error when backend init failed
  mtd: nandsim: Allow external backends
  mtd: nandsim: Add basic support for a file backend
  mtd: nandsim: UAPI v1
  mtd: nandsim: Implement preliminary constructor function
  mtd: nandsim: Implement preliminary destructor function
  mtd: 

[PATCH v2 00/46] Nandsim facelift (part I of II)

[Daniel Walter]

Changes since V1:
  Incooperate feedback for nand_cleanup()
  Improve commit messages



Over a decade ago nandsim was introduced to Linux. The main purpose is having a 
software implementation of a NAND chip for rapid prototyping systems such as 
UBI on top of it. On
the other hand is it also heavily used to load and inspect dumps from real NAND 
flashes. The current design allows only having a single chip and all parameters 
are passed as
modules parameters. Another draw back is that it emulates all NAND chip 
internals including command parsing, this makes it slow and error prone wrt. 
changes in nand_base.c since
the emulated chip is not really ONFI compliant.

This series addresses the singleton property of nandsim. It allows having 
multiple instances which can be controlled by a new userspace tool, nandsimctl. 
Nandsimctl works like
losetup. You can add and remove instances with different settings.
To allow multiple instances nandsim offers an ioctl() interface via a new 
device file, /dev/nandsimctl, to userspace.

Currently nandsim has two backends, ram and cache. In the default backend mode, 
ram, all data you change is stored in main memory. For smaller chips this works 
well but becomes
problematic when modern multi-gigabyte chips are emulated. Cache mode addresses 
this drawback and redirects program commands to a local file. Using the 
cache_file module parameter
the path of the backing file can be set. When nandsim is not a module passing a 
file name to it can lead to unexpected behavior since during kernel bootup the 
real root filesystem
might not be ready and nandsim will populate the cache file on the initial root 
filesysem which is either tmpfs or worse a ramfs.

Via the new ioctl() interface a third backend mode can be used, file mode. File 
mode works like cache file but all data (including erases and OOB data) are 
stored on a local file.
This file can also also be reused later. It is also possible to operate nandsim 
in a mode to omit existing OOB data and masquerade OOB bytes to 0xFF. This 
allows using a nanddump
(without OOB) from a real NAND chip directly in nandsim using the file backend. 
That way you don't have to use nandwrite or other tools to write the dump into 
yout MTD before using
it. You can directly attach the dump in a losetup alike way.

The ioctl() accepts all existing nandsim parameters except that in cache mode 
you pass a file descriptor instead of a file name to nandsim. This allows 
utilizing O_TMPFILE.
To preserve existing behavior and no breaking any users of nandsim it is still 
possible to specify all parameters using module parameters but these parameters 
will only affect the
first nandsim instance which will be automatically created upon module loading. 
If you don't have to have a default instance and explicitly create nandsim 
instances using
nandsimctl pass defaults=n to the module.

There will be an additional patch series for mtd-utils containing nandsimctl.

A side effect of heavily reworking nandsim's backend internals it is now also 
possible to create custom backends. A custom backed was added to UserModeLinux. 
It allows directly
booting from a nanddump using UML such that UBIFS as rootfs can be tested 
nicely on virtual machines.
On step ahead for MTD testing.

The series itself is less straight forward than I wanted it to be, mostly 
because while adding new features it was needed to cleanup some parts, over and 
over.

Part II of that series will address the chip emulation nature of nandsim. It 
will add a second emulation mode. By default NAND chip emulation will be used 
but to allow arbitrary
sized MTDs a more simple mode will be added which just allocates a MTD with the 
expected sizes instead of mocking nand_base.c.


Daniel Walter (1):
  mtd/nandsim: Add ioctl for info

Mathias Kresin (1):
  mtd: nandsim: use the existing output macros

Richard Weinberger (44):
  mtdpart: Propagate _get/put_device()
  mtd: nand: Provide nand_cleanup() function to free NAND related
resources
  mtd: Don't unconditionally unregister reboot notifier
  mtd: Don't unconditionally execute remove notifiers
  mtd: Don't print a scary message when trying to remove a busy MTD
  mtd: nandsim: Add basic control file support
  mtd: nandsim: Begin with removal of global state
  mtd: nandsim: Kill global nsmtd
  mtd: nandsim: Don't directly use module parameters
  mtd: nandsim: Add helper functions for pointer magic
  mtd: nandsim: Factor out nandsim parameters
  mtd: nandsim: Make debugfs logic multi instance capable
  mtd: nandsim: Add final logic for multiple instances
  mtd: nandsim: Add simulator id to MTD parition name
  mtd: nandsim: Introduce backend operations
  mtd: nandsim: Print error when backend init failed
  mtd: nandsim: Allow external backends
  mtd: nandsim: Add basic support for a file backend
  mtd: nandsim: UAPI v1
  mtd: nandsim: Implement preliminary constructor function
  mtd: nandsim: Implement preliminary destructor function
  mtd: