[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 10 Oct 2012 23:39:19 +0000
From: "Zheng, Lv" <lv.zheng@...el.com>
To: Konrad Rzeszutek Wilk <konrad@...nel.org>
CC: "Brown, Len" <len.brown@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Jason Wessel <jason.wessel@...driver.com>,
"Tang, Feng" <feng.tang@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
"platform-driver-x86@...r.kernel.org"
<platform-driver-x86@...r.kernel.org>
Subject: RE: [PATCH v6 1/2] ACPI: Add early console framework for DBGP/DBG2.
> > +static __initdata DECLARE_BITMAP(acpi_early_flags,
> > +MAX_ACPI_DBG_PORTS*2);
It's OK since the keep bit will be derived by the real earlycon drivers in the __acpi_early_console_start() which is an arch specific interface.
You can find this usage in the [PATCH v6 2/2].
> > + set_bit(port, acpi_early_flags);
> > + if (keep)
> > + set_bit(port+MAX_ACPI_DBG_PORTS, acpi_early_flags);
> Put a comment explaining why you use half of the bitmap to mark them as
> 'keep'. Thought wouldn't be just easier if you had another bitmap:
> acpi_keep_ports?
> To set those instead of using this bitmap?
I prefer to put comment here.
I've been a deep embedded engineer for the last 5 years, implementing software containing 4 bus protocol stacks within 128bytes ram and 16kbytes rom, where we used high modularity design patterns.
Thus made my habit being critical to ram/rom consumption...
I'm OOO now, the updated version will be sent next week.
Thanks for your comments and best regards/Lv Zheng
--
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