Ar Maw, 2006-08-01 am 02:03 +0900, ysgrifennodd Tejun Heo:
> 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.
Ouch yes.
> 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.
Agreed. I looked at that but it seemed that it isn't true that you can
assume port_no == hard_port_no because you may have a device which has
the primary port disabled and the secondary port set legacy. This also
sort of comes up in mixed devices but we don't handle them and I think
it comes out correctly once we do the pure legacy case right.
> 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.
Think about the following execution sequence
ati_pci_init_one
primary port already stolen by drivers/ide
secondary port free
legacy_mode = ATA_PORT_SECONDARY
ata_pci_init_legacy_port
port_num = 0
hard_port_num = 1
*kerunnccchhhhhh*
> 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.
I agree with the theory and the diagnosis. I'm a bit worried about
hard_port_no however and I don't think that bit is safe in the secondary
only corner case. Registering both always and disabling one works for me
as a cleanup.
If you do that then I'll audit all the drivers use of ->port_no against
the patches.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
