linux-kernel - Re: [PATCH 0/2] firmware: cs_dsp: Remove usage of GFP

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: <1e251815-5d58-436b-9120-e88f75a7ecaa@sirena.org.uk>
Date: Thu, 13 Feb 2025 15:06:59 +0000
From: Mark Brown <broonie@...nel.org>
To: Richard Fitzgerald <rf@...nsource.cirrus.com>
Cc: Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
	Simon Trimmer <simont@...nsource.cirrus.com>,
	Charles Keepax <ckeepax@...nsource.cirrus.com>,
	patches@...nsource.cirrus.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] firmware: cs_dsp: Remove usage of GFP_DMA

On Thu, Feb 13, 2025 at 02:28:06PM +0000, Richard Fitzgerald wrote:
> On 11/02/2025 5:21 pm, Richard Fitzgerald wrote:

> > > Not tested on real hardware.
> > > This came up while porting kunit to mips64.
> > > Apparently GFP_DMA does not work there, but IMO the usage of GFP_DMA by

> I would say that is a bug in mips64 that should be fixed in mips64.
> It is not reasonable to expect generic drivers to have special cases for
> platforms that don't handle GFP_DMA.

What specifically is the issue?  If it's a build time issue I'd
definitely agree that we should just be able to assume that platforms at
least build.  IIRC there is a Kconfig you can depend on for DMA but it
seems more trouble than it's worth to fix all users.

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