From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: ns16550.c's poll_port variable Date: Fri, 04 May 2012 14:27:03 +0100 Message-ID: References: <4FA3EBC90200007800081A5E@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4FA3EBC90200007800081A5E@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 04/05/2012 13:46, "Jan Beulich" wrote: >>>> On 04.05.12 at 14:03, Keir Fraser wrote: >> On 04/05/2012 12:05, "Jan Beulich" wrote: >> >>>> I'm unclear on exactly what you want to optimise away? Certainly the 8 >>>> bytes >>>> per CPU of the poll_port variable isn't worth much optimising effort. >>> >>> Certainly not (and as you say they are actually needed, even if >>> only rarely). But the pointlessly running timer(s) might be, as might >>> the buffer(s) set up via serial_async_transmit(). >> >> We could delay {init,setup}_postirq until a corresponding serial handle has >> been created via serial_parse_handle()? The logic might be a bit ugly and >> spread across both serial.c and ns16550.c but not actually particularly >> complicated? > > I think this can be done entirely in serial.c - serial_init_postirq() > would directly call any drivers that already got a handle parsed > for them, and serial_parse_handle() would need to call > ->init_postirq() for any driver that didn't have it called already. > serial_suspend() and serial_resume() should then call drivers only > if they previously had ->init_postirq() called. Ah yes, that would work. Feel free to make a patch. -- Keir > I definitely want to avoid putting any part of this into ns16550.c, > as it would need to be replicated for ARM's pl011.c as well as any > future ones (I'm now mostly done with an EHCI debug port driver, > but due to feature freeze won't be able to post this as other than > an RFC any time soon; xHCI appears to also have a debug port, > so in the future that might become a third alternative). > > Jan >