mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
To: Mark Lord <lkml@rtr.ca>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Theodore Ts'o" <tytso@mit.edu>,
	greg@kroah.com, pcihpd-discuss@lists.sourceforge.net
Subject: Re: [PATCH 0/3] Fix two PEIe hotplug issues
Date: Thu, 18 Oct 2007 09:13:47 -0700	[thread overview]
Message-ID: <20071018091347.4b94faf8.kristen.c.accardi@intel.com> (raw)
In-Reply-To: <4716CE79.7040201@rtr.ca>

On Wed, 17 Oct 2007 23:09:45 -0400
Mark Lord <lkml@rtr.ca> wrote:

> Mark Lord wrote:
> > Fix PCIe Hotplug so that it works with ExpressCard slots on Dell notebooks
> > (and others?) in conjunction with the modparam of pciehp_force=1.
> 
> 
> To make things simpler for distro people, I'm contemplating another patch
> in this series, to allow something like:  pciehp_force=2
> 
> This would then *try* the ACPI BIOS calls, and only fall back to pcie_force=1
> if the BIOS support fails.  This would be an ideal default for most desktop/notebook
> distros to consider using.
> 
> Without this, they don't have any good choice:  use the defaults, and things fail
> on the most popular brand of machines in the marketplace.  Use pciehp_force=1,
> and they may break (?) on other brands.
> 
> So a hybrid of the two seems best.  Pity it couldn't be the default behaviour, though.
> Or could it?  We're early enough in the 2.6.24 cycle for it..
> 
> Opinions?
> 

NAK!  Absolutely no way will I take a patch that does this.  
I've been actually having philosophical issues with
even having pciehp_force as a module parameter at all.  As I said before,
using pciehp_force violates the PCI spec.  Vendors often deliberately 
do not support OSC due to hardware errata.  Users who use this option risk
breaking their laptop.  I was thinking actually that we should make it
more difficult to use this option, like make it a compile time option,
or perhaps rename it to this_could_seriously_break_your_hardware_dont_use.

Probably we shouldn't have the functionality in the driver at all, but
I don't really want to take it out all together, because it's handy for those
of us who work on early hardware, where we can ask the BIOS people why
they didn't implement OSC, and then consciously force it knowing exactly
what we are doing and the potential consequences.  But, maybe we should
consider the possibility that we should remove the code so as to really
really prevent distros from using this option.


  reply	other threads:[~2007-10-18 16:27 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-18  2:57 Mark Lord
2007-10-18  2:59 ` [PATCH 1/3] pciehp_handle_preinserted_card Mark Lord
2007-10-18  3:00 ` [PATCH 2/3] pciehp_split_pcie_init Mark Lord
2007-10-18  3:02 ` [PATCH 3/3] pciehp_resume_reinit_hardware Mark Lord
2007-10-18  3:03 ` [PATCH 1/3] pciehp_handle_preinserted_card Mark Lord
2007-10-18  3:04 ` [PATCH 2/3] pciehp_split_pcie_init Mark Lord
2007-10-18  3:05 ` [PATCH 0/3] Fix two PEIe hotplug issues Mark Lord
2007-10-18  3:09 ` Mark Lord
2007-10-18 16:13   ` Kristen Carlson Accardi [this message]
2007-10-18 17:06     ` Mark Lord
2007-10-18 17:06       ` Kristen Carlson Accardi
2007-10-18 17:49         ` Theodore Tso
2007-10-18 17:56           ` Kristen Carlson Accardi
2007-10-18 21:11             ` Mark Lord
2007-10-18 21:26           ` Mark Lord
2007-10-18  3:32 ` [PATCH 1/3] pciehp: hotplug: deal with pre-inserted ExpressCards Mark Lord
2007-10-18  3:33   ` [PATCH 2/3] pciehp: hotplug: split out hardware init from pcie_init() Mark Lord
2007-10-18  3:34     ` [PATCH 3/3] pciehp: hotplug: reinit hotplug h/w on resume from suspend Mark Lord
2007-10-18 11:15   ` [Pcihpd-discuss] [PATCH 1/3] pciehp: hotplug: deal with pre-inserted ExpressCards Kenji Kaneshige
2007-10-18 13:31     ` Mark Lord
2007-10-19  2:38       ` Kenji Kaneshige
2007-10-19  3:09         ` Mark Lord
2007-10-19  3:27           ` Kenji Kaneshige
2007-11-18  0:27 ` [PATCH] Fix PCIe double initialization bug Mark Lord
2007-11-18 12:23   ` Rafael J. Wysocki
2007-11-18 14:20     ` Mark Lord
2007-11-18 14:37       ` Mark Lord

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=20071018091347.4b94faf8.kristen.c.accardi@intel.com \
    --to=kristen.c.accardi@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@rtr.ca \
    --cc=pcihpd-discuss@lists.sourceforge.net \
    --cc=tytso@mit.edu \
    /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

all inboxes | Powered by JetHome®