[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48407C61.4040805@garzik.org>
Date: Fri, 30 May 2008 18:14:57 -0400
From: Jeff Garzik <jeff@...zik.org>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
CC: linux-kernel@...r.kernel.org, linux-ide@...r.kernel.org
Subject: Re: [RFC PATCH] libata-sff: Fix oops reported in kerneloops.org for
pnp devices with no ctl
Alan Cox wrote:
>>> Want me to roll a patch in that style ?
>> Works for me...
>
> Ok
>
> - Make ata_sff_altstatus private so nobody uses it by mistake
> - Drop the 400nS delay from it
>
> Add
>
> ata_sff_irq_status - encapsulates the IRQ check logic
>
> This function keeps the existing behaviour for altstatus using devices. I
> actually suspect the logic was wrong before the changes but -rc isn't the
> time to play with that
>
> ata_sff_sync - ensure writes hit the device
>
> Really we want an io* operation for 'is posted' eg ioisposted(ioaddr) so
> that we can fix the nasty delay this causes on most systems.
>
> - ata_sff_pause - 400nS delay
>
> Ensure the command hit the device and delay 400nS
>
> - ata_sff_dma_pause
>
> Ensure the I/O hit the device and enforce an HDMA1:0 transition delay.
> Requires altstatus register exists, BUG if not so we don't risk
> corruption in MWDMA modes. (UDMA the checksum will save your backside in
> theory)
>
> The only other complication then is devices with their own handlers.
> rb532 can use dma_pause but scc needs to access its own altstatus
> register for internal errata workarounds so directly call the drivers own
> altstatus function.
>
>
> Signed-off-by: Alan Cox <alan@...hat.com>
>
> drivers/ata/libata-sff.c | 115 +++++++++++++++++++++++++++++++++++++------
> drivers/ata/pata_icside.c | 2 -
> drivers/ata/pata_rb532_cf.c | 4 +
> drivers/ata/pata_scc.c | 5 +-
> include/linux/libata.h | 16 +-----
> 5 files changed, 109 insertions(+), 33 deletions(-)
ACK
If no further comments, I'm OK with this version...
--
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/
Powered by blists - more mailing lists