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: vDEUb8LSPlrS3JE+YPvEKf9BoyD387jEE46ihAmYW+W3lpB6K4P4Lnb6w1/FTA+xrwcqaoze67
 Mfhh7LM/YmrVyd345oGUG1y8Hb4kafggLeD5qmQOL2zkdKZbt5k+W4weMSkD6oUW1Yrz5su1+g
 vAq3sJtH7crgBjz/QKEfy/sGg9hDiNOurKy2bZosMfNbHzX8sa8u45VpFR1TtRmEBYLK1OrRnv
 p3guOF9MZ1tgUfl1QT3VGoxrWeNR9FSIy3YEjLsAEPJLIewLoeVSPKQlENaSC1ZZQVUWqYnElU
 b/I=
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/+jjlOV6qfvpmA
Date:   Thu, 1 Apr 2021 14:50:14 +0000
Message-ID: <5fbc077d-1f45-6bc0-8d73-6008c6a28e76@microchip.com>
References: <20210209110109.906034-1-claudiu.beznea@microchip.com>
 <b18fc346-498d-4c6f-7f06-a6148a17d216@microchip.com>
 <ee7f39b3-8f7a-deb4-b4b2-dfc8e2ba86f9@microchip.com>
In-Reply-To: <ee7f39b3-8f7a-deb4-b4b2-dfc8e2ba86f9@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: <1627C4EF6D6D4445930A1E637C215FF6@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 2a4a84a4-bd68-42b2-a9dc-08d8f51d7561
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2021 14:50:14.4237
 (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: VP7YqgTHO7Wc2H5EOU7p6He5giTMHe7B4rWyI3MgyJ4kGfEsIThxtJ9/UUSr9c7jIIhu8PC8lvViNJpgx2dJ+2AWoPZmHQULedeHL9O2U04=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4202
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 01.04.2021 17:42, Claudiu Beznea - M18063 wrote:
> 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).
>>
>> I'm not sure we can use this driver as a module anyway.
>>
>> 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?
>=20
> For:
> reset->rstc_base =3D of_iomap(pdev->dev.of_node, 0);
>=20
> it should work.
>=20
> 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

Just realized I looked at the wrong code. Anyway, I'll double check and ret=
urn.

> 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 =
clock\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]);
>>
>> But if we keep this loop, I have the feeling that some kind of
>> "of_node_put()" is needed as well.
>=20
> No! In the loop:
>=20
> 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++;
> }
>=20
> 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:
>=20
> #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))
>=20
> 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.
>=20
> 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 *pde=
v)
>>> =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]);
>>
>> Ditto
>>
>>> +
>>> =A0=A0=A0=A0=A0 return 0;
>>> =A0 }
>>> =A0
>>
>>
>=20