linux-kernel - Re: [PATCH v2 2/2] drivers: remove force dma flag from buses

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]

Date:   Wed, 21 Mar 2018 10:35:25 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Nipun Gupta <nipun.gupta@....com>
Cc:     robin.murphy@....com, hch@....de, linux@...linux.org.uk,
        m.szyprowski@...sung.com, bhelgaas@...gle.com, zajec5@...il.com,
        andy.gross@...aro.org, david.brown@...aro.org,
        dan.j.williams@...el.com, vinod.koul@...el.com,
        thierry.reding@...il.com, robh+dt@...nel.org,
        frowand.list@...il.com, jarkko.sakkinen@...ux.intel.com,
        rafael.j.wysocki@...el.com, dmitry.torokhov@...il.com,
        johan@...nel.org, msuchanek@...e.de, linux-kernel@...r.kernel.org,
        iommu@...ts.linux-foundation.org, linux-wireless@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-soc@...r.kernel.org,
        dmaengine@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        linux-tegra@...r.kernel.org, devicetree@...r.kernel.org,
        linux-pci@...r.kernel.org, bharat.bhushan@....com,
        leoyang.li@....com
Subject: Re: [PATCH v2 2/2] drivers: remove force dma flag from buses

On Wed, Mar 21, 2018 at 12:25:23PM +0530, Nipun Gupta wrote:
> With each bus implementing its own DMA configuration callback,
> there is no need for bus to explicitly have force_dma in its
> global structure. This patch modifies of_dma_configure API to
> accept an input parameter which specifies if implicit DMA
> configuration is required even when it is not described by the
> firmware.

Having to "remember" what that bool variable means on the end of the
function call is a royal pain over time, right?

Why not just create a new function:
	dma_common_configure_force(dma)
that always does this?  Leave "dma_common_configure()" alone, and then
wrap the old code with these two helper functions that call the 'core'
code with the bool set properly?

That way you do not have to "know" what that parameter is, the function
name just documents it automatically, so when you see it in the
bus-specific code, no need to go and have to hunt for anything.  And if
you are reading the dma core code, it's obvious what is happening as the
functions are all right there.

thanks,

greg k-h