linux-kernel - Re: [PATCH v2 2/3] i2c: Add helper to ease DMA handling

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>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 9 Aug 2018 11:23:40 +0200
From:   Wolfram Sang <wsa@...-dreams.de>
To:     Yingjoe Chen <yingjoe.chen@...iatek.com>
Cc:     Jun Gao <jun.gao@...iatek.com>, devicetree@...r.kernel.org,
        srv_heupstream@...iatek.com, linux-kernel@...r.kernel.org,
        linux-mediatek@...ts.infradead.org, linux-i2c@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 2/3] i2c: Add helper to ease DMA handling

Hi,

> I believe the reason for these api is because some arch changed to can
> not do DMA on stack recently. Maybe we should have dma_mapping to bounce

It is not only arch dependent. You can enable virtual stacks in Kconfig,
too.

> buffer like it bounce un-dma-able address for those arch? or we should
> have a common driver API for this, not just for i2c?

I gave a talk about this problem recently and everyone in the room
agreed the best thing would be to have annotated buffers which can be
used kernel-wide. Someone mentioned DMABUF could be a candidate, but I
haven't looked further into that.

So, yes, a bigger solution is needed but I don't see that coming soon,
so I implemented the I2C part for better safety now. I'd be happy to
remove all that again once we have the annotated buffers. But it is an
effort...

Regards,

   Wolfram

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)