Date: Tue, 2 Nov 2010 19:23:35 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: Andriy Gapon <avg@freebsd.org> Cc: "Moore, Robert" <robert.moore@intel.com>, freebsd-acpi@freebsd.org, Lin Ming <ming.m.lin@intel.com> Subject: Re: MacBookPro 5,1 Message-ID: <201011021924.00552.jkim@FreeBSD.org> In-Reply-To: <4CD087A9.4000809@freebsd.org> References: <201010121209.06397.hselasky@c2i.net> <201011021650.22657.jkim@FreeBSD.org> <4CD087A9.4000809@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 02 November 2010 05:50 pm, Andriy Gapon wrote: > on 02/11/2010 22:50 Jung-uk Kim said the following: > > Yes, I understand. However, ACPICA is expecting the same size of > > buffer *including* the optional parts if I am reading the code > > right. > > Hmm, where is ACPICA doing that? If you scrub ResourceSource, then: AcpiSetCurrentResources() -> AcpiRsSetSrsMethodData() -> AcpiRsCreateAmlResources() -> AcpiRsGetAmlLength() -> AcpiRsStructOptionLength() will return 0 and size of new buffer may be smaller than what we got from _CRS. I may have read it wrong, though. :-/ > I didn't see any connection between what *ACPICA* can return to OS > in _CRS/_PRS and what OS can pass in _SRS. > > > Besides, I don't think there is any harm in doing the right > > thing. ;-) > > I don't think that this is any "righter" than zero-ing out resource > source description string. BIOS/firmware can't possibly use that > for anything meaningful, IMO. I didn't say it is ever useful. My point was it may not work for some BIOS but I am not sure, that's all. Jung-uk Kim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201011021924.00552.jkim>