Add `__free` function attribute to `ap` and `match` pointer
initialisations which ensure that the pointers are freed as soon as they
go out of scope, thus removing the need to manually free them using
`of_node_put`.
This also removes the need for the `goto` statement and the `rc`
variable.
Suggested-by: Julia Lawall <[email protected]>
Signed-off-by: Shresth Prasad <[email protected]>
---
drivers/tty/serial/sunsu.c | 37 +++++++++++--------------------------
1 file changed, 11 insertions(+), 26 deletions(-)
diff --git a/drivers/tty/serial/sunsu.c b/drivers/tty/serial/sunsu.c
index 67a5fc70bb4b..0f463da5e7ce 100644
--- a/drivers/tty/serial/sunsu.c
+++ b/drivers/tty/serial/sunsu.c
@@ -1382,44 +1382,29 @@ static inline struct console *SUNSU_CONSOLE(void)
static enum su_type su_get_type(struct device_node *dp)
{
- struct device_node *ap = of_find_node_by_path("/aliases");
- enum su_type rc = SU_PORT_PORT;
+ struct device_node *ap __free(device_node) =
+ of_find_node_by_path("/aliases");
if (ap) {
const char *keyb = of_get_property(ap, "keyboard", NULL);
const char *ms = of_get_property(ap, "mouse", NULL);
- struct device_node *match;
if (keyb) {
- match = of_find_node_by_path(keyb);
+ struct device_node *match __free(device_node) =
+ of_find_node_by_path(keyb);
- /*
- * The pointer is used as an identifier not
- * as a pointer, we can drop the refcount on
- * the of__node immediately after getting it.
- */
- of_node_put(match);
-
- if (dp == match) {
- rc = SU_PORT_KBD;
- goto out;
- }
+ if (dp == match)
+ return SU_PORT_KBD;
}
if (ms) {
- match = of_find_node_by_path(ms);
+ struct device_node *match __free(device_node) =
+ of_find_node_by_path(ms);
- of_node_put(match);
-
- if (dp == match) {
- rc = SU_PORT_MS;
- goto out;
- }
+ if (dp == match)
+ return SU_PORT_MS;
}
}
-
-out:
- of_node_put(ap);
- return rc;
+ return SU_PORT_PORT;
}
static int su_probe(struct platform_device *op)
--
2.44.0
Hi,
Could I please get some feedback for this patch?
Regards,
Shresth
On Wed, May 01, 2024 at 10:01:00AM +0530, Shresth Prasad wrote:
> Hi,
>
> Could I please get some feedback for this patch?
I don't see anything here, sorry.
Also, how was this tested?
> I don't see anything here, sorry.
I'm sorry but is this patch not visible?
https://lore.kernel.org/all/[email protected]/
> Also, how was this tested?
I tested it using a qemu x86_64 virtual machine
Regards,
Shresth
On Wed, May 1, 2024 at 10:21 AM Greg KH <[email protected]> wrote:
>
> On Wed, May 01, 2024 at 10:01:00AM +0530, Shresth Prasad wrote:
> > Hi,
> >
> > Could I please get some feedback for this patch?
>
> I don't see anything here, sorry.
>
> Also, how was this tested?
On Wed, May 01, 2024 at 10:28:35AM +0530, Shresth Prasad wrote:
> > I don't see anything here, sorry.
> I'm sorry but is this patch not visible?
> https://lore.kernel.org/all/[email protected]/
Yes, but you did not include it in your response at all, so how were we
to see it?
> > Also, how was this tested?
> I tested it using a qemu x86_64 virtual machine
Great, please say so in your changelog text.
thanks,
greg k-h
> Yes, but you did not include it in your response at all, so how were we
> to see it?
Oh, really sorry about that.
I thought I was replying to the thread with the patch.
> Great, please say so in your changelog text.
Right, I'll do that. My bad.
I'll resubmit the patch.
Regards,
Shresth
On Wed, May 1, 2024 at 10:33 AM Greg KH <[email protected]> wrote:
>
> On Wed, May 01, 2024 at 10:28:35AM +0530, Shresth Prasad wrote:
> > > I don't see anything here, sorry.
> > I'm sorry but is this patch not visible?
> > https://lore.kernel.org/all/[email protected]/
>
> Yes, but you did not include it in your response at all, so how were we
> to see it?
>
> > > Also, how was this tested?
> > I tested it using a qemu x86_64 virtual machine
>
> Great, please say so in your changelog text.
>
> thanks,
>
> greg k-h