linux-kernel - Re: [PATCH v3 1/1] dmaengine: dw: Select only supported masters for ACPI devices

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: <onfkegjjn7psbhc44fhjmp5ttbuthiscpccywaxxwabalpmudo@xhfdlxi762o6>
Date: Mon, 23 Sep 2024 15:46:04 +0300
From: Serge Semin <fancer.lancer@...il.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: dmaengine@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Viresh Kumar <vireshk@...nel.org>, Vinod Koul <vkoul@...nel.org>, stable@...r.kernel.org, 
	Ferry Toth <fntoth@...il.com>
Subject: Re: [PATCH v3 1/1] dmaengine: dw: Select only supported masters for
 ACPI devices

On Mon, Sep 23, 2024 at 03:26:24PM +0300, Andy Shevchenko wrote:
> On Mon, Sep 23, 2024 at 02:57:27PM +0300, Serge Semin wrote:
> > On Mon, Sep 23, 2024 at 11:21:37AM +0300, Andy Shevchenko wrote:
> > > On Mon, Sep 23, 2024 at 01:01:08AM +0300, Serge Semin wrote:
> > > > On Fri, Sep 20, 2024 at 06:56:17PM +0300, Andy Shevchenko wrote:
> 
> ...
> 
> 
> Yes, I still prefer mine.
> 
> > But, again IMO, it seems to be
> > better to add the default_{m,p}_master/d{p,m}_master/etc fields to the
> > dw_dma_platform_data structure since the platform-specific controller
> > settings have been consolidated in there. The dw_dma_chip_pdata
> > structure looks as more like generic driver data storage.
> 
> I don't think that is correct place for it. The platform data is specific
> to the DMA controller as a whole and having there the master configuration
> will mean to have the arrays of them. This OTOH will break the OF setup
> where this comes from the slave descriptions and may not be provided with
> DMA controller, making it imbalanced. Yes, I may agree with you that chip data
> is not a good place either, but at least it isolates the case to PCI + ACPI /
> pure ACPI devices (and in particular we won't need to alter Intel Quark case).
> 

> Ideally, we should parse the additional properties from ACPI for this kind
> of DMA controllers to get this from the _slave_ resources. Currently this is
> not done, but anyone may propose a such

I guess it would also mean to fix all the firmware as well, wouldn't it?
Do the Intel/AMD/etc ACPI firmware currently provide such a data? In
anyway it would be inapplicable for the legacy hardware anyway.

> (would you like to volunteer?).

not really.) Maybe in some long-distance future when I get to meet a
device on the ACPI-based platform with the DW DMAC + some peripheral
experiencing the denoted problem, I'll think about implementing what
we've discussed here.

> 
> ...
> 
> TL;DR: If you are okay with your authorship in v3, I prefer it over other
> versions with the explanations given in this email thread.

Ok. Let's leave it as of your preference.

-Serge(y)

> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
>