On Fri, Dec 20, 2019 at 09:02:24PM +, Alexey Brodkin wrote:
> Hi Peter,
>
> > > Well it somehow used to work for quite some time now with the data-buffer
> > > being allocated with 4 words offset (which is 16 bytes for 32-bit platform
> >
> > 3 words, devres_node is 3 words.
>
> Correct, but
Hi Peter,
> > Well it somehow used to work for quite some time now with the data-buffer
> > being allocated with 4 words offset (which is 16 bytes for 32-bit platform
>
> 3 words, devres_node is 3 words.
Correct, but 4th word was implicitly there due to the fact
on most of 32-bit arches "long lo
On Fri, Dec 20, 2019 at 07:32:16PM +, Alexey Brodkin wrote:
> Well it somehow used to work for quite some time now with the data-buffer
> being allocated with 4 words offset (which is 16 bytes for 32-bit platform
3 words, devres_node is 3 words.
Which is exactly why we had to change it, the
Hi Robin, Peter, all,
[snip]
> On 2019-12-20 2:06 pm, Peter Zijlstra wrote:
> > On Fri, Dec 20, 2019 at 11:19:27AM +0100, Marc Gonzalez wrote:
> >> Would anyone else have any suggestions, comments, insights,
> >> recommendations,
> >> improvements, guidance, or wisdom? :-)
> >
> > Flip devres u
On 18/12/2019 15:20, Alexey Brodkin wrote:
> On 17/12/2019 16:30, Marc Gonzalez wrote:
>
>> Commit a66d972465d15 ("devres: Align data[] to ARCH_KMALLOC_MINALIGN")
>> increased the alignment of devres.data unconditionally.
>>
>> Some platforms have very strict alignment requirements for DMA-safe
>
Hi Marc,
We sort of expected something like that to happen at some point.
Funny enough it's been a year since my change was accepted in v4.20
and only now somebody noticed :)
Though quite a few questions below.
> Commit a66d972465d15 ("devres: Align data[] to ARCH_KMALLOC_MINALIGN")
> increased
