All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org, jeff@garzik.org
Subject: Re: RESEND: [PATCH] libata-sff: Fix oops reported in kerneloops.org for pnp devices with no ctl
Date: Thu, 29 May 2008 19:02:35 +0100	[thread overview]
Message-ID: <20080529190235.258d304e@core> (raw)
In-Reply-To: <alpine.LFD.1.10.0805290950230.2958@woody.linux-foundation.org>

> Why the *hell* doesn't it just fix "ata_sff_altstatus()" instead? Why does 
> it introduce a ludicrously named stupid "maybe" version of it that doesn't 
> oops?

Ok the problem is we have three cases to distinguish

- altstatus must be used - in which case we want to blow up anyway if we
touch it (the usual case)
- altstatus should be used if available - shared IRQ check
- altstatus being used for flushing - altstatus irrelevant, it just has
to flush somehow.

So the _maybe naming sucks, but the reasoning I think is sound. The other
way to do it would be to replace it and the bit of irq handler logic with
an ata_sff_busy() that did the status checks correctly for both ctl and
non-ctl capable devices.

> It may be that you meant to make it an "else if" case, ie if there was no 
> IO-read, then you do a ndelay(400) as a last desperate case, but that's 
> not how your ata_sdd_sync() is actually written.

The ndelay(400) is correct. The IO-read is Jeff being paranoid and
actually hurts us materially for the usual PIO case (bus PIO not disk
PIO) to the tune of about 1mS a command in many cases, but is needed for
MMIO (which we almost never do for any SFF hardware). That itself is a
different problem that can be fixed later (and not in -rc5). It wants
fixing as its a key reason that old IDE is still faster for PATA.

maybe_altstatus is crap naming but simply making ata_sff_altstatus fake a
reply in arbitary cases risks not catching mistakes and could mean we
don't catch corrupting mistakes which would be very bad indeed.


  parent reply	other threads:[~2008-05-29 18:17 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-29 16:25 RESEND: [PATCH] libata-sff: Fix oops reported in kerneloops.org for pnp devices with no ctl Alan Cox
2008-05-29 17:04 ` Linus Torvalds
2008-05-29 17:46   ` Jeff Garzik
2008-05-29 18:04     ` Linus Torvalds
2008-05-29 18:13       ` Jeff Garzik
2008-05-29 18:29       ` Alan Cox
2008-05-29 18:19     ` Alan Cox
2008-05-29 21:13       ` Linus Torvalds
2008-05-29 21:19         ` Alan Cox
2008-05-29 18:02   ` Alan Cox [this message]
2008-05-29 18:25     ` Jeff Garzik
2008-05-29 18:38       ` Alan Cox
2008-05-29 19:46         ` Linus Torvalds
2008-05-29 20:18           ` Alan Cox
2008-05-29 18:42       ` Alan Cox
2008-05-29 19:31         ` Jeff Garzik
2008-05-29 21:10           ` [RFC PATCH] " Alan Cox
2008-05-29 21:37             ` Alan Cox
2008-05-29 21:57               ` Jeff Garzik
2008-05-29 21:57                 ` Alan Cox
2008-05-30 22:14             ` Jeff Garzik
2008-06-04 10:45             ` Jeff Garzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080529190235.258d304e@core \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=jeff@garzik.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.