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:   Gustavo Pimentel <Gustavo.Pimentel@synopsys.com>
To:     Arnd Bergmann <arnd@arndb.de>,
        Gustavo Pimentel <Gustavo.Pimentel@synopsys.com>,
        Vinod Koul <vkoul@kernel.org>
CC:     Dan Williams <dan.j.williams@intel.com>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Russell King <rmk+kernel@armlinux.org.uk>,
        Joao Pinto <Joao.Pinto@synopsys.com>,
        "dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] dmaengine: dw-edma: fix endianess confusion
Thread-Topic: [PATCH] dmaengine: dw-edma: fix endianess confusion
Thread-Index: AQHVJQ89RjU0Q02eek2npY11LTCshKalytvg
Date:   Fri, 21 Jun 2019 08:42:32 +0000
Message-ID: <DM6PR12MB40101798EDD46EF4B8E0E0E1DAE70@DM6PR12MB4010.namprd12.prod.outlook.com>
References: <20190617131820.2470686-1-arnd@arndb.de>
In-Reply-To: <20190617131820.2470686-1-arnd@arndb.de>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: synopsys.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: dd612427-85fe-40ea-a7ba-08d6f6246709
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jun 2019 08:42:32.6465
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c33c9f88-1eb7-4099-9700-16013fd9e8aa
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: gustavo@synopsys.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB3609
X-OriginatorOrg: synopsys.com
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi,

On Mon, Jun 17, 2019 at 14:17:47, Arnd Bergmann <arnd@arndb.de> wrote:

> When building with 'make C=3D1', sparse reports an endianess bug:

I didn't know that option.

>=20
> drivers/dma/dw-edma/dw-edma-v0-debugfs.c:60:30: warning: cast removes add=
ress space of expression
> drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24: warning: incorrect type i=
n argument 1 (different address spaces)
> drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24:    expected void const vo=
latile [noderef] <asn:2>*addr
> drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24:    got void *[assigned] p=
tr
> drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24: warning: incorrect type i=
n argument 1 (different address spaces)
> drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24:    expected void const vo=
latile [noderef] <asn:2>*addr
> drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24:    got void *[assigned] p=
tr
> drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24: warning: incorrect type i=
n argument 1 (different address spaces)
> drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24:    expected void const vo=
latile [noderef] <asn:2>*addr
> drivers/dma/dw-edma/dw-edma-v0-debugfs.c:86:24:    got void *[assigned] p=
tr
>=20
> The current code is clearly wrong, as it passes an endian-swapped word
> into a register function where it gets swapped again. I assume that this

Sorry I didn't catch this, endianness-swapped word into a register=20
function where it gets swapped again?
Where?

> was simply ported from a non-Linux OS, and the swap was done incorrectly.
> Replace it with a cast to uintptr_t.
>=20
> Fixes: 7e4b8a4fbe2c ("dmaengine: Add Synopsys eDMA IP version 0 support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  drivers/dma/dw-edma/dw-edma-v0-core.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
>=20
> diff --git a/drivers/dma/dw-edma/dw-edma-v0-core.c b/drivers/dma/dw-edma/=
dw-edma-v0-core.c
> index 97e3fd41c8a8..d670ebcc37b3 100644
> --- a/drivers/dma/dw-edma/dw-edma-v0-core.c
> +++ b/drivers/dma/dw-edma/dw-edma-v0-core.c
> @@ -195,7 +195,7 @@ static void dw_edma_v0_core_write_chunk(struct dw_edm=
a_chunk *chunk)
>  	struct dw_edma_v0_lli __iomem *lli;
>  	struct dw_edma_v0_llp __iomem *llp;
>  	u32 control =3D 0, i =3D 0;
> -	u64 sar, dar, addr;
> +	uintptr_t sar, dar, addr;

Will this type assure variables sar, dar and addr are 64 bits?

>  	int j;
> =20
>  	lli =3D chunk->ll_region.vaddr;
> @@ -214,11 +214,11 @@ static void dw_edma_v0_core_write_chunk(struct dw_e=
dma_chunk *chunk)
>  		/* Transfer size */
>  		SET_LL(&lli[i].transfer_size, child->sz);
>  		/* SAR - low, high */
> -		sar =3D cpu_to_le64(child->sar);
> +		sar =3D (uintptr_t)child->sar;

Assuming the host is a big-endian machine and the eDMA on the endpoint=20
strictly requires the address to be little endian.
By not using cpu_to_le64(), the address to be written on the eDMA will be=20
in big-endian format, right? If so, that will break the driver.

>  		SET_LL(&lli[i].sar_low, lower_32_bits(sar));
>  		SET_LL(&lli[i].sar_high, upper_32_bits(sar));
>  		/* DAR - low, high */
> -		dar =3D cpu_to_le64(child->dar);
> +		dar =3D (uintptr_t)child->dar;

Ditto.

>  		SET_LL(&lli[i].dar_low, lower_32_bits(dar));
>  		SET_LL(&lli[i].dar_high, upper_32_bits(dar));
>  		i++;
> @@ -232,7 +232,7 @@ static void dw_edma_v0_core_write_chunk(struct dw_edm=
a_chunk *chunk)
>  	/* Channel control */
>  	SET_LL(&llp->control, control);
>  	/* Linked list  - low, high */
> -	addr =3D cpu_to_le64(chunk->ll_region.paddr);
> +	addr =3D (uintptr_t)chunk->ll_region.paddr;

Ditto.

>  	SET_LL(&llp->llp_low, lower_32_bits(addr));
>  	SET_LL(&llp->llp_high, upper_32_bits(addr));
>  }
> @@ -262,7 +262,7 @@ void dw_edma_v0_core_start(struct dw_edma_chunk *chun=
k, bool first)
>  		SET_CH(dw, chan->dir, chan->id, ch_control1,
>  		       (DW_EDMA_V0_CCS | DW_EDMA_V0_LLE));
>  		/* Linked list - low, high */
> -		llp =3D cpu_to_le64(chunk->ll_region.paddr);
> +		llp =3D (uintptr_t)chunk->ll_region.paddr;

Ditto.

>  		SET_CH(dw, chan->dir, chan->id, llp_low, lower_32_bits(llp));
>  		SET_CH(dw, chan->dir, chan->id, llp_high, upper_32_bits(llp));
>  	}
> --=20
> 2.20.0