Messages in this thread | | | Date | Thu, 05 Mar 2015 19:26:19 +0800 | From | "Li, Aubrey" <> | Subject | Re: [PATCH] x86: Bypass legacy PIC and PIT on ACPI hardware reduced platform |
| |
On 2015/3/5 5:52, Rafael J. Wysocki wrote: > On Wednesday, March 04, 2015 08:21:01 PM Alan Cox wrote: >> On Wed, 2015-03-04 at 15:05 +0100, Borislav Petkov wrote: >>> On Wed, Mar 04, 2015 at 03:16:07PM +0100, Rafael J. Wysocki wrote: >>>> Sort of. What we need is a "do not touch PIC/PIT" bit for the code that >>>> tries to fall back to them in some cases (which may appear to work if >>>> the hardware is physically there, but it may confuse the platform). >>> >>> Can "some cases" detection be nicely put into a x86_platform >>> platform-specific method? >> >> In some cases they don't belong in x86, ACPI is also used for ARM64. >> >> However >> >> if ( has_8259_pic() ) >> >> is trivally 0, 1 or some platform or acpi provided method. > > And which is how that should have been implemented to start with IMO. > > Besides, the "ACPI reduced hardware" case is kind of a red herring here, > because it most likely is not the only case when we'll want has_8259_pic() > to return 0 (quite likely, we'll want that on all BayTrail-based systems, > for example). > BayTrail-based systems has BayTrail-I, BayTrail-M, BayTrail-D, BayTrail-T, BayTrail-T/CR. BayTrail-D is a desktop and BayTrail-M is a mobile/laptop and 8259 exists on both systems and I don't think we want to bypass it.
ACPI reduced hardware is the best case in my mind unless you want to enumerate the platform one by one. can we make a global variable
u8 has_8259;
and initialize it by acpi reduced hardware flag? or a wrapper function?
Thanks, -Aubrey
| |