linux-kernel - Re: [PATCH 05/20] pata_efar: always program master_data before slave

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: <4D62C5E1.9070307@pobox.com>
Date:	Mon, 21 Feb 2011 15:06:57 -0500
From:	Jeff Garzik <jgarzik@...ox.com>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
CC:	Sergei Shtylyov <sshtylyov@...sta.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-ide@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 05/20] pata_efar: always program master_data before slave_data

On 02/19/2011 04:25 AM, Bartlomiej Zolnierkiewicz wrote:
> Jeff, would it be possible to queue patches #01-15 for 2.6.39 if there
> are no further concerns with them (thus leaving the merging of
> PIIX-like drivers for later)?  They got additional testing on ICH4 and
> they look mostly safe&  straight-forward compared to #16-21.

This seems to directly contradict what you wrote earlier in the thread,

	This is why patches were posted to mailing list with a request
	for a real hardware testing:

	"All testing was done using QEMU's PIIX3 controller emulation
	so any testing with real EFAR, IT8213, old PIIX, RDC and
	Radisys R82600 PATA controllers would be really appreciated.."

	instead of request for a merge.  It was all there in initial
	mail.

and

	I do not really care that much if it will be merged ever

Regardless of this self-contradictory attitude, I do want useful patches 
and many of these patches seem useful.

So I will continue watching the Bart/Alan/Sergei threads play out, and 
then look at merging the result.  In the midst of all the arguing, 
productive work / forward progress is occurring, so the end result 
should be positive.

It would be nice if we could get at least an "it works" test for the 
older hardware, since those are the changes /least/ likely to be tested 
by queueing to linux-next.

	Jeff


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