Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp3505693ybi; Sun, 2 Jun 2019 16:45:05 -0700 (PDT) X-Google-Smtp-Source: APXvYqzTVkoAy8ElaUywNwFjbFlG9uC6L/RLK+J1KO0zo0cM07em66yCB16Hb8NdrpnPKSU1OjyT X-Received: by 2002:a17:90a:2641:: with SMTP id l59mr1755604pje.55.1559519105006; Sun, 02 Jun 2019 16:45:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559519104; cv=none; d=google.com; s=arc-20160816; b=H7JFfce/m4XqFcA3k6ptcJd+tJx35IGjBYuSTwb2DgUkwV45GlupclM54dza5dixWD sf/QMGrhTMRbzMuLoZNlUmg9s6izj0kLeog2fP0/46nrflOOdlA+Myg13H69La+yAC+p nweaKjMS5vtbxRgiqAz6KzNZrtUF7DexNMbcQ/0W70PTv8f0GZX1CILe1z9yCntwIlfR 3fZ6rwI8WQ2OfHmVLn212vY0eueRj4Uotf7uTwXLKezsDXW5es4n6vjM/8huYzKeZsdq kiZB1fLwfXj7PUUj35oLUFyc/5eGC+ZU/oIeKTpt0UfpVOlZCQb/98JbKOJVRx/+M35o Lthg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:references:message-id :in-reply-to:subject:cc:to:from:date; bh=fLFeSk81JK/IqkeCJRaasUNhfx/JWrZ50YFFsUkNGUI=; b=xY/lq3vGvWCcZWqO/o1vrsRxLRCWH5tOP6Ljx7vZsqfyZAOWE3X3y9qqLdLvZ/D/XK /mgkrjDUAsFxiFdolFTJKpqZ+VYAe7MueH28U4/1zRx72W1O/6xNbxOUrEy6KNQ0rUpr PXxAz6ir1PdTmjPRcQZwUORv7MOFjyGDJjqytHYwrkRzRJTsdxESlc0nzSn8H9Su6rRp fMU9UdV//nofUfLm8AN7eAdpLSCgE7E56WMhG8H+NrjKu8JRZwUSlJyaiC1WS644ql5L sA5sHpOOq2mMTKvwrTKnFPmbab9Ywc7zUwu8/3qq2ccFhGEXh0HeAB7bO5mXVq8svkr3 1FTA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h9si6837520pju.85.2019.06.02.16.44.10; Sun, 02 Jun 2019 16:45:04 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726786AbfFBXcl (ORCPT + 99 others); Sun, 2 Jun 2019 19:32:41 -0400 Received: from kvm5.telegraphics.com.au ([98.124.60.144]:48238 "EHLO kvm5.telegraphics.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726305AbfFBXcl (ORCPT ); Sun, 2 Jun 2019 19:32:41 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by kvm5.telegraphics.com.au (Postfix) with ESMTP id C7BA3283AD; Sun, 2 Jun 2019 19:32:35 -0400 (EDT) Date: Mon, 3 Jun 2019 09:32:36 +1000 (AEST) From: Finn Thain To: Geert Uytterhoeven cc: "James E.J. Bottomley" , "Martin K. Petersen" , Michael Schmitz , scsi , Linux Kernel Mailing List , stable , linux-m68k Subject: Re: [PATCH 5/7] scsi: mac_scsi: Fix pseudo DMA implementation, take 2 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2 Jun 2019, Geert Uytterhoeven wrote: > Hi Finn, > > On Sun, Jun 2, 2019 at 3:29 AM Finn Thain > wrote: > > A system bus error during a PDMA transfer can mess up the calculation > > of the transfer residual (the PDMA handshaking hardware lacks a byte > > counter). This results in data corruption. > > > > The algorithm in this patch anticipates a bus error by starting each > > transfer with a MOVE.B instruction. If a bus error is caught the > > transfer will be retried. If a bus error is caught later in the > > transfer (for a MOVE.W instruction) the transfer gets failed and > > subsequent requests for that target will use PIO instead of PDMA. > > > > This avoids the "!REQ and !ACK" error so the severity level of that > > message is reduced to KERN_DEBUG. > > > > Cc: Michael Schmitz > > Cc: Geert Uytterhoeven > > Cc: stable@vger.kernel.org # v4.14+ > > Fixes: 3a0f64bfa907 ("mac_scsi: Fix pseudo DMA implementation") > > Reported-by: Chris Jones > > Tested-by: Stan Johnson > > Signed-off-by: Finn Thain > > Thanks for your patch! > > > --- > > arch/m68k/include/asm/mac_pdma.h | 179 +++++++++++++++++++++++++++ > > drivers/scsi/mac_scsi.c | 201 ++++++++----------------------- > > Why have you moved the PDMA implementation to a header file under > arch/m68k/? Do you intend to reuse it by other drivers? > There are a couple of reasons: the mac_esp driver also uses PDMA and the NuBus PowerMac port also uses mac_scsi.c. OTOH, the NuBus PowerMac port is still out-of-tree, and it is unclear whether the mac_esp driver will ever benefit from this code. > If not, please keep it in the driver, so (a) you don't need an ack from > me ;-), and (b) your change may be easier to review. > I take your wink to mean that you don't want to ask the SCSI maintainers to review m68k asm. Putting aside the code review process for a moment, do you have an opinion on the most logical way to organise this sort of code, from the point-of-view of maintainability, re-usability, readability etc.? Thanks. -- > Thanks! > > Gr{oetje,eeting}s, > > Geert > >