Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp350810pxb; Thu, 5 Nov 2020 01:32:52 -0800 (PST) X-Google-Smtp-Source: ABdhPJyv39mZC7+UHv8QqfBWZlm69JwpXnMw+NeqrJJdyQMScPWHT3qj6QyaTXHBxbUmA9BP92ax X-Received: by 2002:aa7:c40b:: with SMTP id j11mr1565910edq.151.1604568771801; Thu, 05 Nov 2020 01:32:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604568771; cv=none; d=google.com; s=arc-20160816; b=e9kOLs+nKiGrwg3ERa0ABRDRhfG5OJCv5y2nSQ9ZyBCNGq575tZaY8Ap72IwPhEMwJ ubImAc/IhVpaLMZx37JISZHYjwoc6pZKMIaHllapp9/f6QSmoryKa922g23ruqTfdFb8 lF8nruXoQ1FIQQT5ltlufKsUXCm3Jb9ILRDfmE5Lb1IxyA8vkVymm1MuNuW5DkkQeYVk udzTFS2JpPZCKFv67JZpSIJCWO7LF/f09vZqL7cPJ3dMnMDEUhfwrlS/BrISLvb5YLdm BmEf8BGXCXM++4R1OPukLFFmpFufBGFYKq+DadakcpLc8O1tOFJ4PbabHo4zFIHRULHr +rBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:in-reply-to :date:cc:to:from:subject:message-id; bh=j2VJOyFSasj0I08sRK4OEusP8NKyXInh6Drtqte3k6Y=; b=EZqUVUWwwU34KYXinGmkaOW/HVXxvMnsgB+vLYs7syNY3rI7kILsTC53vYoKub1GCz HX1092ILcRhKG9USfVjKY6jypMpn47Ab+2uj+NN5tOew+bYdyCNDWbvaU586jLIZZ/X5 JC+LLW8nkg0zLuh0jfSk91y3OCJD1XtbyVMAG1AuYtTBvxnY7Fl8aL6fQpnrq0nPZ1aw m9R2o9RIch1l0d0keSjPJiIenZ0bfIxR3P3yY1ukMiO67M5KyNlcUQLYx1/95pSP4MGv v97p89J2B4LQyK9tU+igmBUE79EHwJeyGvqnD0SLCOUHDWbf4it+VTObbTGkivlbRzU2 0HgQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x37si844146ede.385.2020.11.05.01.32.29; Thu, 05 Nov 2020 01:32:51 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731052AbgKEJ2t (ORCPT + 99 others); Thu, 5 Nov 2020 04:28:49 -0500 Received: from mx2.suse.de ([195.135.220.15]:55458 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730681AbgKEJ2n (ORCPT ); Thu, 5 Nov 2020 04:28:43 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id DC238AC19; Thu, 5 Nov 2020 09:28:40 +0000 (UTC) Message-ID: <47eaba0bc71c6e23bff87b8a01cebf0c6d12efd0.camel@suse.de> Subject: Re: [PATCH v3 01/11] firmware: raspberrypi: Introduce devm_rpi_firmware_get() From: Nicolas Saenz Julienne To: Bartosz Golaszewski Cc: Uwe =?ISO-8859-1?Q?Kleine-K=F6nig?= , LKML , Florian Fainelli , Ray Jui , Scott Branden , bcm-kernel-feedback-list@broadcom.com, linux-pwm@vger.kernel.org, arm-soc , linux-devicetree , wahrenst@gmx.net, Linux Input , Dmitry Torokhov , Greg KH , devel@driverdev.osuosl.org, Philipp Zabel , linux-gpio , Linus Walleij , linux-clk , Stephen Boyd , linux-rpi-kernel@lists.infradead.org, Andy Shevchenko Date: Thu, 05 Nov 2020 10:28:38 +0100 In-Reply-To: References: <20201104103938.1286-1-nsaenzjulienne@suse.de> <20201104103938.1286-2-nsaenzjulienne@suse.de> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-oC8aCgFhzSXrvhwX/0tO" User-Agent: Evolution 3.36.5 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-oC8aCgFhzSXrvhwX/0tO Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Bartosz, thanks for the review. On Thu, 2020-11-05 at 10:13 +0100, Bartosz Golaszewski wrote: > > +/** > > + * devm_rpi_firmware_get - Get pointer to rpi_firmware structure. > > + * @firmware_node: Pointer to the firmware Device Tree node. > > + * > > + * Returns NULL is the firmware device is not ready. > > + */ > > +struct rpi_firmware *devm_rpi_firmware_get(struct device *dev, > > + struct device_node *firmware= _node) > > +{ > > + struct platform_device *pdev =3D of_find_device_by_node(firmwar= e_node); > > + struct rpi_firmware *fw; > > + > > + if (!pdev) > > + return NULL; > > + > > + fw =3D platform_get_drvdata(pdev); > > + if (!fw) > > + return NULL; > > + > > + if (!refcount_inc_not_zero(&fw->consumers)) > > + return NULL; > > + > > + if (devm_add_action_or_reset(dev, rpi_firmware_put, fw)) > > + return NULL; > > + > > + return fw; > > +} > > +EXPORT_SYMBOL_GPL(devm_rpi_firmware_get); >=20 > Usually I'd expect the devres variant to simply call > rpi_firmware_get() and then schedule a release callback which would > call whatever function is the release counterpart for it currently. > Devres actions are for drivers which want to schedule some more > unusual tasks at driver detach. Any reason for designing it this way? Yes, see patch #8 where I get rid of rpi_firmware_get() altogether after converting all users to devres. Since there is no use for the vanilla versi= on of the function anymore, I figured it'd be better to merge everything into devm_rpi_firmware_get(). That said it's not something I have strong feeling= s about. Regards, Nicolas --=-oC8aCgFhzSXrvhwX/0tO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEErOkkGDHCg2EbPcGjlfZmHno8x/4FAl+jxccACgkQlfZmHno8 x/5VuAf/ZVJHy+YDj0FEO4FzcWJ4vn2WN7US3fwbVPePjVLjGsdlhWl+H5zdV5W2 ZNDlMxJ8w+gcUcLGCaov80hxbNVMQJgoiK/0AeaNxVaa/6fK+IOV05LYOKCIET4a 4FhlGaazIlYPqNLtlW2lCQHmFb7fK+sHX4BQltlAA44qaBVZv206o8WOvmUmxIrz d3rUtSsUcHJMf+HlCRrKol2ZEmgPjSUFdsGnvaoFVtlxeHGvSJ53cOydnRJK27TN bITVEZcyTfW/u7Vd+cOLi3Rd3DuzzIFbxW1nb4nIqy2mg3bg2pjFYkkshrV8m7mA LAhpfGsro/83lduAxqUNuNjw2PoQHQ== =b2j1 -----END PGP SIGNATURE----- --=-oC8aCgFhzSXrvhwX/0tO--