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 EB0CBCCA479 for ; Tue, 28 Jun 2022 21:55:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230163AbiF1Vzi (ORCPT ); Tue, 28 Jun 2022 17:55:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55794 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229548AbiF1Vzh (ORCPT ); Tue, 28 Jun 2022 17:55:37 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A35E21AF1A; Tue, 28 Jun 2022 14:55:36 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3E70E618C7; Tue, 28 Jun 2022 21:55:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97E13C341CD; Tue, 28 Jun 2022 21:55:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1656453335; bh=Ih9a5Om/MmEIX4v6ClfaGsYY95Thx/a8Y6asrG6fwXg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=b9uS1y9zZH5shNehIU788hla2D3cqHzEuOf4ntBz7MxqozEJwfWJnE7Ks7x80vJUW 8kv3pqmsjiCee09PX0yvTGcEx2Cut7rd5VUEPi1Ok/r71Li89UIa9lEeJs5lir3L9G dn4sMp8EjadD8vyN158bB9WMKMo5ug00j2hr3Rw0LFCkWa1OVhmADFgMiyWCAjhqeq 2pPGkYfNIcwUIJa/2IbGbgiBIvXriXV6e543WcMEwsN7/jAf15mGlk3t/07+apGlTT 9sZR5rPOipfKd8HT5ntaMBYuQG73aLI/777pK3YIaE2zifWvCB2udwOFws1KKx4vlJ kWfB059WXYR2A== Received: by mail-yb1-f177.google.com with SMTP id i7so24496795ybe.11; Tue, 28 Jun 2022 14:55:35 -0700 (PDT) X-Gm-Message-State: AJIora/FxTrjp0wIzxv6CQDTIDEof8qJpvgfGJARNat5PBxKqZStB2k0 Eb7uLbyCYFvIS7xTc9tMDmlYP486ikdYzdZjPfw= X-Google-Smtp-Source: AGRyM1tb4BjbkpD5w5tudBkGYRK/cIE8Bb7XiI/EYhHGbLLjj5dThHoetSIfSlMkV4AlJod7kkGZlzoBKXhTY7DLP7I= X-Received: by 2002:a05:6902:120f:b0:668:2228:9627 with SMTP id s15-20020a056902120f00b0066822289627mr22801646ybu.134.1656453334640; Tue, 28 Jun 2022 14:55:34 -0700 (PDT) MIME-Version: 1.0 References: <20220617125750.728590-1-arnd@kernel.org> <20220617125750.728590-4-arnd@kernel.org> <6ba86afe-bf9f-1aca-7af1-d0d348d75ffc@gmail.com> <9289fd82-285c-035f-5355-4d70ce4f87b0@gmail.com> In-Reply-To: From: Arnd Bergmann Date: Tue, 28 Jun 2022 23:55:17 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 3/3] arch/*/: remove CONFIG_VIRT_TO_BUS To: Michael Schmitz Cc: Geert Uytterhoeven , scsi , Linux Kernel Mailing List , Arnd Bergmann , Jakub Kicinski , Christoph Hellwig , Marek Szyprowski , Robin Murphy , Linux IOMMU , Khalid Aziz , "Maciej W . Rozycki" , Matt Wang , Miquel van Smoorenburg , Mark Salyzyn , linuxppc-dev , Linux-Arch , alpha , linux-m68k , Parisc List , Denis Efremov , Michael Ellerman , John Paul Adrian Glaubitz Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org On Tue, Jun 28, 2022 at 11:38 PM Michael Schmitz wrote: > On 28/06/22 19:08, Arnd Bergmann wrote: > > I see two other problems with your patch though: > > > > a) you still duplicate the cache handling: the cache_clear()/cache_push() > > is supposed to already be done by dma_map_single() when the device > > is not cache-coherent. > > That's one of the 'liberties' I alluded to. The reason I left these in > is that I'm none too certain what device feature the DMA API uses to > decide a device isn't cache-coherent. If it's dev->coherent_dma_mask, > the way I set up the device in the a3000 driver should leave the > coherent mask unchanged. For the Zorro drivers, devices are set up to > use the same storage to store normal and coherent masks - something we > most likely want to change. I need to think about the ramifications of > that. > > Note that zorro_esp.c uses dma_sync_single_for_device() and uses a 32 > bit coherent DMA mask which does work OK. I might ask Adrian to test a > change to only set dev->dma_mask, and drop the > dma_sync_single_for_device() calls if there's any doubt on this aspect. The "coherent_mask" is independent of the cache flushing. On some architectures, a device can indicate whether it needs cache management or not to guarantee coherency, but on m68k it appears that we always assume it does, see arch/m68k/kernel/dma.c > > b) The bounce buffer is never mapped here, instead you have the > > virt_to_phys() here, which is not the same. I think you need to map > > the pointer that actually gets passed down to the device after deciding > > to use a bouce buffer or not. > > I hadn't realized that I can map the bounce buffer just as it's done for > the SCp data buffer. Should have been obvious, but I'm still learning > about the DMA API. > > I've updated the patch now, will re-send as part of a complete series > once done. I suppose you can just drop the bounce buffer if this just comes from kmalloc(). Arnd