linux-kernel - Re: [PATCH 10/71] atari_NCR5380: Remove RESET_BOOT, CONFIG_ATARI_SCSI_TOSHIBA_DELAY and CONFIG_ATARI_SCSI_RESET

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 19 Nov 2015 17:43:57 +1300
From:	Michael Schmitz <schmitzmic@...il.com>
To:	Finn Thain <fthain@...egraphics.com.au>
CC:	"James E.J. Bottomley" <JBottomley@...n.com>,
	linux-m68k@...r.kernel.org, linux-scsi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 10/71] atari_NCR5380: Remove RESET_BOOT, CONFIG_ATARI_SCSI_TOSHIBA_DELAY
 and CONFIG_ATARI_SCSI_RESET_BOOT

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/