Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933743AbbKSEoJ (ORCPT ); Wed, 18 Nov 2015 23:44:09 -0500 Received: from mail-pa0-f45.google.com ([209.85.220.45]:32963 "EHLO mail-pa0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756164AbbKSEoG (ORCPT ); Wed, 18 Nov 2015 23:44:06 -0500 Message-ID: <564D538D.2070905@gmail.com> Date: Thu, 19 Nov 2015 17:43:57 +1300 From: Michael Schmitz User-Agent: Mozilla/5.0 (X11; Linux ppc; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Finn Thain CC: "James E.J. Bottomley" , linux-m68k@vger.kernel.org, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 10/71] atari_NCR5380: Remove RESET_BOOT, CONFIG_ATARI_SCSI_TOSHIBA_DELAY and CONFIG_ATARI_SCSI_RESET_BOOT References: <20151118083455.331768508@telegraphics.com.au> <20151118083457.891774987@telegraphics.com.au> <564D3C6C.7020600@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1790 Lines: 45 Hi Finn, Am 19.11.2015 um 17:05 schrieb Finn Thain: > w > On Thu, 19 Nov 2015, Michael Schmitz wrote: > >> Hi Finn, >> >> Am 18.11.2015 um 21:35 schrieb Finn Thain: >> >>> The bus reset may raise an interrupt. That would be new behaviour for >>> atari_scsi only when CONFIG_ATARI_SCSI_RESET_BOOT=n. The ST DMA >>> interrupt is not assigned to atari_scsi at this stage, so >>> CONFIG_ATARI_SCSI_RESET_BOOT=y may well be problematic already. >> >> I can confirm that the bus reset at boot has never been problematic in >> the past. It's been enabled in my kernels as long as I've used the >> driver (must be getting close to 20 years now). > > That's good to know. I'm not sure why it was configurable in the first > place (long delays?). The new algorithm (the one I copied from NCR5380.c) The longer delays (and possibly a reset at boot) were only necessary for certain CD-ROM drives. I don't think I have ever seen such a device, and it's a bit unlikely any of these still survive. Reset at boot before proper driver init can probably go away now. > does not allow the user to prevent a possible scsi bus reset at driver > init time. The scsi bus reset only takes place if the driver discovers > that the bus was already wedged when it started. (It proved useful when I > was introducing faults for EH testing, BTW.) Much saner approach, I'm sure. Don't forget the driver was written before sophisticated error handling came along. Reset at boot and keep your fingers crossed was the strategy in these days. Cheers, Michael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/