linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa@the-dreams.de>
To: Hans de Goede <hdegoede@redhat.com>
Cc: linux-samsung-soc@vger.kernel.org, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	bcm-kernel-feedback-list@broadcom.com, linux-i2c@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC/RFT 00/10] i2c: move handling of suspended adapters to the core
Date: Wed, 12 Dec 2018 00:41:03 +0100	[thread overview]
Message-ID: <20181211234102.GA6701@kunai> (raw)
In-Reply-To: <2094a0d4-733f-7f74-abd2-bdb28edd0f80@redhat.com>


[-- Attachment #1.1: Type: text/plain, Size: 1217 bytes --]

Hi Hans,

thanks for testing this series!

> Note that the i2c-sprd driver changes in your patchset also get close
> to triggering this problem, but they dodge the bullet because there
> are separate system-wide and runtime suspend handlers and only the
> system-wide handlers call the new i2c_mark_adapter_suspended() function.

Yes, this what I assumed to be all around - seperate handlers for RPM
and PM. And I also assumed that they could be seperated if they aren't
already. Until I read...

> As I explain in the commit message of the first attached patch
> simply always using split handlers is not really an option because
> of adapter drivers using DPM_FLAG_SMART_PREPARE or
> DPM_FLAG_SMART_SUSPEND.

... this. I don't know what these flags do (and reading SMART in there
gives me more a 'uh-oh' feeling) but if the handlers can't be split, the
issues you were seeing are a consequence, yes.

For me, this sadly spoils the whole concept. The patches you add make
things even more complicated. Not happy about that.

Looking at the open coded version you did for the designware driver, I
wonder now if it is better to just leave it at driver level? Need to
sleep over it, though.

Thanks again,

   Wolfram


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2018-12-11 23:41 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-10 21:02 [RFC/RFT 00/10] i2c: move handling of suspended adapters to the core Wolfram Sang
2018-12-10 21:02 ` [RFC/RFT 01/10] i2c: add 'is_suspended' flag for i2c adapters Wolfram Sang
2018-12-10 22:03   ` Peter Rosin
2018-12-18 23:33     ` Wolfram Sang
2018-12-19  9:39       ` Geert Uytterhoeven
2018-12-19 16:31         ` Wolfram Sang
2018-12-10 21:03 ` [RFC/RFT 02/10] i2c: reject new transfers when adapters are suspended Wolfram Sang
2018-12-10 21:03 ` [RFC/RFT 03/10] i2c: synquacer: remove unused is_suspended flag Wolfram Sang
2018-12-10 21:04   ` Ard Biesheuvel
2018-12-10 21:03 ` [RFC/RFT 04/10] i2c: brcmstb: use core helper to mark adapter suspended Wolfram Sang
2018-12-11 16:44   ` Kamal Dasu
2018-12-10 21:03 ` [RFC/RFT 05/10] i2c: zx2967: " Wolfram Sang
2018-12-11  2:12   ` Shawn Guo
2018-12-10 21:03 ` [RFC/RFT 06/10] i2c: sprd: don't use pdev as variable name for struct device * Wolfram Sang
2018-12-10 21:03 ` [RFC/RFT 07/10] i2c: sprd: use core helper to mark adapter suspended Wolfram Sang
2018-12-10 21:03 ` [RFC/RFT 08/10] i2c: exynos5: " Wolfram Sang
2018-12-18 11:23   ` Marek Szyprowski
2018-12-18 19:52     ` Wolfram Sang
2018-12-10 21:03 ` [RFC/RFT 09/10] i2c: s3c2410: " Wolfram Sang
2018-12-18 11:24   ` Marek Szyprowski
2018-12-10 21:03 ` [RFC/RFT 10/10] i2c: rcar: add suspend/resume support Wolfram Sang
2018-12-10 21:52   ` Peter Rosin
2018-12-18 23:47     ` Wolfram Sang
2018-12-11 19:24 ` [RFC/RFT 00/10] i2c: move handling of suspended adapters to the core Hans de Goede
2018-12-11 23:41   ` Wolfram Sang [this message]
2018-12-12 10:09     ` Hans de Goede
2018-12-18 20:17       ` Wolfram Sang
2018-12-18 21:44         ` Hans de Goede
2018-12-18 23:32           ` Wolfram Sang

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=20181211234102.GA6701@kunai \
    --to=wsa@the-dreams.de \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=wsa+renesas@sang-engineering.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;
as well as URLs for NNTP newsgroup(s).