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] [thread-next>] [day] [month] [year] [list]
Message-ID: <4177d1d9-2fce-4cd6-bab9-31bbf927a343@broadcom.com>
Date: Wed, 5 Jun 2024 14:24:00 +0200
From: Florian Fainelli <florian.fainelli@...adcom.com>
To: Dave Stevenson <dave.stevenson@...pberrypi.com>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>,
 Broadcom internal kernel review list
 <bcm-kernel-feedback-list@...adcom.com>, Ray Jui <rjui@...adcom.com>,
 Scott Branden <sbranden@...adcom.com>, Vinod Koul <vkoul@...nel.org>,
 Maxime Ripard <mripard@...nel.org>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>,
 Daniel Vetter <daniel@...ll.ch>, Ulf Hansson <ulf.hansson@...aro.org>,
 Mark Brown <broonie@...nel.org>, Christoph Hellwig <hch@....de>,
 Marek Szyprowski <m.szyprowski@...sung.com>,
 Robin Murphy <robin.murphy@....com>, Liam Girdwood <lgirdwood@...il.com>,
 Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
 Vladimir Murzin <vladimir.murzin@....com>, Phil Elwell
 <phil@...pberrypi.com>, Stefan Wahren <wahrenst@....net>,
 Serge Semin <Sergey.Semin@...kalelectronics.ru>
Cc: devicetree@...r.kernel.org, linux-rpi-kernel@...ts.infradead.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 dmaengine@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 linux-mmc@...r.kernel.org, linux-spi@...r.kernel.org, iommu@...ts.linux.dev,
 linux-sound@...r.kernel.org
Subject: Re: [PATCH 00/18] BCM2835 DMA mapping cleanups and fixes



On 5/24/2024 8:26 PM, Dave Stevenson wrote:
> Hi All
> 
> This series initially cleans up the BCM2835 DMA driver in preparation for
> supporting the 40bit version. It then fixes up the incorrect mapping behaviour
> we've had to date.
> 
> The cleanups are based on Stefan Wahren's RFC [1], with a couple of minor bugs
> fixed, but stopping before actually adding the 40bit support. If we can sort
> the mapping issue, it avoids having to have workarounds in the 40bit support.
> 
> The mapping issues were discussed in [2].
> Up until this point all DMA users have been passing in dma addresses rather than
> CPU physical addresses, and the DMA driver has been using those directly rather
> than using dma_map_resource() to map them.
> The DT has also been missing some of the required mappings in "dma-ranges", but
> they have been present in "ranges". I've therefore duplicated the minimum amount
> of of_dma_get_range and translate_phys_to_dma to be able to use "ranges" as
> discussed in that thread. I'm assuming that sort of code is not desirable in the
> core code as it shouldn't be necessary, so keeping it contained within a driver
> is the better solution.
> 
> When Andrea posted our downstream patches in [3], Robin Murphy stated that
> dma_map_resource is the correct API, but as it currently doesn't check the
> dma_range_map we need Sergey Semin's patch [4].
> There seemed to be no follow up over the implications of it. I've therefore
> included it in the series at least for discussion. If it's not acceptable then
> I'm not sure of the route forward in fixing this mapping issue.
> 
> I'm expecting there to be some discussion, but also acknowledge that merging this
> will need to be phased with the patches 1-13 needing to be merged before any of
> 14-17, and then 18 merged last to remove the workaround. I suspect that's the
> least of my worries though.
> 
> 
> I will apologise in advance if I don't respond immediately to comments - I'm
> out of the office for the next week, but do appreciate any feedback.

Those patches should be routed via the dmaengine tree, including the DTS 
files to minimize the possibility of introducing regressions if people 
happen to bisect changes. I don't expect conflicts when these changes 
reach linux-next.
-- 
Florian

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4221 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ