On Thu, Sep 25, 2014 at 10:51:10AM +0100, Geert Uytterhoeven wrote:
> On Thu, Sep 25, 2014 at 11:33 AM, Will Deacon wrote:
> >> Putting them here means they won't have any multiple include protection
> >> (there is no "#ifndef _IO_H" around them). Doesn't seem to lead to
> >> any problems in pract
On Thu, Sep 25, 2014 at 11:33 AM, Will Deacon wrote:
>> Putting them here means they won't have any multiple include protection
>> (there is no "#ifndef _IO_H" around them). Doesn't seem to lead to
>> any problems in practice. Just flagging it...
>
> That's easy enough to fix, and actually, we sho
On Thu, Sep 25, 2014 at 02:05:43AM +0100, Greg Ungerer wrote:
> Hi Will
Hi Greg,
Thanks for taking a look.
> On 25/09/14 03:17, Will Deacon wrote:
> > write{b,w,l}_relaxed are implemented by some architectures in order to
> > permit memory-mapped I/O accesses with weaker barrier semantics than t
Hi Will
On 25/09/14 03:17, Will Deacon wrote:
> write{b,w,l}_relaxed are implemented by some architectures in order to
> permit memory-mapped I/O accesses with weaker barrier semantics than the
> non-relaxed variants.
>
> This patch adds dummy macros for the write accessors to m68k, in the
> same
write{b,w,l}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O accesses with weaker barrier semantics than the
non-relaxed variants.
This patch adds dummy macros for the write accessors to m68k, in the
same vein as the dummy definitions for the relaxed read accesso
5 matches
Mail list logo
