Tejun Heo wrote:
On Mon, Jul 31, 2006 at 05:31:29PM +0100, Alan Cox wrote:
Ar Maw, 2006-08-01 am 01:00 +0900, ysgrifennodd Tejun Heo:
These are patches #110-112. Andrew, can you drop those patches for the
time being? I'm working on integrating those into libata #upstream now.
If you drop the host_set and tuning patches please drop all the PATA
stuff and my other patches out. I don't have time to field a second
batch of hundreds of "why has my drive stopped working, why is the speed
wrong" emails.
Didn't realize pata stuff relies on it.
It'll be easier just to work outside the -mm tree with all this
continued in/out random breakage if people are just going to say "drop
xyz patch" rather than actually specifying *what is actually wrong* and
getting me to fix the merge (Tejun that last one sentence is a hint ;))
Okay, took the hint. Magallon, can you please try the following
patch?
Hit send a bit too fast.
Alan, the reason why the second port disappeared is a bug in
init_legacy_mode(). probe_ent->n_ports is fxied to 1 and port_no gets
incremented while initializing the second port ending up initializing
part of the third port.
Another problem is that probe_ent/ap->hard_port_no are meaningless.
hard_port_no is used to get port_no right on legacy cases where index of
host_set->ports[] doesn't match the actual port_no. When there is only
one host_set, port_no should always equal hard_port_no. For legacy
hosts, the original code ended up assigning the wrong hard_port_no's.
I killed hard_port_no by s/ap->hard_port_no/ap->port_no/g without
actually reviewing the usages (man, those are a LOT). If all pata
drivers always relied on ap->hard_port_no representing the actual port
index in the controller, there shouldn't be a problem. But, just in
case, please review the change.
If this fixes Magallon's problem and you agree with the fix, I'll break
it down to two patches and submit'em to you with proper heading and all.
Thanks. :)
--
tejun
-
: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
