Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1532626 > unrolled thread

Re: [PATCH 1/1] ACPI: Document _OSI and _REV for Linux BIOS writers

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 1/1] ACPI: Document _OSI and _REV for Linux BIOS writers Len Brown <lenb@kernel.org> - 2016-11-29 19:10 +0100
    Re: [PATCH 1/1] ACPI: Document _OSI and _REV for Linux BIOS writers Lukas Wunner <lukas@wunner.de> - 2016-11-29 19:30 +0100

#1532626 — Re: [PATCH 1/1] ACPI: Document _OSI and _REV for Linux BIOS writers

On Tue, Nov 22, 2016 at 5:02 AM, Lukas Wunner <lukas@wunner.de> wrote:
> On Tue, Nov 22, 2016 at 12:29:46AM -0500, Len Brown wrote:
>> +On a platform tasked with running multiple versions of Windows,
>> +the BIOS could use _OS to enable/disable devices that and OS
>                                                            ^
>                                                            delete

Here I was trying to describe that the BIOS may enable or disable
devices and quirks based on the OS.  Yes, there are examples
of disabling in addition to enabling -- as sometimes there is a device
that may appear as different specific flavors of device based on the OS.
Are you  pointing out that I should use the word "or" instead of a '/'?

>> +_OSI("Darwin")
>> +--------------
>> +
>> +No description of _OSI would be complete without mentioning _OSI("Darwin").
>> +This string is mis-used by Apple on Mac platforms, just as Linux
>> +mis-used _OSI("Linux").
>> +
>> +Linux did not originally return TRUE to _OSI("Darwin"),
>> +on the assumption that on Apple hardware, Linux was
>> +probably best pretending to be Windows,
>> +rather than pretending to be OSX.
>> +
>> +But _OSI("Darwin") was required to make Thunderbolt work,
>> +and so Linux changed to enable it by default.  Making matters worse,
>> +that change did not include the ability to disable _OSI("Darwin")
>> +on the cmdline with acpi_OSI=!Darwin, and so the resulting
>> +regressions had no workaround.
>> +
>> +The cmdline has since been fixed to enable !Darwin.
>> +Today "Darwin" enables Thunderbolt, but significantly
>> +hurts battery life, and so the default for _OSI("Darwin")
>> +is still under debate.
>
> So first of all, I'm currently upstreaming a series which enables
> runtime PM for Thunderbolt on Macs.  Two series with prep work went
> into 4.9 and 4.10.  The final bits are slated for 4.11.
>
> IOW the whole "answering affirmative to Darwin hurts battery life"
> argument will be nonsensical and moot from 4.11 onwards.
>
> Link to the series:
> https://github.com/l1k/linux/commits/thunderbolt_runpm_v3
>
> All patches up to 3890c45 ("mfd: intel-lpss: Avoid resuming
> runtime-suspended lpss unnecessarily") are either already in
> mainline or queued up for it.

I'm delighted to learn this is in progress, as I'm sure,
is the entire community of users running Linux on Mac.

>
> Second, your description is incorrect in that Thunderbolt is only
> powered down in the non-Darwin case on Macs introduced before 2015.
> That's because they didn't support Thunderbolt on Windows (with
> BootCamp) on the older machines, so they powered the controller down
> and made it invisible to the OS.
>
> However on Macs introduced 2015+, they now seem to support Thunderbolt
> on Windows.  They seem to switch the controller between SMM-managed
> versus OS-managed mode based on the _OSI string.  In any case they no
> longer just power it down.
>
>
> Third, Apple uses _OSI("Darwin") not just for Thunderbolt, so the
> above description is incomplete.  They use it *generally* to
> distinguish between macOS versus Windows code paths in AML.
> (These are the only two OSes they care about.)
>
> E.g. on the 12" MacBook, which doesn't even have Thunderbolt, the
> _PS0 and _PS3 methods become no-ops in the non-Darwin case.
>
> Usually Apple only supports a subset of the hardware on Windows,
> so we have to pretend being Darwin to be afforded full access to
> the machine.
>
> One noteworthy issue with _OSI("Darwin") is that we have to respond
> negatively to all other vendor strings once it's encountered.
> See here for details:  http://mjg59.dreamwidth.org/29954.html
>

Great feedback!
Yes, I did a somewhat superficial job on the Darwin section.
I'll re-write it, incorporating your feedback, and send out an updated patch.

thanks,
Len Brown, Intel Open Source Technology Center

[toc] | [next] | [standalone]

#1532638

On Tue, Nov 29, 2016 at 01:07:55PM -0500, Len Brown wrote:
> On Tue, Nov 22, 2016 at 5:02 AM, Lukas Wunner <lukas@wunner.de> wrote:
> > On Tue, Nov 22, 2016 at 12:29:46AM -0500, Len Brown wrote:
> >> +On a platform tasked with running multiple versions of Windows,
> >> +the BIOS could use _OS to enable/disable devices that and OS
> >                                                            ^
> >                                                            delete
> 
> Here I was trying to describe that the BIOS may enable or disable
> devices and quirks based on the OS.  Yes, there are examples
> of disabling in addition to enabling -- as sometimes there is a device
> that may appear as different specific flavors of device based on the OS.
> Are you  pointing out that I should use the word "or" instead of a '/'?

I meant s/and/an/, so "devices that an OS", it looked like a typo to me.
Sorry for not making this clear enough.


> Great feedback!
> Yes, I did a somewhat superficial job on the Darwin section.
> I'll re-write it, incorporating your feedback, and send out an updated patch.

Great, thanks!

Lukas

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web