linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

  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).