Interesting point about ACPICA throwing an exception when there is no
handler. The spec (6.0) says this:
"When an operation region handler is unavailable, AML cannot access
data fields in that region. (Operation region writes will be ignored
and reads will return indeterminate data.)."
If unavailable reads just returned 0, this code would all work. I have
no idea when this field would ever be set. I don't know if Windows
Installer has particular bytes it sets in the CMOS.
Perhaps Windows is just returning 0 on read. Why does ACPICA throw an exception?
Here is the relevant device and _INI disassembly, with most things
elided. OSDW is a method that determines if the OS is Darwin.
\_SB.PCI0.LPCB.RTC.ISWI is the field of interest. I have not elided
any of these RTC references. On unpatched ACPICA/Linux (when Darwin
mode is disabled), the first Debug = \_SB.PCI0.LPCB.RTC.ISWI fails.
.....
Device (RTC)
{
Name (_HID, EisaId ("PNP0B00") /* AT Real-Time
Clock */) // _HID: Hardware ID
Name (_CRS, ResourceTemplate () // _CRS: Current
Resource Settings
{
IO (Decode16,
0x0070, // Range Minimum
0x0070, // Range Maximum
0x01, // Alignment
0x08, // Length
)
})
OperationRegion (CMS0, SystemCMOS, 0x00, 0x40)
Field (CMS0, ByteAcc, NoLock, Preserve)
{
Offset (0x38),
ISTB, 1,
, 2,
ISWI, 1,
Offset (0x39)
}
}
.....
Scope (\_SB.PCI0)
{
Method (_INI, 0, NotSerialized) // _INI: Initialize
{
..... [elided]
Debug = \_SB.PCI0.LPCB.RTC.ISWI
If (!OSDW ())
{
If ((OSYS >= 0x07DC))
{
Debug = "Save Ridge Config on Boot"
..... [thunderbolt init code elided]
If ((\_SB.PCI0.LPCB.RTC.ISWI != 0x01))
{
Debug = "Enable ICM on Boot"
..... [more init code elided]
}
Else
{
Debug = "Windows Installation"
}
..... [more code elided]
Debug = "Enable ICM on Boot, Complete"
}
}
On Wed, May 20, 2015 at 1:24 PM, Moore, Robert <robert.moore@xxxxxxxxx> wrote:
> Another possibility is that Windows just *ignores* a CMOS access from the _INI before it gets a real CMOS driver installed. We've seen similar before.
>
> Could you please post the disassembled _INI method, or the binary DSDT where it came from?
> Thanks.
>
>> -----Original Message-----
>> From: Devel [mailto:devel-bounces@xxxxxxxxxx] On Behalf Of Moore, Robert
>> Sent: Wednesday, May 20, 2015 10:17 AM
>> To: Adam Goode
>> Cc: Lan, Tianyu; linux-acpi@xxxxxxxxxxxxxxx; Box, David E;
>> devel@xxxxxxxxxx
>> Subject: Re: [Devel] Correct place to send patches?
>>
>> ACPICA does in fact try to bug-for-bug compatible with Windows.
>>
>> The trick is to figure out just *how* Windows works in these cases.
>>
>> I might guess that a solution may be that a "default handler" for the CMOS
>> operation region should be installed immediately at boot time. If and when
>> this handler is first run, it should figure out which CMOS device is
>> present on the system and then install the "real" handler for the device.
>> Or, if you want to support only one CMOS device, just install the region
>> handler at boot time and be done with it.
>>
>>
>>
>> > -----Original Message-----
>> > From: Adam Goode [mailto:agoode@xxxxxxxxxx]
>> > Sent: Wednesday, May 20, 2015 10:11 AM
>> > To: Moore, Robert
>> > Cc: Zheng, Lv; Lan, Tianyu; linux-acpi@xxxxxxxxxxxxxxx;
>> > devel@xxxxxxxxxx; Box, David E
>> > Subject: Re: [Devel] Correct place to send patches?
>> >
>> > Yes, it really looks like a bug in the firmware. Still, Windows works
>> > correctly without any special support.
>> >
>> > What is the policy for ACPICA in this case where Windows works in a
>> > spec- violating way?
>> >
>> >
>> > Adam
>> >
>> >
>> > On Wed, May 20, 2015 at 1:07 PM, Moore, Robert
>> > <robert.moore@xxxxxxxxx>
>> > wrote:
>> > > Then perhaps this is where the machine is violating the ACPI
>> > specification:
>> > >
>> > >
>> > > 6.5.1 _INI (Init)
>> > >
>> > > The _INI method must only access Operation Regions that have been
>> > indicated to be available as defined by the _REG method.
>> > >
>> > >
>> > >
>> > >
>> > >> -----Original Message-----
>> > >> From: Adam Goode [mailto:agoode@xxxxxxxxxx]
>> > >> Sent: Wednesday, May 20, 2015 9:56 AM
>> > >> To: Moore, Robert
>> > >> Cc: Zheng, Lv; Lan, Tianyu; linux-acpi@xxxxxxxxxxxxxxx;
>> > >> devel@xxxxxxxxxx
>> > >> Subject: Re: [Devel] Correct place to send patches?
>> > >>
>> > >> No, I did not see a _REG method defined in the code.
>> > >>
>> > >>
>> > >> Adam
>> > >>
>> > >>
>> > >> On Wed, May 20, 2015 at 12:46 PM, Moore, Robert
>> > >> <robert.moore@xxxxxxxxx>
>> > >> wrote:
>> > >> > Does the CMOS operation region have a _REG method?
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> > From: Zheng, Lv
>> > >> > Sent: Tuesday, May 19, 2015 11:03 PM
>> > >> > To: Zheng, Lv; Moore, Robert; Adam Goode; Lan, Tianyu
>> > >> > Cc: linux-acpi@xxxxxxxxxxxxxxx; devel@xxxxxxxxxx
>> > >> >
>> > >> >
>> > >> > Subject: RE: [Devel] Correct place to send patches?
>> > >> >
>> > >> >
>> > >> >
>> > >> > Since no reply from Tianyu…
>> > >> >
>> > >> > What if we move _INI invocation out of ACPICA, and let OSPM to
>> > >> > invoke
>> > >> it.
>> > >> >
>> > >> >
>> > >> >
>> > >> > Thanks
>> > >> >
>> > >> > -Lv
>> > >> >
>> > >> >
>> > >> >
>> > >> > From: Devel [mailto:devel-bounces@xxxxxxxxxx] On Behalf Of Zheng,
>> > >> > Lv
>> > >> > Sent: Thursday, May 14, 2015 8:33 AM
>> > >> > To: Moore, Robert; Adam Goode; Lan, Tianyu
>> > >> > Cc: linux-acpi@xxxxxxxxxxxxxxx; devel@xxxxxxxxxx
>> > >> > Subject: Re: [Devel] Correct place to send patches?
>> > >> >
>> > >> >
>> > >> >
>> > >> > You should discuss this in the linux-acpi mailing list where the
>> > >> > Linux CMOS opregion driver is implemented, reviewed, and merged.
>> > >> >
>> > >> > Let me Cc Tianyu who is the original author of the CMOS opregion
>> > driver.
>> > >> >
>> > >> >
>> > >> >
>> > >> > Thanks
>> > >> >
>> > >> > -Lv
>> > >> >
>> > >> >
>> > >> >
>> > >> > From: Moore, Robert
>> > >> > Sent: Wednesday, May 13, 2015 10:25 PM
>> > >> > To: Adam Goode; Zheng, Lv
>> > >> > Cc: devel@xxxxxxxxxx
>> > >> > Subject: RE: [Devel] Correct place to send patches?
>> > >> >
>> > >> >
>> > >> >
>> > >> > I’ll have to let Lv answer this question.
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> > From: Adam Goode [mailto:agoode@xxxxxxxxxx]
>> > >> > Sent: Wednesday, May 13, 2015 7:23 AM
>> > >> > To: Moore, Robert
>> > >> > Cc: devel@xxxxxxxxxx
>> > >> > Subject: Re: [Devel] Correct place to send patches?
>> > >> >
>> > >> >
>> > >> >
>> > >> > The problem is that on new Apple hardware (Macmini7,1 and
>> > >> > others), the system reads and writes from CMOS in _INI. With no
>> > >> > CMOS handler, the Thunderbolt device doesn't initialize correctly.
>> > >> >
>> > >> >
>> > >> >
>> > >> > The current framework in Linux doesn't register the PNP* CMOS
>> > >> > devices until after _INI runs. Do you have a suggestion on what
>> > >> > to do in this case? Is it possible to register a device driver
>> > >> > before
>> > _INI runs?
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> > Thanks,
>> > >> >
>> > >> >
>> > >> >
>> > >> > Adam
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> > On Wed, May 13, 2015 at 4:07 PM, Moore, Robert
>> > >> > <robert.moore@xxxxxxxxx>
>> > >> > wrote:
>> > >> >
>> > >> > Actually, I had a question about this.
>> > >> >
>> > >> >
>> > >> >
>> > >> > Given that the CMOS device has a _HID and requires a device
>> > >> > driver (there can be multiple types of CMOS devices), in ACPICA
>> > >> > we decided that we could not provide CMOS interfaces.
>> > >> >
>> > >> >
>> > >> >
>> > >> > What problem does this patch solve, and how will it work in the
>> > >> > face of different CMOS devices?
>> > >> >
>> > >> >
>> > >> >
>> > >> > Thanks,
>> > >> >
>> > >> > Bob
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> > From: Devel [mailto:devel-bounces@xxxxxxxxxx] On Behalf Of Adam
>> > >> > Goode
>> > >> > Sent: Wednesday, May 13, 2015 4:53 AM
>> > >> > To: devel@xxxxxxxxxx
>> > >> > Subject: [Devel] Correct place to send patches?
>> > >> >
>> > >> >
>> > >> >
>> > >> > Hi,
>> > >> >
>> > >> >
>> > >> >
>> > >> > Is this the correct place to send patches for review? I have a
>> > >> > patch from a few weeks ago
>> > >> > (https://lists.acpica.org/pipermail/devel/2015-May/000698.html)
>> > >> > that I would like feedback on.
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> > Thanks,
>> > >> >
>> > >> >
>> > >> >
>> > >> > Adam
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> _______________________________________________
>> Devel mailing list
>> Devel@xxxxxxxxxx
>> https://lists.acpica.org/mailman/listinfo/devel
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
