From: Rene Herman <rene.herman@keyaccess.nl>
To: Ingo Molnar <mingo@elte.hu>, Wolfram Sang <w.sang@pengutronix.de>
Cc: "Linus Torvalds" <torvalds@linux-foundation.org>,
"Suresh Siddha" <suresh.b.siddha@intel.com>,
"Wim Van Sebroeck" <wim@iguana.be>,
"Pádraig Brady" <P@draigBrady.com>,
"Andi Kleen" <andi@firstfloor.org>,
"H. Peter Anvin" <hpa@zytor.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"arjan@linux.intel.com" <arjan@linux.intel.com>,
"roland@redhat.com" <roland@redhat.com>,
"drepper@redhat.com" <drepper@redhat.com>,
"mikpe@it.uu.se" <mikpe@it.uu.se>,
"chrisw@sous-sol.org" <chrisw@sous-sol.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [patch 0/9] x86, xsave: xsave/xrstor support
Date: Fri, 01 Aug 2008 16:27:53 +0200 [thread overview]
Message-ID: <48931D69.2010309@keyaccess.nl> (raw)
In-Reply-To: <20080801095105.GA18055@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 2756 bytes --]
On 01-08-08 11:51, Ingo Molnar wrote:
> find attached below a newer version of the original list i published
> half a year ago:
>
> http://people.redhat.com/mingo/auto-qa-patches/Kconfig-qa.patch
>
> these are just pragmatic local hacks to get things going. (There are
> more per machine quirks as well.)
>
> i have not used a BROKEN annotation because CONFIG_BROKEN is
> impractical: it just kills code altogether, indiscriminately. There's no
> way for users to enable CONFIG_BROKEN in the upstream kernel - nothing
> selects it and it's not an interactive option either.
>
> So by all means if we mark a driver or a kernel feature as
> CONFIG_BROKEN, it's killed altogether for all practical purposes.
>
> What we'd need is some more gradual approach: for example a way to mark
> "drivers that are not expected to boot on a whitebox PC", without
> removing them altogether via a CONFIG_BROKEN dependency - often it's
> hardware that cannot be probed safely.
For real ISA at the least, the best fix I feel is just not go grabbing
resources without anything (ie, ISAPnP) or anyone (ie, the user) telling
us that's where the hardware's at.
For example, for the first real ISA driver in the list:
> Index: linux/drivers/i2c/busses/Kconfig
> ===================================================================
> --- linux.orig/drivers/i2c/busses/Kconfig
> +++ linux/drivers/i2c/busses/Kconfig
> @@ -610,6 +610,11 @@ config I2C_ELEKTOR
> config I2C_PCA_ISA
> tristate "PCA9564 on an ISA bus"
> depends on ISA
> +
> + # takes away IRQ10 on venus and thus breaks e1000
> + depends on BROKEN_BOOT_ALLOWED
> + select BROKEN_BOOT
> +
The attached would be my preffered approach to this.
(to avoid an IRQ 0 discussion -- the middle hunk is unrelated, just
makes it consistent with the rest of the file)
(and this uses the isa_bus match() method as intended; the idea of the
isa_bus is to make it look at least somewhat like a sane bus such as PCI
which includes only failing a load if there's no way a later bind could
conceivably succeed. somewhat debatable merit sometimes, but such is the
device model, and it's actually fairly nice once you get used to it for
quickly switching drivers for a single piece of hardware)
A user of this hardware is a one-time
$ echo options i2c-pca-isa base=0x330 irq=10 >> /etc/modprobe.conf
away from the old behaviour. Given the hackish nature of all this kind
of hardware these days its users tend to not mind. In fact, what with
getting old hardware to play nice with modern systems, I myself at least
very much welcome having to be explicit about these things.
(and just saw the CC list on this thing while adding Wolfram. ouch. will
be dropping all from any followups...)
Rene.
[-- Attachment #2: 0001-i2c-don-t-autograb-i2c-pca-isa.patch --]
[-- Type: text/plain, Size: 1974 bytes --]
>From 58f25a608b827426bf5c110795dd7e917e9cc568 Mon Sep 17 00:00:00 2001
From: Rene Herman <rene.herman@gmail.com>
Date: Fri, 1 Aug 2008 15:35:31 +0200
Subject: [PATCH] i2c: don't autograb i2c-pca-isa
Grabbing resources without anything telling us we should can break
randconfig builds by keeping them busy. Insist that when hardware
is not capable of telling us, the user does.
Signed-off-by: Rene Herman <rene.herman@gmail.com>
---
drivers/i2c/busses/i2c-pca-isa.c | 20 +++++++++++++++++---
1 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pca-isa.c b/drivers/i2c/busses/i2c-pca-isa.c
index a119784..2579169 100644
--- a/drivers/i2c/busses/i2c-pca-isa.c
+++ b/drivers/i2c/busses/i2c-pca-isa.c
@@ -36,8 +36,8 @@
#define DRIVER "i2c-pca-isa"
#define IO_SIZE 4
-static unsigned long base = 0x330;
-static int irq = 10;
+static unsigned long base;
+static int irq = -1;
/* Data sheet recommends 59kHz for 100kHz operation due to variation
* in the actual clock rate */
@@ -107,6 +107,19 @@ static struct i2c_adapter pca_isa_ops = {
.timeout = 100,
};
+static int __devinit pca_isa_match(struct device *dev, unsigned int id)
+{
+ int match = base != 0;
+
+ if (match) {
+ if (irq == -1)
+ dev_warn(dev, "using poling mode (specify irq)\n");
+ } else
+ dev_err(dev, "please specify base\n");
+
+ return match;
+}
+
static int __devinit pca_isa_probe(struct device *dev, unsigned int id)
{
init_waitqueue_head(&pca_wait);
@@ -153,7 +166,7 @@ static int __devexit pca_isa_remove(struct device *dev, unsigned int id)
{
i2c_del_adapter(&pca_isa_ops);
- if (irq > 0) {
+ if (irq > -1) {
disable_irq(irq);
free_irq(irq, &pca_isa_ops);
}
@@ -163,6 +176,7 @@ static int __devexit pca_isa_remove(struct device *dev, unsigned int id)
}
static struct isa_driver pca_isa_driver = {
+ .match = pca_isa_match,
.probe = pca_isa_probe,
.remove = __devexit_p(pca_isa_remove),
.driver = {
--
1.5.5
next prev parent reply other threads:[~2008-08-01 14:26 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-29 17:29 [patch 0/9] x86, xsave: xsave/xrstor support Suresh Siddha
2008-07-29 17:29 ` [patch 1/9] x86, xsave: xsave cpuid feature bits Suresh Siddha
2008-07-29 17:29 ` [patch 2/9] x86, xsave: enable xsave/xrstor on cpus with xsave support Suresh Siddha
2008-07-29 17:29 ` [patch 3/9] x86, xsave: context switch support using xsave/xrstor Suresh Siddha
2008-07-29 17:29 ` [patch 4/9] x86, xsave: dynamically allocate sigframes fpstate instead of static allocation Suresh Siddha
2008-07-29 17:29 ` [patch 5/9] x86, xsave: reorganization of signal save/restore fpstate code layout Suresh Siddha
2008-07-29 17:29 ` [patch 6/9] x86, xsave: xsave/xrstor specific routines Suresh Siddha
2008-07-29 17:29 ` [patch 7/9] x86, xsave: struct _fpstate extensions to include extended state information Suresh Siddha
2008-07-29 17:29 ` [patch 8/9] x86, xsave: save/restore the extended state context in sigframe Suresh Siddha
2008-07-29 17:29 ` [patch 9/9] x86, xsave: update xsave header bits during ptrace fpregs set Suresh Siddha
2008-07-29 23:09 ` [patch 0/9] x86, xsave: xsave/xrstor support H. Peter Anvin
2008-07-29 23:29 ` Suresh Siddha
2008-07-29 23:43 ` H. Peter Anvin
2008-07-30 10:03 ` Ingo Molnar
2008-07-30 16:31 ` H. Peter Anvin
2008-07-30 17:08 ` Suresh Siddha
2008-07-30 17:14 ` H. Peter Anvin
2008-07-30 18:25 ` Ingo Molnar
2008-07-30 21:46 ` Suresh Siddha
2008-07-30 23:41 ` Suresh Siddha
2008-07-31 21:29 ` Ingo Molnar
2008-07-31 21:58 ` Suresh Siddha
2008-07-31 22:14 ` Andi Kleen
2008-07-31 22:19 ` Suresh Siddha
2008-07-31 22:36 ` Andi Kleen
2008-07-31 22:38 ` Linus Torvalds
2008-07-31 22:50 ` Ingo Molnar
2008-08-01 2:06 ` Rene Herman
2008-08-01 9:51 ` Ingo Molnar
2008-08-01 14:27 ` Rene Herman [this message]
2008-08-01 14:49 ` Andi Kleen
2008-08-01 15:19 ` Rene Herman
2008-08-01 15:44 ` Andi Kleen
2008-08-01 16:03 ` Rene Herman
2008-07-31 22:48 ` Alan Cox
2008-07-31 22:17 ` Ingo Molnar
2008-08-13 11:00 ` Ingo Molnar
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=48931D69.2010309@keyaccess.nl \
--to=rene.herman@keyaccess.nl \
--cc=P@draigBrady.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=arjan@linux.intel.com \
--cc=chrisw@sous-sol.org \
--cc=drepper@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mikpe@it.uu.se \
--cc=mingo@elte.hu \
--cc=roland@redhat.com \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=w.sang@pengutronix.de \
--cc=wim@iguana.be \
/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