From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
Marek Vasut <marek.vasut@gmail.com>,
Richard Weinberger <richard@nod.at>,
Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>,
linux-mtd@lists.infradead.org,
Robert Jarzmik <robert.jarzmik@free.fr>,
Kyungmin Park <kyungmin.park@samsung.com>
Subject: Re: [PATCH v2 1/2] mtd: Stop directly calling master ->_xxx() hooks from mtdpart code
Date: Tue, 27 Jun 2017 21:52:00 +0200 [thread overview]
Message-ID: <20170627215200.71248cb3@bbrezillon> (raw)
In-Reply-To: <20170627211938.05abf5ac@bbrezillon>
Le Tue, 27 Jun 2017 21:19:38 +0200,
Boris Brezillon <boris.brezillon@free-electrons.com> a écrit :
> >
> > [...]
> >
> > I was also wondering whether this patch couldn't go a step further, and
> > remove conditions like this:
> >
> > if (parent->_panic_write)
> > slave->mtd._panic_write = part_panic_write;
> >
> > Since part_panic_write() should call mtd_panic_write() on the parent
> > (master), which would do its own -EOPNOTSUPP check. But then I suppose
> > that might invert the order of the checks, causing (for example) -EINVAL
> > for out-of-bounds panic write instead of -EOPNOTSUPP. So maybe that's
> > better left alone.
>
> I considered doing that but was too lazy to check if all helpers were
> properly checking the pointer value before dereferencing it :).
I just checked, and it seems we can unconditionally set part hooks and
rely on default mtd_xxx() helpers to detect when the feature is not
supported by the master.
prev parent reply other threads:[~2017-06-27 19:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-25 16:01 [PATCH v2 1/2] mtd: Stop directly calling master ->_xxx() hooks from mtdpart code Boris Brezillon
2017-06-25 16:01 ` [PATCH v2 2/2] mtd: Fallback to ->_read/write_oob() when ->_read/write() is missing Boris Brezillon
2017-06-25 16:36 ` [PATCH v2 1/2] mtd: Stop directly calling master ->_xxx() hooks from mtdpart code Boris Brezillon
2017-06-27 18:46 ` Brian Norris
2017-06-27 19:19 ` Boris Brezillon
2017-06-27 19:52 ` Boris Brezillon [this message]
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=20170627215200.71248cb3@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=cyrille.pitchen@wedev4u.fr \
--cc=dwmw2@infradead.org \
--cc=kyungmin.park@samsung.com \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=richard@nod.at \
--cc=robert.jarzmik@free.fr \
/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.