Le 16/10/2015 11:49, Michael Ellerman a écrit :

On Fri, 2015-10-16 at 08:20 +0200, Christophe JAILLET wrote:

quoted

Le 15/10/2015 08:36, Michael Ellerman a écrit :

quoted

On Thu, 2015-10-15 at 07:56 +0200, Christophe JAILLET wrote:

quoted

Use 'of_property_read_u32()' instead of
'of_get_property()'+pointer
dereference in order to avoid access to potentially freed memory.

Use 'of_get_next_parent()' to simplify the while() loop and avoid
the
need of a temp variable.

Signed-off-by: Christophe JAILLET <redacted>
---
v2: Use of_property_read_u32 instead of of_get_property+pointer
dereference
*** Untested ***

Thanks.

Can someone with an mpc5xxx test this?

Hi,
I don't think it is an issue, but while looking at another similar
patch, I noticed that the proposed patch adds a call to
be32_to_cpup()
(within of_property_read_u32).
Apparently, powerPC is a BE architecture, so this call should be a no
-op.

Just wanted to point it out, in case of.

Hi Christoph,

I'm not sure I follow.

The device tree is always big endian, but of_property_read_u32() does
the
conversion to CPU endian for you already. That is one of the advantages
of
using it.

cheers

Hi,
sorry if un-clear.

What I mean is that in the patch related 
'powerpc/sysdev/mpc5xxx_clocks.c', there was no call to 'be32_to_cpup'.
So in the proposed patch, 'of_property_read_u32' adds it.

While in the patch against 'powerpc/kernel/prom.c', 'be32_to_cpup' was 
called explicitly.
So using 'of_property_read_u32' keep the same logic.


Basically the code from 'mpc5xxx_clocks.c' and from 'prom.c' were 
written the same way. I found spurious that a call to 'be32_to_cpup' was 
done in only one case.
Maybe, it was a missing in 'mpc5xxx_clocks.c'.


I don't know if it can be an issue or not. I just find it 'strange'.


CJ