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;
> }
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
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: 47+ 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 ` Sean Nyekjaer
2021-10-11 11:52 ` [PATCH 1/3] mtd: core: protect access to MTD " Sean Nyekjaer
2021-10-11 11:52 ` Sean Nyekjaer
2021-10-11 13:37 ` Boris Brezillon
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-14 6:50 ` kernel test robot
2021-10-14 6:50 ` kernel test robot
2021-10-15 6:55 ` Boris Brezillon [this message]
2021-10-15 6:55 ` [PATCH 1/3] mtd: core: protect access to MTD devices while in suspend Boris Brezillon
2021-10-11 11:52 ` [PATCH 2/3] mtd: rawnand: remove suspended check Sean Nyekjaer
2021-10-11 11:52 ` Sean Nyekjaer
2021-10-11 11:52 ` [PATCH 3/3] mtd: mtdconcat: add suspend lock handling Sean Nyekjaer
2021-10-11 11:52 ` Sean Nyekjaer
2021-10-11 13:15 ` Boris Brezillon
2021-10-11 13:15 ` Boris Brezillon
2021-10-11 13:27 ` Boris Brezillon
2021-10-11 13:27 ` Boris Brezillon
2021-10-11 13:35 ` Sean Nyekjaer
2021-10-11 13:35 ` Sean Nyekjaer
2021-10-11 13:49 ` Boris Brezillon
2021-10-11 13:49 ` Boris Brezillon
2021-10-11 13:58 ` 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-11 14:05 ` Boris Brezillon
2021-10-15 6:22 ` Miquel Raynal
2021-10-15 6:22 ` Miquel Raynal
2021-10-19 18:08 ` Sean Nyekjaer
2021-10-19 18:08 ` Sean Nyekjaer
2021-10-20 6:52 ` Boris Brezillon
2021-10-20 6:52 ` Boris Brezillon
2021-10-20 7:00 ` Boris Brezillon
2021-10-20 7:00 ` Boris Brezillon
2021-10-20 7:12 ` Miquel Raynal
2021-10-20 7:12 ` Miquel Raynal
2021-10-20 7:23 ` Sean Nyekjaer
2021-10-20 7:23 ` Sean Nyekjaer
2021-10-20 7:47 ` Boris Brezillon
2021-10-20 7:47 ` Boris Brezillon
2021-10-20 7:12 ` Sean Nyekjaer
2021-10-20 7:12 ` Sean Nyekjaer
2021-10-20 7:23 ` Miquel Raynal
2021-10-20 7:23 ` Miquel Raynal
2021-10-20 7:30 ` Boris Brezillon
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.