[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ydqyvme43ul6ui7bl37kv3kuhn7js7tvkje2u4a3vasiw4kgdv@w2govkhaa3xz>
Date: Mon, 1 Dec 2025 16:28:58 +0100
From: Uwe Kleine-König <ukleinek@...nel.org>
To: Biju Das <biju.das.jz@...renesas.com>
Cc: "biju.das.au" <biju.das.au@...il.com>,
Philipp Zabel <p.zabel@...gutronix.de>, "linux-pwm@...r.kernel.org" <linux-pwm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Geert Uytterhoeven <geert+renesas@...der.be>,
Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...renesas.com>,
"linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>, "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Subject: Re: [PATCH v3 6/8] pwm: rzg2l-gpt: Add suspend/resume support
Hello Biju,
On Mon, Dec 01, 2025 at 03:04:08PM +0000, Biju Das wrote:
> You mean to avoid unbalance between suspend()/resume(), we should not
> do error handling in resume()??
Consider the following resume function:
static int myresume(...)
{
ret = enable_some_resource(...);
if (ret)
return ret;
ret = enable_some_other_resource(...)
if (ret) {
disable_some_resource();
return ret;
}
return 0;
}
If disable_some_resource() can fail it might happen that the first call
to myresume() is left with some_resource enabled and some_other_resource
disabled (i.e. if both enable_some_other_resource() and
disable_some_resource() fail). Now if the resume is retried
some_resource is enabled a second time without being tracked and a later
suspend (or remove) won't bring the enable count to 0 and thus leak a
resource.
Best regards
Uwe
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists