linux-kernel - Re: linux-next: build failure after merge of the sound tree

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]

Message-ID: <s5h4kq6ljhn.wl-tiwai@suse.de>
Date:   Fri, 17 Jul 2020 08:54:12 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     Christoph Hellwig <hch@....de>
Cc:     Takashi Iwai <tiwai@...e.de>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the sound tree

On Fri, 17 Jul 2020 08:50:30 +0200,
Christoph Hellwig wrote:
> 
> On Fri, Jul 17, 2020 at 08:34:47AM +0200, Takashi Iwai wrote:
> > On Fri, 17 Jul 2020 07:33:24 +0200,
> > Christoph Hellwig wrote:
> > > 
> > > On Fri, Jul 17, 2020 at 01:01:12PM +1000, Stephen Rothwell wrote:
> > > > Hi all,
> > > > 
> > > > After merging the sound tree, today's linux-next build (x86_64
> > > > allmodconfig) failed like this:
> > > 
> > > No, the sound commit needs to be reverted.  Drivers has absolutely not
> > > business poking into DMA layer internals.
> > 
> > OK, I'll drop that stuff again.  It was the thing posted in the thread
> > of DMA regression with AMD SEV on 5.8-rc1.  Meanwhile it was fixed in
> > the proper Kconfig dependency.
> 
> We have other x86 changes that will not support just remapping stuff
> ignoring the API in the pipe, so this will need to get sorted out.  And
> with that I mean sorted out properly instead of poking into undocumented
> DMA API internals and coming to the wrong conclusions again..

OK, when a proper API (or some kconfig) is ready for referring from
the driver side, let me know.  I'd love to keep the SG-buffer support
as much as possible, since HD-audio stuff has been used for a very old
machine with a small RAM.


thanks,

Takashi