Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp485822pxk; Wed, 2 Sep 2020 07:05:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzOLYHK1hjHoo+f3t2oOgbpyWVzav3I1xAyO+t5vFLGhLcfX4Djye6HxLENtyCIyCpuedyt X-Received: by 2002:a17:906:d787:: with SMTP id pj7mr177618ejb.340.1599055524324; Wed, 02 Sep 2020 07:05:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599055524; cv=none; d=google.com; s=arc-20160816; b=qn9Vjp4Z9zmRPnrwxDZXhL3HJTRC/+ekIx3nCtapfnaxcKtXSx/rAteD1ujDreHW6X O5JvYcCSxZB4GwgZBa+RsV5PAi2LdxtYCbrL1gzP7WoKhaJuuo7QoGl6tlEAY9rL3ISX dFhCtTx1iSJNI/THyW05633ZwXmG5xCx8bzCFANLizP9DvBfCyG/akiNk6rhRbeR/xhF fh8VQDV3ayfoa6+DRfmHwVNh1CQItL0kBuiaoVeOat2z3VY3OLnCU3gUTFWQyJrxZRXp 2Q4g5HDrdBg7K2LaRALtaig9hM6i3hIr7xB8FBG9oBynLqCXWmYG+czYcAY+/tv0KSqk TQiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=fmF5AQ9FKss8+0F1TJ7j6EXbdXn/kPiEyS4tV4JF1dM=; b=hNX55abNeMMqncVtCarn0RPmOf9KKNLvNN6G9bzl7svIMaf1l3lnuERQG1YlGo143K jTW/wXObK9pV6vvRnnDSY9K7ruxvi7/1X5LDc0TrMEJY7xfew8lXPKPteSpPjfsV0kEV t+uW0nMbO+5l/o7vsYLvM2rTKwU/rsYUDBtfnf3DR+4CFcsQnlpNm1u3j5c+rMII4eC7 jSjQmhsaJKUuhsRnZ25gCYJJhASDo04DHBcQjd5pHglbWTRDcM76c/gLFKdU6OcZXK5b /SnnsQNy5LNdXtgN1Tl8YotLCNQchVRP71AiyLq7A3RncVWDMOAl4BlwrbyiBsxe4KfF XwYQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m16si2582113edr.280.2020.09.02.07.04.50; Wed, 02 Sep 2020 07:05:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727797AbgIBODk (ORCPT + 99 others); Wed, 2 Sep 2020 10:03:40 -0400 Received: from brightrain.aerifal.cx ([216.12.86.13]:48914 "EHLO brightrain.aerifal.cx" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727838AbgIBNtk (ORCPT ); Wed, 2 Sep 2020 09:49:40 -0400 Date: Wed, 2 Sep 2020 09:34:07 -0400 From: Rich Felker To: Christoph Hellwig Cc: Ulf Hansson , "linux-mmc@vger.kernel.org" , Mark Brown , Linux-sh list , Linux Kernel Mailing List Subject: Re: [PATCH v2] mmc: mmc_spi: Allow the driver to be built when CONFIG_HAS_DMA is unset Message-ID: <20200902133400.GQ3265@brightrain.aerifal.cx> References: <20200901150438.228887-1-ulf.hansson@linaro.org> <20200901150654.GB30034@lst.de> <20200901154049.GA376@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200901154049.GA376@lst.de> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 01, 2020 at 05:40:49PM +0200, Christoph Hellwig wrote: > On Tue, Sep 01, 2020 at 05:36:17PM +0200, Ulf Hansson wrote: > > > I still don't think this makes sense, as the dma_mask should always > > > be non-NULL here. > > > > If that is the case, I wonder how the driver could even have worked without DMA. > > > > Because in the existing code, host->dma_dev gets assigned to > > spi->master->dev.parent->dma_mask - which seems to turn on the DMA > > usage in the driver. > > > > What am I missing? > > Do you know of other non-DMA users? For SH nommu it probably worked > because SH nommu used to provide a DMA implementation that worked > fine for streaming maps, but was completely broken for coherent > allocation. And this driver appears to only use the former. On the system we're using it on, there's no DMA whatsoever. It just used to allow memory allocations suitable for DMA (which any allocation vacuuously is when there's no DMA) but now it doesn't, due to your change. Just below the if block in question in this thread is: host->readback.is_dma_mapped = (host->dma_dev != NULL); and similar conditions appear elsewhere all over the file in the form of if (host->dma_dev). Of course doing DMA requires a link to a DMA controller device, and plenty SPI devices (most obviously bit-banged ones) lack DMA. The right condition for the block in question here is probably just checking dma_dev instead of dma_mask or CONFIG_HAS_DMA, but it seems useful to optimize out the code if CONFIG_HAS_DMA is false, anyway. Rich