From: Mark Lord <liml@rtr.ca>
To: Tejun Heo <htejun@gmail.com>
Cc: Jeff Garzik <jeff@garzik.org>,
jb.faq@gmx.de,
IDE/ATA development list <linux-ide@vger.kernel.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH #upstream-fixes] libata: assume no device is attached if both IDENTIFYs are aborted
Date: Wed, 26 Mar 2008 10:48:16 -0400 [thread overview]
Message-ID: <47EA6230.1090301@rtr.ca> (raw)
In-Reply-To: <47EA6128.9000006@gmail.com>
Tejun Heo wrote:
> Mark Lord wrote:
>> Tejun Heo wrote:
>> ..
>>> Modify EH such that it assumes no device is attached if both flavors
>>> of IDENTIFY are aborted by the device. There really isn't much point
>>> in retrying when the device actively aborts the commands.
>> ..
>>
>> And thus dies support for the few very early IDE drives that lacked
>> IDENTIFY.
>>
>> R.I.P. :)
>>
>> (not that they would have worked with libata in the first place)
>
> How did they work anyway? By specifying geometry manually to the
> driver? I think we can do that. We just need another cute HORKAGE.
> ATA_HORKAGE_NO_IDENITFY and some massaging around EH to handle it.
> Heh... That's gonna be a silly but fun project. :-)
..
Geometry from CMOS, BIOS, partition table, or kernel command line.
But I haven't owned one for perhaps 15 years or more,
and they really are NOT WORTH IT in libata -- all of those
nice little ata_id_* macros would be affected.
If one did want to do it, I think the best approach would be to
generate a fake drive ID block, and populate it with suitably
pre-ATA1 era default values. Then the rest of libata would not
require modifications.
Cheers
next prev parent reply other threads:[~2008-03-26 14:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-23 6:16 [PATCH #upstream-fixes] libata: assume no device is attached if both IDENTIFYs are aborted Tejun Heo
2008-03-23 12:46 ` Alan Cox
2008-03-25 2:26 ` Jeff Garzik
2008-03-26 14:05 ` Mark Lord
2008-03-26 14:43 ` Tejun Heo
2008-03-26 14:48 ` Mark Lord [this message]
2008-03-26 15:44 ` Alan Cox
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=47EA6230.1090301@rtr.ca \
--to=liml@rtr.ca \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=htejun@gmail.com \
--cc=jb.faq@gmx.de \
--cc=jeff@garzik.org \
--cc=linux-ide@vger.kernel.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.