From: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Paul Osmialowski <p.osmialowsk-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Cc: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>,
Jonathan Corbet <corbet-T1hC0tSOHrs@public.gmane.org>,
Greg Kroah-Hartman
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
Kukjin Kim <kgene-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC 2/3] regmap: Use the enhancement of i2c API to address circular dependency problem
Date: Fri, 16 Jan 2015 18:36:35 +0000 [thread overview]
Message-ID: <20150116183635.GH3856@sirena.org.uk> (raw)
In-Reply-To: <alpine.DEB.2.10.1501161811280.21618-rWxBz+Dn3+580y0nlK0+ubjjLBE8jN/0@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2156 bytes --]
On Fri, Jan 16, 2015 at 06:36:14PM +0100, Paul Osmialowski wrote:
> On Fri, 16 Jan 2015, Mark Brown wrote:
> >I don't know what this means, sorry. I'm also very worried about the
> >fact that this is being discussed purely in terms of I2C - why would
> >this not affect other buses?
> I tried to open some gate for further extension to any bus that is used for
> regmap communications. Currently it goes down to regmap-i2c.c since I
> enhanced i2c API for this. Anyone who feels it is useful or saves oneself
> from locking troubles can voluntarily adapt other regmap-i2c.* places (as
> needed?).
> My whole point is that I proposed a way to solve nasty deadlock which is
> better to fix than just leave as it is. I got a feeling that situation I
> adressed here may occur others too, so I proposed this extension that allows
> future adaptations. I don't expect it to be accepted easily (i.e. I'm new
> here and have mixed feelins about proposing changes that go so far),
> therefore I prepared other solution for this particular deadlock that occurs
> on this particular device.
What I'm saying is that I want to understand this change from a point of
view that isn't tied to I2C - at the regmap level what is this doing,
I2C is a bus that has some properties which you're saying needs some
changes, what are those properties and those changes?
> >>+ void (*reg_unprepare_sync_io)(void *context);
> >The first question here is why this only affects synchronous I/O or
> >alternatively why these operations have _sync in the name if they aren't
> >for synchronous I/O.
> IMHO this whole idea is against asynchronous I/O.
Can you be more specific please? If something needs preparing it seems
like it'd need preparing over an async transaction just as much as over
a synchronous one.
> >>+ if (bus) {
> >>+ map->reg_prepare_sync_io = regmap_bus_prepare_sync_io;
> >>+ map->reg_unprepare_sync_io = regmap_bus_unprepare_sync_io;
> >>+ }
> >Why are we using these indirections instead of assigning the operation
> >directly? They...
> I followed the pattern used throughout this file.
Not in this pattern where the caller needs to check too.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2015-01-16 18:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-16 14:39 [RFC 1/3] i2c: Enhancement of i2c API to address circular lock dependency problem Paul Osmialowski
2015-01-16 14:39 ` [RFC 2/3] regmap: Use the enhancement of i2c API to address circular " Paul Osmialowski
2015-01-16 16:23 ` Mark Brown
2015-01-16 17:36 ` Paul Osmialowski
[not found] ` <alpine.DEB.2.10.1501161811280.21618-rWxBz+Dn3+580y0nlK0+ubjjLBE8jN/0@public.gmane.org>
2015-01-16 18:36 ` Mark Brown [this message]
2015-01-19 9:31 ` Paul Osmialowski
2015-01-19 19:25 ` Mark Brown
2015-01-20 11:14 ` Paul Osmialowski
[not found] ` <alpine.DEB.2.10.1501201214200.8428-rWxBz+Dn3+580y0nlK0+ubjjLBE8jN/0@public.gmane.org>
2015-01-27 18:12 ` Mark Brown
2015-01-16 14:39 ` [RFC 3/3] i2c: s3c2410: Adopt i2c-s3c2410 driver for new enhancement of i2c API Paul Osmialowski
[not found] ` <1421419194-1849-3-git-send-email-p.osmialowsk-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2015-01-16 16:28 ` Mark Brown
[not found] ` <1421419194-1849-1-git-send-email-p.osmialowsk-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2015-01-18 6:30 ` [RFC 1/3] i2c: Enhancement of i2c API to address circular lock dependency problem Tomasz Figa
2015-01-18 10:54 ` Krzysztof Kozlowski
2015-01-18 13:41 ` Mark Brown
2015-02-25 19:47 ` Mike Turquette
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=20150116183635.GH3856@sirena.org.uk \
--to=broonie-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
--cc=corbet-T1hC0tSOHrs@public.gmane.org \
--cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
--cc=kgene-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=p.osmialowsk-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org \
/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;
as well as URLs for NNTP newsgroup(s).