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]
Message-ID: <alpine.LNX.2.00.1511252132580.23266@nippy.intranet>
Date:	Wed, 25 Nov 2015 22:50:32 +1100 (AEDT)
From:	Finn Thain <fthain@...egraphics.com.au>
To:	Ondrej Zary <linux@...nbow-software.org>
cc:	Sam Creasey <sammy@...my.net>,
	Michael Schmitz <schmitzmic@...il.com>,
	"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 00/71] More fixes, cleanup and modernization for NCR5380
 drivers


On Wed, 25 Nov 2015, Ondrej Zary wrote:

> On Wednesday 25 November 2015, Finn Thain wrote:
> > 
> > On Tue, 24 Nov 2015, Ondrej Zary wrote:
> > 
> > > Instead of fixing split transfers, simply forced everything 
> > > non-modulo-128 to PIO:
> > 
> > [...]
> > I don't have any reason to think that your card will allow part of 
> > a transfer to be performed with PDMA and the rest with PIO. So I don't 
> > really object to the patch.
> > 

>From looking at the datasheet, I think your patch is correct.

Your patch needs to be applied after mine, so if you will sign-off, I'll 
include it in the series with your Signed-off-by and "From:" header.

> > But I don't understand the need for it either: I have no idea what 
> > state the driver, chip and scsi bus were in when the 126-byte PIO 
> > transfer failed. If the PIO transfer didn't succeed then the entire 
> > command should have failed.
> 
> The patch was just a quick hack to confirm that PDMA is not completely 
> broken.
> Now we know that it mostly works so I can investigate the partial PIO 
> problem.
> 

There may not be any problem to investigate. Because this 53C80 core is 
embedded in other logic, it's hard to say whether or not the partial PIO 
algorithm could be expected to work at all.

Besides, the DMA errata don't apply to this core. And large transfers will 
always be divisible by 128 bytes so there's very little to be gained.

> [...]
> 
> 53C400A datasheet would be great too but haven't found any.

I don't have one either.

-- 
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ