Re: [2.6.18-rc2-mm1] libata ate one PATA channel

[Tejun Heo <htejun@gmail.com>]

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