public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Sean Nyekjaer <sean@geanix.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Boris Brezillon <bbrezillon@kernel.org>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] mtd: core: protect access to MTD devices while in suspend
Date: Fri, 15 Oct 2021 08:55:11 +0200	[thread overview]
Message-ID: <20211015085511.0e2ac916@collabora.com> (raw)
In-Reply-To: <20211011115253.38497-2-sean@geanix.com>

On Mon, 11 Oct 2021 13:52:51 +0200
Sean Nyekjaer <sean@geanix.com> wrote:

>  struct mtd_info {
> @@ -476,10 +478,49 @@ static inline u32 mtd_oobavail(struct mtd_info *mtd, struct mtd_oob_ops *ops)
>  	return ops->mode == MTD_OPS_AUTO_OOB ? mtd->oobavail : mtd->oobsize;
>  }
>  
> +static inline void mtd_start_access(struct mtd_info *mtd)
> +{
> +	struct mtd_info *master = mtd_get_master(mtd);

mtd_start_{access,end}() should only be called on master devices, so I
guess you can drop the mtd_get_master() call and use mtd directly.
Maybe add a WARN_ON_ONCE(mtd != mtd_get_master(mtd)) so we can
easily catch silly mistakes.

> +
> +	/*
> +	 * Don't take the suspend_lock on devices that don't
> +	 * implement the suspend hook. Otherwise, lockdep will
> +	 * complain about nested locks when trying to suspend MTD
> +	 * partitions or MTD devices created by gluebi which are
> +	 * backed by real devices.
> +	 */
> +	if (!master->_suspend)
> +		return;
> +
> +	/*
> +	 * Wait until the device is resumed. Should we have a
> +	 * non-blocking mode here?
> +	 */
> +	while (1) {
> +		down_read(&master->master.suspend_lock);
> +		if (!master->master.suspended)
> +			return;
> +
> +		up_read(&master->master.suspend_lock);
> +		wait_event(master->master.resume_wq, master->master.suspended == 0);
> +	}
> +}
> +
> +static inline void mtd_end_access(struct mtd_info *mtd)
> +{
> +	struct mtd_info *master = mtd_get_master(mtd);
> +
> +	if (!master->_suspend)
> +		return;
> +
> +	up_read(&master->master.suspend_lock);
> +}
> +
>  static inline int mtd_max_bad_blocks(struct mtd_info *mtd,
>  				     loff_t ofs, size_t len)
>  {
>  	struct mtd_info *master = mtd_get_master(mtd);
> +	int ret;
>  
>  	if (!master->_max_bad_blocks)
>  		return -ENOTSUPP;
> @@ -487,8 +528,12 @@ static inline int mtd_max_bad_blocks(struct mtd_info *mtd,
>  	if (mtd->size < (len + ofs) || ofs < 0)
>  		return -EINVAL;
>  
> -	return master->_max_bad_blocks(master, mtd_get_master_ofs(mtd, ofs),
> -				       len);
> +	mtd_start_access(mtd);
> +	ret = master->_max_bad_blocks(master, mtd_get_master_ofs(mtd, ofs),
> +				      len);
> +	mtd_end_access(mtd);

Please pass the master to those functions, there's no point walking the
parent chain again in the start/end_access() functions if you already
have the master retrieved in the caller. Oh, and there seems to be a
common pattern here, so maybe it's worth adding those macros:

#define mtd_no_suspend_void_call(master, method, ...) \
	mtd_start_access(master); \
	master->method(master, __VA_ARGS__); \
	mtd_end_access(master);

#define mtd_no_suspend_ret_call(ret, master, method, ...) \
	mtd_start_access(master); \
	ret = master->method(master, __VA_ARGS__); \
	mtd_end_access(master);

I don't really like the helper names, so feel free to propose something
else.

> +
> +	return ret;
>  }
>  


  parent reply	other threads:[~2021-10-15  6:55 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-11 11:52 [PATCH 0/3] mtd: core: protect access to mtd devices while in suspend Sean Nyekjaer
2021-10-11 11:52 ` [PATCH 1/3] mtd: core: protect access to MTD " Sean Nyekjaer
2021-10-11 13:37   ` Boris Brezillon
2021-10-14  6:50   ` [mtd] d3ff51cfa9: WARNING:at_kernel/locking/rwsem.c:#down_read kernel test robot
2021-10-15  6:55   ` Boris Brezillon [this message]
2021-10-11 11:52 ` [PATCH 2/3] mtd: rawnand: remove suspended check Sean Nyekjaer
2021-10-11 11:52 ` [PATCH 3/3] mtd: mtdconcat: add suspend lock handling Sean Nyekjaer
2021-10-11 13:15   ` Boris Brezillon
2021-10-11 13:27     ` Boris Brezillon
2021-10-11 13:35       ` Sean Nyekjaer
2021-10-11 13:49         ` Boris Brezillon
2021-10-11 13:58   ` Boris Brezillon
2021-10-11 14:05 ` [PATCH 0/3] mtd: core: protect access to mtd devices while in suspend Boris Brezillon
2021-10-15  6:22   ` Miquel Raynal
2021-10-19 18:08     ` Sean Nyekjaer
2021-10-20  6:52       ` Boris Brezillon
2021-10-20  7:00         ` Boris Brezillon
2021-10-20  7:12           ` Miquel Raynal
2021-10-20  7:23             ` Sean Nyekjaer
2021-10-20  7:47               ` Boris Brezillon
2021-10-20  7:12           ` Sean Nyekjaer
2021-10-20  7:23             ` Miquel Raynal
2021-10-20  7:30             ` Boris Brezillon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211015085511.0e2ac916@collabora.com \
    --to=boris.brezillon@collabora.com \
    --cc=bbrezillon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=sean@geanix.com \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox