| Message ID | 20201019225903.14276-4-djrscally@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add functionality to ipu3-cio2 driver allowing software_node connections to sensors on platforms designed for Windows | expand |
On Tue, Oct 20, 2020 at 12:59 AM Daniel Scally <djrscally@gmail.com> wrote: > > The software_node_get_next_child() function currently does not hold a kref > to the child software_node; fix that. > > Fixes: 59abd83672f7 ("drivers: base: Introducing software nodes to the firmware node framework") > Signed-off-by: Daniel Scally <djrscally@gmail.com> > --- > Changes in v3: > - split out from the full software_node_graph*() patch > > drivers/base/swnode.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c > index f01b1cc61..741149b90 100644 > --- a/drivers/base/swnode.c > +++ b/drivers/base/swnode.c > @@ -450,7 +450,7 @@ software_node_get_next_child(const struct fwnode_handle *fwnode, > c = list_next_entry(c, entry); > else > c = list_first_entry(&p->children, struct swnode, entry); > - return &c->fwnode; > + return software_node_get(&c->fwnode); > } > > static struct fwnode_handle * > -- This should be sent as a separate fix AFAICS.
Hi Daniel, On Mon, Oct 19, 2020 at 11:58:57PM +0100, Daniel Scally wrote: > The software_node_get_next_child() function currently does not hold a kref > to the child software_node; fix that. > > Fixes: 59abd83672f7 ("drivers: base: Introducing software nodes to the firmware node framework") > Signed-off-by: Daniel Scally <djrscally@gmail.com> > --- > Changes in v3: > - split out from the full software_node_graph*() patch > > drivers/base/swnode.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c > index f01b1cc61..741149b90 100644 > --- a/drivers/base/swnode.c > +++ b/drivers/base/swnode.c > @@ -450,7 +450,7 @@ software_node_get_next_child(const struct fwnode_handle *fwnode, > c = list_next_entry(c, entry); > else > c = list_first_entry(&p->children, struct swnode, entry); > - return &c->fwnode; > + return software_node_get(&c->fwnode); I believe similarly, the function should drop the reference to the previous node, and not expect the caller to do this. The OF equivalent does the same. > } > > static struct fwnode_handle *
Hi Sakari On 20/10/2020 14:31, Sakari Ailus wrote: > Hi Daniel, > > On Mon, Oct 19, 2020 at 11:58:57PM +0100, Daniel Scally wrote: >> The software_node_get_next_child() function currently does not hold a kref >> to the child software_node; fix that. >> >> Fixes: 59abd83672f7 ("drivers: base: Introducing software nodes to the firmware node framework") >> Signed-off-by: Daniel Scally <djrscally@gmail.com> >> --- >> Changes in v3: >> - split out from the full software_node_graph*() patch >> >> drivers/base/swnode.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c >> index f01b1cc61..741149b90 100644 >> --- a/drivers/base/swnode.c >> +++ b/drivers/base/swnode.c >> @@ -450,7 +450,7 @@ software_node_get_next_child(const struct fwnode_handle *fwnode, >> c = list_next_entry(c, entry); >> else >> c = list_first_entry(&p->children, struct swnode, entry); >> - return &c->fwnode; >> + return software_node_get(&c->fwnode); > I believe similarly, the function should drop the reference to the previous > node, and not expect the caller to do this. The OF equivalent does the > same. I think I prefer it this way myself, since the alternative is having to explicitly call *_node_get() on a returned child if you want to keep it but also keep iterating. But I agree that it's important to take a consistent approach. I'll add that too; this will mean swnode_graph_find_next_port() and software_node_graph_get_next_endpoint() in patch 4 of this series will need changing slightly to square away their references.
On Wed, Oct 21, 2020 at 12:25:28AM +0100, Dan Scally wrote: > On 20/10/2020 14:31, Sakari Ailus wrote: > > On Mon, Oct 19, 2020 at 11:58:57PM +0100, Daniel Scally wrote: > >> + return software_node_get(&c->fwnode); > > I believe similarly, the function should drop the reference to the previous > > node, and not expect the caller to do this. The OF equivalent does the > > same. > > I think I prefer it this way myself, since the alternative is having to > explicitly call *_node_get() on a returned child if you want to keep it > but also keep iterating. But I agree that it's important to take a > consistent approach. I'll add that too; this will mean > swnode_graph_find_next_port() and > software_node_graph_get_next_endpoint() in patch 4 of this series will > need changing slightly to square away their references. What about ACPI case? Does it square?
On Wed, Oct 21, 2020 at 12:33:21PM +0300, Andy Shevchenko wrote: > On Wed, Oct 21, 2020 at 12:25:28AM +0100, Dan Scally wrote: > > On 20/10/2020 14:31, Sakari Ailus wrote: > > > On Mon, Oct 19, 2020 at 11:58:57PM +0100, Daniel Scally wrote: > > > >> + return software_node_get(&c->fwnode); > > > I believe similarly, the function should drop the reference to the previous > > > node, and not expect the caller to do this. The OF equivalent does the > > > same. > > > > I think I prefer it this way myself, since the alternative is having to > > explicitly call *_node_get() on a returned child if you want to keep it > > but also keep iterating. But I agree that it's important to take a > > consistent approach. I'll add that too; this will mean > > swnode_graph_find_next_port() and > > software_node_graph_get_next_endpoint() in patch 4 of this series will > > need changing slightly to square away their references. > > What about ACPI case? Does it square? In ACPI, we seem to assume these nodes are always there and thus don't need reference counting.
On 21/10/2020 10:33, Andy Shevchenko wrote: > On Wed, Oct 21, 2020 at 12:25:28AM +0100, Dan Scally wrote: >> On 20/10/2020 14:31, Sakari Ailus wrote: >>> On Mon, Oct 19, 2020 at 11:58:57PM +0100, Daniel Scally wrote: >>>> + return software_node_get(&c->fwnode); >>> I believe similarly, the function should drop the reference to the previous >>> node, and not expect the caller to do this. The OF equivalent does the >>> same. >> I think I prefer it this way myself, since the alternative is having to >> explicitly call *_node_get() on a returned child if you want to keep it >> but also keep iterating. But I agree that it's important to take a >> consistent approach. I'll add that too; this will mean >> swnode_graph_find_next_port() and >> software_node_graph_get_next_endpoint() in patch 4 of this series will >> need changing slightly to square away their references. > What about ACPI case? Does it square? ACPI version doesn't handle references at all; neither puts() the old nor gets() the new child node.
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c index f01b1cc61..741149b90 100644 --- a/drivers/base/swnode.c +++ b/drivers/base/swnode.c @@ -450,7 +450,7 @@ software_node_get_next_child(const struct fwnode_handle *fwnode, c = list_next_entry(c, entry); else c = list_first_entry(&p->children, struct swnode, entry); - return &c->fwnode; + return software_node_get(&c->fwnode); } static struct fwnode_handle *
The software_node_get_next_child() function currently does not hold a kref to the child software_node; fix that. Fixes: 59abd83672f7 ("drivers: base: Introducing software nodes to the firmware node framework") Signed-off-by: Daniel Scally <djrscally@gmail.com> --- Changes in v3: - split out from the full software_node_graph*() patch drivers/base/swnode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)