diff mbox

mtd: Add sysfs attribute for mtd OOB available size

Message ID 1522657210-56833-2-git-send-email-xiaolei.li@mediatek.com (mailing list archive)
State New, archived
Headers show

Commit Message

xiaolei li April 2, 2018, 8:20 a.m. UTC
Expose mtd OOB available size by sysfs file. Then users can get available
OOB size by accessing /sys/class/mtd/mtdX/oobavail.

Signed-off-by: Xiaolei Li <xiaolei.li@mediatek.com>
---
 Documentation/ABI/testing/sysfs-class-mtd |  8 ++++++++
 drivers/mtd/mtdcore.c                     | 10 ++++++++++
 2 files changed, 18 insertions(+)

Comments

Boris Brezillon April 2, 2018, 12:15 p.m. UTC | #1
Hi Xiaolei,

On Mon, 2 Apr 2018 16:20:10 +0800
Xiaolei Li <xiaolei.li@mediatek.com> wrote:

> Expose mtd OOB available size by sysfs file. Then users can get available
> OOB size by accessing /sys/class/mtd/mtdX/oobavail.

May I ask why you need to expose that? I'm not against exposing new
things through sysfs, but since this is part of the ABI, I'd like to be
sure we actually need it.

Regards,

Boris

> 
> Signed-off-by: Xiaolei Li <xiaolei.li@mediatek.com>
> ---
>  Documentation/ABI/testing/sysfs-class-mtd |  8 ++++++++
>  drivers/mtd/mtdcore.c                     | 10 ++++++++++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-mtd b/Documentation/ABI/testing/sysfs-class-mtd
> index f34e5923..3bc7c0a 100644
> --- a/Documentation/ABI/testing/sysfs-class-mtd
> +++ b/Documentation/ABI/testing/sysfs-class-mtd
> @@ -232,3 +232,11 @@ Description:
>  		of the parent (another partition or a flash device) in bytes.
>  		This attribute is absent on flash devices, so it can be used
>  		to distinguish them from partitions.
> +
> +What:		/sys/class/mtd/mtdX/oobavail
> +Date:		April 2018
> +KernelVersion:	4.16
> +Contact:	linux-mtd@lists.infradead.org
> +Description:
> +		Number of bytes available for a client to place data into
> +		the out of band area.
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index 807d17d..99d9352 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -210,6 +210,15 @@ static ssize_t mtd_oobsize_show(struct device *dev,
>  }
>  static DEVICE_ATTR(oobsize, S_IRUGO, mtd_oobsize_show, NULL);
>  
> +static ssize_t mtd_oobavail_show(struct device *dev,
> +				 struct device_attribute *attr, char *buf)
> +{
> +	struct mtd_info *mtd = dev_get_drvdata(dev);
> +
> +	return snprintf(buf, PAGE_SIZE, "%lu\n", (unsigned long)mtd->oobavail);
> +}
> +static DEVICE_ATTR(oobavail, S_IRUGO, mtd_oobavail_show, NULL);
> +
>  static ssize_t mtd_numeraseregions_show(struct device *dev,
>  		struct device_attribute *attr, char *buf)
>  {
> @@ -327,6 +336,7 @@ static ssize_t mtd_bbtblocks_show(struct device *dev,
>  	&dev_attr_writesize.attr,
>  	&dev_attr_subpagesize.attr,
>  	&dev_attr_oobsize.attr,
> +	&dev_attr_oobavail.attr,
>  	&dev_attr_numeraseregions.attr,
>  	&dev_attr_name.attr,
>  	&dev_attr_ecc_strength.attr,
xiaolei li April 3, 2018, 2:46 a.m. UTC | #2
Hello Boris,

On Mon, 2018-04-02 at 14:15 +0200, Boris Brezillon wrote:
> Hi Xiaolei,
> 
> On Mon, 2 Apr 2018 16:20:10 +0800
> Xiaolei Li <xiaolei.li@mediatek.com> wrote:
> 
> > Expose mtd OOB available size by sysfs file. Then users can get available
> > OOB size by accessing /sys/class/mtd/mtdX/oobavail.
> 
> May I ask why you need to expose that? I'm not against exposing new
> things through sysfs, but since this is part of the ABI, I'd like to be
> sure we actually need it.
> 
That is user-space can write OOB data through ioctl MEMWRITE now.
If OOB operation mode is MTD_OPS_AUTO_OOB, user should know how many
OOB available bytes it can use. But I didn't find a way to get it. (If
there is already a method, please kindly let me know, thanks.)

One problem I know is to do Jffs2 type flash erase using MTD user-space
tool flash_erase. flash_erase tool will program "cleanmarker" into OOB
free area, but it can not get OOB available size.
Please refer this commit:
http://git.infradead.org/mtd-utils.git/commit/d7e86124d55bbcee1b82c68b82389ebcda588076

Thanks!
Xiaolei

> Regards,
> 
> Boris
> 
> > 
> > Signed-off-by: Xiaolei Li <xiaolei.li@mediatek.com>
> > ---
> >  Documentation/ABI/testing/sysfs-class-mtd |  8 ++++++++
> >  drivers/mtd/mtdcore.c                     | 10 ++++++++++
> >  2 files changed, 18 insertions(+)
> > 
> > diff --git a/Documentation/ABI/testing/sysfs-class-mtd b/Documentation/ABI/testing/sysfs-class-mtd
> > index f34e5923..3bc7c0a 100644
> > --- a/Documentation/ABI/testing/sysfs-class-mtd
> > +++ b/Documentation/ABI/testing/sysfs-class-mtd
> > @@ -232,3 +232,11 @@ Description:
> >  		of the parent (another partition or a flash device) in bytes.
> >  		This attribute is absent on flash devices, so it can be used
> >  		to distinguish them from partitions.
> > +
> > +What:		/sys/class/mtd/mtdX/oobavail
> > +Date:		April 2018
> > +KernelVersion:	4.16
> > +Contact:	linux-mtd@lists.infradead.org
> > +Description:
> > +		Number of bytes available for a client to place data into
> > +		the out of band area.
> > diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> > index 807d17d..99d9352 100644
> > --- a/drivers/mtd/mtdcore.c
> > +++ b/drivers/mtd/mtdcore.c
> > @@ -210,6 +210,15 @@ static ssize_t mtd_oobsize_show(struct device *dev,
> >  }
> >  static DEVICE_ATTR(oobsize, S_IRUGO, mtd_oobsize_show, NULL);
> >  
> > +static ssize_t mtd_oobavail_show(struct device *dev,
> > +				 struct device_attribute *attr, char *buf)
> > +{
> > +	struct mtd_info *mtd = dev_get_drvdata(dev);
> > +
> > +	return snprintf(buf, PAGE_SIZE, "%lu\n", (unsigned long)mtd->oobavail);
> > +}
> > +static DEVICE_ATTR(oobavail, S_IRUGO, mtd_oobavail_show, NULL);
> > +
> >  static ssize_t mtd_numeraseregions_show(struct device *dev,
> >  		struct device_attribute *attr, char *buf)
> >  {
> > @@ -327,6 +336,7 @@ static ssize_t mtd_bbtblocks_show(struct device *dev,
> >  	&dev_attr_writesize.attr,
> >  	&dev_attr_subpagesize.attr,
> >  	&dev_attr_oobsize.attr,
> > +	&dev_attr_oobavail.attr,
> >  	&dev_attr_numeraseregions.attr,
> >  	&dev_attr_name.attr,
> >  	&dev_attr_ecc_strength.attr,
> 
> 
>
Boris Brezillon April 3, 2018, 8:43 a.m. UTC | #3
On Tue, 3 Apr 2018 10:46:58 +0800
xiaolei li <xiaolei.li@mediatek.com> wrote:

> Hello Boris,
> 
> On Mon, 2018-04-02 at 14:15 +0200, Boris Brezillon wrote:
> > Hi Xiaolei,
> > 
> > On Mon, 2 Apr 2018 16:20:10 +0800
> > Xiaolei Li <xiaolei.li@mediatek.com> wrote:
> >   
> > > Expose mtd OOB available size by sysfs file. Then users can get available
> > > OOB size by accessing /sys/class/mtd/mtdX/oobavail.  
> > 
> > May I ask why you need to expose that? I'm not against exposing new
> > things through sysfs, but since this is part of the ABI, I'd like to be
> > sure we actually need it.
> >   
> That is user-space can write OOB data through ioctl MEMWRITE now.
> If OOB operation mode is MTD_OPS_AUTO_OOB, user should know how many
> OOB available bytes it can use. But I didn't find a way to get it. (If
> there is already a method, please kindly let me know, thanks.)

Nope. We have the ECCGETLAYOUT ioctl, but it's not reliable because of
the MTD_MAX_OOBFREE_ENTRIES limitation.

> 
> One problem I know is to do Jffs2 type flash erase using MTD user-space
> tool flash_erase. flash_erase tool will program "cleanmarker" into OOB
> free area, but it can not get OOB available size.

That's a good reason to expose this property indeed. Do you plan to fix
mtd-utils to use the sysfs value when it's available? Also, do we need
to expose the ECC/free layout as done with the
ECCGETLAYOUT/MEMGETOOBSEL ioctls?
xiaolei li April 3, 2018, 9:40 a.m. UTC | #4
On Tue, 2018-04-03 at 10:43 +0200, Boris Brezillon wrote:
> On Tue, 3 Apr 2018 10:46:58 +0800
> xiaolei li <xiaolei.li@mediatek.com> wrote:
> 
> > Hello Boris,
> > 
> > On Mon, 2018-04-02 at 14:15 +0200, Boris Brezillon wrote:
> > > Hi Xiaolei,
> > > 
> > > On Mon, 2 Apr 2018 16:20:10 +0800
> > > Xiaolei Li <xiaolei.li@mediatek.com> wrote:
> > >   
> > > > Expose mtd OOB available size by sysfs file. Then users can get available
> > > > OOB size by accessing /sys/class/mtd/mtdX/oobavail.  
> > > 
> > > May I ask why you need to expose that? I'm not against exposing new
> > > things through sysfs, but since this is part of the ABI, I'd like to be
> > > sure we actually need it.
> > >   
> > That is user-space can write OOB data through ioctl MEMWRITE now.
> > If OOB operation mode is MTD_OPS_AUTO_OOB, user should know how many
> > OOB available bytes it can use. But I didn't find a way to get it. (If
> > there is already a method, please kindly let me know, thanks.)
> 
> Nope. We have the ECCGETLAYOUT ioctl, but it's not reliable because of
> the MTD_MAX_OOBFREE_ENTRIES limitation.
> 
> > 
> > One problem I know is to do Jffs2 type flash erase using MTD user-space
> > tool flash_erase. flash_erase tool will program "cleanmarker" into OOB
> > free area, but it can not get OOB available size.
> 
> That's a good reason to expose this property indeed. Do you plan to fix
> mtd-utils to use the sysfs value when it's available? Also, do we need
> to expose the ECC/free layout as done with the
> ECCGETLAYOUT/MEMGETOOBSEL ioctls?
> 
Yes. I plan to fix mtd-utils problem if this change is accepted.

struct nand_oobinfo and struct nand_ecclayout_user in mtd-abi.h are
obsoleted, and user can not get oob layout by ioctl method now.
sysfs seems a method to fetch oob layout. But I don't know which
user-space case will use oob layout now. Maybe expose them in the future
if they are really needed?

Thanks,
Xiaolei
Boris Brezillon April 3, 2018, 10:14 a.m. UTC | #5
On Tue, 3 Apr 2018 17:40:11 +0800
xiaolei li <xiaolei.li@mediatek.com> wrote:

> On Tue, 2018-04-03 at 10:43 +0200, Boris Brezillon wrote:
> > On Tue, 3 Apr 2018 10:46:58 +0800
> > xiaolei li <xiaolei.li@mediatek.com> wrote:
> >   
> > > Hello Boris,
> > > 
> > > On Mon, 2018-04-02 at 14:15 +0200, Boris Brezillon wrote:  
> > > > Hi Xiaolei,
> > > > 
> > > > On Mon, 2 Apr 2018 16:20:10 +0800
> > > > Xiaolei Li <xiaolei.li@mediatek.com> wrote:
> > > >     
> > > > > Expose mtd OOB available size by sysfs file. Then users can get available
> > > > > OOB size by accessing /sys/class/mtd/mtdX/oobavail.    
> > > > 
> > > > May I ask why you need to expose that? I'm not against exposing new
> > > > things through sysfs, but since this is part of the ABI, I'd like to be
> > > > sure we actually need it.
> > > >     
> > > That is user-space can write OOB data through ioctl MEMWRITE now.
> > > If OOB operation mode is MTD_OPS_AUTO_OOB, user should know how many
> > > OOB available bytes it can use. But I didn't find a way to get it. (If
> > > there is already a method, please kindly let me know, thanks.)  
> > 
> > Nope. We have the ECCGETLAYOUT ioctl, but it's not reliable because of
> > the MTD_MAX_OOBFREE_ENTRIES limitation.
> >   
> > > 
> > > One problem I know is to do Jffs2 type flash erase using MTD user-space
> > > tool flash_erase. flash_erase tool will program "cleanmarker" into OOB
> > > free area, but it can not get OOB available size.  
> > 
> > That's a good reason to expose this property indeed. Do you plan to fix
> > mtd-utils to use the sysfs value when it's available? Also, do we need
> > to expose the ECC/free layout as done with the
> > ECCGETLAYOUT/MEMGETOOBSEL ioctls?
> >   
> Yes. I plan to fix mtd-utils problem if this change is accepted.
> 
> struct nand_oobinfo and struct nand_ecclayout_user in mtd-abi.h are
> obsoleted, and user can not get oob layout by ioctl method now.
> sysfs seems a method to fetch oob layout. But I don't know which
> user-space case will use oob layout now. Maybe expose them in the future
> if they are really needed?

If the layout is not needed yet, let's not expose it. BTW, are you
really using JFFS2 on modern NAND chips? Sounds like a bad idea to me.
xiaolei li April 3, 2018, 11:01 a.m. UTC | #6
On Tue, 2018-04-03 at 12:14 +0200, Boris Brezillon wrote:
> On Tue, 3 Apr 2018 17:40:11 +0800
> xiaolei li <xiaolei.li@mediatek.com> wrote:
> 
> > On Tue, 2018-04-03 at 10:43 +0200, Boris Brezillon wrote:
> > > On Tue, 3 Apr 2018 10:46:58 +0800
> > > xiaolei li <xiaolei.li@mediatek.com> wrote:
> > >   
> > > > Hello Boris,
> > > > 
> > > > On Mon, 2018-04-02 at 14:15 +0200, Boris Brezillon wrote:  
> > > > > Hi Xiaolei,
> > > > > 
> > > > > On Mon, 2 Apr 2018 16:20:10 +0800
> > > > > Xiaolei Li <xiaolei.li@mediatek.com> wrote:
> > > > >     
> > > > > > Expose mtd OOB available size by sysfs file. Then users can get available
> > > > > > OOB size by accessing /sys/class/mtd/mtdX/oobavail.    
> > > > > 
> > > > > May I ask why you need to expose that? I'm not against exposing new
> > > > > things through sysfs, but since this is part of the ABI, I'd like to be
> > > > > sure we actually need it.
> > > > >     
> > > > That is user-space can write OOB data through ioctl MEMWRITE now.
> > > > If OOB operation mode is MTD_OPS_AUTO_OOB, user should know how many
> > > > OOB available bytes it can use. But I didn't find a way to get it. (If
> > > > there is already a method, please kindly let me know, thanks.)  
> > > 
> > > Nope. We have the ECCGETLAYOUT ioctl, but it's not reliable because of
> > > the MTD_MAX_OOBFREE_ENTRIES limitation.
> > >   
> > > > 
> > > > One problem I know is to do Jffs2 type flash erase using MTD user-space
> > > > tool flash_erase. flash_erase tool will program "cleanmarker" into OOB
> > > > free area, but it can not get OOB available size.  
> > > 
> > > That's a good reason to expose this property indeed. Do you plan to fix
> > > mtd-utils to use the sysfs value when it's available? Also, do we need
> > > to expose the ECC/free layout as done with the
> > > ECCGETLAYOUT/MEMGETOOBSEL ioctls?
> > >   
> > Yes. I plan to fix mtd-utils problem if this change is accepted.
> > 
> > struct nand_oobinfo and struct nand_ecclayout_user in mtd-abi.h are
> > obsoleted, and user can not get oob layout by ioctl method now.
> > sysfs seems a method to fetch oob layout. But I don't know which
> > user-space case will use oob layout now. Maybe expose them in the future
> > if they are really needed?
> 
> If the layout is not needed yet, let's not expose it. BTW, are you
> really using JFFS2 on modern NAND chips? Sounds like a bad idea to me.
Yes. I tested Micron SLC NAND with 4K page size and 224 OOB size these
days. Jffs2 runs good on this NAND.
Boris Brezillon April 4, 2018, 8:05 p.m. UTC | #7
On Tue, 3 Apr 2018 19:01:03 +0800
xiaolei li <xiaolei.li@mediatek.com> wrote:

> On Tue, 2018-04-03 at 12:14 +0200, Boris Brezillon wrote:
> > On Tue, 3 Apr 2018 17:40:11 +0800
> > xiaolei li <xiaolei.li@mediatek.com> wrote:
> >   
> > > On Tue, 2018-04-03 at 10:43 +0200, Boris Brezillon wrote:  
> > > > On Tue, 3 Apr 2018 10:46:58 +0800
> > > > xiaolei li <xiaolei.li@mediatek.com> wrote:
> > > >     
> > > > > Hello Boris,
> > > > > 
> > > > > On Mon, 2018-04-02 at 14:15 +0200, Boris Brezillon wrote:    
> > > > > > Hi Xiaolei,
> > > > > > 
> > > > > > On Mon, 2 Apr 2018 16:20:10 +0800
> > > > > > Xiaolei Li <xiaolei.li@mediatek.com> wrote:
> > > > > >       
> > > > > > > Expose mtd OOB available size by sysfs file. Then users can get available
> > > > > > > OOB size by accessing /sys/class/mtd/mtdX/oobavail.      
> > > > > > 
> > > > > > May I ask why you need to expose that? I'm not against exposing new
> > > > > > things through sysfs, but since this is part of the ABI, I'd like to be
> > > > > > sure we actually need it.
> > > > > >       
> > > > > That is user-space can write OOB data through ioctl MEMWRITE now.
> > > > > If OOB operation mode is MTD_OPS_AUTO_OOB, user should know how many
> > > > > OOB available bytes it can use. But I didn't find a way to get it. (If
> > > > > there is already a method, please kindly let me know, thanks.)    
> > > > 
> > > > Nope. We have the ECCGETLAYOUT ioctl, but it's not reliable because of
> > > > the MTD_MAX_OOBFREE_ENTRIES limitation.
> > > >     
> > > > > 
> > > > > One problem I know is to do Jffs2 type flash erase using MTD user-space
> > > > > tool flash_erase. flash_erase tool will program "cleanmarker" into OOB
> > > > > free area, but it can not get OOB available size.    
> > > > 
> > > > That's a good reason to expose this property indeed. Do you plan to fix
> > > > mtd-utils to use the sysfs value when it's available? Also, do we need
> > > > to expose the ECC/free layout as done with the
> > > > ECCGETLAYOUT/MEMGETOOBSEL ioctls?
> > > >     
> > > Yes. I plan to fix mtd-utils problem if this change is accepted.
> > > 
> > > struct nand_oobinfo and struct nand_ecclayout_user in mtd-abi.h are
> > > obsoleted, and user can not get oob layout by ioctl method now.
> > > sysfs seems a method to fetch oob layout. But I don't know which
> > > user-space case will use oob layout now. Maybe expose them in the future
> > > if they are really needed?  
> > 
> > If the layout is not needed yet, let's not expose it. BTW, are you
> > really using JFFS2 on modern NAND chips? Sounds like a bad idea to me.  
> Yes. I tested Micron SLC NAND with 4K page size and 224 OOB size these
> days. Jffs2 runs good on this NAND.

Yes, it should work, but I'm not sure JFFS2 scales well on >128MB
NANDs, and people tend to use UBI on such devices nowadays (this + the
fact that JFFS2 is not actively maintained).

Anyway, I guess your change is acceptable, I'd just like to see
patches for mtd-utils using this sysfs entry now ;-).

Regards,

Boris
xiaolei li April 8, 2018, 1:26 a.m. UTC | #8
On Wed, 2018-04-04 at 22:05 +0200, Boris Brezillon wrote:
> On Tue, 3 Apr 2018 19:01:03 +0800
> xiaolei li <xiaolei.li@mediatek.com> wrote:
> 
> > On Tue, 2018-04-03 at 12:14 +0200, Boris Brezillon wrote:
> > > On Tue, 3 Apr 2018 17:40:11 +0800
> > > xiaolei li <xiaolei.li@mediatek.com> wrote:
> > >   
> > > > On Tue, 2018-04-03 at 10:43 +0200, Boris Brezillon wrote:  
> > > > > On Tue, 3 Apr 2018 10:46:58 +0800
> > > > > xiaolei li <xiaolei.li@mediatek.com> wrote:
> > > > >     
> > > > > > Hello Boris,
> > > > > > 
> > > > > > On Mon, 2018-04-02 at 14:15 +0200, Boris Brezillon wrote:    
> > > > > > > Hi Xiaolei,
> > > > > > > 
> > > > > > > On Mon, 2 Apr 2018 16:20:10 +0800
> > > > > > > Xiaolei Li <xiaolei.li@mediatek.com> wrote:
> > > > > > >       
> > > > > > > > Expose mtd OOB available size by sysfs file. Then users can get available
> > > > > > > > OOB size by accessing /sys/class/mtd/mtdX/oobavail.      
> > > > > > > 
> > > > > > > May I ask why you need to expose that? I'm not against exposing new
> > > > > > > things through sysfs, but since this is part of the ABI, I'd like to be
> > > > > > > sure we actually need it.
> > > > > > >       
> > > > > > That is user-space can write OOB data through ioctl MEMWRITE now.
> > > > > > If OOB operation mode is MTD_OPS_AUTO_OOB, user should know how many
> > > > > > OOB available bytes it can use. But I didn't find a way to get it. (If
> > > > > > there is already a method, please kindly let me know, thanks.)    
> > > > > 
> > > > > Nope. We have the ECCGETLAYOUT ioctl, but it's not reliable because of
> > > > > the MTD_MAX_OOBFREE_ENTRIES limitation.
> > > > >     
> > > > > > 
> > > > > > One problem I know is to do Jffs2 type flash erase using MTD user-space
> > > > > > tool flash_erase. flash_erase tool will program "cleanmarker" into OOB
> > > > > > free area, but it can not get OOB available size.    
> > > > > 
> > > > > That's a good reason to expose this property indeed. Do you plan to fix
> > > > > mtd-utils to use the sysfs value when it's available? Also, do we need
> > > > > to expose the ECC/free layout as done with the
> > > > > ECCGETLAYOUT/MEMGETOOBSEL ioctls?
> > > > >     
> > > > Yes. I plan to fix mtd-utils problem if this change is accepted.
> > > > 
> > > > struct nand_oobinfo and struct nand_ecclayout_user in mtd-abi.h are
> > > > obsoleted, and user can not get oob layout by ioctl method now.
> > > > sysfs seems a method to fetch oob layout. But I don't know which
> > > > user-space case will use oob layout now. Maybe expose them in the future
> > > > if they are really needed?  
> > > 
> > > If the layout is not needed yet, let's not expose it. BTW, are you
> > > really using JFFS2 on modern NAND chips? Sounds like a bad idea to me.  
> > Yes. I tested Micron SLC NAND with 4K page size and 224 OOB size these
> > days. Jffs2 runs good on this NAND.
> 
> Yes, it should work, but I'm not sure JFFS2 scales well on >128MB
> NANDs, and people tend to use UBI on such devices nowadays (this + the
> fact that JFFS2 is not actively maintained).
Yes.
> 
> Anyway, I guess your change is acceptable, I'd just like to see
> patches for mtd-utils using this sysfs entry now ;-).
OK. Thanks. I will send mtd-utils patches ASAP.
> 
> Regards,
> 
> Boris
Boris Brezillon April 26, 2018, 6:04 p.m. UTC | #9
On Mon, 2 Apr 2018 16:20:10 +0800
Xiaolei Li <xiaolei.li@mediatek.com> wrote:

> Expose mtd OOB available size by sysfs file. Then users can get available
> OOB size by accessing /sys/class/mtd/mtdX/oobavail.
> 
> Signed-off-by: Xiaolei Li <xiaolei.li@mediatek.com>

Applied.

Thanks,

Boris

> ---
>  Documentation/ABI/testing/sysfs-class-mtd |  8 ++++++++
>  drivers/mtd/mtdcore.c                     | 10 ++++++++++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-class-mtd b/Documentation/ABI/testing/sysfs-class-mtd
> index f34e5923..3bc7c0a 100644
> --- a/Documentation/ABI/testing/sysfs-class-mtd
> +++ b/Documentation/ABI/testing/sysfs-class-mtd
> @@ -232,3 +232,11 @@ Description:
>  		of the parent (another partition or a flash device) in bytes.
>  		This attribute is absent on flash devices, so it can be used
>  		to distinguish them from partitions.
> +
> +What:		/sys/class/mtd/mtdX/oobavail
> +Date:		April 2018
> +KernelVersion:	4.16
> +Contact:	linux-mtd@lists.infradead.org
> +Description:
> +		Number of bytes available for a client to place data into
> +		the out of band area.
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index 807d17d..99d9352 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -210,6 +210,15 @@ static ssize_t mtd_oobsize_show(struct device *dev,
>  }
>  static DEVICE_ATTR(oobsize, S_IRUGO, mtd_oobsize_show, NULL);
>  
> +static ssize_t mtd_oobavail_show(struct device *dev,
> +				 struct device_attribute *attr, char *buf)
> +{
> +	struct mtd_info *mtd = dev_get_drvdata(dev);
> +
> +	return snprintf(buf, PAGE_SIZE, "%lu\n", (unsigned long)mtd->oobavail);
> +}
> +static DEVICE_ATTR(oobavail, S_IRUGO, mtd_oobavail_show, NULL);
> +
>  static ssize_t mtd_numeraseregions_show(struct device *dev,
>  		struct device_attribute *attr, char *buf)
>  {
> @@ -327,6 +336,7 @@ static ssize_t mtd_bbtblocks_show(struct device *dev,
>  	&dev_attr_writesize.attr,
>  	&dev_attr_subpagesize.attr,
>  	&dev_attr_oobsize.attr,
> +	&dev_attr_oobavail.attr,
>  	&dev_attr_numeraseregions.attr,
>  	&dev_attr_name.attr,
>  	&dev_attr_ecc_strength.attr,
diff mbox

Patch

diff --git a/Documentation/ABI/testing/sysfs-class-mtd b/Documentation/ABI/testing/sysfs-class-mtd
index f34e5923..3bc7c0a 100644
--- a/Documentation/ABI/testing/sysfs-class-mtd
+++ b/Documentation/ABI/testing/sysfs-class-mtd
@@ -232,3 +232,11 @@  Description:
 		of the parent (another partition or a flash device) in bytes.
 		This attribute is absent on flash devices, so it can be used
 		to distinguish them from partitions.
+
+What:		/sys/class/mtd/mtdX/oobavail
+Date:		April 2018
+KernelVersion:	4.16
+Contact:	linux-mtd@lists.infradead.org
+Description:
+		Number of bytes available for a client to place data into
+		the out of band area.
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 807d17d..99d9352 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -210,6 +210,15 @@  static ssize_t mtd_oobsize_show(struct device *dev,
 }
 static DEVICE_ATTR(oobsize, S_IRUGO, mtd_oobsize_show, NULL);
 
+static ssize_t mtd_oobavail_show(struct device *dev,
+				 struct device_attribute *attr, char *buf)
+{
+	struct mtd_info *mtd = dev_get_drvdata(dev);
+
+	return snprintf(buf, PAGE_SIZE, "%lu\n", (unsigned long)mtd->oobavail);
+}
+static DEVICE_ATTR(oobavail, S_IRUGO, mtd_oobavail_show, NULL);
+
 static ssize_t mtd_numeraseregions_show(struct device *dev,
 		struct device_attribute *attr, char *buf)
 {
@@ -327,6 +336,7 @@  static ssize_t mtd_bbtblocks_show(struct device *dev,
 	&dev_attr_writesize.attr,
 	&dev_attr_subpagesize.attr,
 	&dev_attr_oobsize.attr,
+	&dev_attr_oobavail.attr,
 	&dev_attr_numeraseregions.attr,
 	&dev_attr_name.attr,
 	&dev_attr_ecc_strength.attr,