From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mika Westerberg Subject: Re: [PATCH v2 2/4] ACPI / property: Support Apple _DSM properties Date: Thu, 29 Jun 2017 10:45:38 +0300 Message-ID: <20170629074538.GA629@lahna.fi.intel.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Rafael J. Wysocki" , Mark Brown , Ronald Tschalaer , Federico Lorenzi , Andy Shevchenko , Leif Liddy , Daniel Roschka , linux-acpi@vger.kernel.org, linux-spi@vger.kernel.org To: Lukas Wunner Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-spi.vger.kernel.org On Wed, Jun 28, 2017 at 07:20:19PM +0200, Lukas Wunner wrote: > While the rest of the world has standardized on _DSD as the way to store > device properties in AML (introduced with ACPI 5.1 in 2014), Apple has > been using a custom _DSM to achieve the same for much longer (ever since > they switched from DeviceTree-based PowerPC to Intel in 2005, verified > with MacOS X 10.4.11). > > The theory of operation on macOS is as follows: AppleACPIPlatform.kext > invokes mergeEFIproperties() and mergeDSMproperties() for each device to > merge properties conveyed by EFI drivers as well as properties stored in > AML into the I/O Kit registry from which they can be retrieved by > drivers. We've been supporting EFI properties since commit 58c5475aba67 > ("x86/efi: Retrieve and assign Apple device properties"). The present > commit adds support for _DSM properties, thereby completing our support > for Apple device properties. The _DSM properties are made available > under the primary fwnode, the EFI properties under the secondary fwnode. > So for devices which possess both property types, they can all be > elegantly accessed with the uniform API in . > > Until recently we had no need to support _DSM properties, they contained > only uninteresting garbage. The situation has changed with MacBooks and > MacBook Pros introduced since 2015: Their keyboard is attached with SPI > instead of USB and the _CRS data which is necessary to initialize the > spi driver only contains valid information if OSPM responds "false" to > _OSI("Darwin"). If OSPM responds "true", _CRS is empty and the spi > driver fails to initialize. The rationale is very simple, Apple only > cares about macOS and Windows: On Windows, _CRS contains valid data, > whereas on macOS it is empty. Instead, macOS gleans the necessary data > from the _DSM properties. > > Since Linux deliberately defaults to responding "true" to _OSI("Darwin"), > we need to emulate macOS' behaviour by initializing the spi driver with > data returned by the _DSM. > > An out-of-tree driver for the SPI keyboard exists which currently binds > to the ACPI device, invokes the _DSM, parses the returned package and > instantiates an SPI device with the data gleaned from the _DSM: > https://github.com/cb22/macbook12-spi-driver/commit/9a416d699ef4 > https://github.com/cb22/macbook12-spi-driver/commit/0c34936ed9a1 > > By adding support for Apple's _DSM properties in generic ACPI code, the > out-of-tree driver will be able to register as a regular SPI device, > significantly reducing its amount of code and improving its chances to > be mainlined. > > The SPI keyboard will not be the only user of this commit: E.g. on the > MacBook8,1, the UART-attached Bluetooth device likewise returns empty > _CRS data if OSPM returns "true" to _OSI("Darwin"). > > The _DSM returns a Package whose format unfortunately deviates slightly > from the _DSD spec: The properties are marshalled up in a single Package > as alternating key/value elements, unlike _DSD which stores them as a > Package of 2-element Packages. The present commit therefore converts > the Package to _DSD format and the ACPI core can then treat the data as > if Apple would follow the standard. > > Well, except for one small annoyance: The properties returned by the > _DSM only ever have one of two types, Integer or Buffer. The former is > retrievable as usual with device_property_read_u64(), but the latter is > not part of the _DSD spec and it is not possible to retrieve Buffer > properties with the device_property_read_*() functions due to the type > checking performed in drivers/acpi/property.c. It is however possible > to retrieve them with acpi_dev_get_property(). Apple is using the > Buffer type somewhat sloppily to store null-terminated strings but also > integers. The real data type is not distinguishable by the ACPI core > and the onus is on the caller to use the contents of the Buffer in an > appropriate way. > > In case Apple moves to _DSD in the future, this commit first checks for > _DSD and falls back to _DSM only if _DSD is not found. > > Cc: Rafael J. Wysocki > Cc: Mika Westerberg Andy had some comments which I think you should consider. Regardless of that this looks good to me. Also I have one of those new Macs with SPI connected keyboard so happy to see the support getting into mainline ;-) Acked-by: Mika Westerberg