[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8359caf0-5219-47dc-b68b-41486757be92@tuxon.dev>
Date: Fri, 9 Aug 2024 10:08:57 +0300
From: claudiu beznea <claudiu.beznea@...on.dev>
To: Wolfram Sang <wsa+renesas@...g-engineering.com>,
chris.brandt@...esas.com, andi.shyti@...nel.org, robh@...nel.org,
krzk+dt@...nel.org, conor+dt@...nel.org, geert+renesas@...der.be,
magnus.damm@...il.com, p.zabel@...gutronix.de,
linux-renesas-soc@...r.kernel.org, linux-i2c@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
Subject: Re: [PATCH v3 05/11] i2c: riic: Add suspend/resume support
On 08.08.2024 18:15, Wolfram Sang wrote:
> On Thu, Jul 11, 2024 at 02:52:01PM +0300, Claudiu wrote:
>> From: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
>>
>> Add suspend/resume support for the RIIC driver. This is necessary for the
>> Renesas RZ/G3S SoC which support suspend to deep sleep state where power
>> to most of the SoC components is turned off. As a result the I2C controller
>> needs to be reconfigured after suspend/resume. For this, the reset line
>> was stored in the driver private data structure as well as i2c timings.
>> The reset line and I2C timings are necessary to re-initialize the
>> controller after resume.
>>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
>
> ? Doesn't apply on top of the previous patches for me?
I just checked it on next-20240809. It should be due to commit
e1571b1fb4ff ("i2c: riic: reword according to newest specification")
which introduced changes around riic_algo object, present also in the diff
of this patch.
>
>> +static int riic_i2c_resume(struct device *dev)
>> +{
>> + struct riic_dev *riic = dev_get_drvdata(dev);
>> + int ret;
>> +
>> + ret = reset_control_deassert(riic->rstc);
>> + if (ret)
>> + return ret;
>> +
>> + ret = riic_init_hw(riic);
>> + if (ret) {
>> + reset_control_assert(riic->rstc);
>
> Is this assertion really needed? It is not done when init_hw fails in
> probe().
In case riic_init_hw() fails there is no recovering way for this driver,
AFAICT, and thus there is no point in keeping the reset signal de-asserted.
In probe this is handled by the devres through action or reset function
(riic_reset_control_assert) registered by:
ret = devm_add_action_or_reset(dev, riic_reset_control_assert, rstc);
if (ret)
return ret;
Thank you,
Claudiu Beznea
Powered by blists - more mailing lists