[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YaUEQwYeUgqlMOmu@kunai>
Date: Mon, 29 Nov 2021 17:48:03 +0100
From: Wolfram Sang <wsa@...nel.org>
To: Rajat Jain <rajatja@...gle.com>
Cc: Jarkko Nikula <jarkko.nikula@...ux.intel.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org, dtor@...gle.com, rajatxjain@...il.com,
dbasehore@...omium.org
Subject: Re: [PATCH v2 0/3] i2c: Enable asynchronous suspend/resume
Hi,
> As far as I understand, the only reason we might not want a device to be
> marked for asynchronous resume is if we suspect it cannot handle
> concurrent resume with other devices, which does not look to be the
> case.
Since parent-child relationships are handled, I'd say let us try this.
If there are siblings which depend on each other, I think they should be
marked with "device_link_add" anyhow. I am afraid we will encounter some
regressions with such siblings. However, I don't think there will be a
lot and the time savings for all Linux systems may be worth the
(hopefully) little hazzle.
> This patchset marks the designware, the I2c adapters, and the i2c
> clients for asynchronous suspend/resume. In case it helps to gain any
> confidence, the patch 3 (for i2c clients) has been included and shipping
> on all our chromebooks for the past 3+ years, and has not shown any
> issues. The designware and i2c adapters should be easier.
This in deed helps to gain confidence. I agree that the clients are
probably the most tricky ones. If that works on all Chromebooks for 3
years now, I am positive we can test this series in linux-next now.
Thanks for this work,
Wolfram
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists