When we obtain a reference to of a platform_device, we need to release
it via put_device.
Found by cocci:
./platform/nuvoton/npcm-video.c:1677:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function.
./platform/nuvoton/npcm-video.c:1684:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function.
./platform/nuvoton/npcm-video.c:1690:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function.
./platform/nuvoton/npcm-video.c:1694:1-7: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function.
Cc: stable@vger.kernel.org
Fixes: 46c15a4ff1f4 ("media: nuvoton: Add driver for NPCM video capture and encoding engine")
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
---
drivers/media/platform/nuvoton/npcm-video.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/platform/nuvoton/npcm-video.c b/drivers/media/platform/nuvoton/npcm-video.c
index 024cd8ee1709..7b4c23dbe709 100644
--- a/drivers/media/platform/nuvoton/npcm-video.c
+++ b/drivers/media/platform/nuvoton/npcm-video.c
@@ -1673,6 +1673,7 @@ static int npcm_video_ece_init(struct npcm_video *video)
regs = devm_platform_ioremap_resource(ece_pdev, 0);
if (IS_ERR(regs)) {
+ put_device(&ece_pdev->dev);
dev_err(dev, "Failed to parse ECE reg in DTS\n");
return PTR_ERR(regs);
}
@@ -1680,11 +1681,13 @@ static int npcm_video_ece_init(struct npcm_video *video)
video->ece.regmap = devm_regmap_init_mmio(dev, regs,
&npcm_video_ece_regmap_cfg);
if (IS_ERR(video->ece.regmap)) {
+ put_device(&ece_pdev->dev);
dev_err(dev, "Failed to initialize ECE regmap\n");
return PTR_ERR(video->ece.regmap);
}
video->ece.reset = devm_reset_control_get(&ece_pdev->dev, NULL);
+ put_device(&ece_pdev->dev);
if (IS_ERR(video->ece.reset)) {
dev_err(dev, "Failed to get ECE reset control in DTS\n");
return PTR_ERR(video->ece.reset);
--
2.48.0.rc2.279.g1de40edade-googHi Ricardo,
On 21/01/2025 22:14, Ricardo Ribalda wrote:
> When we obtain a reference to of a platform_device, we need to release
> it via put_device.
>
> Found by cocci:
> ./platform/nuvoton/npcm-video.c:1677:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function.
> ./platform/nuvoton/npcm-video.c:1684:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function.
> ./platform/nuvoton/npcm-video.c:1690:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function.
> ./platform/nuvoton/npcm-video.c:1694:1-7: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function.
This driver uses this construct:
struct device *ece_dev __free(put_device) = &ece_pdev->dev;
to automatically call put_device. So this patch would 'put' the device twice.
Does cocci understand constructs like this? If I hadn't looked closely at the
code first, I would just have merged it.
Regards,
Hans
>
> Cc: stable@vger.kernel.org
> Fixes: 46c15a4ff1f4 ("media: nuvoton: Add driver for NPCM video capture and encoding engine")
> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> ---
> drivers/media/platform/nuvoton/npcm-video.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/media/platform/nuvoton/npcm-video.c b/drivers/media/platform/nuvoton/npcm-video.c
> index 024cd8ee1709..7b4c23dbe709 100644
> --- a/drivers/media/platform/nuvoton/npcm-video.c
> +++ b/drivers/media/platform/nuvoton/npcm-video.c
> @@ -1673,6 +1673,7 @@ static int npcm_video_ece_init(struct npcm_video *video)
>
> regs = devm_platform_ioremap_resource(ece_pdev, 0);
> if (IS_ERR(regs)) {
> + put_device(&ece_pdev->dev);
> dev_err(dev, "Failed to parse ECE reg in DTS\n");
> return PTR_ERR(regs);
> }
> @@ -1680,11 +1681,13 @@ static int npcm_video_ece_init(struct npcm_video *video)
> video->ece.regmap = devm_regmap_init_mmio(dev, regs,
> &npcm_video_ece_regmap_cfg);
> if (IS_ERR(video->ece.regmap)) {
> + put_device(&ece_pdev->dev);
> dev_err(dev, "Failed to initialize ECE regmap\n");
> return PTR_ERR(video->ece.regmap);
> }
>
> video->ece.reset = devm_reset_control_get(&ece_pdev->dev, NULL);
> + put_device(&ece_pdev->dev);
> if (IS_ERR(video->ece.reset)) {
> dev_err(dev, "Failed to get ECE reset control in DTS\n");
> return PTR_ERR(video->ece.reset);
>
… > > Found by cocci: > > ./platform/nuvoton/npcm-video.c:1677:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function. … > This driver uses this construct: > > struct device *ece_dev __free(put_device) = &ece_pdev->dev; > > to automatically call put_device. So this patch would 'put' the device twice. > > Does cocci understand constructs like this? … Not yet directly (for coccicheck scripts). https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/scripts/coccinelle/free/put_device.cocci?h=v6.14-rc3 I am unsure under which circumstances support can be added for the detection of scope-based resource management also by the means of the semantic patch language. Regards, Markus
On 21/02/2025 10:04, Hans Verkuil wrote:
> Hi Ricardo,
>
> On 21/01/2025 22:14, Ricardo Ribalda wrote:
>> When we obtain a reference to of a platform_device, we need to release
>> it via put_device.
>>
>> Found by cocci:
>> ./platform/nuvoton/npcm-video.c:1677:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function.
>> ./platform/nuvoton/npcm-video.c:1684:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function.
>> ./platform/nuvoton/npcm-video.c:1690:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function.
>> ./platform/nuvoton/npcm-video.c:1694:1-7: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function.
>
> This driver uses this construct:
>
> struct device *ece_dev __free(put_device) = &ece_pdev->dev;
>
> to automatically call put_device. So this patch would 'put' the device twice.
>
> Does cocci understand constructs like this? If I hadn't looked closely at the
> code first, I would just have merged it.
Oh wait, now that I am reading the following patches I see that it was those later
patches that add the __free code.
This is far too confusing. Please post a v2 that just combines the 'fix references'
and 'use cleanup.h macros' in a single patch. It makes no sense to have this two-phase
approach.
Regards,
Hans
>
> Regards,
>
> Hans
>
>>
>> Cc: stable@vger.kernel.org
>> Fixes: 46c15a4ff1f4 ("media: nuvoton: Add driver for NPCM video capture and encoding engine")
>> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
>> ---
>> drivers/media/platform/nuvoton/npcm-video.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/media/platform/nuvoton/npcm-video.c b/drivers/media/platform/nuvoton/npcm-video.c
>> index 024cd8ee1709..7b4c23dbe709 100644
>> --- a/drivers/media/platform/nuvoton/npcm-video.c
>> +++ b/drivers/media/platform/nuvoton/npcm-video.c
>> @@ -1673,6 +1673,7 @@ static int npcm_video_ece_init(struct npcm_video *video)
>>
>> regs = devm_platform_ioremap_resource(ece_pdev, 0);
>> if (IS_ERR(regs)) {
>> + put_device(&ece_pdev->dev);
>> dev_err(dev, "Failed to parse ECE reg in DTS\n");
>> return PTR_ERR(regs);
>> }
>> @@ -1680,11 +1681,13 @@ static int npcm_video_ece_init(struct npcm_video *video)
>> video->ece.regmap = devm_regmap_init_mmio(dev, regs,
>> &npcm_video_ece_regmap_cfg);
>> if (IS_ERR(video->ece.regmap)) {
>> + put_device(&ece_pdev->dev);
>> dev_err(dev, "Failed to initialize ECE regmap\n");
>> return PTR_ERR(video->ece.regmap);
>> }
>>
>> video->ece.reset = devm_reset_control_get(&ece_pdev->dev, NULL);
>> + put_device(&ece_pdev->dev);
>> if (IS_ERR(video->ece.reset)) {
>> dev_err(dev, "Failed to get ECE reset control in DTS\n");
>> return PTR_ERR(video->ece.reset);
>>
>
>
On Fri, 21 Feb 2025 at 10:18, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
> On 21/02/2025 10:04, Hans Verkuil wrote:
> > Hi Ricardo,
> >
> > On 21/01/2025 22:14, Ricardo Ribalda wrote:
> >> When we obtain a reference to of a platform_device, we need to release
> >> it via put_device.
> >>
> >> Found by cocci:
> >> ./platform/nuvoton/npcm-video.c:1677:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function.
> >> ./platform/nuvoton/npcm-video.c:1684:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function.
> >> ./platform/nuvoton/npcm-video.c:1690:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function.
> >> ./platform/nuvoton/npcm-video.c:1694:1-7: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function.
> >
> > This driver uses this construct:
> >
> > struct device *ece_dev __free(put_device) = &ece_pdev->dev;
> >
> > to automatically call put_device. So this patch would 'put' the device twice.
> >
> > Does cocci understand constructs like this? If I hadn't looked closely at the
> > code first, I would just have merged it.
>
> Oh wait, now that I am reading the following patches I see that it was those later
> patches that add the __free code.
>
> This is far too confusing. Please post a v2 that just combines the 'fix references'
> and 'use cleanup.h macros' in a single patch. It makes no sense to have this two-phase
> approach.
I believe this is discouraged.
cleanup.h macros does not exist in old kernel versions, so makes it
impossible to backport the fix to them.
This is an example of other series following this policy:
https://lore.kernel.org/lkml/173608125422.1253657.3732758016133408588.stgit@devnote2/
They also mention the same here:
https://hackerbikepacker.com/kernel-auto-cleanup-1 .... I am pretty
sure that I read the policy in a more official location... but I
cannot find it right now :)
>
> Regards,
>
> Hans
>
> >
> > Regards,
> >
> > Hans
> >
> >>
> >> Cc: stable@vger.kernel.org
> >> Fixes: 46c15a4ff1f4 ("media: nuvoton: Add driver for NPCM video capture and encoding engine")
> >> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> >> ---
> >> drivers/media/platform/nuvoton/npcm-video.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/media/platform/nuvoton/npcm-video.c b/drivers/media/platform/nuvoton/npcm-video.c
> >> index 024cd8ee1709..7b4c23dbe709 100644
> >> --- a/drivers/media/platform/nuvoton/npcm-video.c
> >> +++ b/drivers/media/platform/nuvoton/npcm-video.c
> >> @@ -1673,6 +1673,7 @@ static int npcm_video_ece_init(struct npcm_video *video)
> >>
> >> regs = devm_platform_ioremap_resource(ece_pdev, 0);
> >> if (IS_ERR(regs)) {
> >> + put_device(&ece_pdev->dev);
> >> dev_err(dev, "Failed to parse ECE reg in DTS\n");
> >> return PTR_ERR(regs);
> >> }
> >> @@ -1680,11 +1681,13 @@ static int npcm_video_ece_init(struct npcm_video *video)
> >> video->ece.regmap = devm_regmap_init_mmio(dev, regs,
> >> &npcm_video_ece_regmap_cfg);
> >> if (IS_ERR(video->ece.regmap)) {
> >> + put_device(&ece_pdev->dev);
> >> dev_err(dev, "Failed to initialize ECE regmap\n");
> >> return PTR_ERR(video->ece.regmap);
> >> }
> >>
> >> video->ece.reset = devm_reset_control_get(&ece_pdev->dev, NULL);
> >> + put_device(&ece_pdev->dev);
> >> if (IS_ERR(video->ece.reset)) {
> >> dev_err(dev, "Failed to get ECE reset control in DTS\n");
> >> return PTR_ERR(video->ece.reset);
> >>
> >
> >
>
--
Ricardo Ribalda
On Sun, Feb 23, 2025 at 07:34:30PM +0100, Ricardo Ribalda wrote: > On Fri, 21 Feb 2025 at 10:18, Hans Verkuil <hverkuil@xs4all.nl> wrote: > > > > On 21/02/2025 10:04, Hans Verkuil wrote: > > > Hi Ricardo, > > > > > > On 21/01/2025 22:14, Ricardo Ribalda wrote: > > >> When we obtain a reference to of a platform_device, we need to release > > >> it via put_device. > > >> > > >> Found by cocci: > > >> ./platform/nuvoton/npcm-video.c:1677:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function. > > >> ./platform/nuvoton/npcm-video.c:1684:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function. > > >> ./platform/nuvoton/npcm-video.c:1690:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function. > > >> ./platform/nuvoton/npcm-video.c:1694:1-7: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function. > > > > > > This driver uses this construct: > > > > > > struct device *ece_dev __free(put_device) = &ece_pdev->dev; > > > > > > to automatically call put_device. So this patch would 'put' the device twice. > > > > > > Does cocci understand constructs like this? If I hadn't looked closely at the > > > code first, I would just have merged it. > > > > Oh wait, now that I am reading the following patches I see that it was those later > > patches that add the __free code. > > > > This is far too confusing. Please post a v2 that just combines the 'fix references' > > and 'use cleanup.h macros' in a single patch. It makes no sense to have this two-phase > > approach. > > I believe this is discouraged. > > cleanup.h macros does not exist in old kernel versions, so makes it > impossible to backport the fix to them. That's not a problem, fix things properly in the main tree and let the stable/lts kernels work it out on their own. > This is an example of other series following this policy: > https://lore.kernel.org/lkml/173608125422.1253657.3732758016133408588.stgit@devnote2/ > > They also mention the same here: > https://hackerbikepacker.com/kernel-auto-cleanup-1 .... I am pretty > sure that I read the policy in a more official location... but I > cannot find it right now :) No, it is NOT official policy at all. Otherwise you would be saying that no one could use these new functions for 6 years just because of really old kernels still living around somewhere. That's not how kernel development works, thankfully. thanks, greg k-h
On Mon, 24 Feb 2025 at 06:52, Greg KH <gregkh@linuxfoundation.org> wrote: > > On Sun, Feb 23, 2025 at 07:34:30PM +0100, Ricardo Ribalda wrote: > > On Fri, 21 Feb 2025 at 10:18, Hans Verkuil <hverkuil@xs4all.nl> wrote: > > > > > > On 21/02/2025 10:04, Hans Verkuil wrote: > > > > Hi Ricardo, > > > > > > > > On 21/01/2025 22:14, Ricardo Ribalda wrote: > > > >> When we obtain a reference to of a platform_device, we need to release > > > >> it via put_device. > > > >> > > > >> Found by cocci: > > > >> ./platform/nuvoton/npcm-video.c:1677:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function. > > > >> ./platform/nuvoton/npcm-video.c:1684:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function. > > > >> ./platform/nuvoton/npcm-video.c:1690:3-9: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function. > > > >> ./platform/nuvoton/npcm-video.c:1694:1-7: ERROR: missing put_device; call of_find_device_by_node on line 1667, but without a corresponding object release within this function. > > > > > > > > This driver uses this construct: > > > > > > > > struct device *ece_dev __free(put_device) = &ece_pdev->dev; > > > > > > > > to automatically call put_device. So this patch would 'put' the device twice. > > > > > > > > Does cocci understand constructs like this? If I hadn't looked closely at the > > > > code first, I would just have merged it. > > > > > > Oh wait, now that I am reading the following patches I see that it was those later > > > patches that add the __free code. > > > > > > This is far too confusing. Please post a v2 that just combines the 'fix references' > > > and 'use cleanup.h macros' in a single patch. It makes no sense to have this two-phase > > > approach. > > > > I believe this is discouraged. > > > > cleanup.h macros does not exist in old kernel versions, so makes it > > impossible to backport the fix to them. > > That's not a problem, fix things properly in the main tree and let the > stable/lts kernels work it out on their own. > > > This is an example of other series following this policy: > > https://lore.kernel.org/lkml/173608125422.1253657.3732758016133408588.stgit@devnote2/ > > > > They also mention the same here: > > https://hackerbikepacker.com/kernel-auto-cleanup-1 .... I am pretty > > sure that I read the policy in a more official location... but I > > cannot find it right now :) > > No, it is NOT official policy at all. Otherwise you would be saying > that no one could use these new functions for 6 years just because of > really old kernels still living around somewhere. That's not how kernel > development works, thankfully. No, I am not saying that we cannot use cleanup.h for 6 years. What I am saying is that first we fix the errors without it, and then we move to cleanup.h. All in the same series: 1/2 Fix reference handling (cc: stable) 2/2 Use cleanup.h That way the fix (1/2) can be applied without changes to all the stable trees, and 2/2 can be ignored by them. The alternative is a patch that cannot be applied to stable and either you, the author or the maintainer have to backport to stable (basically implementing 1/2). So no, we do not save work by just posting a cleanup.h version of the fix to the mailing list. The even better alternative is that cleanup.h is backported to all the stable trees. Anyway, it is up to you and Sasha to decide. I will repost the series only using cleanup.h Best regards! > > thanks, > > greg k-h -- Ricardo Ribalda
© 2016 - 2026 Red Hat, Inc.