Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp3777786ybi; Sun, 2 Jun 2019 23:26:19 -0700 (PDT) X-Google-Smtp-Source: APXvYqwEhPEEsb3vXw+UJ6gKxML3Ymc17cPBjnFgY7cI9CMHK4tLOgjq2w+TJ6SWYt0xGbKAcNK/ X-Received: by 2002:a65:620a:: with SMTP id d10mr26493230pgv.42.1559543179066; Sun, 02 Jun 2019 23:26:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559543179; cv=none; d=google.com; s=arc-20160816; b=ypQZmDZZ317cay3o9WkmOTZ611ltYSQTWUpUPQMXtDNc86Opy/z2Vrgty07r7x1sZM YnBncnYcQ7CaoDq+07AmmbxutAbmV/3TcFl3pHZFJNQFQYb2iSljQ1X0OqEuhAA1L+YF WziL14+5wjFpwbsIMLIE9llTsqAH5oKyVxAtNEjBCwyfKirSstKaqeqAV3kzey5O9t2Q gS9DDop4TYKxSBdeH6Ia+FO/jB/N1aVu9OqhMOthH++0Icet3uze/IhH4x/+aAWOfsbj MFEcyJeegP4Cwxf4CUJW6Z1VVNTbSjJbr5mPq3VvjugjUhxlB7to/HXIyaJHzInqvO/y 16sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=lU1yMqA1q556Chq2SdDTyPyC3Sn1W2i9WqstPYhXvqc=; b=q9PqmOG6u6DEX+gR1ykoNbkB27CvkdB06AdgCjrCSI9KH/0ZjlZlwkUFHa65J31dtZ n6/Nhx+ILFcEMPOvK2nJbrK+dFZbu5IgYKc49te5pOEF7eudA/VGdaBesLJwaJLf1bCX LxLhxBJZbQPWtEZlUL4EKySqK8FrqEYb4bnNy5YeS/sYXrs+A12gfGEJZI7VC+JINusQ Svcq5+Sn/Lg8Ul8F2r2Q9UfpMaILm2VV+hDOV+sZogXqgz104tEZtu6nGMMugg/GNjX/ ejzKHEcxkdsz2LFRWGfDPT6hP5wMJQzc7Ab0mdJzf2+LHS/ImiFCBFS+1Q3kQ3E8dDZR Xggg== 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 z72si16996328pgz.56.2019.06.02.23.26.02; Sun, 02 Jun 2019 23:26:19 -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 S1726958AbfFCGX2 (ORCPT + 99 others); Mon, 3 Jun 2019 02:23:28 -0400 Received: from mail-lj1-f194.google.com ([209.85.208.194]:32881 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726792AbfFCGX1 (ORCPT ); Mon, 3 Jun 2019 02:23:27 -0400 Received: by mail-lj1-f194.google.com with SMTP id v29so3720191ljv.0; Sun, 02 Jun 2019 23:23:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lU1yMqA1q556Chq2SdDTyPyC3Sn1W2i9WqstPYhXvqc=; b=ZYF8ZHHot0+aZVLTzj+zFLYJ/Bax7NjPF5zoBNHKQebLv17ZWFbuKANwmK5WZwUDvZ MiseXXo2G/AkEf+q9+hSpO/y6pv3wHhxeZeLOiZpBZy/0detOd1WQWYqXl5G8EBtALxp JD/IFUoOqzXXjCQ5Md5i8RnrZrNoGstocyG5YTq7ORlPezlXmeHI9rRalz8KsAZKosb5 uXPl/z/YQDeWKOoQg3A39X8AInZ2TU47/LlZl2NtH2k9sFMYrsVHrpqZNkXQ38CfLTjp SDfM8P64sk+PvbVyTQzIRXhnPCp/rFwSX7gEC63ezV8eFWirfipUk3tj6kR2ByVOqpOp fNNg== X-Gm-Message-State: APjAAAV+mSHsmQXCf+FxnTZ2Wau2VGtG8XgjxO/+olk36DAg9Y33Q5ze NjPKqczPKrGP4yC5hX+Kw2ZVFM7t1wcWZfhtwYY= X-Received: by 2002:a2e:91c5:: with SMTP id u5mr1310202ljg.65.1559543005801; Sun, 02 Jun 2019 23:23:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Geert Uytterhoeven Date: Mon, 3 Jun 2019 08:23:13 +0200 Message-ID: Subject: Re: [PATCH 5/7] scsi: mac_scsi: Fix pseudo DMA implementation, take 2 To: Finn Thain Cc: "James E.J. Bottomley" , "Martin K. Petersen" , Michael Schmitz , scsi , Linux Kernel Mailing List , stable , linux-m68k Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Finn, On Mon, Jun 3, 2019 at 1:32 AM Finn Thain wrote: > On Sun, 2 Jun 2019, Geert Uytterhoeven wrote: > > 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. So you do have future sharing in mind... > > 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 I meant that apart from the code containing m68k assembler source, it is not related to arch/m68k/, and thus belongs to the driver. There are several other drivers that contain pieces of assembler code. > 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.? If the code is used by multiple SCSI drivers, you can move it to a header file under drivers/scsi/. If the code is shared by drivers belonging to multiple subsystems, you can move it to a header file under include/linux/. Anyone who has a better solution? Thanks! Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds