linux-kernel - [DMA-engine Question] inconsistent policy of src_addr_widths, dst_addr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Wed, 10 Oct 2018 21:00:01 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" 
        <dmaengine@...r.kernel.org>
Cc:     Vinod <vkoul@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: [DMA-engine Question] inconsistent policy of src_addr_widths, dst_addr_widths

Hi.

When I wrote my DMA engine driver,
I had difficulty in understanding
what to set to the struct dma_device members.

For example, src_addr_widths.
I see two driver groups regarding this.

[A] BIT(DMA_SLAVE_BUSWIDTH_*_BYTES) are OR'ed

For example, st_fdma.c

https://github.com/torvalds/linux/blob/v4.19-rc4/drivers/dma/st_fdma.c#L729

[B] DMA_SLAVE_BUSWIDTH_*_BYTES are directly OR'ed without BIT()

For example, sh/rcar-dmac.c

https://github.com/torvalds/linux/blob/v4.19-rc4/drivers/dma/sh/rcar-dmac.c#L1778

Which is correct?

If we go with [A],
BIT(DMA_SLAVE_BUSWIDTH_64_BYTES) i.e. BIT(64)
would not fit in ddevice->src_addr_widths whose type is u32.

If we go with [B], the following formula is met.
DMA_SLAVE_BUSWIDTH_3_BYTES ==
DMA_SLAVE_BUSWIDTH_1_BYTE | DMA_SLAVE_BUSWIDTH_2_BYTES

We never know whether 3_BYTES is supported,
or it is just a combination of 1_BYTE and 2_BYTES.

-- 
Best Regards
Masahiro Yamada