On Wed, Mar 01, 2017 at 05:59:38PM -0800, Michael Zoran wrote:
> Hi Arnd,
>
> I submitted a change which is in Linux-next now that makes the whole
> CACHE_LINE_SIZE macro meaningless. It now always reads the size from
> the DT and errors out with -ENODEV if the property is missing.
>
> I was
On Wed, Mar 01, 2017 at 05:59:38PM -0800, Michael Zoran wrote:
> Hi Arnd,
>
> I submitted a change which is in Linux-next now that makes the whole
> CACHE_LINE_SIZE macro meaningless. It now always reads the size from
> the DT and errors out with -ENODEV if the property is missing.
>
> I was
Hi Arnd,
I submitted a change which is in Linux-next now that makes the whole
CACHE_LINE_SIZE macro meaningless. It now always reads the size from
the DT and errors out with -ENODEV if the property is missing.
I was going to submit a change to delete the macro completely, just
never got to it.
Hi Arnd,
I submitted a change which is in Linux-next now that makes the whole
CACHE_LINE_SIZE macro meaningless. It now always reads the size from
the DT and errors out with -ENODEV if the property is missing.
I was going to submit a change to delete the macro completely, just
never got to it.
While debugging another problem I noticed that g_cache_line_size gets set
to sizeof(CACHE_LINE_SIZE), which is sizeof(int) or 4, while presumably
CACHE_LINE_SIZE (e.g. 32) was meant.
This initializes it the way it was meant.
Signed-off-by: Arnd Bergmann
---
While debugging another problem I noticed that g_cache_line_size gets set
to sizeof(CACHE_LINE_SIZE), which is sizeof(int) or 4, while presumably
CACHE_LINE_SIZE (e.g. 32) was meant.
This initializes it the way it was meant.
Signed-off-by: Arnd Bergmann
---
6 matches
Mail list logo