26 Jun, 2016
1 commit
-
For device nodes in both DT and ACPI, it possible to have named
child nodes which contain properties (an existing example being
gpio-leds). This adds a function to find a named child node for
a device which can be used by drivers for property retrieval.For DT data node name matching, of_node_cmp() and similar functions
are made available outside of CONFIG_OF block so the new function
can reference these for DT and non-DT builds.For ACPI data node name matching, a helper function is also added
which returns false if CONFIG_ACPI is not set, otherwise it
performs a string comparison on the data node name. This avoids
using the acpi_data_node struct for non CONFIG_ACPI builds,
which would otherwise cause a build failure.Signed-off-by: Adam Thomson
Acked-by: Sathyanarayana Nujella
Acked-by: Rob Herring
Acked-by: Rafael J. Wysocki
Signed-off-by: Mark Brown
24 May, 2016
1 commit
-
Pull libnvdimm updates from Dan Williams:
"The bulk of this update was stabilized before the merge window and
appeared in -next. The "device dax" implementation was revised this
week in response to review feedback, and to address failures detected
by the recently expanded ndctl unit test suite.Not included in this pull request are two dax topic branches (dax
error handling, and dax radix-tree locking). These topics were
deferred to get a few more days of -next integration testing, and to
coordinate a branch baseline with Ted and the ext4 tree. Vishal and
Ross will send the error handling and locking topics respectively in
the next few days.This branch has received a positive build result from the kbuild robot
across 226 configs.Summary:
- Device DAX for persistent memory: Device DAX is the device-centric
analogue of Filesystem DAX (CONFIG_FS_DAX). It allows memory
ranges to be allocated and mapped without need of an intervening
file system. Device DAX is strict, precise and predictable.
Specifically this interface:a) Guarantees fault granularity with respect to a given page size
(pte, pmd, or pud) set at configuration time.b) Enforces deterministic behavior by being strict about what
fault scenarios are supported.Persistent memory is the first target, but the mechanism is also
targeted for exclusive allocations of performance/feature
differentiated memory ranges.- Support for the HPE DSM (device specific method) command formats.
This enables management of these first generation devices until a
unified DSM specification materializes.- Further ACPI 6.1 compliance with support for the common dimm
identifier format.- Various fixes and cleanups across the subsystem"
* tag 'libnvdimm-for-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm: (40 commits)
libnvdimm, dax: fix deletion
libnvdimm, dax: fix alignment validation
libnvdimm, dax: autodetect support
libnvdimm: release ida resources
Revert "block: enable dax for raw block devices"
/dev/dax, core: file operations and dax-mmap
/dev/dax, pmem: direct access to persistent memory
libnvdimm: stop requiring a driver ->remove() method
libnvdimm, dax: record the specified alignment of a dax-device instance
libnvdimm, dax: reserve space to store labels for device-dax
libnvdimm, dax: introduce device-dax infrastructure
nfit: add sysfs dimm 'family' and 'dsm_mask' attributes
tools/testing/nvdimm: ND_CMD_CALL support
nfit: disable vendor specific commands
nfit: export subsystem ids as attributes
nfit: fix format interface code byte order per ACPI6.1
nfit, libnvdimm: limited/whitelisted dimm command marshaling mechanism
nfit, libnvdimm: clarify "commands" vs "_DSMs"
libnvdimm: increase max envelope size for ioctl
acpi/nfit: Add sysfs "id" for NVDIMM ID
...
16 May, 2016
1 commit
-
* acpi-pci:
ACPI,PCI,IRQ: remove SCI penalize function
ACPI,PCI,IRQ: remove redundant code in acpi_irq_penalty_init()
ACPI,PCI,IRQ: reduce static IRQ array size to 16
ACPI,PCI,IRQ: reduce resource requirements* acpi-misc:
ACPI / sysfs: fix error code in get_status()
ACPI / device_sysfs: Clean up checkpatch errors
ACPI / device_sysfs: Change _SUN and _STA show functions error return to EIO
ACPI / device_sysfs: Add sysfs support for _HRV hardware revision
arm64: defconfig: Enable ACPI
ACPI / ARM64: Remove EXPERT dependency for ACPI on ARM64
ACPI / ARM64: Don't enable ACPI by default on ARM64
acer-wmi: Use acpi_dev_found()
eeepc-wmi: Use acpi_dev_found()
ACPI / utils: Rename acpi_dev_present()* acpi-tools:
tools/power/acpi: close file only if it is open
28 Apr, 2016
1 commit
-
Since fwnode may hold ERR_PTR(-ENODEV) or it may be NULL,
the fwnode type checks is_of_node(), is_acpi_node() and is
is_pset_node() need to consider it. Using IS_ERR_OR_NULL()
to check it.Fixes: 0d67e0fa1664 (device property: fix for a case of use-after-free)
Reported-by: Dan Carpenter
Signed-off-by: Heikki Krogerus
[ rjw: Subject & changelog ]
Signed-off-by: Rafael J. Wysocki
12 Apr, 2016
1 commit
-
The ACPI specification states that arguments "Revision ID" and "Function
Index" to a _DSM are type "Integer." Type Integers are 64 bit
quantities.The function evaluate_dsm specifies these types as simple "int" which
are 32 bits. Widen type passed to acpi_evaluate_dsm and its callers and
derived callers to pass correct type.acpi_check_dsm and acpi_evaluate_dsm_typed had similar issue and were
corrected as well.This is in preparation for libnvdimm implementing a generic _DSM
passthrough facility to have the capacity to pass 64-bit values as the
ACPI specification allows.[djbw: clarify the changelog, add rationale]
Signed-off-by: Jerry Hoemann
Acked-by: Rafael J. Wysocki
Signed-off-by: Dan Williams
09 Apr, 2016
1 commit
-
acpi_dev_present() was originally named after pci_dev_present()
to signify the similarity of the two functions.However Rafael J. Wysocki pointed out that the exported function
acpi_dev_present() is easily confused with the non-exported
acpi_device_is_present(). Additionally in ACPI parlance the term
"present" usually refers to the "device is present" bit returned
by the _STA control method, yet acpi_dev_present() merely checks
presence in the namespace. It does not invoke _STA at all, let
alone check the "device is present" bit.As suggested by Rafael, rename the function to acpi_dev_found()
and adjust all existing call sites.Signed-off-by: Lukas Wunner
Signed-off-by: Rafael J. Wysocki
12 Jan, 2016
1 commit
-
* acpi-scan:
ACPI: Fix white space in a structure definition
ACPI / utils: Add acpi_dev_present()
ACPI / scan: Fix acpi_bus_id_list bookkeeping
ACPI / scan: set status to 0 if _STA failed* acpi-bus:
ACPI / bus: Show _OSC UUID when _OSC fails
ACPI / bus: Tidy up _OSC error spacing* acpi-osl:
ACPI / OSL: Add kerneldoc comments to memory mapping functions* acpi-pm:
ACPI / PM: Support D3 COLD device in old BIOS for ZPODD
10 Dec, 2015
1 commit
-
D3cold is only regarded as valid if the "_PR3" object is
present for the given device after the commit 20dacb71ad28
("ACPI/PM: Rework device power management to follow ACPI 6").But some old BIOS only defined "_PS3" for the D3COLD device,
such as ZPODD device. And old kernel also believes the device with
"_PS3" is a D3COLD device.So, add some logics for supporting D3 COLD device with old BIOS
which is compatible with earlier ACPI spec and kernel behavior.Link: http://marc.info/?l=linux-acpi&m=144946938709759&w=2
Signed-off-by: Ken Xue
Reported-and-tested-by: Gang Long
Signed-off-by: Rafael J. Wysocki
09 Dec, 2015
1 commit
-
There's an idiom in use by 7 Linux drivers to detect the presence of a
particular ACPI HID by walking the namespace with acpi_get_devices().
The callback passed to acpi_get_devices() is mostly identical across
the drivers, leading to lots of duplicate code.Add acpi_dev_present(), the ACPI equivalent to pci_dev_present(),
allowing us to deduplicate all that boilerplate in the drivers.Signed-off-by: Lukas Wunner
Reviewed-by: Hanjun Guo
Signed-off-by: Rafael J. Wysocki
07 Nov, 2015
4 commits
-
* acpi-pci:
PCI: ACPI: Add support for PCI device DMA coherency
PCI: OF: Move of_pci_dma_configure() to pci_dma_configure()
of/pci: Fix pci_get_host_bridge_device leak
device property: ACPI: Remove unused DMA APIs
device property: ACPI: Make use of the new DMA Attribute APIs
device property: Adding DMA Attribute APIs for Generic Devices
ACPI: Adding DMA Attribute APIs for ACPI Device
device property: Introducing enum dev_dma_attr
ACPI: Honor ACPI _CCA attribute settingConflicts:
drivers/crypto/ccp/ccp-platform.c -
These DMA APIs are replaced with the newer versions, which return
the enum dev_dma_attr. So, we can safely remove them.Signed-off-by: Suravee Suthikulpanit
Acked-by: Bjorn Helgaas
Reviewed-by: Hanjun Guo
Signed-off-by: Rafael J. Wysocki -
Adding acpi_get_dma_attr() to query DMA attributes of ACPI devices.
It returns the enum dev_dma_attr, which communicates DMA information
more clearly. This API replaces the acpi_check_dma(), which will be
removed in subsequent patch.This patch also provides a convenient function, acpi_dma_supported(),
to check DMA support of the specified ACPI device.Signed-off-by: Suravee Suthikulpanit
Acked-by: Bjorn Helgaas
Reviewed-by: Hanjun Guo
Signed-off-by: Rafael J. Wysocki -
ACPI configurations can now mark devices as noncoherent,
support that choice.NOTE: This is required to support USB on ARM Juno Development Board.
Signed-off-by: Jeremy Linton
Signed-off-by: Suravee Suthikulpanit
Acked-by: Bjorn Helgaas
Reviewed-by: Hanjun Guo
Signed-off-by: Rafael J. Wysocki
26 Oct, 2015
1 commit
-
* acpi-scan:
ACPI / scan: use kstrdup_const() in acpi_add_id()
ACPI / scan: constify struct acpi_hardware_id::id
ACPI / scan: constify first argument of struct acpi_scan_handler::match* acpi-tables:
ACPI / tables: test the correct variable
x86, ACPI: Handle apic/x2apic entries in MADT in correct order
ACPI / tables: Add acpi_subtable_proc to ACPI table parsers* acpi-ec:
ACPI / EC: Fix a race issue in acpi_ec_guard_event()
ACPI / EC: Fix query handler related issues* acpi-assorted:
ACPI: change acpi_sleep_proc_init() to return void
ACPI: change init_acpi_device_notify() to return void
15 Sep, 2015
5 commits
-
This is preparation for using kstrdup_const to initialize that member.
Signed-off-by: Rasmus Villemoes
Signed-off-by: Rafael J. Wysocki -
One wouldn't expect a "match" function modify the string it searches
for, and indeed the only instance of the struct
acpi_scan_handler::match callback, acpi_pnp_match, can easily be
changed. While there, update its helper matching_id().This is also preparation for constifying struct acpi_hardware_id::id.
Signed-off-by: Rasmus Villemoes
Signed-off-by: Rafael J. Wysocki -
Modify is_acpi_node() to return "true" for ACPI data-only subnodes as
well as for ACPI device objects and change the name of to_acpi_node()
to to_acpi_device_node() so it is clear that it covers ACPI device
objects only. Accordingly, introduce to_acpi_data_node() to cover
data-only subnodes in an analogous way.With that, make the fwnode_property_* family of functions work with
ACPI data-only subnodes introduced previously.Signed-off-by: Rafael J. Wysocki
Tested-by: Mika Westerberg -
Add infrastructure needed to expose data-only subnodes of ACPI
device objects introduced previously via sysfs.Each data-only subnode is represented as a sysfs directory under
the directory corresponding to its parent object (a device or a
data-only subnode). Each of them has a "path" attribute (containing
the full ACPI namespace path to the object the subnode data come from)
at this time.Signed-off-by: Rafael J. Wysocki
Tested-by: Mika Westerberg -
In some cases, the information expressed via device properties is
hierarchical by nature. For example, the properties of a composite
device consisting of multiple semi-dependent components may need
to be represented in the form of a tree of property data sets
corresponding to specific components of the device.Unfortunately, using ACPI device objects for this purpose turns out
to be problematic, mostly due to the assumption made by some operating
systems (that platform firmware generally needs to work with) that
each device object in the ACPI namespace represents a device requiring
a separate driver. That assumption leads to complications which
reportedly are impractically difficult to overcome and a different
approach is needed for the sake of interoperability.The approach implemented here is based on extending _DSD via pointers
(links) to additional ACPI objects returning data packages formatted
in accordance with the _DSD formatting rules defined by Section 6.2.5
of ACPI 6. Those additional objects are referred to as data-only
subnodes of the device object containing the _DSD pointing to them.The links to them need to be located in a separate section of the
_DSD data package following UUID dbb8e3e6-5886-4ba6-8795-1319f52a966b
referred to as the Hierarchical Data Extension UUID as defined in [1].
Each of them is represented by a package of two strings. The first
string in that package (the key) is regarded as the name of the
data-only subnode pointed to by the link. The second string in it
(the target) is expected to hold the ACPI namespace path (possibly
utilizing the usual ACPI namespace search rules) of an ACPI object
evaluating to a data package extending the _DSD.The device properties initialization code follows those links,
creates a struct acpi_data_node object for each of them to store
the data returned by the ACPI object pointed to by it and processes
those data recursively (which may lead to the creation of more
struct acpi_data_node objects if the returned data package contains
the Hierarchical Data Extension UUID section with more links in it).All of the struct acpi_data_node objects are present until the the
ACPI device object containing the _DSD with links to them is deleted
and they are deleted along with that object.[1]: http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.pdf
Signed-off-by: Rafael J. Wysocki
Tested-by: Mika Westerberg
08 Jul, 2015
1 commit
-
There is no need to carry potentially outdated Free Software Foundation
mailing address in file headers since the COPYING file includes it.Signed-off-by: Jarkko Nikula
Signed-off-by: Rafael J. Wysocki
26 Jun, 2015
1 commit
-
* acpi-video:
ACPI / video: Inline acpi_video_set_dmi_backlight_type* device-properties:
ACPI / OF: Rename of_node() and acpi_node() to to_of_node() and to_acpi_node()* pm-sleep:
PM / sleep: Increase default DPM watchdog timeout to 60
PM / hibernate: re-enable nonboot cpus on disable_nonboot_cpus() failure* pm-cpuidle:
tick/idle/powerpc: Do not register idle states with CPUIDLE_FLAG_TIMER_STOP set in periodic mode
25 Jun, 2015
1 commit
-
Commit 8a0662d9 introduced of_node and acpi_node symbols in global namespace
but there were already ~63 of_node local variables or function parameters
(no single acpi_node though, but anyway).After debugging undefined but used of_node local varible (which turned out
to reference static function of_node() instead) it became clear that the names
for the functions are too short and too generic for global scope.Signed-off-by: Alexander Sverdlin
Signed-off-by: Rafael J. Wysocki
19 Jun, 2015
2 commits
-
* acpi-cca:
ufs: fix TRUE and FALSE re-define build error
megaraid_sas: fix TRUE and FALSE re-define build error
amd-xgbe: Unify coherency checking logic with device_dma_is_coherent()
crypto: ccp - Unify coherency checking logic with device_dma_is_coherent()
device property: Introduces device_dma_is_coherent()
arm64 : Introduce support for ACPI _CCA object
ACPI / scan: Parse _CCA and setup device coherency -
* acpi-pm:
ACPI / PM: Add missing pm_generic_complete() invocation
ACPI / PM: Turn power resources on and off in the right order during resume
ACPI / PM: Rework device power management to follow ACPI 6
ACPI / PM: Drop stale comment from acpi_power_transition()* acpi-apei:
GHES: Make NMI handler have a single reader
GHES: Elliminate double-loop in the NMI handler
GHES: Panic right after detection
GHES: Carve out the panic functionality
GHES: Carve out error queueing in a separate function* acpi-osl:
ACPI / osl: use same type for acpi_predefined_names values as in definition* acpi-pci:
ACPI / PCI: remove stale list_head in struct acpi_prt_entry
15 Jun, 2015
1 commit
-
This patch implements support for ACPI _CCA object, which is introduced in
ACPIv5.1, can be used for specifying device DMA coherency attribute.The parsing logic traverses device namespace to parse coherency
information, and stores it in acpi_device_flags. Then uses it to call
arch_setup_dma_ops() when creating each device enumerated in DSDT
during ACPI scan.This patch also introduces acpi_dma_is_coherent(), which provides
an interface for device drivers to check the coherency information
similarly to the of_dma_is_coherent().Signed-off-by: Mark Salter
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Rafael J. Wysocki
16 May, 2015
1 commit
-
The ACPI 6 specification has made some changes in the device power
management area. In particular:* The D3hot power state is now supposed to be always available
(instead of D3cold) and D3cold is only regarded as valid if the
_PR3 object is present for the given device.* The required ordering of transitions into power states deeper than
D0 is now such that for a transition into state Dx the _PSx method
is supposed to be executed first, if present, and the states of
the power resources the device depends on are supposed to be
changed after that.* It is now explicitly forbidden to transition devices from
lower-power (deeper) into higher-power (shallower) power states
other than D0.Those changes have been made so the specification reflects the
Windows' device power management code that the vast majority of
systems using ACPI is validated against.To avoid artificial differences in ACPI device power management
between Windows and Linux, modify the ACPI device power management
code to follow the new specification. Add comments explaining the
code flow in some unclear places.This only may affect some real corner cases in which the OS behavior
expected by the firmware is different from the Windows one, but that's
quite unlikely. The transition ordering change affects transitions
to D1 and D2 which are rarely used (if at all) and into D3hot and
D3cold for devices actually having _PR3, but those are likely to
be validated against Windows anyway. The other changes may affect
code calling acpi_device_get_power() or acpi_device_update_power()
where ACPI_STATE_D3_HOT may be returned instead of ACPI_STATE_D3_COLD
(that's why the ACPI fan driver needs to be updated too) and since
transitions into ACPI_STATE_D3_HOT may remove power now, it is better
to avoid this one in acpi_pm_device_sleep_state() if the "no power
off" PM QoS flag is set.The only existing user of acpi_device_can_poweroff() really cares
about the case when _PR3 is present, so the change in that function
should not cause any problems to happen too.A plus is that PCI_D3hot can be mapped to ACPI_STATE_D3_HOT
now and the compatibility with older systems should be covered
automatically.In any case, if any real problems result from this, it still will
be better to follow the Windows' behavior (which now is reflected
by the specification too) in general and handle the cases when it
doesn't work via quirks.Signed-off-by: Rafael J. Wysocki
05 May, 2015
1 commit
-
Refine the check for the presence of the "compatible" property
if the PRP0001 device ID is present in the device's list of
ACPI/PNP IDs to also print the message if _DSD is missing
entirely or the format of it is incorrect.One special case to take into accout is that the "compatible"
property need not be provided for devices having the PRP0001
device ID in their lists of ACPI/PNP IDs if they are ancestors
of PRP0001 devices with the "compatible" property present.
This is to cover heriarchies of device objects where the kernel
is only supposed to use a struct device representation for the
topmost one and the others represent, for example, functional
blocks of a composite device.While at it, reduce the log level of the message to "info"
and reduce the log level of the "broken _DSD" message to
"debug" (noise reduction).Signed-off-by: Rafael J. Wysocki
Reviewed-by: Mika Westerberg
13 Apr, 2015
1 commit
-
* device-properties:
device property: Introduce firmware node type for platform data
device property: Make it possible to use secondary firmware nodes
driver core: Implement device property accessors through fwnode ones
driver core: property: Update fwnode_property_read_string_array()
driver core: Add comments about returning array counts
ACPI: Introduce has_acpi_companion()
driver core / ACPI: Represent ACPI companions using fwnode_handle
18 Mar, 2015
1 commit
-
Add a nicer way to get the ACPI _UID.
Signed-off-by: Adrian Hunter
Signed-off-by: Rafael J. Wysocki
17 Mar, 2015
1 commit
-
Now that we have struct fwnode_handle, we can use that to point to
ACPI companions from struct device objects instead of pointing to
struct acpi_device directly.There are two benefits from that. First, the somewhat ugly and
hackish struct acpi_dev_node can be dropped and, second, the same
struct fwnode_handle pointer can be used in the future to point
to other (non-ACPI) firmware device node types.Signed-off-by: Rafael J. Wysocki
Acked-by: Greg Kroah-Hartman
Acked-by: Grant Likely
19 Dec, 2014
1 commit
-
* acpi-scan:
ACPI / scan: Change the level of _DEP-related messages to KERN_DEBUG* acpi-utils:
ACPI / utils: Drop error messages from acpi_evaluate_reference()* acpi-pm:
ACPI / PM: Do not disable wakeup GPEs that have not been enabled
13 Dec, 2014
1 commit
-
In some cases acpi_device_wakeup() may be called to ensure wakeup
power to be off for a given device even though that device's wakeup
GPE has not been enabled so far. It calls acpi_disable_gpe() on a
GPE that's not enabled and this causes ACPICA to return the AE_LIMIT
status code from that call which then is reported as an error by the
ACPICA's debug facilities (if enabled). This may lead to a fair
amount of confusion, so introduce a new ACPI device wakeup flag
to store the wakeup GPE status and avoid disabling wakeup GPEs
that have not been enabled.Reported-and-tested-by: Venkat Raghavulu
Signed-off-by: Rafael J. Wysocki
09 Dec, 2014
2 commits
-
* pm-runtime: (25 commits)
i2c-omap / PM: Drop CONFIG_PM_RUNTIME from i2c-omap.c
dmaengine / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
drivers: sh / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
e1000e / igb / PM: Eliminate CONFIG_PM_RUNTIME
MMC / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
MFD / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
misc / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
media / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
input / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
iio / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
hsi / OMAP / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
i2c-hid / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
drm / exynos / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
gpio / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
hwrandom / exynos / PM: Use CONFIG_PM in #ifdef
block / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
USB / PM: Drop CONFIG_PM_RUNTIME from the USB core
PM: Merge the SET*_RUNTIME_PM_OPS() macros
PM / Kconfig: Do not select PM directly from Kconfig files
PCI / PM: Drop CONFIG_PM_RUNTIME from the PCI core
... -
* acpi-scan:
ACPI: Add _DEP support to fix battery issue on Asus T100TA* acpi-pm:
ACPI / sleep: Drain outstanding events after disabling multiple GPEs
ACPI / PM: Fixed a typo in a comment* acpi-lpss:
dmaengine: dw: enable runtime PM
ACPI / LPSS: introduce a 'proxy' device to power on LPSS for DMA
ACPI / LPSS: allow to use specific PM domain during ->probe()
ACPI / LPSS: add all LPSS devices to the specific power domain* acpi-processor:
ACPI / cpuidle: avoid assigning signed errno to acpi_status
ACPI / processor: remove unused variabled from acpi_processor_power structure
ACPI / processor: Update the comments in processor.h
04 Dec, 2014
1 commit
-
After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so quite a few
depend on CONFIG_PM.Replace CONFIG_PM_RUNTIME with CONFIG_PM in the ACPI core code.
Reviewed-by: Ulf Hansson
Acked-by: Kevin Hilman
Signed-off-by: Rafael J. Wysocki
24 Nov, 2014
1 commit
-
ACPI 5.0 introduces _DEP (Operation Region Dependencies) to designate
device objects that OSPM should assign a higher priority in start
ordering due to future operation region accesses.On Asus T100TA, ACPI battery info are read from a I2C slave device via
I2C operation region. Before I2C operation region handler is installed,
battery _STA always returns 0. There is a _DEP method of designating
start order under battery device node.This patch is to implement _DEP feature to fix battery issue on the
Asus T100TA. Introducing acpi_dep_list and adding dep_unmet count
in struct acpi_device. During ACPI namespace scan, create struct
acpi_dep_data for a valid pair of master (device pointed to by _DEP)/
slave(device with _DEP), record master's and slave's ACPI handle in
it and put it into acpi_dep_list. The dep_unmet count will increase
by one if there is a device under its _DEP. Driver's probe() should
return EPROBE_DEFER when find dep_unmet is larger than 0. When I2C
operation region handler is installed, remove all struct acpi_dep_data
on the acpi_dep_list whose master is pointed to I2C host controller
and decrease slave's dep_unmet. When dep_unmet decreases to 0, all
_DEP conditions are met and then do acpi_bus_attach() for the device
in order to resolve battery _STA issue on the Asus T100TA.Link: https://bugzilla.kernel.org/show_bug.cgi?id=69011
Tested-by: Jan-Michael Brummer
Tested-by: Adam Williamson
Tested-by: Michael Shigorin
Acked-by: Wolfram Sang
Acked-by: Mika Westerberg
Signed-off-by: Lan Tianyu
Signed-off-by: Rafael J. Wysocki
05 Nov, 2014
4 commits
-
Provide a way for device drivers using GPIOs described by ACPI
GpioIo resources in _CRS to tell the GPIO subsystem what names
(connection IDs) to associate with specific GPIO pins defined
in there.To do that, a driver needs to define a mapping table as a
NULL-terminated array of struct acpi_gpio_mapping objects
that each contain a name, a pointer to an array of line data
(struct acpi_gpio_params) objects and the size of that array.Each struct acpi_gpio_params object consists of three fields,
crs_entry_index, line_index, active_low, representing the index of
the target GpioIo()/GpioInt() resource in _CRS starting from zero,
the index of the target line in that resource starting from zero,
and the active-low flag for that line, respectively.Next, the mapping table needs to be passed as the second
argument to acpi_dev_add_driver_gpios() that will register it with
the ACPI device object pointed to by its first argument. That
should be done in the driver's .probe() routine.On removal, the driver should unregister its GPIO mapping table
by calling acpi_dev_remove_driver_gpios() on the ACPI device
object where that table was previously registered.Included are fixes from Mika Westerberg.
Acked-by: Alexandre Courbot
Reviewed-by: Linus Walleij
Signed-off-by: Rafael J. Wysocki -
Add new generic routines are provided for retrieving properties from
device description objects in the platform firmware in case there are
no struct device objects for them (either those objects have not been
created yet or they do not exist at all).The following functions are provided:
fwnode_property_present()
fwnode_property_read_u8()
fwnode_property_read_u16()
fwnode_property_read_u32()
fwnode_property_read_u64()
fwnode_property_read_string()
fwnode_property_read_u8_array()
fwnode_property_read_u16_array()
fwnode_property_read_u32_array()
fwnode_property_read_u64_array()
fwnode_property_read_string_array()in analogy with the corresponding functions for struct device added
previously. For all of them, the first argument is a pointer to struct
fwnode_handle (new type) that allows a device description object
(depending on what platform firmware interface is in use) to be
obtained.Add a new macro device_for_each_child_node() for iterating over the
children of the device description object associated with a given
device and a new function device_get_child_node_count() returning the
number of a given device's child nodes.The interface covers both ACPI and Device Trees.
Suggested-by: Grant Likely
Acked-by: Greg Kroah-Hartman
Acked-by: Grant Likely
Signed-off-by: Rafael J. Wysocki -
We have lots of existing Device Tree enabled drivers and allocating
separate _HID for each is not feasible. Instead we allocate special _HID
"PRP0001" that means that the match should be done using Device Tree
compatible property using driver's .of_match_table instead if the driver
is missing .acpi_match_table.If there is a need to distinguish from where the device is enumerated
(DT/ACPI) driver can check dev->of_node or ACPI_COMPATION(dev).Signed-off-by: Mika Westerberg
Acked-by: Grant Likely
Signed-off-by: Rafael J. Wysocki -
Device Tree is used in many embedded systems to describe the system
configuration to the OS. It supports attaching properties or name-value
pairs to the devices it describe. With these properties one can pass
additional information to the drivers that would not be available
otherwise.ACPI is another configuration mechanism (among other things) typically
seen, but not limited to, x86 machines. ACPI allows passing arbitrary
data from methods but there has not been mechanism equivalent to Device
Tree until the introduction of _DSD in the recent publication of the
ACPI 5.1 specification.In order to facilitate ACPI usage in systems where Device Tree is
typically used, it would be beneficial to standardize a way to retrieve
Device Tree style properties from ACPI devices, which is what we do in
this patch.If a given device described in ACPI namespace wants to export properties it
must implement _DSD method (Device Specific Data, introduced with ACPI 5.1)
that returns the properties in a package of packages. For example:Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"name1", },
Package () {"name2", },
...
}
})The UUID reserved for properties is daffd814-6eba-4d8c-8a91-bc9bbf4aa301
and is documented in the ACPI 5.1 companion document called "_DSD
Implementation Guide" [1], [2].We add several helper functions that can be used to extract these
properties and convert them to different Linux data types.The ultimate goal is that we only have one device property API that
retrieves the requested properties from Device Tree or from ACPI
transparent to the caller.[1] http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
[2] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdfReviewed-by: Hanjun Guo
Reviewed-by: Josh Triplett
Reviewed-by: Grant Likely
Signed-off-by: Darren Hart
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki
