From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0FAD7C433FE for ; Tue, 22 Nov 2022 06:12:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232076AbiKVGMI (ORCPT ); Tue, 22 Nov 2022 01:12:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33914 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229539AbiKVGMD (ORCPT ); Tue, 22 Nov 2022 01:12:03 -0500 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B40332A70E; Mon, 21 Nov 2022 22:12:01 -0800 (PST) Received: by verein.lst.de (Postfix, from userid 2407) id 7522168D05; Tue, 22 Nov 2022 07:11:58 +0100 (CET) Date: Tue, 22 Nov 2022 07:11:58 +0100 From: Christoph Hellwig To: Stephen Rothwell Cc: Christoph Hellwig , Linux Kernel Mailing List , Linux Next Mailing List , Takashi Iwai Subject: Re: linux-next: manual merge of the dma-mapping tree with Linus' tree Message-ID: <20221122061158.GA14175@lst.de> References: <20221122100611.13a374e2@canb.auug.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221122100611.13a374e2@canb.auug.org.au> User-Agent: Mutt/1.5.17 (2007-11-01) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 22, 2022 at 10:06:11AM +1100, Stephen Rothwell wrote: > I fixed it up (see below) and can carry the fix as necessary. This > is now fixed as far as linux-next is concerned, but any non trivial > conflicts should be mentioned to your upstream maintainer when your tree > is submitted for merging. You may also want to consider cooperating > with the maintainer of the conflicting tree to minimise any particularly > complex conflicts. Thanks Stephen, the fix look good. The being said the code in the sound tree here is questionable to start with: > #ifdef CONFIG_SND_DMA_SGBUF > + if (!sgt && !get_dma_ops(dmab->dev.dev)) { > if (dmab->dev.type == SNDRV_DMA_TYPE_DEV_WC_SG) > dmab->dev.type = SNDRV_DMA_TYPE_DEV_WC_SG_FALLBACK; > else driver have no busuness calling get_dma_ops and poking into the dma-mapping internals.