Re: [PATCH v3 2/9] of: property: add of_graph_get_next_port_endpoint()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Jonathan, Rob

> > > Do you mean it should include __free() inside this loop, like _scoped() ?
(snip)
> > > In such case, I wonder does it need to have _scoped() in loop name ?
(snip)
> > So back to the name, I don't think we need _scoped in it. I think if
> > any user treats the iterator like it's the old style, the compiler is
> > going to complain.
> 
> Hmm.  Up to you but I'd be concerned that the scoping stuff is non
> obvious enough that it is worth making people really really aware
> it is going on.
> 
> However I don't feel strongly about it.
> For the other _scoped iterators there is some push back
> on the churn using them is causing so I doubt we'll ever get rid
> of the non scoped variants.  For something new that's not a concern.

I noticed that we can write below code, and then, and there is no waning/error
from compiler.

Now for_each macro is using __free()

	#define for_each_of_graph_port(parent, child)	\
		for (... *child __free(device_node) = ...)

(A)	struct device_node *node = xxx;

	for_each_of_graph_port(parent, node) {
(B)		/* do something */
	}

(C)	xxx = node;

In this case, "(A) node" and "(C) node" are same, but "(B) node" are different.
New user might confuse about this behavior.

Thank you for your help !!

Best regards
---
Kuninori Morimoto




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux