* linux-next: manual merge of the input tree with the s5p tree
From: Stephen Rothwell @ 2011-11-11 2:11 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-next, linux-kernel, Thomas Abraham, Kukjin Kim
[-- Attachment #1: Type: text/plain, Size: 2093 bytes --]
Hi Dmitry,
Today's linux-next merge of the input tree got a conflict in
drivers/input/keyboard/samsung-keypad.c between commit 532f74540134
("input: samsung-keypad: Add device tree support") from the s5p tree and
commit 400bf2995be6 ("Input: samsung-keypad - switch to using
SIMPLE_DEV_PM_OPS") from the input tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/input/keyboard/samsung-keypad.c
index 8a0060c,1a2b755..0000000
--- a/drivers/input/keyboard/samsung-keypad.c
+++ b/drivers/input/keyboard/samsung-keypad.c
@@@ -21,10 -21,8 +21,10 @@@
#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
#include <linux/sched.h>
- #include <plat/keypad.h>
+ #include <linux/input/samsung-keypad.h>
#define SAMSUNG_KEYIFCON 0x00
#define SAMSUNG_KEYIFSTSCLR 0x04
@@@ -578,24 -440,11 +578,22 @@@ static int samsung_keypad_resume(struc
return 0;
}
-
- static const struct dev_pm_ops samsung_keypad_pm_ops = {
- .suspend = samsung_keypad_suspend,
- .resume = samsung_keypad_resume,
- };
#endif
+#ifdef CONFIG_OF
+static const struct of_device_id samsung_keypad_dt_match[] = {
+ { .compatible = "samsung,s3c6410-keypad" },
+ { .compatible = "samsung,s5pv210-keypad" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, samsung_keypad_dt_match);
+#else
+#define samsung_keypad_dt_match NULL
+#endif
+
+ static SIMPLE_DEV_PM_OPS(samsung_keypad_pm_ops,
+ samsung_keypad_suspend, samsung_keypad_resume);
+
static struct platform_device_id samsung_keypad_driver_ids[] = {
{
.name = "samsung-keypad",
@@@ -614,10 -463,7 +612,8 @@@ static struct platform_driver samsung_k
.driver = {
.name = "samsung-keypad",
.owner = THIS_MODULE,
+ .of_match_table = samsung_keypad_dt_match,
- #ifdef CONFIG_PM
.pm = &samsung_keypad_pm_ops,
- #endif
},
.id_table = samsung_keypad_driver_ids,
};
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the input tree with the s5p tree
From: Stephen Rothwell @ 2011-11-11 2:11 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-next, linux-kernel, Thomas Abraham, Kukjin Kim
[-- Attachment #1: Type: text/plain, Size: 1521 bytes --]
Hi Dmitry,
Today's linux-next merge of the input tree got a conflict in
drivers/input/keyboard/Kconfig between commit 007205aa47e9 ("input:
samsung-keypad: Add HAVE_SAMSUNG_KEYPAD config option") from the s5p tree
and commit 5862c02d745f ("Input: samsung-keypad - enable compiling on
other platforms") from the input tree.
I have fixed it up (probably incorrectly - see below) and can carry the
fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/input/keyboard/Kconfig
index d80b4ea,cdc385b..0000000
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@@ -423,18 -439,12 +439,19 @@@ config KEYBOARD_PMIC8XX
To compile this driver as a module, choose M here: the module will
be called pmic8xxx-keypad.
+config HAVE_SAMSUNG_KEYPAD
+ bool
+ help
+ This will include Samsung Keypad controller driver support. If you
+ want to include Samsung Keypad support for any machine, kindly
+ select this in the respective mach-xxxx/Kconfig file.
+
config KEYBOARD_SAMSUNG
tristate "Samsung keypad support"
- depends on SAMSUNG_DEV_KEYPAD || HAVE_SAMSUNG_KEYPAD
- depends on HAVE_CLK
++ depends on HAVE_CLK || HAVE_SAMSUNG_KEYPAD
help
- Say Y here if you want to use the Samsung keypad.
+ Say Y here if you want to use the keypad on your Samsung mobile
+ device.
To compile this driver as a module, choose M here: the
module will be called samsung-keypad.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the slave-dma tree with the s5p tree
From: Stephen Rothwell @ 2011-11-11 1:00 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-next, linux-kernel, Boojin Kim, Thomas Abraham, Kukjin Kim
[-- Attachment #1: Type: text/plain, Size: 1086 bytes --]
Hi Vinod,
Today's linux-next merge of the slave-dma tree got a conflict in
drivers/dma/pl330.c between commit c6e00b47067b ("DMA: PL330: Add device
tree support") from the s5p tree and commit dab6538e29e6 ("DMA: PL330:
Fix build warning") from the slave-dma tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/dma/pl330.c
index a626e15,186b822..0000000
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@@ -870,8 -856,8 +870,8 @@@ pl330_probe(struct amba_device *adev, c
INIT_LIST_HEAD(&pd->channels);
/* Initialize channel parameters */
- num_chan = max(pdat ? pdat->nr_valid_peri : (u8)pi->pcfg.num_peri,
- (u8)pi->pcfg.num_chan);
- num_chan = max(pdat ? (int)pdat->nr_valid_peri : 0,
- (int)pi->pcfg.num_chan);
++ num_chan = max(pdat ? (int)pdat->nr_valid_peri : (int)pi->pcfg.num_peri,
++ (int)pi->pcfg.num_chan);
pdmac->peripherals = kzalloc(num_chan * sizeof(*pch), GFP_KERNEL);
for (i = 0; i < num_chan; i++) {
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the crypto-current tree
From: Herbert Xu @ 2011-11-10 22:50 UTC (permalink / raw)
To: Ingo Molnar
Cc: Luis Henriques, Steffen Klassert, Stephen Rothwell, linux-next,
linux-kernel
In-Reply-To: <20111110155019.GA7068@elte.hu>
On Thu, Nov 10, 2011 at 04:50:19PM +0100, Ingo Molnar wrote:
>
> v3.2-rc1 has been released with this (commonly triggering) build bug
> included. Herbert, is the fix on the way to upstream?
Oops, I thought I had committed it already. Let me push it now.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: linux-next: Tree for Nov 1 (ata/libata-sff.c)
From: Jeff Garzik @ 2011-11-10 21:26 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, linux-next, LKML, Linus,
linux-ide@vger.kernel.org
In-Reply-To: <4EB0854D.5090002@xenotime.net>
On 11/01/2011 07:48 PM, Randy Dunlap wrote:
> On 11/01/2011 02:53 AM, Stephen Rothwell wrote:
>> Hi all,
>
>
> When ATA_SFF is enabled but ATA_BMDMA is not enabled:
>
>
> drivers/ata/libata-sff.c: In function 'ata_pci_init_one':
> drivers/ata/libata-sff.c:2538:3: error: implicit declaration of function 'ata_pci_bmdma_prepare_host'
> drivers/ata/libata-sff.c:2549:40: error: 'ata_bmdma_interrupt' undeclared (first use in this function)
Absjoern's patch seen, thanks.
^ permalink raw reply
* [PATCH] kernel/cpu.c: Add right qualifiers for intel_thermal_interrupt() and cpu_hotplug_pm_sync_init()
From: Fenghua Yu @ 2011-11-10 20:22 UTC (permalink / raw)
To: Linus Torvalds, Ingo Molnar, Rusty Russell, Rafael J. Wysocki,
"Srivatsa S. Bhat" <sriva>
Cc: linux-kernel, linux-pm, linux-next, Fenghua Yu
From: Fenghua Yu <fenghua.yu@intel.com>
Add __init for functions alloc_frozen_cpus() and cpu_hotplug_pm_sync_init()
because they are only called during boot time.
Add static for function cpu_hotplug_pm_sync_init() because its scope is limited
in this file only.
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
---
kernel/cpu.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 563f136..cf915b8 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -470,7 +470,7 @@ out:
cpu_maps_update_done();
}
-static int alloc_frozen_cpus(void)
+static int __init alloc_frozen_cpus(void)
{
if (!alloc_cpumask_var(&frozen_cpus, GFP_KERNEL|__GFP_ZERO))
return -ENOMEM;
@@ -543,7 +543,7 @@ cpu_hotplug_pm_callback(struct notifier_block *nb,
}
-int cpu_hotplug_pm_sync_init(void)
+static int __init cpu_hotplug_pm_sync_init(void)
{
pm_notifier(cpu_hotplug_pm_callback, 0);
return 0;
--
1.6.0.3
^ permalink raw reply related
* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
From: Jeff Garzik @ 2011-11-10 20:34 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Alan Cox, Ingo Molnar, Jeff Garzik, Grant Likely, Randy Dunlap,
Stephen Rothwell, linux-next, LKML, linux-ide, Linus Torvalds,
Andrew Morton, devicetree-discuss
In-Reply-To: <20111110162859.GA7088@oksana.dev.rtsoft.ru>
On 11/10/2011 11:28 AM, Anton Vorontsov wrote:
> Drivers should not use NO_IRQ; moreover, some architectures don't
> have it nowadays. '0' is the 'no irq' case.
>
> Signed-off-by: Anton Vorontsov<cbouatmailru@gmail.com>
> Acked-by: Alan Cox<alan@linux.intel.com>
> ---
>
> On Thu, Nov 10, 2011 at 03:38:16PM +0000, Alan Cox wrote:
>> On Thu, 10 Nov 2011 19:26:06 +0400
>> Anton Vorontsov<cbouatmailru@gmail.com> wrote:
>>
>>> Drivers should not use NO_IRQ; moreover, some architectures don't
>>> have it nowadays. '0' is the 'no irq' case.
>>>
>>> Signed-off-by: Anton Vorontsov<cbouatmailru@gmail.com>
>>
>> Acked-by: Alan Cox<alan@linux.intel.com>
>
> In case if we don't want a "band-aid fix" for 3.2, here is the patch
> that just does the proper fix (w/ a risk to break minor architectures).
>
> drivers/ata/pata_of_platform.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
> index a72ab0d..2a472c5 100644
> --- a/drivers/ata/pata_of_platform.c
> +++ b/drivers/ata/pata_of_platform.c
> @@ -52,7 +52,7 @@ static int __devinit pata_of_platform_probe(struct platform_device *ofdev)
> }
>
> ret = of_irq_to_resource(dn, 0,&irq_res);
> - if (ret == NO_IRQ)
> + if (!ret)
> irq_res.start = irq_res.end = 0;
> else
> irq_res.flags = 0;
Unless someone screams, that is what I'll push upstream.
Jeff
^ permalink raw reply
* Re: linux-next: Tree for Oct 11 (ata/pata_of_platform.c)
From: Jeff Garzik @ 2011-11-10 18:18 UTC (permalink / raw)
To: Ingo Molnar
Cc: Randy Dunlap, Stephen Rothwell, linux-next, LKML,
linux-ide@vger.kernel.org, Anton Vorontsov, Linus Torvalds,
Andrew Morton
In-Reply-To: <20111110135703.GA23609@elte.hu>
On 11/10/2011 08:57 AM, Ingo Molnar wrote:
>
> * Randy Dunlap<rdunlap@xenotime.net> wrote:
>
>> On 10/11/2011 01:37 PM, Randy Dunlap wrote:
>>> On 10/11/11 02:11, Stephen Rothwell wrote:
>>>> Hi all,
>>>>
>>>> The linux-next tree is now available from
>>>> git://github.com/sfrothwell/linux-next.git as a temporary measure while
>>>> the kernel.org servers are unavailable.
>>>>
>>>> It may also turn up on git.kernel.org (depending on the mirroring). The
>>>> patch set is still absent, however.
>>>>
>>>> Changes since 20111007:
>>>>
>>>> Removed tree: ide (at the maintainer's request)
>>>
>>>
>>> drivers/ata/pata_of_platform.c:55:13: error: 'NO_IRQ' undeclared (first use in this function)
>>
>>
>> [adding Author: Anton]
>>
>> Build error still present in linux-next of 20111014.
>
> This build failure regression report was ignored twice and then
> pushed upstream and is still unfixed a month after the initial
> report. Upstream now fails to build on like 25% of x86 configs.
>
> What's going on with this bug guys?
Hum, I missed it in my LKML scans, and never got a CC.
Will merge Anton's patch immediately...
Jeff
^ permalink raw reply
* [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
From: Anton Vorontsov @ 2011-11-10 16:28 UTC (permalink / raw)
To: Alan Cox
Cc: Ingo Molnar, Jeff Garzik, Grant Likely, Randy Dunlap,
Stephen Rothwell, linux-next, LKML, linux-ide, Linus Torvalds,
Andrew Morton, devicetree-discuss
In-Reply-To: <20111110153816.239af1d7@lxorguk.ukuu.org.uk>
Drivers should not use NO_IRQ; moreover, some architectures don't
have it nowadays. '0' is the 'no irq' case.
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
Acked-by: Alan Cox <alan@linux.intel.com>
---
On Thu, Nov 10, 2011 at 03:38:16PM +0000, Alan Cox wrote:
> On Thu, 10 Nov 2011 19:26:06 +0400
> Anton Vorontsov <cbouatmailru@gmail.com> wrote:
>
> > Drivers should not use NO_IRQ; moreover, some architectures don't
> > have it nowadays. '0' is the 'no irq' case.
> >
> > Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
>
> Acked-by: Alan Cox <alan@linux.intel.com>
In case if we don't want a "band-aid fix" for 3.2, here is the patch
that just does the proper fix (w/ a risk to break minor architectures).
drivers/ata/pata_of_platform.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
index a72ab0d..2a472c5 100644
--- a/drivers/ata/pata_of_platform.c
+++ b/drivers/ata/pata_of_platform.c
@@ -52,7 +52,7 @@ static int __devinit pata_of_platform_probe(struct platform_device *ofdev)
}
ret = of_irq_to_resource(dn, 0, &irq_res);
- if (ret == NO_IRQ)
+ if (!ret)
irq_res.start = irq_res.end = 0;
else
irq_res.flags = 0;
--
1.7.5.3
^ permalink raw reply related
* Re: linux-next: build failure after merge of the crypto-current tree
From: Ingo Molnar @ 2011-11-10 15:50 UTC (permalink / raw)
To: Luis Henriques
Cc: Herbert Xu, Steffen Klassert, Stephen Rothwell, linux-next,
linux-kernel
In-Reply-To: <20111103115933.GA12708@onza.mythic-beasts.com>
* Luis Henriques <henrix@camandro.org> wrote:
> On Thu, Nov 03, 2011 at 10:42:14PM +1100, Herbert Xu wrote:
> > On Thu, Nov 03, 2011 at 10:15:54AM +0000, Luis Henriques wrote:
> > >
> > > No, this did not solved the problem; build still fails. The problem is
> > > that, in lib/nlattr.c, we have:
> >
> > Ugh, for the time being I guess we'll have to wrap these within
> > CONFIG_NET, as I'd rather not have CONFIG_CRYPTO depend on CONFIG_NET.
> >
> > Please let me know whether this patch fixes the problem.
>
> Yep, it compiles and boots. Thanks for the patch.
v3.2-rc1 has been released with this (commonly triggering) build bug
included. Herbert, is the fix on the way to upstream?
Thanks,
Ingo
^ permalink raw reply
* Re: linux-next: build failure after merge of the pm tree
From: Tejun Heo @ 2011-11-10 15:48 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <201111101311.32012.rjw@sisk.pl>
On Thu, Nov 10, 2011 at 01:11:31PM +0100, Rafael J. Wysocki wrote:
> On Thursday, November 10, 2011, Stephen Rothwell wrote:
> > Hi Rafael,
> >
> > After merging the pm tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > mm/oom_kill.c: In function 'select_bad_process':
> > mm/oom_kill.c:326:5: error: implicit declaration of function 'thaw_process'
> >
> > Caused by commit 944e192db53c ("freezer: rename thaw_process() to
> > __thaw_task() and simplify the implementation").
> >
> > I have used the pm tree from next-20111109 for today.
>
> Thanks, I'll drop pm-freezer from my linux-next branch until that issue is
> fixed.
Will try to resolve soon.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH 2/2] ata: Don't use NO_IRQ in pata_of_platform driver
From: Alan Cox @ 2011-11-10 15:38 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Ingo Molnar, Jeff Garzik, Grant Likely, Randy Dunlap,
Stephen Rothwell, linux-next, LKML, linux-ide, Linus Torvalds,
Andrew Morton, devicetree-discuss
In-Reply-To: <20111110152606.GB3207@oksana.dev.rtsoft.ru>
On Thu, 10 Nov 2011 19:26:06 +0400
Anton Vorontsov <cbouatmailru@gmail.com> wrote:
> Drivers should not use NO_IRQ; moreover, some architectures don't
> have it nowadays. '0' is the 'no irq' case.
>
> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Alan
^ permalink raw reply
* Re: [PATCH] ata: Fix build error in pata_of_platform (NO_IRQ usage)
From: Alan Cox @ 2011-11-10 15:35 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Ingo Molnar, Jeff Garzik, Grant Likely, Randy Dunlap,
Stephen Rothwell, linux-next, LKML, linux-ide@vger.kernel.org,
Linus Torvalds, Andrew Morton, devicetree-discuss
In-Reply-To: <20111110151852.GA7465@oksana.dev.rtsoft.ru>
> The proper fix (stop OF code from returning NO_IRQ values) is pending.
Please just apply the proper fix.
> - The NO_IRQ disease spreads despite our willingness, even within
> the new OF code.
Then it can stop right here, because if the arch people don't fix their
code to use zero their ATA port won't work.
> +/* For archs that don't support NO_IRQ (such as x86), provide a dummy value */
> +#ifndef NO_IRQ
> +#define NO_IRQ 0
> +#endif
NAK - just test against zero. They've been complained at about this for
over two years. Enough is enough.
Alan
^ permalink raw reply
* [PATCH 2/2] ata: Don't use NO_IRQ in pata_of_platform driver
From: Anton Vorontsov @ 2011-11-10 15:26 UTC (permalink / raw)
To: Ingo Molnar, Jeff Garzik, Grant Likely
Cc: Randy Dunlap, Stephen Rothwell, linux-next, LKML, linux-ide,
Linus Torvalds, Andrew Morton, devicetree-discuss, Alan Cox
In-Reply-To: <20111110151852.GA7465@oksana.dev.rtsoft.ru>
Drivers should not use NO_IRQ; moreover, some architectures don't
have it nowadays. '0' is the 'no irq' case.
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
---
drivers/ata/pata_of_platform.c | 7 +------
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
index f99e17b..2a472c5 100644
--- a/drivers/ata/pata_of_platform.c
+++ b/drivers/ata/pata_of_platform.c
@@ -16,11 +16,6 @@
#include <linux/of_platform.h>
#include <linux/ata_platform.h>
-/* For archs that don't support NO_IRQ (such as x86), provide a dummy value */
-#ifndef NO_IRQ
-#define NO_IRQ 0
-#endif
-
static int __devinit pata_of_platform_probe(struct platform_device *ofdev)
{
int ret;
@@ -57,7 +52,7 @@ static int __devinit pata_of_platform_probe(struct platform_device *ofdev)
}
ret = of_irq_to_resource(dn, 0, &irq_res);
- if (ret == NO_IRQ)
+ if (!ret)
irq_res.start = irq_res.end = 0;
else
irq_res.flags = 0;
--
1.7.5.3
^ permalink raw reply related
* [PATCH 1/2] of/irq: Get rid of NO_IRQ usage
From: Anton Vorontsov @ 2011-11-10 15:25 UTC (permalink / raw)
To: Ingo Molnar, Jeff Garzik, Grant Likely
Cc: Randy Dunlap, Stephen Rothwell, linux-next, LKML, linux-ide,
Linus Torvalds, Andrew Morton, devicetree-discuss, Alan Cox
In-Reply-To: <20111110151852.GA7465@oksana.dev.rtsoft.ru>
PPC32/64 defines NO_IRQ to zero, so no problems expected.
ARM defines NO_IRQ to -1, but OF code relies on IRQ domains support,
which returns correct ('0') value in 'no irq' case. So everything
should be fine.
Other arches might break if some of their OF drivers rely on NO_IRQ
being not 0. If so, the drivers must be fixed, finally.
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
---
drivers/of/irq.c | 30 ++++++++++++++++++------------
1 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 6d3dd39..2dd4937 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -26,11 +26,6 @@
#include <linux/string.h>
#include <linux/slab.h>
-/* For archs that don't support NO_IRQ (such as x86), provide a dummy value */
-#ifndef NO_IRQ
-#define NO_IRQ 0
-#endif
-
/**
* irq_of_parse_and_map - Parse and map an interrupt into linux virq space
* @device: Device node of the device whose interrupt is to be mapped
@@ -42,12 +37,23 @@
unsigned int irq_of_parse_and_map(struct device_node *dev, int index)
{
struct of_irq oirq;
+ int ret = 0;
if (of_irq_map_one(dev, index, &oirq))
- return NO_IRQ;
-
- return irq_create_of_mapping(oirq.controller, oirq.specifier,
- oirq.size);
+ goto no_irq;
+
+ ret = irq_create_of_mapping(oirq.controller, oirq.specifier,
+ oirq.size);
+no_irq:
+#ifdef NO_IRQ
+#if NO_IRQ != 0
+ if (ret == NO_IRQ)
+ pr_warn("Hit NO_IRQ case for your arch. Drivers might expect "
+ "NO_IRQ, but we return 0. If anything breaks, driver "
+ "have to be fixed.\n");
+#endif
+#endif
+ return ret;
}
EXPORT_SYMBOL_GPL(irq_of_parse_and_map);
@@ -345,7 +351,7 @@ int of_irq_to_resource(struct device_node *dev, int index, struct resource *r)
/* Only dereference the resource if both the
* resource and the irq are valid. */
- if (r && irq != NO_IRQ) {
+ if (r && irq) {
r->start = r->end = irq;
r->flags = IORESOURCE_IRQ;
r->name = dev->full_name;
@@ -363,7 +369,7 @@ int of_irq_count(struct device_node *dev)
{
int nr = 0;
- while (of_irq_to_resource(dev, nr, NULL) != NO_IRQ)
+ while (of_irq_to_resource(dev, nr, NULL))
nr++;
return nr;
@@ -383,7 +389,7 @@ int of_irq_to_resource_table(struct device_node *dev, struct resource *res,
int i;
for (i = 0; i < nr_irqs; i++, res++)
- if (of_irq_to_resource(dev, i, res) == NO_IRQ)
+ if (!of_irq_to_resource(dev, i, res))
break;
return i;
--
1.7.5.3
^ permalink raw reply related
* [PATCH] ata: Fix build error in pata_of_platform (NO_IRQ usage)
From: Anton Vorontsov @ 2011-11-10 15:18 UTC (permalink / raw)
To: Ingo Molnar, Jeff Garzik, Grant Likely
Cc: Randy Dunlap, Stephen Rothwell, linux-next, LKML,
linux-ide@vger.kernel.org, Linus Torvalds, Andrew Morton,
devicetree-discuss
In-Reply-To: <20111110135703.GA23609@elte.hu>
This patch makes a band-aid fix the following build failure:
CC drivers/ata/pata_of_platform.o
drivers/ata/pata_of_platform.c: In function 'pata_of_platform_probe':
drivers/ata/pata_of_platform.c:55:13: error: 'NO_IRQ' undeclared (first use in this function)
drivers/ata/pata_of_platform.c:55:13: note: each undeclared identifier is reported only once for each function it appears in
The proper fix (stop OF code from returning NO_IRQ values) is pending.
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
---
On Thu, Nov 10, 2011 at 02:57:03PM +0100, Ingo Molnar wrote:
[...]
> > > drivers/ata/pata_of_platform.c:55:13: error: 'NO_IRQ' undeclared (first use in this function)
> >
> > [adding Author: Anton]
> >
> > Build error still present in linux-next of 20111014.
>
> This build failure regression report was ignored twice and then
> pushed upstream and is still unfixed a month after the initial
> report. Upstream now fails to build on like 25% of x86 configs.
>
> What's going on with this bug guys?
Here is the story:
- NO_IRQ is evil[1], AFAIR the trend is to remove its usage completely;
- Sane arches (x86) don't use it at all, or have it defined to 0
(PPC32/64).
- On another arches it is either -1 or whatever random value;
- The NO_IRQ disease spreads despite our willingness, even within
the new OF code.
The new irq domain stuff (that is used on ARM) always returns 0
in 'no irq' case, so we may easily remove it.
So the proper fix would be two-fold: for OF and for that driver.
But this is for 3.3 kernels. I'll send the two patches as follow-ups.
In the meantime, the band-aid (for 3.2) is down below.
[1]
http://lkml.org/lkml/2005/11/22/159
http://lkml.org/lkml/2005/11/22/227
drivers/ata/pata_of_platform.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/ata/pata_of_platform.c b/drivers/ata/pata_of_platform.c
index a72ab0d..f99e17b 100644
--- a/drivers/ata/pata_of_platform.c
+++ b/drivers/ata/pata_of_platform.c
@@ -16,6 +16,11 @@
#include <linux/of_platform.h>
#include <linux/ata_platform.h>
+/* For archs that don't support NO_IRQ (such as x86), provide a dummy value */
+#ifndef NO_IRQ
+#define NO_IRQ 0
+#endif
+
static int __devinit pata_of_platform_probe(struct platform_device *ofdev)
{
int ret;
--
1.7.5.3
^ permalink raw reply related
* Re: linux-next: Tree for Oct 11 (ata/pata_of_platform.c)
From: Alan Cox @ 2011-11-10 14:25 UTC (permalink / raw)
To: Ingo Molnar
Cc: Randy Dunlap, Stephen Rothwell, linux-next, LKML,
linux-ide@vger.kernel.org, Anton Vorontsov, Linus Torvalds,
Andrew Morton, Jeff Garzik
In-Reply-To: <20111110135703.GA23609@elte.hu>
O> > > drivers/ata/pata_of_platform.c:55:13: error: 'NO_IRQ' undeclared (first use in this function)
> >
> >
> > [adding Author: Anton]
> >
> > Build error still present in linux-next of 20111014.
>
> This build failure regression report was ignored twice and then
> pushed upstream and is still unfixed a month after the initial
> report. Upstream now fails to build on like 25% of x86 configs.
>
> What's going on with this bug guys?
As I've said before the driver shouldn't be trying to use "NO_IRQ", Not
having an irq is 0 as in if (!dev->irq)
^ permalink raw reply
* Re: linux-next: Tree for Oct 11 (ata/pata_of_platform.c)
From: Ingo Molnar @ 2011-11-10 13:57 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, linux-next, LKML, linux-ide@vger.kernel.org,
Anton Vorontsov, Linus Torvalds, Andrew Morton, Jeff Garzik
In-Reply-To: <4E987829.3080104@xenotime.net>
* Randy Dunlap <rdunlap@xenotime.net> wrote:
> On 10/11/2011 01:37 PM, Randy Dunlap wrote:
> > On 10/11/11 02:11, Stephen Rothwell wrote:
> >> Hi all,
> >>
> >> The linux-next tree is now available from
> >> git://github.com/sfrothwell/linux-next.git as a temporary measure while
> >> the kernel.org servers are unavailable.
> >>
> >> It may also turn up on git.kernel.org (depending on the mirroring). The
> >> patch set is still absent, however.
> >>
> >> Changes since 20111007:
> >>
> >> Removed tree: ide (at the maintainer's request)
> >
> >
> > drivers/ata/pata_of_platform.c:55:13: error: 'NO_IRQ' undeclared (first use in this function)
>
>
> [adding Author: Anton]
>
> Build error still present in linux-next of 20111014.
This build failure regression report was ignored twice and then
pushed upstream and is still unfixed a month after the initial
report. Upstream now fails to build on like 25% of x86 configs.
What's going on with this bug guys?
Thanks,
Ingo
^ permalink raw reply
* Re: linux-next: Tree for Oct 25 (pci/ats.c)
From: Ingo Molnar @ 2011-11-10 13:09 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, linux-next, LKML, Linus,
linux-pci@vger.kernel.org, Joerg Roedel, Yu Zhao, Andrew Morton
In-Reply-To: <4EA85353.4060101@xenotime.net>
* Randy Dunlap <rdunlap@xenotime.net> wrote:
> On 10/25/11 02:36, Stephen Rothwell wrote:
> > Hi all,
>
>
> When CONFIG_PCI_IOV is not enabled:
> (probably because PCI_PRI selects PCI_ATS even when PCI_IOV is not
> enabled)
>
> drivers/pci/ats.c:37:5: error: 'struct pci_dev' has no member named 'ats'
> drivers/pci/ats.c:44:11: error: 'struct pci_dev' has no member named 'ats'
> drivers/pci/ats.c:45:5: error: 'struct pci_dev' has no member named 'ats'
> drivers/pci/ats.c:55:5: error: redefinition of 'pci_enable_ats'
> drivers/pci/ats.c:60:2: error: 'struct pci_dev' has no member named 'ats'
> drivers/pci/ats.c:60:2: error: 'struct pci_dev' has no member named 'ats'
> drivers/pci/ats.c:66:52: error: 'struct pci_dev' has no member named 'physfn'
> drivers/pci/ats.c:68:3: error: 'struct pci_dev' has no member named 'sriov'
> drivers/pci/ats.c:69:11: error: 'struct pci_dev' has no member named 'ats'
> drivers/pci/ats.c:70:13: error: 'struct pci_dev' has no member named 'ats'
> drivers/pci/ats.c:75:8: error: 'struct pci_dev' has no member named 'ats'
> drivers/pci/ats.c:76:21: error: 'struct pci_dev' has no member named 'sriov'
> drivers/pci/ats.c:90:32: error: 'struct pci_dev' has no member named 'ats'
> drivers/pci/ats.c:92:5: error: 'struct pci_dev' has no member named 'ats'
> drivers/pci/ats.c:102:6: error: redefinition of 'pci_disable_ats'
> drivers/pci/ats.c:106:2: error: 'struct pci_dev' has no member named 'ats'
> drivers/pci/ats.c:106:2: error: 'struct pci_dev' has no member named 'ats'
> drivers/pci/ats.c:108:31: error: 'struct pci_dev' has no member named 'ats'
> drivers/pci/ats.c:110:32: error: 'struct pci_dev' has no member named 'ats'
> drivers/pci/ats.c:112:5: error: 'struct pci_dev' has no member named 'ats'
> drivers/pci/ats.c:115:52: error: 'struct pci_dev' has no member named 'physfn'
> drivers/pci/ats.c:117:3: error: 'struct pci_dev' has no member named 'sriov'
> drivers/pci/ats.c:118:7: error: 'struct pci_dev' has no member named 'ats'
> drivers/pci/ats.c:119:12: error: 'struct pci_dev' has no member named 'ats'
> drivers/pci/ats.c:121:21: error: 'struct pci_dev' has no member named 'sriov'
> drivers/pci/ats.c:141:5: error: redefinition of 'pci_ats_queue_depth'
> drivers/pci/ats.c:149:9: error: 'struct pci_dev' has no member named 'ats'
> next-2011-1025/drivers/pci/ats.c:150:13: error: 'struct pci_dev' has no member named 'ats'
This build failure is still present upstream, in v3.2-rc1 and later
kernels.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH] MIPS/sound: DB1200 audio support depends on MIPS arch.
From: Ralf Baechle @ 2011-11-10 12:17 UTC (permalink / raw)
To: Manuel Lauss; +Cc: alsa-devel, Stephen Rothwell, linux-next
In-Reply-To: <1320924059-4142-1-git-send-email-manuel.lauss@googlemail.com>
On Thu, Nov 10, 2011 at 12:20:59PM +0100, Manuel Lauss wrote:
> DB1200 audio support should only be visible if MIPS/Alchemy arch is
> selected. Fixes an x86-allmodconfig build failure in linux-next.
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Manuel Lauss <manuel.lauss@googlemail.com>
Thanks, folded into the offending patch.
Ralf
^ permalink raw reply
* Re: linux-next: build failure after merge of the pm tree
From: Rafael J. Wysocki @ 2011-11-10 12:11 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Tejun Heo
In-Reply-To: <20111110133106.12e519d17f6a28adfee3b883@canb.auug.org.au>
On Thursday, November 10, 2011, Stephen Rothwell wrote:
> Hi Rafael,
>
> After merging the pm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> mm/oom_kill.c: In function 'select_bad_process':
> mm/oom_kill.c:326:5: error: implicit declaration of function 'thaw_process'
>
> Caused by commit 944e192db53c ("freezer: rename thaw_process() to
> __thaw_task() and simplify the implementation").
>
> I have used the pm tree from next-20111109 for today.
Thanks, I'll drop pm-freezer from my linux-next branch until that issue is
fixed.
Rafael
^ permalink raw reply
* Re: [PATCH] MIPS/sound: DB1200 audio support depends on MIPS arch.
From: Manuel Lauss @ 2011-11-10 11:46 UTC (permalink / raw)
To: Ralf Baechle; +Cc: alsa-devel, Stephen Rothwell, linux-next, Manuel Lauss
In-Reply-To: <1320924059-4142-1-git-send-email-manuel.lauss@googlemail.com>
On Thu, Nov 10, 2011 at 12:20 PM, Manuel Lauss
<manuel.lauss@googlemail.com> wrote:
> DB1200 audio support should only be visible if MIPS/Alchemy arch is
> selected. Fixes an x86-allmodconfig build failure in linux-next.
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Manuel Lauss <manuel.lauss@googlemail.com>
Please ignore this one. This is caused by a stray change in on the
Alchemy patches
for 3.3. I'll send a fix to Ralf asap.
Manuel
^ permalink raw reply
* Re: [alsa-devel] [PATCH] MIPS/sound: DB1200 audio support depends on MIPS arch.
From: Mark Brown @ 2011-11-10 11:36 UTC (permalink / raw)
To: Manuel Lauss; +Cc: Stephen Rothwell, alsa-devel, linux-next, alsa-devel
In-Reply-To: <20111110113448.GF21630@sirena.org.uk>
On Thu, Nov 10, 2011 at 11:34:48AM +0000, Mark Brown wrote:
> On Thu, Nov 10, 2011 at 12:20:59PM +0100, Manuel Lauss wrote:
> > DB1200 audio support should only be visible if MIPS/Alchemy arch is
> > selected. Fixes an x86-allmodconfig build failure in linux-next.
>
> Applied but *always* CC maintainers on patches.
Sorry, actually not applied as it's not against mainline - please
resubmit against mainline.
^ permalink raw reply
* Re: [alsa-devel] [PATCH] MIPS/sound: DB1200 audio support depends on MIPS arch.
From: Mark Brown @ 2011-11-10 11:34 UTC (permalink / raw)
To: Manuel Lauss; +Cc: alsa-devel, Stephen Rothwell, linux-next, alsa-devel
In-Reply-To: <1320924059-4142-1-git-send-email-manuel.lauss@googlemail.com>
On Thu, Nov 10, 2011 at 12:20:59PM +0100, Manuel Lauss wrote:
> DB1200 audio support should only be visible if MIPS/Alchemy arch is
> selected. Fixes an x86-allmodconfig build failure in linux-next.
Applied but *always* CC maintainers on patches.
^ permalink raw reply
* Re: linux-next: failed import of the rr quilt series
From: Rusty Russell @ 2011-11-10 11:28 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel
In-Reply-To: <20111109101909.585d2406dc46af8890f28e66@canb.auug.org.au>
On Wed, 9 Nov 2011 10:19:09 +1100, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
Non-text part: multipart/signed
> Hi Rusty,
>
> Tryiong to import the rr quilt series today produced this error:
>
> Importing rr based on v3.1-8907-g43672a0
> $ git reset --hard 43672a0784707d795556b1f93925da8b8e797d03
> Checking out files: 100% (37600/37600), done.
> HEAD is now at 43672a0 Merge git://git.kernel.org/pub/scm/linux/kernel/git/steve/linux-dm
> $ git am ../quilt/rr/virtio:pci_fix_use_after_free.patch
> Applying: virtio-pci: fix use after free
> error: patch failed: drivers/virtio/virtio_pci.c:822
> error: drivers/virtio/virtio_pci.c: patch does not apply
Fuzz, I didn't notice (since it's a warning, not an error here).
Verified it, and refreshed.
Thanks,
Rusty.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox