Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: 0lS7gE5IWsPzXAQqFZdtq2N0iRBMqpYsqSWJHKTTVsgWzuc3E4m2vFF2Ira8G3XkmmNARgMZc8
 IRDr82Zoi3EZ+6AKafT+7OHBhoYQZyQEpshU2+kZa++9SJITQG6891C19sAlwKl2NwReccTApx
 /aWgR2khjyaIVv3+X4M7m0bWAnsL9UieXwa5zaZV7djw3q6Eq4gLZ3t9RUayaDh1v/yOP8XlDF
 XSlHQaLKzonCavdi6DTmO9G4kdwuIqA/w12WP0aiyUsOcLMB8PDdOb301BWp5SgUqrq7Qz+fLy
 FF8=
From:   <Claudiu.Beznea@microchip.com>
To:     <Nicolas.Ferre@microchip.com>, <sre@kernel.org>,
        <alexandre.belloni@bootlin.com>, <Ludovic.Desroches@microchip.com>
CC:     <linux-pm@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>,
        <linux-kernel@vger.kernel.org>, <lkp@intel.com>,
        <dan.carpenter@oracle.com>
Subject: Re: [PATCH] power: reset: at91-reset: free resources on exit path
Thread-Topic: [PATCH] power: reset: at91-reset: free resources on exit path
Thread-Index: AQHXJwVGaY7mOnkUnUSKpK/+jjlOVw==
Date:   Thu, 1 Apr 2021 14:42:47 +0000
Message-ID: <ee7f39b3-8f7a-deb4-b4b2-dfc8e2ba86f9@microchip.com>
References: <20210209110109.906034-1-claudiu.beznea@microchip.com>
 <b18fc346-498d-4c6f-7f06-a6148a17d216@microchip.com>
In-Reply-To: <b18fc346-498d-4c6f-7f06-a6148a17d216@microchip.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.7.1
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <947C63E03A38D045A5DD32A21DDE0AA8@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: bb2a6723-71ce-4bb0-1530-08d8f51c6acd
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2021 14:42:47.1180
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3f4057f3-b418-4d4e-ba84-d55b4e897d88
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 0t5jw+QHQ/l3wKQ7R7DENUDxEwGJp0xYSb3m8Z4IcCTyZQMp8yzsRo/RK4WUD+mAsdDIeX6KvY656FhCItYccAEAAKpZwBPo0e0pc7qKNr4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4722
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 31.03.2021 11:18, Nicolas Ferre wrote:
> On 09/02/2021 at 12:01, Claudiu Beznea wrote:
>> Free resources on exit path (failure path of probe and remove).
>=20
> I'm not sure we can use this driver as a module anyway.
>=20
> Otherwise, it looks fine, but isn't it possible to use devm_of_iomap(),
> even in loop, and avoid having to deal with exit path?

For:
reset->rstc_base =3D of_iomap(pdev->dev.of_node, 0);

it should work.

For the maps in the loop I have to double check. Basically, the struct
resource object to pass to devm_of_iomap() is needed and for this the
pointer to a struct platform_device object corresponding to the node we
look for in the loop is needed. So, I think this cannot be done this way.

>=20
>> Reported-by: kernel test robot <lkp@intel.com>
>> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
>> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
>> ---
>> =A0 drivers/power/reset/at91-reset.c | 25 ++++++++++++++++++++-----
>> =A0 1 file changed, 20 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/power/reset/at91-reset.c
>> b/drivers/power/reset/at91-reset.c
>> index 3ff9d93a5226..2ff7833153b6 100644
>> --- a/drivers/power/reset/at91-reset.c
>> +++ b/drivers/power/reset/at91-reset.c
>> @@ -206,7 +206,8 @@ static int __init at91_reset_probe(struct
>> platform_device *pdev)
>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 if (!reset->ramc_base[idx]) {
>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 dev_err(&pdev->dev, =
"Could not map ram controller
>> address\n");
>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 of_node_put(np);
>> -=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return -ENODEV;
>> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ret =3D -ENODEV;
>> +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 goto unmap;
>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 }
>> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 idx++;
>> =A0=A0=A0=A0=A0=A0=A0=A0=A0 }
>> @@ -218,13 +219,15 @@ static int __init at91_reset_probe(struct
>> platform_device *pdev)
>> =A0=A0=A0=A0=A0 reset->args =3D (u32)match->data;
>> =A0 =A0=A0=A0=A0=A0 reset->sclk =3D devm_clk_get(&pdev->dev, NULL);
>> -=A0=A0=A0 if (IS_ERR(reset->sclk))
>> -=A0=A0=A0=A0=A0=A0=A0 return PTR_ERR(reset->sclk);
>> +=A0=A0=A0 if (IS_ERR(reset->sclk)) {
>> +=A0=A0=A0=A0=A0=A0=A0 ret =3D PTR_ERR(reset->sclk);
>> +=A0=A0=A0=A0=A0=A0=A0 goto unmap;
>> +=A0=A0=A0 }
>> =A0 =A0=A0=A0=A0=A0 ret =3D clk_prepare_enable(reset->sclk);
>> =A0=A0=A0=A0=A0 if (ret) {
>> =A0=A0=A0=A0=A0=A0=A0=A0=A0 dev_err(&pdev->dev, "Could not enable slow c=
lock\n");
>> -=A0=A0=A0=A0=A0=A0=A0 return ret;
>> +=A0=A0=A0=A0=A0=A0=A0 goto unmap;
>> =A0=A0=A0=A0=A0 }
>> =A0 =A0=A0=A0=A0=A0 platform_set_drvdata(pdev, reset);
>> @@ -239,21 +242,33 @@ static int __init at91_reset_probe(struct
>> platform_device *pdev)
>> =A0=A0=A0=A0=A0 ret =3D register_restart_handler(&reset->nb);
>> =A0=A0=A0=A0=A0 if (ret) {
>> =A0=A0=A0=A0=A0=A0=A0=A0=A0 clk_disable_unprepare(reset->sclk);
>> -=A0=A0=A0=A0=A0=A0=A0 return ret;
>> +=A0=A0=A0=A0=A0=A0=A0 goto unmap;
>> =A0=A0=A0=A0=A0 }
>> =A0 =A0=A0=A0=A0=A0 at91_reset_status(pdev, reset->rstc_base);
>> =A0 =A0=A0=A0=A0=A0 return 0;
>> +
>> +unmap:
>> +=A0=A0=A0 iounmap(reset->rstc_base);
>> +=A0=A0=A0 for (idx =3D 0; idx < ARRAY_SIZE(reset->ramc_base); idx++)
>> +=A0=A0=A0=A0=A0=A0=A0 iounmap(reset->ramc_base[idx]);
>=20
> But if we keep this loop, I have the feeling that some kind of
> "of_node_put()" is needed as well.

No! In the loop:

for_each_matching_node_and_match(np, at91_ramc_of_match, &match) {
	reset->ramc_lpr =3D (u32)match->data;
	reset->ramc_base[idx] =3D of_iomap(np, 0);
	if (!reset->ramc_base[idx]) {
		dev_err(&pdev->dev, "Could not map ram controller address\n");
		of_node_put(np);
		ret =3D -ENODEV;
		goto unmap;
	}
	idx++;
}

the of_node_put() is needed only if the loop is interrupted as the macro:
for_each_matching_node_and_match() is defined as follows:

#define for_each_matching_node_and_match(dn, matches, match) \
	for (dn =3D of_find_matching_node_and_match(NULL, matches, match); \
	     dn; dn =3D of_find_matching_node_and_match(dn, matches, match))

and of_find_matching_node_and_match() will return a np with refcount
incremented but at the next loop step the of_find_matching_node_and_match()
will be called with the same np pointer and the np refcount will be
decremented.

struct device_node *of_find_matching_node_and_match(
		struct device_node *from,
		const struct of_device_id *matches,
		const struct of_device_id **match)
{
	// ...
	of_node_put(from);
	// ...
}

>=20
>> +
>> +=A0=A0=A0 return ret;
>> =A0 }
>> =A0 =A0 static int __exit at91_reset_remove(struct platform_device *pdev=
)
>> =A0 {
>> =A0=A0=A0=A0=A0 struct at91_reset *reset =3D platform_get_drvdata(pdev);
>> +=A0=A0=A0 int idx;
>> =A0 =A0=A0=A0=A0=A0 unregister_restart_handler(&reset->nb);
>> =A0=A0=A0=A0=A0 clk_disable_unprepare(reset->sclk);
>> =A0 +=A0=A0=A0 iounmap(reset->rstc_base);
>> +=A0=A0=A0 for (idx =3D 0; idx < ARRAY_SIZE(reset->ramc_base); idx++)
>> +=A0=A0=A0=A0=A0=A0=A0 iounmap(reset->ramc_base[idx]);
>=20
> Ditto
>=20
>> +
>> =A0=A0=A0=A0=A0 return 0;
>> =A0 }
>> =A0
>=20
>=20