06 Aug, 2020
1 commit
-
Pull block driver updates from Jens Axboe:
- NVMe:
- ZNS support (Aravind, Keith, Matias, Niklas)
- Misc cleanups, optimizations, fixes (Baolin, Chaitanya, David,
Dongli, Max, Sagi)- null_blk zone capacity support (Aravind)
- MD:
- raid5/6 fixes (ChangSyun)
- Warning fixes (Damien)
- raid5 stripe fixes (Guoqing, Song, Yufen)
- sysfs deadlock fix (Junxiao)
- raid10 deadlock fix (Vitaly)- struct_size conversions (Gustavo)
- Set of bcache updates/fixes (Coly)
* tag 'for-5.9/drivers-20200803' of git://git.kernel.dk/linux-block: (117 commits)
md/raid5: Allow degraded raid6 to do rmw
md/raid5: Fix Force reconstruct-write io stuck in degraded raid5
raid5: don't duplicate code for different paths in handle_stripe
raid5-cache: hold spinlock instead of mutex in r5c_journal_mode_show
md: print errno in super_written
md/raid5: remove the redundant setting of STRIPE_HANDLE
md: register new md sysfs file 'uuid' read-only
md: fix max sectors calculation for super 1.0
nvme-loop: remove extra variable in create ctrl
nvme-loop: set ctrl state connecting after init
nvme-multipath: do not fall back to __nvme_find_path() for non-optimized paths
nvme-multipath: fix logic for non-optimized paths
nvme-rdma: fix controller reset hang during traffic
nvme-tcp: fix controller reset hang during traffic
nvmet: introduce the passthru Kconfig option
nvmet: introduce the passthru configfs interface
nvmet: Add passthru enable/disable helpers
nvmet: add passthru code to process commands
nvme: export nvme_find_get_ns() and nvme_put_ns()
nvme: introduce nvme_ctrl_get_by_path()
...
29 Jul, 2020
1 commit
-
This patch implements a solution for a BIOS hack used on some currently
shipping Intel systems to change driver power management policy for PCIe
NVMe drives. Some newer Intel platforms, like some Comet Lake systems,
require that PCIe devices use D3 when doing suspend-to-idle in order to
allow the platform to realize maximum power savings. This is particularly
needed to support ATX power supply shutdown on desktop systems. In order to
ensure this happens for root ports with storage devices, Microsoft
apparently created this ACPI _DSD property as a way to influence their
driver policy. To my knowledge this property has not been discussed with
the NVME specification body.Though the solution is not ideal, it addresses a problem that also affects
Linux since the NVMe driver's default policy of using NVMe APST during
suspend-to-idle prevents the PCI root port from going to D3 and leads to
higher power consumption for these platforms. The power consumption
difference may be negligible on laptop systems, but many watts on desktop
systems when the ATX power supply is blocked from powering down.The patch creates a new nvme_acpi_storage_d3 function to check for the
StorageD3Enable property during probe and enables D3 as a quirk if set. It
also provides a 'noacpi' module parameter to allow skipping the quirk if
needed.Tested with:
- PM961 NVMe SED Samsung 512GB
- INTEL SSDPEKKF512G8Link: https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/power-management-for-storage-hardware-devices-intro
Signed-off-by: David E. Box
Reviewed-by: Rafael J. Wysocki
Signed-off-by: Christoph Hellwig
22 Jun, 2020
1 commit
-
There is no need to re-evaluate the object name.
Signed-off-by: Heikki Krogerus
Signed-off-by: Rafael J. Wysocki
11 Oct, 2019
2 commits
-
The prefix is used for printing purpose before a node, and it also works
as a separator between two nodes.Signed-off-by: Sakari Ailus
Acked-by: Rob Herring (for OF)
Reviewed-by: Andy Shevchenko
Signed-off-by: Rafael J. Wysocki -
The fwnode framework did not have means to obtain the name of a node. Add
that now, in form of the fwnode_get_name() function and a corresponding
get_name fwnode op. OF and ACPI support is included.Signed-off-by: Sakari Ailus
Acked-by: Rob Herring (for OF)
Reviewed-by: Andy Shevchenko
Signed-off-by: Rafael J. Wysocki
19 Sep, 2019
1 commit
-
Pull char/misc driver updates from Greg KH:
"Here is the big char/misc driver pull request for 5.4-rc1.As has been happening in previous releases, more and more individual
driver subsystem trees are ending up in here. Now if that is good or
bad I can't tell, but hopefully it makes your life easier as it's more
of an aggregation of trees together to one merge point for you.Anyway, lots of stuff in here:
- habanalabs driver updates
- thunderbolt driver updates
- misc driver updates
- coresight and intel_th hwtracing driver updates
- fpga driver updates
- extcon driver updates
- some dma driver updates
- char driver updates
- android binder driver updates
- nvmem driver updates
- phy driver updates
- parport driver fixes
- pcmcia driver fix
- uio driver updates
- w1 driver updates
- configfs fixes
- other assorted driver updatesAll of these have been in linux-next for a long time with no reported
issues"* tag 'char-misc-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (200 commits)
misc: mic: Use PTR_ERR_OR_ZERO rather than its implementation
habanalabs: correctly cast variable to __le32
habanalabs: show correct id in error print
habanalabs: stop using the acronym KMD
habanalabs: display card name as sensors header
habanalabs: add uapi to retrieve aggregate H/W events
habanalabs: add uapi to retrieve device utilization
habanalabs: Make the Coresight timestamp perpetual
habanalabs: explicitly set the queue-id enumerated numbers
habanalabs: print to kernel log when reset is finished
habanalabs: replace __le32_to_cpu with le32_to_cpu
habanalabs: replace __cpu_to_le32/64 with cpu_to_le32/64
habanalabs: Handle HW_IP_INFO if device disabled or in reset
habanalabs: Expose devices after initialization is done
habanalabs: improve security in Debug IOCTL
habanalabs: use default structure for user input in Debug IOCTL
habanalabs: Add descriptive name to PSOC app status register
habanalabs: Add descriptive names to PSOC scratch-pad registers
habanalabs: create two char devices per ASIC
habanalabs: change device_setup_cdev() to be more generic
...
03 Sep, 2019
1 commit
-
The function is called acpi_graph_get_remote_endpoint(), not
acpi_graph_get_remote_enpoint().Fixes: 79389a83bc3888a9 ("ACPI / property: Add support for remote endpoints")
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Rafael J. Wysocki
26 Aug, 2019
1 commit
-
Ice Lake Thunderbolt controller includes two new device property
compatible properties that we need to be able to extract in the driver
so add them to the growing array of GUIDs.Signed-off-by: Mika Westerberg
Acked-by: Rafael J. Wysocki
10 Jul, 2019
1 commit
-
Pull device properties framework updates from Rafael Wysocki:
"These add helpers for counting items in a property array and extend
the "software nodes" support to be more convenient for representing
device properties supplied by drivers and make the intel_cht_int33fe
driver use that.Specifics:
- Add helpers to count items in a property array (Andy Shevchenko).
- Extend "software nodes" support to be more convenient for
representing device properties supplied by drivers (Heikki
Krogerus).- Add device_find_child_by_name() helper to the driver core (Heikki
Krogerus).- Extend device connection code to also look for references provided
via fwnode pointers (Heikki Krogerus).- Start to register proper struct device objects for USB Type-C muxes
and orientation switches (Heikki Krogerus).- Update the intel_cht_int33fe driver to describe devices in a more
general way with the help of "software nodes" (Heikki Krogerus)"* tag 'devprop-5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
device property: Add helpers to count items in an array
platform/x86: intel_cht_int33fe: Replacing the old connections with references
platform/x86: intel_cht_int33fe: Supply fwnodes for the external dependencies
platform/x86: intel_cht_int33fe: Provide fwnode for the USB connector
platform/x86: intel_cht_int33fe: Provide software nodes for the devices
platform/x86: intel_cht_int33fe: Remove unused fusb302 device property
platform/x86: intel_cht_int33fe: Register max17047 in its own function
usb: typec: Registering real device entries for the muxes
device connection: Find connections also by checking the references
device property: Introduce fwnode_find_reference()
ACPI / property: Don't limit named child node matching to data nodes
driver core: Add helper device_find_child_by_name()
software node: Add software_node_get_reference_args()
software node: Use kobject name when finding child nodes by name
software node: Add support for static node descriptors
software node: Simplify software_node_release() function
software node: Allow node creation without properties
19 Jun, 2019
1 commit
-
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundationthis program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Enrico Weigelt
Reviewed-by: Kate Stewart
Reviewed-by: Allison Randal
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman
03 Jun, 2019
1 commit
-
There is no reason why we should limit the use of
fwnode_get_named_child_node() to data nodes only.Signed-off-by: Heikki Krogerus
Tested-by: Hans de Goede
Signed-off-by: Rafael J. Wysocki
01 May, 2019
1 commit
-
When the DSDT tables expose devices with subdevices and a set of
hierarchical _DSD properties, the data returned by
acpi_get_next_subnode() is incorrect, with the results suggesting a bad
pointer assignment. The parser works fine with device_nodes or
data_nodes, but not with a combination of the two.The problem is traced to an invalid pointer used when jumping from
handling device_nodes to data nodes. The existing code looks for data
nodes below the last subdevice found instead of the common root. Fix
by forcing the acpi_device pointer to be derived from the same fwnode
for the two types of subnodes.This same problem of handling device and data nodes was already fixed
in a similar way by 'commit bf4703fdd166 ("ACPI / property: fix data
node parsing in acpi_get_next_subnode()")' but broken later by 'commit
34055190b19 ("ACPI / property: Add fwnode_get_next_child_node()")', so
this should probably go to linux-stable all the way to 4.12Signed-off-by: Pierre-Louis Bossart
Reviewed-by: Andy Shevchenko
Signed-off-by: Rafael J. Wysocki
17 Apr, 2019
1 commit
-
Commit 5f5e4890d57a ("ACPI / property: Allow multiple property
compatible _DSD entries") removed the comment of _DSD data subnodes
GUID. Restore it.Fixes: 5f5e4890d57a ("ACPI / property: Allow multiple property compatible _DSD entries")
Signed-off-by: Shunyong Yang
Signed-off-by: Rafael J. Wysocki
05 Dec, 2018
1 commit
-
A malicious PCI device may use DMA to attack the system. An external
Thunderbolt port is a convenient point to attach such a device. The OS
may use IOMMU to defend against DMA attacks.Some BIOSes mark these externally facing root ports with this
ACPI _DSD [1]:Name (_DSD, Package () {
ToUUID ("efcc06cc-73ac-4bc3-bff0-76143807c389"),
Package () {
Package () {"ExternalFacingPort", 1},
Package () {"UID", 0 }
}
})If we find such a root port, mark it and all its children as untrusted.
The rest of the OS may use this information to enable DMA protection
against malicious devices. For instance the device may be put behind an
IOMMU to keep it from accessing memory outside of what the driver has
allocated for it.While at it, add a comment on top of prp_guids array explaining the
possible caveat resulting when these GUIDs are treated equivalent.[1] https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-externally-exposed-pcie-root-ports
Signed-off-by: Mika Westerberg
Acked-by: Rafael J. Wysocki
Acked-by: Bjorn Helgaas
03 Oct, 2018
2 commits
-
In order to have better power management for Thunderbolt PCIe chains,
Windows enables power management for native PCIe hotplug ports if there is
the following ACPI _DSD attached to the root port:Name (_DSD, Package () {
ToUUID ("6211e2c0-58a3-4af3-90e1-927a4e0c55a4"),
Package () {
Package () {"HotPlugSupportInD3", 1}
}
})This is also documented in:
https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports#identifying-pcie-root-ports-supporting-hot-plug-in-d3
Do the same in Linux by introducing new firmware PM callback
(->bridge_d3()) and then implement it for ACPI based systems so that the
above property is checked.There is one catch, though. The initial pci_dev->bridge_d3 is set before
the root port has ACPI companion bound (the device is not added to the PCI
bus either) so we need to look up the ACPI companion manually in that case
in acpi_pci_bridge_d3().Signed-off-by: Mika Westerberg
Signed-off-by: Bjorn Helgaas
Reviewed-by: Rafael J. Wysocki -
It is possible to have _DSD entries where the data is compatible with
device properties format but are using different GUID for various reasons.
In addition to that there can be many such _DSD entries for a single device
such as for PCIe root port used to host a Thunderbolt hierarchy:Scope (\_SB.PCI0.RP21)
{
Name (_DSD, Package () {
ToUUID ("6211e2c0-58a3-4af3-90e1-927a4e0c55a4"),
Package () {
Package () {"HotPlugSupportInD3", 1}
},ToUUID ("efcc06cc-73ac-4bc3-bff0-76143807c389"),
Package () {
Package () {"ExternalFacingPort", 1},
Package () {"UID", 0 }
}
})
}More information about these new _DSD entries can be found in:
https://docs.microsoft.com/en-us/windows-hardware/drivers/pci/dsd-for-pcie-root-ports
To make these available for drivers via unified device property APIs,
modify ACPI property core so that it supports multiple _DSD entries
organized in a linked list. We also store GUID of each _DSD entry in struct
acpi_device_properties in case there is need to differentiate between
entries. The supported GUIDs are then listed in prp_guids array.Signed-off-by: Mika Westerberg
Signed-off-by: Bjorn Helgaas
Reviewed-by: Rafael J. Wysocki
Acked-by: Sakari Ailus
23 Jul, 2018
5 commits
-
Instead of using the port and endpoint properties, rely on the names of
the port and endpoint nodes as well as the reg property, as on DT.Signed-off-by: Sakari Ailus
Signed-off-by: Rafael J. Wysocki -
By using device and further data node references, allow direct references
to endpoints. These are of formPackage() { \DEV, "portX", "endpointY" }
where X is the number of the port and Y is the number of the endpoint.
Signed-off-by: Sakari Ailus
Signed-off-by: Rafael J. Wysocki -
The fwnode graph API is preferred over the ACPI graph API. Therefore
make the ACPI graph API private, and use it as a back-end for the
fwnode graph API only.Unused functionality is removed while the functionality actually used
remains the same.Signed-off-by: Sakari Ailus
Signed-off-by: Rafael J. Wysocki -
Implement references to non-device nodes using the first package
entry in the hierarchical data extension reference, the second one
being the name of the referred object.The data node references are parsed just after the device arguments
before the integer arguments. If there are no strings after the
device arguments, the parsing works exactly as it used to be.Referring to a data node called "node" under device DEV, with
integer arguments 0, 2 would thus look like:Package() { DEV, "node", 0, 2 }
Signed-off-by: Sakari Ailus
Signed-off-by: Rafael J. Wysocki -
Convert all users of struct acpi_reference_args to more generic
fwnode_reference_args. This will1) avoid an ACPI specific references to device nodes with integer
arguments as well as2) allow making references to nodes other than device nodes in ACPI.
As a by-product, convert the fwnode interger arguments to u64. The
arguments were 64-bit integers on ACPI but the fwnode arguments were
just 32-bit.Signed-off-by: Sakari Ailus
Signed-off-by: Rafael J. Wysocki
12 Feb, 2018
2 commits
-
Constify device_get_match_data() as OF and ACPI variants return
constant value.Acked-by: Sakari Ailus
Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki -
Do the renaming to be consistent with its sibling, i.e.
of_device_get_match_data().No functional change.
Signed-off-by: Andy Shevchenko
Reviewed-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki
13 Dec, 2017
1 commit
-
Now that we have a get_match_data() callback as part of the firmware node,
implement the ACPI specific piece for it.Signed-off-by: Sinan Kaya
Acked-by: Sakari Ailus
Signed-off-by: Vinod Koul
12 Oct, 2017
2 commits
-
Fix more return codes for device property: Align return codes of
__acpi_node_get_property_reference().In particular, what was missed previously:
-EPROTO could be returned in certain cases, now -EINVAL;
-EINVAL was returned if the property was not found, now -ENOENT;
-EINVAL was returned also if the index was higher than the number of
entries in a package, now -ENOENT.Reported-by: Hyungwoo Yang
Fixes: 3e3119d3088f (device property: Introduce fwnode_property_get_reference_args)
Signed-off-by: Sakari Ailus
Tested-by: Hyungwoo Yang
Signed-off-by: Rafael J. Wysocki -
acpi_fwnode_get_reference_args(), the function implementing ACPI
support for fwnode_property_get_reference_args(), returns directly
error codes from __acpi_node_get_property_reference(). The latter
uses different error codes than the OF implementation. In particular,
the OF implementation uses -ENOENT to indicate that the property is
not found, a reference entry is empty and there are no more
references.Document and align the error codes for property for
fwnode_property_get_reference_args() so that they match with
of_parse_phandle_with_args().Fixes: 3e3119d3088f (device property: Introduce fwnode_property_get_reference_args)
Signed-off-by: Sakari Ailus
Signed-off-by: Rafael J. Wysocki
23 Sep, 2017
1 commit
-
* acpi-pmic:
ACPI / PMIC: Add code reviewers to MAINTAINERS* acpi-bus:
ACPI / bus: Make ACPI_HANDLE() work for non-GPL code again* acpi-wdat:
ACPI / watchdog: properly initialize resources* acpi-properties:
ACPI: properties: Return _DSD hierarchical extension (data) sub-nodes correctly
20 Sep, 2017
2 commits
-
The recently merged patch "ACPI: Prepare for constifying
acpi_get_next_subnode() fwnode argument" was part of a patchset
constifying the fwnode arguments across the fwnode property API. The
purpose of the patch was to allow returning non-const fwnodes from a data
structure the root of which is const.Unfortunately the patch introduced the functionality, in particular when
starting parsed from an ACPI device node, the hierarchical data extension
nodes would not be enumerated.Restore the old behaviour while still retaining constness properties of
the patch.Fixes: 01c1da289791 "ACPI: Prepare for constifying acpi_get_next_subnode() fwnode argument"
Signed-off-by: Sakari Ailus
Acked-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki -
Due to commit db3e50f3234b (device property: Get rid of struct
fwnode_handle type field), ACPI_HANDLE() inadvertently became
a GPL-only call. The call path that led to that was:ACPI_HANDLE()
ACPI_COMPANION()
to_acpi_device_node()
is_acpi_device_node()
acpi_device_fwnode_ops
DECLARE_ACPI_FWNODE_OPS(acpi_device_fwnode_ops);...and the new DECLARE_ACPI_FWNODE_OPS() includes
EXPORT_SYMBOL_GPL, whereas previously it was a static struct.In order to avoid changing any of that, let's instead provide ever
so slightly better encapsulation of those struct fwnode_operations
instances. Those do not really need to be directly used in
inline function calls in header files. Simply moving two small
functions (is_acpi_device_node and is_acpi_data_node) out of
acpi_bus.h, and into a .c file, does that.That leaves the internals of struct fwnode_operations as GPL-only
(which I think was the intent all along), but un-breaks any driver
code out there that relies on the ACPI subsystem's being (historically)
an EXPORT_SYMBOL-usable system. By that, I mean, ACPI_HANDLE() and
other basic ACPI calls were non-GPL-protected.Also, while I'm there, remove a tiny bit of redundancy that was missed
in the earlier commit, by having is_acpi_node() use the other two
routines, instead of checking fwnode directly.Fixes: db3e50f3234b (device property: Get rid of struct fwnode_handle type field)
Signed-off-by: John Hubbard
Acked-by: Sakari Ailus
Acked-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki
06 Sep, 2017
1 commit
-
Pull device properties framework updates from Rafael Wysocki:
"These introduce fwnode operations for all of the separate types of
'firmware nodes' that can be handled by the device properties
framework, make the framework use const fwnode arguments all over, add
a helper for the consolidated handling of node references and switch
over the framework to the new UUID API.Specifics:
- Introduce fwnode operations for all of the separate types of
'firmware nodes' that can be handled by the device properties
framework and drop the type field from struct fwnode_handle (Sakari
Ailus, Arnd Bergmann).- Make the device properties framework use const fwnode arguments
where possible (Sakari Ailus).- Add a helper for the consolidated handling of node references to
the device properties framework (Sakari Ailus).- Switch over the ACPI part of the device properties framework to the
new UUID API (Andy Shevchenko)"* tag 'devprop-4.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: device property: Switch to use new generic UUID API
device property: export irqchip_fwnode_ops
device property: Introduce fwnode_property_get_reference_args
device property: Constify fwnode property API
device property: Constify argument to pset fwnode backend
ACPI: Constify internal fwnode arguments
ACPI: Constify acpi_bus helper functions, switch to macros
ACPI: Prepare for constifying acpi_get_next_subnode() fwnode argument
device property: Get rid of struct fwnode_handle type field
ACPI: Use IS_ERR_OR_NULL() instead of non-NULL check in is_acpi_data_node()
04 Sep, 2017
1 commit
-
* acpi-x86:
ACPI / boot: Add number of legacy IRQs to debug output
ACPI / boot: Correct address space of __acpi_map_table()
ACPI / boot: Don't define unused variables* acpi-soc:
ACPI / LPSS: Don't abort ACPI scan on missing mem resource* acpi-pmic:
ACPI / PMIC: xpower: Do pinswitch magic when reading GPADC* acpi-apple:
spi: Use Apple device properties in absence of ACPI resources
ACPI / scan: Recognize Apple SPI and I2C slaves
ACPI / property: Support Apple _DSM properties
ACPI / property: Don't evaluate objects for devices w/o handle
treewide: Consolidate Apple DMI checks
23 Aug, 2017
1 commit
-
acpi_graph_get_child_prop_value() is intended to find a child node with a
certain property value pair. The checkif (!fwnode_property_read_u32(fwnode, prop_name, &nr))
continue;is faulty: fwnode_property_read_u32() returns zero on success, not on
failure, leading to comparing values only if the searched property was not
found.Moreover, the check is made against the parent device node instead of
the child one as it should be.Fixes: 79389a83bc38 (ACPI / property: Add support for remote endpoints)
Reported-by: Hyungwoo Yang
Signed-off-by: Sakari Ailus
Cc: 4.12+ # 4.12+
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki
04 Aug, 2017
2 commits
-
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/0c34936ed9a1By 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 driver,
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.Tested-by: Ronald Tschalär
Acked-by: Mika Westerberg
Reviewed-by: Andy Shevchenko
Signed-off-by: Lukas Wunner
Signed-off-by: Rafael J. Wysocki -
Fabricated devices such as LNXPWRBN lack a handle, causing evaluation
of _CCA and _DSD to always fail with AE_BAD_PARAMETER. While that is
merely a (negligible) waste of processing power, evaluating a _DSM for
them (such as Apple's device properties _DSM which we're about to add)
results in an ugly error:ACPI: \: failed to evaluate _DSM (0x1001)
Avoid by not evaluating _DSD and the upcoming _DSM for devices without
handle.Acked-by: Mika Westerberg
Signed-off-by: Lukas Wunner
Signed-off-by: Rafael J. Wysocki
26 Jul, 2017
1 commit
-
There are new types and helpers that are supposed to be used in new code.
As a preparation to get rid of legacy types and API functions do
the conversion here.Signed-off-by: Andy Shevchenko
Acked-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki
22 Jul, 2017
5 commits
-
The new fwnode_property_get_reference_args() interface amends the fwnode
property API with the functionality of both of_parse_phandle_with_args()
and __acpi_node_get_property_reference().The semantics is slightly different: the cells property is ignored on ACPI
as the number of arguments can be explicitly obtained from the firmware
interface.Signed-off-by: Sakari Ailus
Signed-off-by: Rafael J. Wysocki -
Make fwnode arguments to the fwnode property API const.
Signed-off-by: Sakari Ailus
Reviewed-by: Rob Herring
Signed-off-by: Rafael J. Wysocki -
Constify internal ACPI fwnode arguments in preparation for the same in
fwnode API.Signed-off-by: Sakari Ailus
Signed-off-by: Rafael J. Wysocki -
Make local variables const (head) or add new variables; adev was used for
two purposes: to refer the root device node and its children. The two
purposes are separated by this patch.This is preparation for making fwnode arguments const for fwnode ops.
Don't constify the argument itself quite yet as this is used as a callback
function.Signed-off-by: Sakari Ailus
Signed-off-by: Rafael J. Wysocki -
Instead of relying on the struct fwnode_handle type field, define
fwnode_operations structs for all separate types of fwnodes. To find out
the type, compare to the ops field to relevant ops structs.This change has two benefits:
1. it avoids adding the type field to each and every instance of struct
fwnode_handle, thus saving memory and2. makes the ops field the single factor that defines both the types of
the fwnode as well as defines the implementation of its operations,
decreasing the possibility of bugs when developing code dealing with
fwnode internals.Suggested-by: Rob Herring
Signed-off-by: Sakari Ailus
Reviewed-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki