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;
> }
>
next prev 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