Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Vineet Gupta <vineet.gupta1@synopsys.com>
To:     Arnd Bergmann <arnd@arndb.de>
CC:     Vitor Soares <vitor.soares@synopsys.com>,
        "alexey.brodkin@synopsys.com" <alexey.brodkin@synopsys.com>,
        Joao Pinto <joao.pinto@synopsys.com>,
        "jose.abreu@synopsys.com" <jose.abreu@synopsys.com>,
        "open list:SYNOPSYS ARC ARCHITECTURE" 
        <linux-snps-arc@lists.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Misaligned Access
Thread-Topic: Misaligned Access
Thread-Index: AQHUa8BEl692JJiolkiUiQERHFjjDw==
Date:   Wed, 21 Nov 2018 20:15:54 +0000
Message-ID: <C2D7FE5348E1B147BCA15975FBA23075014641664A@US01WEMBX2.internal.synopsys.com>
References: <13D59CF9CEBAF94592A12E8AE55501350113CD10@DE02WEMBXB.internal.synopsys.com>
 <C2D7FE5348E1B147BCA15975FBA23075012B0B4CD5@US01WEMBX2.internal.synopsys.com>
 <9ffd1270-ad92-88b7-eb53-85c65fe971dd@synopsys.com>
 <f8c469e7-9e1d-18d6-4e56-ba4338462048@synopsys.com>
 <ebe7f165-2901-2885-0583-c7be53329372@synopsys.com>
 <4881796E12491D4BB15146FE0209CE6468198AC6@DE02WEMBXB.internal.synopsys.com>
 <C2D7FE5348E1B147BCA15975FBA230750146415496@US01WEMBX2.internal.synopsys.com>
 <661a4323-5768-4977-5434-ab644c5418aa@synopsys.com>
 <C2D7FE5348E1B147BCA15975FBA23075014641580A@US01WEMBX2.internal.synopsys.com>
 <CAK8P3a1Gszsg7Wky+7Z8TuOtAtZR2ia-QjYm01-wWKRmYfdm7Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 11/21/18 12:12 PM, Arnd Bergmann wrote:=0A=
> On Wed, Nov 21, 2018 at 8:42 PM Vineet Gupta <vineet.gupta1@synopsys.com>=
 wrote:=0A=
>> +CC lkml, Arnd : subject matter expert=0A=
>>=0A=
>> On 11/21/18 10:06 AM, Vitor Soares wrote:=0A=
>>> I use the follow function to get data from a RX Fifo.=0A=
>>>=0A=
>>>=0A=
>>> static void dw_i3c_master_read_rx_fifo(struct dw_i3c_master *master,=0A=
>>>                         u8 *bytes, int nbytes)=0A=
>>> {=0A=
>>>      readsl(master->regs + RX_TX_DATA_PORT, bytes, nbytes / 4);=0A=
>> So the semantics are reading the same fifo register N times, to get the =
N words,=0A=
>> hence read*s*l is appropriate. That however expects the buffer to be 4 b=
ytes=0A=
>> aligned, hence your issue. You can't possibly use the reads*b* as we wan=
t the=0A=
>>=0A=
>> The obvious but crude hack is to use a temp array for readsl and then co=
py over=0A=
>> using memcpy, but I'm sure there are better ways, @Arnd ? To summarize i=
s issue is=0A=
>> a driver triggering unaligned access due to the misinteraction of API (d=
river get=0A=
>> an unaligned u8 *) which goes against expectations of io accessor readl =
 (needed=0A=
>> since the register contents are 4 bytes)=0A=
> Is this again on ARC or some other architecture that cannot do unaligned=
=0A=
> access to normal RAM? On ARMv7 or x86, you should never see a problem=0A=
> because the CPU handles misaligned writes. On ARMv4/v5, the readsl()=0A=
> implementation internally aligns the access to the output buffer so it=0A=
> will work correctly.=0A=
=0A=
This is indeed on ARC: on ARC700 unaligned access to RAM was never supporte=
d and=0A=
on HS38x cores, it is configurable, so the API probably needs to support bo=
th cases.=0A=
=0A=
Thx,=0A=
-Vineet=0A=