* [PATCH 00/33] dyn_array and nr_irqs support v4
[not found] <No>
@ 2008-08-06 8:38 ` Yinghai Lu
2008-08-06 8:38 ` [PATCH 01/33] x86: add after_bootmem for 32bit Yinghai Lu
2008-08-06 17:37 ` [PATCH 00/33] dyn_array and nr_irqs support v4 Eric W. Biederman
2015-01-12 9:52 ` [PATCH gpio] gpio-arizona: drop owner assignment from platform_drivers Varka Bhadram
1 sibling, 2 replies; 17+ messages in thread
From: Yinghai Lu @ 2008-08-06 8:38 UTC (permalink / raw)
To: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, Eric W. Biederman,
Dhaval Giani, Mike Travis, Andrew Morton
Cc: linux-kernel, Yinghai Lu
Please check dyn_array support for x86
v3: split changing to nr_irqs to small patches
fix checkpatch error
reorder the patch sequence to make dyn_array support go at first
so could use that with arrays other than NR_IRQS
v4: add CONFIG_HAVE_SPARSE_IRQ with list to use condensed irq_desc array
so could use 32 init, and init more if needed.
now: x86 32bit: have CONFIG_HAVE_DYN_ARRAY
x86 64bit: have CONFIG_HAVE_DYN_ARRAY and CONFIG_HAVE_SPARSE_IRQ
left:
a. hook irq_2_iommu to irq_desc ?
b. expand /proc/interrupts to process > nr_irqs
c. expand to use irq > nr_irqs for msi
notes: may break some arch compling...
Thanks
Yinghai Lu
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH 01/33] x86: add after_bootmem for 32bit
2008-08-06 8:38 ` [PATCH 00/33] dyn_array and nr_irqs support v4 Yinghai Lu
@ 2008-08-06 8:38 ` Yinghai Lu
2008-08-06 8:38 ` [PATCH 02/33] x86: remove irq_vectors_limits Yinghai Lu
2008-08-06 17:37 ` [PATCH 00/33] dyn_array and nr_irqs support v4 Eric W. Biederman
1 sibling, 1 reply; 17+ messages in thread
From: Yinghai Lu @ 2008-08-06 8:38 UTC (permalink / raw)
To: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, Eric W. Biederman,
Dhaval Giani, Mike Travis, Andrew Morton
Cc: linux-kernel, Yinghai Lu
to prepare to use dyn_array support etc.
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
---
arch/x86/mm/init_32.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index 4974e97..b5c1751 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -65,6 +65,7 @@ static unsigned long __meminitdata table_end;
static unsigned long __meminitdata table_top;
static int __initdata after_init_bootmem;
+int after_bootmem;
static __init void *alloc_low_page(unsigned long *phys)
{
@@ -924,6 +925,8 @@ void __init mem_init(void)
set_highmem_pages_init();
+ after_bootmem = 1;
+
codesize = (unsigned long) &_etext - (unsigned long) &_text;
datasize = (unsigned long) &_edata - (unsigned long) &_etext;
initsize = (unsigned long) &__init_end - (unsigned long) &__init_begin;
--
1.5.4.5
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [PATCH 02/33] x86: remove irq_vectors_limits
2008-08-06 8:38 ` [PATCH 01/33] x86: add after_bootmem for 32bit Yinghai Lu
@ 2008-08-06 8:38 ` Yinghai Lu
0 siblings, 0 replies; 17+ messages in thread
From: Yinghai Lu @ 2008-08-06 8:38 UTC (permalink / raw)
To: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, Eric W. Biederman,
Dhaval Giani, Mike Travis, Andrew Morton
Cc: linux-kernel, Yinghai Lu
no user
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
---
include/asm-x86/mach-generic/irq_vectors_limits.h | 14 --------------
include/asm-x86/summit/irq_vectors_limits.h | 14 --------------
2 files changed, 0 insertions(+), 28 deletions(-)
delete mode 100644 include/asm-x86/mach-generic/irq_vectors_limits.h
delete mode 100644 include/asm-x86/summit/irq_vectors_limits.h
diff --git a/include/asm-x86/mach-generic/irq_vectors_limits.h b/include/asm-x86/mach-generic/irq_vectors_limits.h
deleted file mode 100644
index f7870e1..0000000
--- a/include/asm-x86/mach-generic/irq_vectors_limits.h
+++ /dev/null
@@ -1,14 +0,0 @@
-#ifndef ASM_X86__MACH_GENERIC__IRQ_VECTORS_LIMITS_H
-#define ASM_X86__MACH_GENERIC__IRQ_VECTORS_LIMITS_H
-
-/*
- * For Summit or generic (i.e. installer) kernels, we have lots of I/O APICs,
- * even with uni-proc kernels, so use a big array.
- *
- * This value should be the same in both the generic and summit subarches.
- * Change one, change 'em both.
- */
-#define NR_IRQS 224
-#define NR_IRQ_VECTORS 1024
-
-#endif /* ASM_X86__MACH_GENERIC__IRQ_VECTORS_LIMITS_H */
diff --git a/include/asm-x86/summit/irq_vectors_limits.h b/include/asm-x86/summit/irq_vectors_limits.h
deleted file mode 100644
index 890ce3f..0000000
--- a/include/asm-x86/summit/irq_vectors_limits.h
+++ /dev/null
@@ -1,14 +0,0 @@
-#ifndef _ASM_IRQ_VECTORS_LIMITS_H
-#define _ASM_IRQ_VECTORS_LIMITS_H
-
-/*
- * For Summit or generic (i.e. installer) kernels, we have lots of I/O APICs,
- * even with uni-proc kernels, so use a big array.
- *
- * This value should be the same in both the generic and summit subarches.
- * Change one, change 'em both.
- */
-#define NR_IRQS 224
-#define NR_IRQ_VECTORS 1024
-
-#endif /* _ASM_IRQ_VECTORS_LIMITS_H */
--
1.5.4.5
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH 00/33] dyn_array and nr_irqs support v4
2008-08-06 8:38 ` [PATCH 00/33] dyn_array and nr_irqs support v4 Yinghai Lu
2008-08-06 8:38 ` [PATCH 01/33] x86: add after_bootmem for 32bit Yinghai Lu
@ 2008-08-06 17:37 ` Eric W. Biederman
2008-08-06 18:29 ` Yinghai Lu
1 sibling, 1 reply; 17+ messages in thread
From: Eric W. Biederman @ 2008-08-06 17:37 UTC (permalink / raw)
To: Yinghai Lu
Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, Dhaval Giani,
Mike Travis, Andrew Morton, linux-kernel
Yinghai Lu <yhlu.kernel@gmail.com> writes:
> Please check dyn_array support for x86
> v3: split changing to nr_irqs to small patches
> fix checkpatch error
> reorder the patch sequence to make dyn_array support go at first
> so could use that with arrays other than NR_IRQS
> v4: add CONFIG_HAVE_SPARSE_IRQ with list to use condensed irq_desc array
> so could use 32 init, and init more if needed.
>
> now: x86 32bit: have CONFIG_HAVE_DYN_ARRAY
> x86 64bit: have CONFIG_HAVE_DYN_ARRAY and CONFIG_HAVE_SPARSE_IRQ
>
> left:
> a. hook irq_2_iommu to irq_desc ?
> b. expand /proc/interrupts to process > nr_irqs
> c. expand to use irq > nr_irqs for msi
>
> notes: may break some arch compling...
It looks like you might possibly be iterating to something usable.
Breaking architectures is not acceptable however.
My suggestion for a non-breaking path:
- Kill NR_IRQS in then generic code.
With Alan's serial patch and my kstat patch it looks like we have
the worst of that.
- Introduce get_irq_desc and the functions or function modifications
that pass a struct irq_desc * into the genirq code.
Although I absolutely hate the name get_irq_desc as it implies we are
reference counting something and need a corresponding put_irq_desc.
Since the lifetime rules don't require that. Please just call the
function irq_desc().
- Update arch/x86 to do everything interesting with irq_desc pointers.
- Start dynamically allocating irq_desc and irq_cfg.
Eric
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 00/33] dyn_array and nr_irqs support v4
2008-08-06 17:37 ` [PATCH 00/33] dyn_array and nr_irqs support v4 Eric W. Biederman
@ 2008-08-06 18:29 ` Yinghai Lu
2008-08-06 18:50 ` Yinghai Lu
2008-08-06 20:35 ` Eric W. Biederman
0 siblings, 2 replies; 17+ messages in thread
From: Yinghai Lu @ 2008-08-06 18:29 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, Dhaval Giani,
Mike Travis, Andrew Morton, linux-kernel
On Wed, Aug 6, 2008 at 10:37 AM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Yinghai Lu <yhlu.kernel@gmail.com> writes:
>
>> Please check dyn_array support for x86
>> v3: split changing to nr_irqs to small patches
>> fix checkpatch error
>> reorder the patch sequence to make dyn_array support go at first
>> so could use that with arrays other than NR_IRQS
>> v4: add CONFIG_HAVE_SPARSE_IRQ with list to use condensed irq_desc array
>> so could use 32 init, and init more if needed.
>>
>> now: x86 32bit: have CONFIG_HAVE_DYN_ARRAY
>> x86 64bit: have CONFIG_HAVE_DYN_ARRAY and CONFIG_HAVE_SPARSE_IRQ
>>
>> left:
>> a. hook irq_2_iommu to irq_desc ?
>> b. expand /proc/interrupts to process > nr_irqs
>> c. expand to use irq > nr_irqs for msi
>>
>> notes: may break some arch compling...
>
> It looks like you might possibly be iterating to something usable.
> Breaking architectures is not acceptable however.
>
> My suggestion for a non-breaking path:
> - Kill NR_IRQS in then generic code.
> With Alan's serial patch and my kstat patch it looks like we have
> the worst of that.
will use Alan's patch.at first.
already reused your patch about kstat. and move kstat_irqs to irq_desc.
>
> - Introduce get_irq_desc and the functions or function modifications
> that pass a struct irq_desc * into the genirq code.
>
> Although I absolutely hate the name get_irq_desc as it implies we are
> reference counting something and need a corresponding put_irq_desc.
> Since the lifetime rules don't require that. Please just call the
> function irq_desc().
will check that.
>
> - Update arch/x86 to do everything interesting with irq_desc pointers.
>
> - Start dynamically allocating irq_desc and irq_cfg.
already done in last 10 patches.
YH
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 00/33] dyn_array and nr_irqs support v4
2008-08-06 18:29 ` Yinghai Lu
@ 2008-08-06 18:50 ` Yinghai Lu
2008-08-06 20:32 ` Eric W. Biederman
2008-08-06 20:35 ` Eric W. Biederman
1 sibling, 1 reply; 17+ messages in thread
From: Yinghai Lu @ 2008-08-06 18:50 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, Dhaval Giani,
Mike Travis, Andrew Morton, linux-kernel
>>
>> - Introduce get_irq_desc and the functions or function modifications
>> that pass a struct irq_desc * into the genirq code.
>>
>> Although I absolutely hate the name get_irq_desc as it implies we are
>> reference counting something and need a corresponding put_irq_desc.
>> Since the lifetime rules don't require that. Please just call the
>> function irq_desc().
>
> will check that.
>
how about get_irq_desc_without_new()?
irq_desc_without_new()
YH
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 00/33] dyn_array and nr_irqs support v4
2008-08-06 18:50 ` Yinghai Lu
@ 2008-08-06 20:32 ` Eric W. Biederman
2008-08-06 20:52 ` Yinghai Lu
0 siblings, 1 reply; 17+ messages in thread
From: Eric W. Biederman @ 2008-08-06 20:32 UTC (permalink / raw)
To: Yinghai Lu
Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, Dhaval Giani,
Mike Travis, Andrew Morton, linux-kernel
"Yinghai Lu" <yhlu.kernel@gmail.com> writes:
>>>
>>> - Introduce get_irq_desc and the functions or function modifications
>>> that pass a struct irq_desc * into the genirq code.
>>>
>>> Although I absolutely hate the name get_irq_desc as it implies we are
>>> reference counting something and need a corresponding put_irq_desc.
>>> Since the lifetime rules don't require that. Please just call the
>>> function irq_desc().
>>
>> will check that.
>>
> how about get_irq_desc_without_new()?
>
> irq_desc_without_new()
Possibly irq_desc_with_new() or even create_irq_desc in the one or two code paths that care.
Everywhere else can reasonably assume that the irq_desc entries have either been setup, or that
the irq number is invalid.
Eric
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 00/33] dyn_array and nr_irqs support v4
2008-08-06 18:29 ` Yinghai Lu
2008-08-06 18:50 ` Yinghai Lu
@ 2008-08-06 20:35 ` Eric W. Biederman
2008-08-06 20:57 ` Yinghai Lu
2008-08-06 23:26 ` Alan Cox
1 sibling, 2 replies; 17+ messages in thread
From: Eric W. Biederman @ 2008-08-06 20:35 UTC (permalink / raw)
To: Yinghai Lu
Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, Dhaval Giani,
Mike Travis, Andrew Morton, linux-kernel
"Yinghai Lu" <yhlu.kernel@gmail.com> writes:
>> My suggestion for a non-breaking path:
>> - Kill NR_IRQS in then generic code.
>> With Alan's serial patch and my kstat patch it looks like we have
>> the worst of that.
>
> will use Alan's patch.at first.
> already reused your patch about kstat. and move kstat_irqs to irq_desc.
Part of what I am thinking is that there should never be a patch
that does s/NR_IRQS/nr_irqs/ that is just pointless noise.
Either we need a new abstraction like for_each_irq or to update the
code to the current best practices.
Which means the patches should be uncontroversial and mergeble on their
own with no weird dependencies.
Eric
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 00/33] dyn_array and nr_irqs support v4
2008-08-06 20:32 ` Eric W. Biederman
@ 2008-08-06 20:52 ` Yinghai Lu
0 siblings, 0 replies; 17+ messages in thread
From: Yinghai Lu @ 2008-08-06 20:52 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, Dhaval Giani,
Mike Travis, Andrew Morton, linux-kernel
On Wed, Aug 6, 2008 at 1:32 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
> "Yinghai Lu" <yhlu.kernel@gmail.com> writes:
>
>>>>
>>>> - Introduce get_irq_desc and the functions or function modifications
>>>> that pass a struct irq_desc * into the genirq code.
>>>>
>>>> Although I absolutely hate the name get_irq_desc as it implies we are
>>>> reference counting something and need a corresponding put_irq_desc.
>>>> Since the lifetime rules don't require that. Please just call the
>>>> function irq_desc().
>>>
>>> will check that.
>>>
>> how about get_irq_desc_without_new()?
>>
>> irq_desc_without_new()
>
> Possibly irq_desc_with_new() or even create_irq_desc in the one or two code paths that care.
> Everywhere else can reasonably assume that the irq_desc entries have either been setup, or that
> the irq number is invalid.
will use irq_desc_with_new() toghether irq_desc()
YH
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 00/33] dyn_array and nr_irqs support v4
2008-08-06 20:35 ` Eric W. Biederman
@ 2008-08-06 20:57 ` Yinghai Lu
2008-08-06 23:26 ` Alan Cox
1 sibling, 0 replies; 17+ messages in thread
From: Yinghai Lu @ 2008-08-06 20:57 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, Dhaval Giani,
Mike Travis, Andrew Morton, linux-kernel
On Wed, Aug 6, 2008 at 1:35 PM, Eric W. Biederman <ebiederm@xmission.com> wrote:
> "Yinghai Lu" <yhlu.kernel@gmail.com> writes:
>
>>> My suggestion for a non-breaking path:
>>> - Kill NR_IRQS in then generic code.
>>> With Alan's serial patch and my kstat patch it looks like we have
>>> the worst of that.
>>
>> will use Alan's patch.at first.
>> already reused your patch about kstat. and move kstat_irqs to irq_desc.
>
> Part of what I am thinking is that there should never be a patch
> that does s/NR_IRQS/nr_irqs/ that is just pointless noise.
for some platform like 32bit, may not like to mess up with
CONFIG_HAVE_SPARSE_IRQ, to have dyn_array to take small nr_irqs with
probing.
>
> Either we need a new abstraction like for_each_irq or to update the
> code to the current best practices.
already add for_each_irq_desc(irq, desc)...
| #ifndef CONFIG_HAVE_DYN_ARRAY
| /* could be removed if we get rid of all irq_desc reference */
| extern struct irq_desc irq_desc[NR_IRQS];
| #else
| extern struct irq_desc *irq_desc;
| #endif
|
| #define for_each_irq_desc(irq, desc) \
| for (irq = 0, desc = irq_desc; irq < nr_irqs; irq++, desc =
&irq_desc[irq])
|
|#else
|
|extern struct irq_desc *irq_descX;
|#define for_each_irq_desc(irqX, desc) \
| for (desc = irq_descX, irqX = desc->irq; desc && irqX != -1U;
desc = desc->next, irqX = desc ? desc->irq: -1U)
|
|#endif
>
> Which means the patches should be uncontroversial and mergeble on their
> own with no weird dependencies.
sure.
YH
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 00/33] dyn_array and nr_irqs support v4
2008-08-06 20:35 ` Eric W. Biederman
2008-08-06 20:57 ` Yinghai Lu
@ 2008-08-06 23:26 ` Alan Cox
2008-08-07 1:02 ` Eric W. Biederman
1 sibling, 1 reply; 17+ messages in thread
From: Alan Cox @ 2008-08-06 23:26 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Yinghai Lu, Ingo Molnar, Thomas Gleixner, H. Peter Anvin,
Dhaval Giani, Mike Travis, Andrew Morton, linux-kernel
On Wed, 06 Aug 2008 13:35:55 -0700
ebiederm@xmission.com (Eric W. Biederman) wrote:
> "Yinghai Lu" <yhlu.kernel@gmail.com> writes:
>
> >> My suggestion for a non-breaking path:
> >> - Kill NR_IRQS in then generic code.
> >> With Alan's serial patch and my kstat patch it looks like we have
> >> the worst of that.
> >
> > will use Alan's patch.at first.
> > already reused your patch about kstat. and move kstat_irqs to irq_desc.
>
> Part of what I am thinking is that there should never be a patch
> that does s/NR_IRQS/nr_irqs/ that is just pointless noise.
>
> Either we need a new abstraction like for_each_irq or to update the
> code to the current best practices.
>
> Which means the patches should be uncontroversial and mergeble on their
> own with no weird dependencies.
A lot of these are range checks so could be replaced by a single
valid_irq(irq) test.
Alan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 00/33] dyn_array and nr_irqs support v4
2008-08-06 23:26 ` Alan Cox
@ 2008-08-07 1:02 ` Eric W. Biederman
2008-08-07 10:12 ` Alan Cox
0 siblings, 1 reply; 17+ messages in thread
From: Eric W. Biederman @ 2008-08-07 1:02 UTC (permalink / raw)
To: Alan Cox
Cc: Yinghai Lu, Ingo Molnar, Thomas Gleixner, H. Peter Anvin,
Dhaval Giani, Mike Travis, Andrew Morton, linux-kernel
Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> A lot of these are range checks so could be replaced by a single
> valid_irq(irq) test.
Yes. My first impression was that with NR_IRQS dead valid_irq could
easily become. #define valid_irq(irq) ((irq) != 0) However thinking
just a little more since ultimately we will know which irqs have
something hooked up to them we might actually be able to say something
more interesting. So I guess actually having a valid irq function
makes sense. Instead of doing the idiomatic if (irq) logic inline.
Eric
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 00/33] dyn_array and nr_irqs support v4
2008-08-07 1:02 ` Eric W. Biederman
@ 2008-08-07 10:12 ` Alan Cox
2008-08-07 10:51 ` Yinghai Lu
0 siblings, 1 reply; 17+ messages in thread
From: Alan Cox @ 2008-08-07 10:12 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Yinghai Lu, Ingo Molnar, Thomas Gleixner, H. Peter Anvin,
Dhaval Giani, Mike Travis, Andrew Morton, linux-kernel
On Wed, 06 Aug 2008 18:02:18 -0700
ebiederm@xmission.com (Eric W. Biederman) wrote:
> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
>
> > A lot of these are range checks so could be replaced by a single
> > valid_irq(irq) test.
>
> Yes. My first impression was that with NR_IRQS dead valid_irq could
> easily become. #define valid_irq(irq) ((irq) != 0)
Not really - there are lots of cases where we sanity check an IRQ passed
from user space or module parameter configuration. So we do actually need
valid_irq(irq) ((irq) > 0 && (irq) < nr_irqs)
[or relevant per arch alternatives]
Alan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 00/33] dyn_array and nr_irqs support v4
2008-08-07 10:12 ` Alan Cox
@ 2008-08-07 10:51 ` Yinghai Lu
2008-08-07 10:57 ` Alan Cox
2008-08-07 18:12 ` H. Peter Anvin
0 siblings, 2 replies; 17+ messages in thread
From: Yinghai Lu @ 2008-08-07 10:51 UTC (permalink / raw)
To: Alan Cox
Cc: Eric W. Biederman, Ingo Molnar, Thomas Gleixner, H. Peter Anvin,
Dhaval Giani, Mike Travis, Andrew Morton, linux-kernel
On Thu, Aug 7, 2008 at 3:12 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Wed, 06 Aug 2008 18:02:18 -0700
> ebiederm@xmission.com (Eric W. Biederman) wrote:
>
>> Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
>>
>> > A lot of these are range checks so could be replaced by a single
>> > valid_irq(irq) test.
>>
>> Yes. My first impression was that with NR_IRQS dead valid_irq could
>> easily become. #define valid_irq(irq) ((irq) != 0)
>
> Not really - there are lots of cases where we sanity check an IRQ passed
> from user space or module parameter configuration. So we do actually need
>
> valid_irq(irq) ((irq) > 0 && (irq) < nr_irqs)
>
> [or relevant per arch alternatives]
#ifndef CONFIG_HAVE_SPARSE_IRQ
#define valid_irq(irq) ((irq) > 0 && (irq) < nr_irqs)
#else
#define valid_irq(irq) ((irq) > 0)
anyway why 0 is invalid instead of -1U...?
YH
#endif
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 00/33] dyn_array and nr_irqs support v4
2008-08-07 10:51 ` Yinghai Lu
@ 2008-08-07 10:57 ` Alan Cox
2008-08-07 18:12 ` H. Peter Anvin
1 sibling, 0 replies; 17+ messages in thread
From: Alan Cox @ 2008-08-07 10:57 UTC (permalink / raw)
To: Yinghai Lu
Cc: Eric W. Biederman, Ingo Molnar, Thomas Gleixner, H. Peter Anvin,
Dhaval Giani, Mike Travis, Andrew Morton, linux-kernel
> #ifndef CONFIG_HAVE_SPARSE_IRQ
> #define valid_irq(irq) ((irq) > 0 && (irq) < nr_irqs)
> #else
> #define valid_irq(irq) ((irq) > 0)
For a sparse IRQ you might want to call an arch specific bit of C to do
the validating. Not sure that matters too much though as must user set
interrupts are ISA 8)
> anyway why 0 is invalid instead of -1U...?
So you can write the natural thing in C
if (!dev->irq)
poll_device();
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 00/33] dyn_array and nr_irqs support v4
2008-08-07 10:51 ` Yinghai Lu
2008-08-07 10:57 ` Alan Cox
@ 2008-08-07 18:12 ` H. Peter Anvin
1 sibling, 0 replies; 17+ messages in thread
From: H. Peter Anvin @ 2008-08-07 18:12 UTC (permalink / raw)
To: Yinghai Lu
Cc: Alan Cox, Eric W. Biederman, Ingo Molnar, Thomas Gleixner,
Dhaval Giani, Mike Travis, Andrew Morton, linux-kernel
Yinghai Lu wrote:
>
> #ifndef CONFIG_HAVE_SPARSE_IRQ
> #define valid_irq(irq) ((irq) > 0 && (irq) < nr_irqs)
> #else
> #define valid_irq(irq) ((irq) > 0)
>
> anyway why 0 is invalid instead of -1U...?
>
Because 0 is easier to understand to a user when specifying in a module
option.
-hpa
^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH gpio] gpio-arizona: drop owner assignment from platform_drivers
[not found] <No>
2008-08-06 8:38 ` [PATCH 00/33] dyn_array and nr_irqs support v4 Yinghai Lu
@ 2015-01-12 9:52 ` Varka Bhadram
1 sibling, 0 replies; 17+ messages in thread
From: Varka Bhadram @ 2015-01-12 9:52 UTC (permalink / raw)
To: linux-gpio; +Cc: linus.walleij, gnurou, Varka Bhadram
This driver no need to set the owner field, it will be populated
by driver core.
Signed-off-by: Varka Bhadram <varkab@cdac.in>
---
drivers/gpio/gpio-arizona.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpio/gpio-arizona.c b/drivers/gpio/gpio-arizona.c
index cd28ab66..eb5a0ce 100644
--- a/drivers/gpio/gpio-arizona.c
+++ b/drivers/gpio/gpio-arizona.c
@@ -155,7 +155,6 @@ static int arizona_gpio_remove(struct platform_device *pdev)
static struct platform_driver arizona_gpio_driver = {
.driver.name = "arizona-gpio",
- .driver.owner = THIS_MODULE,
.probe = arizona_gpio_probe,
.remove = arizona_gpio_remove,
};
--
1.7.9.5
^ permalink raw reply related [flat|nested] 17+ messages in thread
end of thread, other threads:[~2015-01-12 9:56 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <No>
2008-08-06 8:38 ` [PATCH 00/33] dyn_array and nr_irqs support v4 Yinghai Lu
2008-08-06 8:38 ` [PATCH 01/33] x86: add after_bootmem for 32bit Yinghai Lu
2008-08-06 8:38 ` [PATCH 02/33] x86: remove irq_vectors_limits Yinghai Lu
2008-08-06 17:37 ` [PATCH 00/33] dyn_array and nr_irqs support v4 Eric W. Biederman
2008-08-06 18:29 ` Yinghai Lu
2008-08-06 18:50 ` Yinghai Lu
2008-08-06 20:32 ` Eric W. Biederman
2008-08-06 20:52 ` Yinghai Lu
2008-08-06 20:35 ` Eric W. Biederman
2008-08-06 20:57 ` Yinghai Lu
2008-08-06 23:26 ` Alan Cox
2008-08-07 1:02 ` Eric W. Biederman
2008-08-07 10:12 ` Alan Cox
2008-08-07 10:51 ` Yinghai Lu
2008-08-07 10:57 ` Alan Cox
2008-08-07 18:12 ` H. Peter Anvin
2015-01-12 9:52 ` [PATCH gpio] gpio-arizona: drop owner assignment from platform_drivers Varka Bhadram
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.