NV SATA breakage: jgarzik/libata-dev#upstream etc

[Krzysztof Halasa]

Hi,

The following commit in libata-dev breaks NV SATA init - I don't
have a dump handy, but the problem is a NULL ptr dereference here:

libata-core.c
int ata_device_add(const struct ata_probe_ent *ent)
{
...
        /* register each port bound to this device */
        for (i = 0; i < host->n_ports; i++) {
...
                /* start port */
                rc = ap->ops->port_start(ap);
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The problematic commit is fea63e38013ec628ab3f7fddc4c2148064b7910a:
"[PATCH] libata: fix non-uniform ports handling

Non-uniform ports handling got broken while updating libata to handle
those in the same host.  Only separate irq for the non-uniform
secondary port was implemented while all other fields (host flags,
transfer mode...) of the secondary port simply shared those of the
first.

For ata_piix combined mode, which ATM is the only user of non-uniform
ports, this causes the secondary port assume the wrong type.  This can
cause PATA port to use SATA ops, which results in bogus check on PCS
and detection failure.

This patch adds ata_probe_ent->pinfo2 which points to optional
port_info for the secondary port.  For the time being, this seems to
be the simplest solution.  This workaround will be removed together
with ata_probe_ent itself after init model is updated to allow more
flexibility."


All details etc. are, as always, available on request.

00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2)
(prog-if 85 [Master SecO PriO])
        Subsystem: Micro-Star International Co., Ltd. Unknown device 7250
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 225
        I/O ports at c800 [size=8]
        I/O ports at c480 [size=4]
        I/O ports at c400 [size=8]
        I/O ports at c080 [size=4]
        I/O ports at c000 [size=16]
        Memory at feaf9000 (32-bit, non-prefetchable) [size=4K]
-- 
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/