Le 16/10/2015 11:49, Michael Ellerman a écrit :
On Fri, 2015-10-16 at 08:20 +0200, Christophe JAILLET wrote:
Le 15/10/2015 08:36, Michael Ellerman a écrit :
On Thu, 2015-10-15 at 07:56 +0200, Christophe JAILLET wrote:
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 <christophe.jaillet@xxxxxxxxxx>
---
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
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
