On Sat, Feb 22, 2014 at 3:38 PM, Thomas Gleixner wrote:
>
> OMG, you really mean that:
>
> +++ b/arch/alpha/kernel/irq_i8259.c
> @@ -92,6 +92,7 @@ init_i8259a_irqs(void)
> outb(0xff, 0xA1); /* mask all of 8259A-2 */
>
> for (i = 0; i < 16; i++) {
> +
On Sat, Feb 22, 2014 at 3:38 PM, Thomas Gleixner t...@linutronix.de wrote:
OMG, you really mean that:
+++ b/arch/alpha/kernel/irq_i8259.c
@@ -92,6 +92,7 @@ init_i8259a_irqs(void)
outb(0xff, 0xA1); /* mask all of 8259A-2 */
for (i = 0; i 16; i++) {
+
On Sat, 22 Feb 2014, Yinghai Lu wrote:
> On Sat, Feb 22, 2014 at 9:28 AM, Yinghai Lu wrote:
> > On Sat, Feb 22, 2014 at 2:08 AM, Thomas Gleixner wrote:
> >>
> >> As I said before irq_reserve_irq() is a misnomer and a
> >> misconception. Of course this needs to be fixed as well.
> >>
> >> And you
On Sat, Feb 22, 2014 at 9:28 AM, Yinghai Lu wrote:
> On Sat, Feb 22, 2014 at 2:08 AM, Thomas Gleixner wrote:
>>
>> As I said before irq_reserve_irq() is a misnomer and a
>> misconception. Of course this needs to be fixed as well.
>>
>> And you cannot just blindly change it because !SPARSE can
On Sat, Feb 22, 2014 at 2:08 AM, Thomas Gleixner wrote:
>
> As I said before irq_reserve_irq() is a misnomer and a
> misconception. Of course this needs to be fixed as well.
>
> And you cannot just blindly change it because !SPARSE can use the
> allocation. We are not creating stupid corner cases
On Mon, 17 Feb 2014, Yinghai Lu wrote:
> On Wed, Jan 22, 2014 at 4:03 PM, Thomas Gleixner wrote:
> >
> > There is a clear step by step approach to get this done proper:
> >
> > 1) Get rid of the existing misconception/misnomer of
> > irq_reserve_irqs().
> >
> > Make it explicit that this
On Mon, 17 Feb 2014, Yinghai Lu wrote:
On Wed, Jan 22, 2014 at 4:03 PM, Thomas Gleixner t...@linutronix.de wrote:
There is a clear step by step approach to get this done proper:
1) Get rid of the existing misconception/misnomer of
irq_reserve_irqs().
Make it explicit that
On Sat, Feb 22, 2014 at 2:08 AM, Thomas Gleixner t...@linutronix.de wrote:
As I said before irq_reserve_irq() is a misnomer and a
misconception. Of course this needs to be fixed as well.
And you cannot just blindly change it because !SPARSE can use the
allocation. We are not creating stupid
On Sat, Feb 22, 2014 at 9:28 AM, Yinghai Lu ying...@kernel.org wrote:
On Sat, Feb 22, 2014 at 2:08 AM, Thomas Gleixner t...@linutronix.de wrote:
As I said before irq_reserve_irq() is a misnomer and a
misconception. Of course this needs to be fixed as well.
And you cannot just blindly change
On Sat, 22 Feb 2014, Yinghai Lu wrote:
On Sat, Feb 22, 2014 at 9:28 AM, Yinghai Lu ying...@kernel.org wrote:
On Sat, Feb 22, 2014 at 2:08 AM, Thomas Gleixner t...@linutronix.de wrote:
As I said before irq_reserve_irq() is a misnomer and a
misconception. Of course this needs to be fixed as
On 2014/1/3 8:05, Yinghai Lu wrote:
> For ioapic hot-add support, it would be easy if we have continuous
> irq numbers for hot added ioapic controller.
>
> We can reserve irq range at first, and later allocate desc for those
> pre-reserved irqs when they are needed.
>
> The reasons for not
On 2014/1/3 8:05, Yinghai Lu wrote:
For ioapic hot-add support, it would be easy if we have continuous
irq numbers for hot added ioapic controller.
We can reserve irq range at first, and later allocate desc for those
pre-reserved irqs when they are needed.
The reasons for not allocating
On Wed, Jan 22, 2014 at 4:03 PM, Thomas Gleixner wrote:
>
> There is a clear step by step approach to get this done proper:
>
> 1) Get rid of the existing misconception/misnomer of
> irq_reserve_irqs().
>
> Make it explicit that this is dealing with legacy irq spaces. It's
> not that
On Wed, Jan 22, 2014 at 4:03 PM, Thomas Gleixner t...@linutronix.de wrote:
There is a clear step by step approach to get this done proper:
1) Get rid of the existing misconception/misnomer of
irq_reserve_irqs().
Make it explicit that this is dealing with legacy irq spaces. It's
Yinghai,
On Thu, 2 Jan 2014, Yinghai Lu wrote:
> For ioapic hot-add support, it would be easy if we have continuous
> irq numbers for hot added ioapic controller.
I really don't care about easy. Easy to solve problems are for
wimps.
What you really want to say is, that ioapic hot-add support
Yinghai,
On Thu, 2 Jan 2014, Yinghai Lu wrote:
For ioapic hot-add support, it would be easy if we have continuous
irq numbers for hot added ioapic controller.
I really don't care about easy. Easy to solve problems are for
wimps.
What you really want to say is, that ioapic hot-add support
For ioapic hot-add support, it would be easy if we have continuous
irq numbers for hot added ioapic controller.
We can reserve irq range at first, and later allocate desc for those
pre-reserved irqs when they are needed.
The reasons for not allocating them during reserving:
1. only several pins
For ioapic hot-add support, it would be easy if we have continuous
irq numbers for hot added ioapic controller.
We can reserve irq range at first, and later allocate desc for those
pre-reserved irqs when they are needed.
The reasons for not allocating them during reserving:
1. only several pins
18 matches
Mail list logo
