All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Slaby <jirislaby@gmail.com>
To: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-pci@vger.kernel.org, linux-ide@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	"David S. Miller" <davem@davemloft.net>,
	Thomas Renninger <trenn@suse.de>
Subject: Re: [PATCH 1/1] PCI: tune up ICH4 quirk for broken BIOSes
Date: Fri, 11 Feb 2011 11:32:34 +0100	[thread overview]
Message-ID: <4D551042.10003@gmail.com> (raw)
In-Reply-To: <20110208132055.1c55ff93@jbarnes-desktop>

On 02/08/2011 10:20 PM, Jesse Barnes wrote:
> On Tue, 08 Feb 2011 10:55:01 +0100
> Jiri Slaby <jirislaby@gmail.com> wrote:
> 
>> On 01/14/2011 05:10 PM, Bjorn Helgaas wrote:
>>> On Friday, January 14, 2011 03:31:16 am Jiri Slaby wrote:
>>>> On 01/14/2011 01:15 AM, Linus Torvalds wrote:
>>>>> On Thu, Jan 13, 2011 at 3:19 PM, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
>>>>>>
>>>>>> I think we're back to the question of why we have the ICH4 quirk in
>>>>>> the first place, and I don't know the answer to that.
>>>>>
>>>>> Iirc, there were several laptops that didn't have the ACPI region
>>>>> mentioned in any of the regular places, and we'd allocate the PCMCIA
>>>>> IO region on top of them. The machine would boot, but if anybody ever
>>>>> inserted a PCCard into the machine, the first access to the IO region
>>>>> would generally just halt it (because it was trying to read the
>>>>> PCCard, but the APCI region decodes first, and then the read from that
>>>>> usually put the CPU in a sleep state that it would never wake up from
>>>>> for obvious reasons).
>>>>>
>>>>> So we do want the ICH4 quirk.
>>>>
>>>> Yes, this is an "official" way how ICH4 (and later) advertises the region.
>>>
>>> The quirk is a bug workaround, *not* the "official, planned" way to
>>> deal with these regions.  The official way is to use ACPI, because
>>> that's a generic way that doesn't require changes for new versions
>>> of ICH.
>>
>> Ok, I understand that. For non-ACPI setups this is probably the only
>> place to look at.
>>
>> Anyway, has anybody had a chance to look at the patches? Any comments,
>> nacks/acks?
>>
>> https://lkml.org/lkml/2011/1/14/115
>> https://lkml.org/lkml/2011/1/14/113
>> https://lkml.org/lkml/2011/1/14/114
> 
> I don't have a problem making the quirk quirkier, but it would be nice
> to get rid of the need for it entirely (though we can leave that to
> Bjorn :). Can you re-submit these three against my linux-next branch?

Ok, I can. But do you want solution 113 or 114 -- they solve the same,
but in a different manner?

thanks,
-- 
js

      reply	other threads:[~2011-02-11 10:32 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-06 15:17 [PATCH 1/1] PCI: tune up ICH4 quirk for broken BIOSes Jiri Slaby
2011-01-06 19:24 ` Bjorn Helgaas
2011-01-07 20:44   ` Jiri Slaby
2011-01-07 22:37     ` Jesse Barnes
2011-01-07 23:13       ` Jiri Slaby
2011-01-07 23:03     ` Bjorn Helgaas
2011-01-07 23:29       ` Jiri Slaby
2011-01-08  0:16         ` Bjorn Helgaas
2011-01-08  9:58           ` Jiri Slaby
2011-01-10 18:40             ` Bjorn Helgaas
2011-01-13 10:07               ` Jiri Slaby
2011-01-13 10:07                 ` Jiri Slaby
2011-01-13 23:19                 ` Bjorn Helgaas
2011-01-14  0:15                   ` Linus Torvalds
2011-01-14 10:31                     ` Jiri Slaby
2011-01-14 10:32                       ` [PATCH 1/2] PCI: add more checking to ICH region quirks Jiri Slaby
2011-01-14 10:32                       ` [PATCH option B 2/2] PCI: do not create quirk I/O regions below PCIBIOS_MIN_IO for ICH Jiri Slaby
2011-02-11 12:09                         ` Sergei Shtylyov
2011-02-11 14:16                           ` Jiri Slaby
2011-01-14 10:32                       ` [PATCH option A 2/2] PCI: do not create quirk I/O regions below PCIBIOS_MIN_IO Jiri Slaby
2011-01-14 16:10                       ` [PATCH 1/1] PCI: tune up ICH4 quirk for broken BIOSes Bjorn Helgaas
2011-01-15 15:39                         ` Robert Hancock
2011-02-08  9:55                         ` Jiri Slaby
2011-02-08 21:20                           ` Jesse Barnes
2011-02-11 10:32                             ` Jiri Slaby [this message]

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=4D551042.10003@gmail.com \
    --to=jirislaby@gmail.com \
    --cc=bjorn.helgaas@hp.com \
    --cc=davem@davemloft.net \
    --cc=jbarnes@virtuousgeek.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=trenn@suse.de \
    /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.