Received: by 10.192.165.148 with SMTP id m20csp1739695imm; Sat, 21 Apr 2018 14:58:34 -0700 (PDT) X-Google-Smtp-Source: AIpwx492p1X2o26rngnoI9qcm6y/JxD5KFQsp2nIrEbpUUW/ftX1iuvCfvsUawSjzss/NxLQIxiG X-Received: by 10.101.69.132 with SMTP id o4mr12532657pgq.213.1524347914156; Sat, 21 Apr 2018 14:58:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524347914; cv=none; d=google.com; s=arc-20160816; b=I5hHriEkhUO4gCxd5DYuyZA88nW1ma8vUhnaCyBozCTf6ZCOsWw0/4I8N/qHsyPo8X 7PVib4n/0Kovw2kBiDpIMMM1avjnhjyPFz1wXGOvqNgQR8QOy7TRvCe9R2GWJW996ywX CPW9/ScCHzfNWiCKKQJnBYO9ZM2NUI80FszM3CEY/0A0y/8zEMTJl2AsNL2ARPb7xr0U 8QNBBCiGLKlNmb4zQmycBpohBTw/RaO75uNeb5i2qfO5mTbt1cni1j/Mhf5yyssfXsCC pxT9mpXawErCFQihuBR8TNlhyckav1ZwI5kvXeN6j7GwhGvfIaBAXL15jZwBBzZ/tl0T knMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :dkim-signature:arc-authentication-results; bh=GkAq7TogJbMfDOJCGhIYm0uKYJhdVtevPihkcrMoPyM=; b=oAH2pOHfOJo3oRifpN4JsJjlKmGQzZ61uZfT/u6796nbspI+gS8YjylLlMxf6Q15qX YEHer2zZzx5Qnl5Ixq3n1bKNJLw3YXTMSKdxvhQwXXqjPW6t9dH5lFpOaABP4FKx2Hkp sXff5X3ecx4hpMHqr0whNVlrsKNeUib3QGgjjW84hlGftgEifX7U1pdlii+OL1vPfWqD ecaB1kq1qshLQietQRxWvM1/YDKPZZC7zs94pgXjXXrvvKbHWfeYy8QpoG/qsZA+BltF B/LK1+w9TdYlsljI3CQ+mFOW+VMHBfpiFvQhOK2snupWhTByJchz+C9+a7lm0UjI9xHq D4EA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=JSeQKU8j; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hansenpartnership.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i7si6217022pgo.489.2018.04.21.14.58.19; Sat, 21 Apr 2018 14:58:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@hansenpartnership.com header.s=20151216 header.b=JSeQKU8j; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=hansenpartnership.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753350AbeDUVzw (ORCPT + 99 others); Sat, 21 Apr 2018 17:55:52 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:37456 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753310AbeDUVzs (ORCPT ); Sat, 21 Apr 2018 17:55:48 -0400 Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 91C858EE293; Sat, 21 Apr 2018 14:55:47 -0700 (PDT) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rj7rUnjl6IPo; Sat, 21 Apr 2018 14:55:47 -0700 (PDT) Received: from [192.168.40.139] (unknown [80.169.201.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 2433C8EE062; Sat, 21 Apr 2018 14:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1524347747; bh=JhwGxYbcjz2hU7Dqx/75JZAj3vVpTcWUwaBaMTv7dHk=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=JSeQKU8jdKnG9ZJgqyBpf1I4rDkYAcnS8htsGHQDRCvhT4cD6RDx0IeYxHlfu9aB5 pTHUujOrj4rkLGYHBHD/BQnbCDnWyC2BYaf8aopImKCeUOEXq6jz8kW4XtJBpBK8C4 y1F+o0Uc1S45iaNGwjiIWEjEH4rzGrGs/arLHt34= Message-ID: <1524347537.3335.12.camel@HansenPartnership.com> Subject: Re: [PATCH 22/22] parisc: use generic dma_noncoherent_ops From: James Bottomley To: Helge Deller , Christoph Hellwig Cc: linux-arch@vger.kernel.org, Michal Simek , Greentime Hu , Vincent Chen , linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-c6x-dev@linux-c6x.org, linux-hexagon@vger.kernel.org, linux-m68k@lists.linux-m68k.org, nios2-dev@lists.rocketboards.org, openrisc@lists.librecores.org, linux-parisc@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org Date: Sat, 21 Apr 2018 22:52:17 +0100 In-Reply-To: References: <20180420080313.18796-1-hch@lst.de> <20180420080313.18796-23-hch@lst.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 2018-04-21 at 19:43 +0200, Helge Deller wrote: > On 20.04.2018 10:03, Christoph Hellwig wrote: > > Switch to the generic noncoherent direct mapping implementation. > > > > Parisc previously had two different non-coherent dma ops > > implementation that just different in the way coherent allocations > > were handled or not handled.  The different behavior is not > > selected at runtime in the arch_dma_alloc and arch_dma_free > > routines.  The non-coherent allocation in the pcx cases now uses > > the dma_direct helpers that are a little more sophisticated and > > used by a lot of other architectures. > > > > Fix sync_single_for_cpu to do skip the cache flush unless the > > transfer is to the device to match the more tested unmap_single > > path which should have the same cache coherency implications. > > > > This also now consistenly uses flush_kernel_dcache_range for cache > > flushing while previously some of the SG based operations used > > flush_kernel_vmap_range instead. > > > This patch breaks a 32bit kernel on a B160L machine (PA7300LC CPU, > "pcxl2"). After applying this patch series the lasi82956 network > driver works unreliable.  NIC gets IP, but ping doesn't work. > See drivers/net/ethernet/i825xx/lasi_82596.c, it uses dma*sync() > functions. That's actually a weird result. The 32 bit machines have two cases: those that can make uncached memory by setting the U bit (and thus don't need the sync operations in the lasi and D700 drivers) and those that can't. The latter is basically only the old 700 series. The B180 is in the class of can set pages to uncached, so it sounds like something in our uncached memory allocation for dma areas is failing after this patch set. I still have an old 700 in my box of curiosities, so I can try to dust it off and plug it back in when I get home to see what it makes of the series when it gets fixed. James James