linux-kernel - Re: [PATCH] dt: add helper function to read u8 & u16 variables & arrays

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAKohponSbbusMjcsEwKczvxaN54YKJPL05vLELSjW6dnKO_6Dg@mail.gmail.com>
Date:	Fri, 26 Oct 2012 09:47:24 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	Rob Herring <robherring2@...il.com>
Cc:	grant.likely@...retlab.ca, spear-devel@...t.st.com,
	devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	andriy.shevchenko@...el.com
Subject: Re: [PATCH] dt: add helper function to read u8 & u16 variables & arrays

On 25 October 2012 19:48, Viresh Kumar <viresh.kumar@...aro.org> wrote:
> The problem i see here is:
>
> The data passed via DT comes as Little Endian in the kernel.
>
> For a little endian system, byte zero will contain the data and so
> (u8) val
>
> look to be the correct thing.
>
> For a big endian system, byte 3 will contain data as it is swapped by
> be32_to_cpup.
> So (u8) val would return value stored by byte 0 instead. ??

I feel above explanation was wrong. I didn't had a big endian system
to test this but this is what i derived theoretically. Consider following
sequence of commands:

u32 x = 0x01;              //This will store off-0: 1, off-3:0 for LE system
                                   // and will store off-0: 0, off-3:1
for BE system
u8 y = (u8) x;              // For any architecture type, i.e. big or
little this must store
                                   // 1 in y. This is ANCI C semantic
and should be architecture
                                   // independent.

Which would mean, type cast will give off-0 on LE and off-3 on BE systems. Don't
confuse this with getting values using pointers, as we try to get data
out of specific
locations in those cases.

So, my initial code seems to be doing the right thing. be32_to_cpup()
will move the
LSB to off-3 and that is what we will get during the cast.

I will resend my original code to you.

--
viresh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/