From: Gleb Natapov <gleb@redhat.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Hannes Reinecke <hare@suse.de>,
LKML <linux-kernel@vger.kernel.org>,
"H. Peter Anvin" <hpa@linux.intel.com>
Subject: Re: [PATCH] EDD: Check for correct EDD 3.0 length
Date: Tue, 15 May 2012 18:00:05 +0300 [thread overview]
Message-ID: <20120515150005.GG6948@redhat.com> (raw)
In-Reply-To: <20120515155450.13040d1f@pyramind.ukuu.org.uk>
On Tue, May 15, 2012 at 03:54:50PM +0100, Alan Cox wrote:
> > > Sample case of .. 1
> > >
> > Not one. Any system with SCSI disk. Revert the patch and check on yours.
>
> I don't have a SCSI disk. In fact most users don't have a SCSI disk 8)
>
Most of them have SATA which is not even defined by Phoenix spec 8)
> > > Actual systems in the field are using both 3.0 and 4.0 so we need to deal
> > > with that as part of fixing this. That is the reality of the situation.
> > Again let me correct myself. This is not about 3.0 versus 4.0. This is
> > about Phoenix vs T13 spec. The code was written to support only T13.
>
> Well actually the code was written to mishandle both in different ways.
This is simply not true. The code defines device path structure
according to T13 spec and clearly states in the header which spec it was
written to support. May be this is not clear from the thread but the code
still provides every other information except device path from Phoenix
EDD. You can still see pci device from /sys/firmware/edd/int13_80.
> You propose to change it to handle one correctly and completely fail on
> the other. That isn't what needs to happen.
>
Not completely fail, only suppress information the code does not know
how to parse!
--
Gleb.
next prev parent reply other threads:[~2012-05-15 15:00 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-15 11:04 [PATCH] EDD: Check for correct EDD 3.0 length Hannes Reinecke
2012-05-15 11:12 ` Gleb Natapov
2012-05-15 11:20 ` Hannes Reinecke
2012-05-15 11:59 ` Gleb Natapov
2012-05-15 12:53 ` Gleb Natapov
2012-05-15 13:49 ` Alan Cox
2012-05-15 14:12 ` Gleb Natapov
2012-05-15 14:18 ` Alan Cox
2012-05-15 14:21 ` Gleb Natapov
2012-05-15 14:36 ` Alan Cox
2012-05-15 14:48 ` Gleb Natapov
2012-05-15 14:54 ` Alan Cox
2012-05-15 15:00 ` Gleb Natapov [this message]
2012-05-15 14:00 ` Alan Cox
2012-05-15 14:36 ` Gleb Natapov
2012-05-15 14:52 ` Alan Cox
2012-05-15 14:53 ` Gleb Natapov
2012-05-15 15:22 ` Alan Cox
2012-05-15 15:29 ` Gleb Natapov
2012-05-15 15:41 ` Alan Cox
2012-05-15 15:53 ` Gleb Natapov
2012-05-15 15:14 ` Alan Cox
2012-05-15 15:31 ` Alan Cox
2012-05-15 15:46 ` Gleb Natapov
2012-05-15 17:17 ` H. Peter Anvin
-- strict thread matches above, loose matches on Subject: below --
2012-05-16 6:51 Hannes Reinecke
2012-05-16 8:28 ` Gleb Natapov
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=20120515150005.GG6948@redhat.com \
--to=gleb@redhat.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=hare@suse.de \
--cc=hpa@linux.intel.com \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox