[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m163ql3ox2.fsf@frodo.ebiederm.org>
Date: Thu, 31 Jul 2008 11:10:33 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Yinghai Lu <yhlu.kernel@...il.com>, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>,
Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
Mike Travis <travis@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] serial: change remove NR_IRQS in 8250.c
Alan Cox <alan@...rguk.ukuu.org.uk> writes:
> On Thu, 31 Jul 2008 04:50:21 -0700
> ebiederm@...ssion.com (Eric W. Biederman) wrote:
>
>> > replace
>> > [PATCH] serial: change irq_lists to use dyn_array
>> > use small array with index to handle irq locking for serial port
>> > hope 32 slot is enough
>>
>> Could you size this array by NR_UARTS (our worst case usage)
>> and place irq_no in struct irq_info?
>
> NR_UARTS is likely to go away in time so don't get attached to it
I'm not attached to it, but NR_UARTS is a closer approximation to what
we are trying to do then YH's hard coded 32. Do you know if we
actually need the list of uarts per irq or if request_irq having a
shared isa would work?
The practical question is how do we cleanly kill the array
irq_lists[NR_IRQS]. YH's hack where he isn't paying attention to what
the code is doing and just trying to avoid the problem is not
something I am fond of seeing being merged.
It is also true that sorting out 8250.c and by extension the other
serial drivers that have cloned it is the significant non-arch
piece of work needed to kill NR_IRQs
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists