From 603fadf33604a2e170eb833f99f569d3597f1f09 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Mon, 25 Mar 2019 13:34:00 -0500 Subject: ACPI: Fix comment typos Fix some misspellings in comments. No functional change intended. Signed-off-by: Bjorn Helgaas Signed-off-by: Rafael J. Wysocki --- drivers/acpi/acpi_dbg.c | 2 +- drivers/acpi/acpi_lpat.c | 2 +- drivers/acpi/cppc_acpi.c | 34 ++++++++++++++++---------------- drivers/acpi/power.c | 4 ++-- drivers/acpi/pptt.c | 48 ++++++++++++++++++++++----------------------- drivers/acpi/scan.c | 2 +- drivers/acpi/spcr.c | 2 +- drivers/acpi/video_detect.c | 2 +- 8 files changed, 48 insertions(+), 48 deletions(-) diff --git a/drivers/acpi/acpi_dbg.c b/drivers/acpi/acpi_dbg.c index 4a434c23a196..d18246a2a65e 100644 --- a/drivers/acpi/acpi_dbg.c +++ b/drivers/acpi/acpi_dbg.c @@ -390,7 +390,7 @@ again: return size > 0 ? size : ret; } -static int acpi_aml_thread(void *unsed) +static int acpi_aml_thread(void *unused) { acpi_osd_exec_callback function = NULL; void *context; diff --git a/drivers/acpi/acpi_lpat.c b/drivers/acpi/acpi_lpat.c index 2cd9f738812b..43f1b99c86ca 100644 --- a/drivers/acpi/acpi_lpat.c +++ b/drivers/acpi/acpi_lpat.c @@ -22,7 +22,7 @@ * LPAT conversion table * * @lpat_table: the temperature_raw mapping table structure - * @raw: the raw value, used as a key to get the temerature from the + * @raw: the raw value, used as a key to get the temperature from the * above mapping table * * A positive converted temperature value will be returned on success, diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c index 1b207fca1420..e947a1ec82f9 100644 --- a/drivers/acpi/cppc_acpi.c +++ b/drivers/acpi/cppc_acpi.c @@ -81,9 +81,9 @@ struct cppc_pcc_data { int refcount; }; -/* Array to represent the PCC channel per subspace id */ +/* Array to represent the PCC channel per subspace ID */ static struct cppc_pcc_data *pcc_data[MAX_PCC_SUBSPACES]; -/* The cpu_pcc_subspace_idx containsper CPU subspace id */ +/* The cpu_pcc_subspace_idx contains per CPU subspace ID */ static DEFINE_PER_CPU(int, cpu_pcc_subspace_idx); /* @@ -436,7 +436,7 @@ int acpi_get_psd_map(struct cppc_cpudata **all_cpu_data) return -ENOMEM; /* - * Now that we have _PSD data from all CPUs, lets setup P-state + * Now that we have _PSD data from all CPUs, let's setup P-state * domain info. */ for_each_possible_cpu(i) { @@ -588,7 +588,7 @@ static int register_pcc_channel(int pcc_ss_idx) return -ENOMEM; } - /* Set flag so that we dont come here for each CPU. */ + /* Set flag so that we don't come here for each CPU. */ pcc_data[pcc_ss_idx]->pcc_channel_acquired = true; } @@ -613,7 +613,7 @@ bool __weak cpc_ffh_supported(void) * * Check and allocate the cppc_pcc_data memory. * In some processor configurations it is possible that same subspace - * is shared between multiple CPU's. This is seen especially in CPU's + * is shared between multiple CPUs. This is seen especially in CPUs * with hardware multi-threading support. * * Return: 0 for success, errno for failure @@ -711,7 +711,7 @@ static bool is_cppc_supported(int revision, int num_ent) /** * acpi_cppc_processor_probe - Search for per CPU _CPC objects. - * @pr: Ptr to acpi_processor containing this CPUs logical Id. + * @pr: Ptr to acpi_processor containing this CPU's logical ID. * * Return: 0 for success or negative value for err. */ @@ -728,7 +728,7 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) acpi_status status; int ret = -EFAULT; - /* Parse the ACPI _CPC table for this cpu. */ + /* Parse the ACPI _CPC table for this CPU. */ status = acpi_evaluate_object_typed(handle, "_CPC", NULL, &output, ACPI_TYPE_PACKAGE); if (ACPI_FAILURE(status)) { @@ -840,7 +840,7 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) if (ret) goto out_free; - /* Register PCC channel once for all PCC subspace id. */ + /* Register PCC channel once for all PCC subspace ID. */ if (pcc_subspace_id >= 0 && !pcc_data[pcc_subspace_id]->pcc_channel_acquired) { ret = register_pcc_channel(pcc_subspace_id); if (ret) @@ -860,7 +860,7 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr) goto out_free; } - /* Plug PSD data into this CPUs CPC descriptor. */ + /* Plug PSD data into this CPU's CPC descriptor. */ per_cpu(cpc_desc_ptr, pr->id) = cpc_ptr; ret = kobject_init_and_add(&cpc_ptr->kobj, &cppc_ktype, &cpu_dev->kobj, @@ -891,7 +891,7 @@ EXPORT_SYMBOL_GPL(acpi_cppc_processor_probe); /** * acpi_cppc_processor_exit - Cleanup CPC structs. - * @pr: Ptr to acpi_processor containing this CPUs logical Id. + * @pr: Ptr to acpi_processor containing this CPU's logical ID. * * Return: Void */ @@ -931,7 +931,7 @@ EXPORT_SYMBOL_GPL(acpi_cppc_processor_exit); /** * cpc_read_ffh() - Read FFH register - * @cpunum: cpu number to read + * @cpunum: CPU number to read * @reg: cppc register information * @val: place holder for return value * @@ -946,7 +946,7 @@ int __weak cpc_read_ffh(int cpunum, struct cpc_reg *reg, u64 *val) /** * cpc_write_ffh() - Write FFH register - * @cpunum: cpu number to write + * @cpunum: CPU number to write * @reg: cppc register information * @val: value to write * @@ -1093,7 +1093,7 @@ int cppc_get_desired_perf(int cpunum, u64 *desired_perf) EXPORT_SYMBOL_GPL(cppc_get_desired_perf); /** - * cppc_get_perf_caps - Get a CPUs performance capabilities. + * cppc_get_perf_caps - Get a CPU's performance capabilities. * @cpunum: CPU from which to get capabilities info. * @perf_caps: ptr to cppc_perf_caps. See cppc_acpi.h * @@ -1178,7 +1178,7 @@ out_err: EXPORT_SYMBOL_GPL(cppc_get_perf_caps); /** - * cppc_get_perf_ctrs - Read a CPUs performance feedback counters. + * cppc_get_perf_ctrs - Read a CPU's performance feedback counters. * @cpunum: CPU from which to read counters. * @perf_fb_ctrs: ptr to cppc_perf_fb_ctrs. See cppc_acpi.h * @@ -1205,7 +1205,7 @@ int cppc_get_perf_ctrs(int cpunum, struct cppc_perf_fb_ctrs *perf_fb_ctrs) ctr_wrap_reg = &cpc_desc->cpc_regs[CTR_WRAP_TIME]; /* - * If refernce perf register is not supported then we should + * If reference perf register is not supported then we should * use the nominal perf value */ if (!CPC_SUPPORTED(ref_perf_reg)) @@ -1258,7 +1258,7 @@ out_err: EXPORT_SYMBOL_GPL(cppc_get_perf_ctrs); /** - * cppc_set_perf - Set a CPUs performance controls. + * cppc_set_perf - Set a CPU's performance controls. * @cpu: CPU for which to set performance controls. * @perf_ctrls: ptr to cppc_perf_ctrls. See cppc_acpi.h * @@ -1339,7 +1339,7 @@ int cppc_set_perf(int cpu, struct cppc_perf_ctrls *perf_ctrls) * executing the Phase-II. * 2. Some other CPU has beaten this CPU to successfully execute the * write_trylock and has already acquired the write_lock. We know for a - * fact it(other CPU acquiring the write_lock) couldn't have happened + * fact it (other CPU acquiring the write_lock) couldn't have happened * before this CPU's Phase-I as we held the read_lock. * 3. Some other CPU executing pcc CMD_READ has stolen the * down_write, in which case, send_pcc_cmd will check for pending diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c index 665e93ca0b40..87db3e124725 100644 --- a/drivers/acpi/power.c +++ b/drivers/acpi/power.c @@ -535,12 +535,12 @@ int acpi_device_sleep_wake(struct acpi_device *dev, /* * Try to execute _DSW first. * - * Three agruments are needed for the _DSW object: + * Three arguments are needed for the _DSW object: * Argument 0: enable/disable the wake capabilities * Argument 1: target system state * Argument 2: target device state * When _DSW object is called to disable the wake capabilities, maybe - * the first argument is filled. The values of the other two agruments + * the first argument is filled. The values of the other two arguments * are meaningless. */ in_arg[0].type = ACPI_TYPE_INTEGER; diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c index 065c4fc245d1..b72e6afaa8fb 100644 --- a/drivers/acpi/pptt.c +++ b/drivers/acpi/pptt.c @@ -164,7 +164,7 @@ static struct acpi_pptt_cache *acpi_find_cache_level(struct acpi_table_header *t } /** - * acpi_count_levels() - Given a PPTT table, and a cpu node, count the caches + * acpi_count_levels() - Given a PPTT table, and a CPU node, count the caches * @table_hdr: Pointer to the head of the PPTT table * @cpu_node: processor node we wish to count caches for * @@ -235,7 +235,7 @@ static int acpi_pptt_leaf_node(struct acpi_table_header *table_hdr, /** * acpi_find_processor_node() - Given a PPTT table find the requested processor * @table_hdr: Pointer to the head of the PPTT table - * @acpi_cpu_id: cpu we are searching for + * @acpi_cpu_id: CPU we are searching for * * Find the subtable entry describing the provided processor. * This is done by iterating the PPTT table looking for processor nodes @@ -456,21 +456,21 @@ static struct acpi_pptt_processor *acpi_find_processor_package_id(struct acpi_ta static void acpi_pptt_warn_missing(void) { - pr_warn_once("No PPTT table found, cpu and cache topology may be inaccurate\n"); + pr_warn_once("No PPTT table found, CPU and cache topology may be inaccurate\n"); } /** * topology_get_acpi_cpu_tag() - Find a unique topology value for a feature * @table: Pointer to the head of the PPTT table - * @cpu: Kernel logical cpu number + * @cpu: Kernel logical CPU number * @level: A level that terminates the search * @flag: A flag which terminates the search * - * Get a unique value given a cpu, and a topology level, that can be + * Get a unique value given a CPU, and a topology level, that can be * matched to determine which cpus share common topological features * at that level. * - * Return: Unique value, or -ENOENT if unable to locate cpu + * Return: Unique value, or -ENOENT if unable to locate CPU */ static int topology_get_acpi_cpu_tag(struct acpi_table_header *table, unsigned int cpu, int level, int flag) @@ -510,7 +510,7 @@ static int find_acpi_cpu_topology_tag(unsigned int cpu, int level, int flag) return -ENOENT; } retval = topology_get_acpi_cpu_tag(table, cpu, level, flag); - pr_debug("Topology Setup ACPI cpu %d, level %d ret = %d\n", + pr_debug("Topology Setup ACPI CPU %d, level %d ret = %d\n", cpu, level, retval); acpi_put_table(table); @@ -519,9 +519,9 @@ static int find_acpi_cpu_topology_tag(unsigned int cpu, int level, int flag) /** * acpi_find_last_cache_level() - Determines the number of cache levels for a PE - * @cpu: Kernel logical cpu number + * @cpu: Kernel logical CPU number * - * Given a logical cpu number, returns the number of levels of cache represented + * Given a logical CPU number, returns the number of levels of cache represented * in the PPTT. Errors caused by lack of a PPTT table, or otherwise, return 0 * indicating we didn't find any cache levels. * @@ -534,7 +534,7 @@ int acpi_find_last_cache_level(unsigned int cpu) int number_of_levels = 0; acpi_status status; - pr_debug("Cache Setup find last level cpu=%d\n", cpu); + pr_debug("Cache Setup find last level CPU=%d\n", cpu); acpi_cpu_id = get_acpi_id_for_cpu(cpu); status = acpi_get_table(ACPI_SIG_PPTT, 0, &table); @@ -551,14 +551,14 @@ int acpi_find_last_cache_level(unsigned int cpu) /** * cache_setup_acpi() - Override CPU cache topology with data from the PPTT - * @cpu: Kernel logical cpu number + * @cpu: Kernel logical CPU number * * Updates the global cache info provided by cpu_get_cacheinfo() * when there are valid properties in the acpi_pptt_cache nodes. A * successful parse may not result in any updates if none of the - * cache levels have any valid flags set. Futher, a unique value is + * cache levels have any valid flags set. Further, a unique value is * associated with each known CPU cache entry. This unique value - * can be used to determine whether caches are shared between cpus. + * can be used to determine whether caches are shared between CPUs. * * Return: -ENOENT on failure to find table, or 0 on success */ @@ -567,7 +567,7 @@ int cache_setup_acpi(unsigned int cpu) struct acpi_table_header *table; acpi_status status; - pr_debug("Cache Setup ACPI cpu %d\n", cpu); + pr_debug("Cache Setup ACPI CPU %d\n", cpu); status = acpi_get_table(ACPI_SIG_PPTT, 0, &table); if (ACPI_FAILURE(status)) { @@ -582,8 +582,8 @@ int cache_setup_acpi(unsigned int cpu) } /** - * find_acpi_cpu_topology() - Determine a unique topology value for a given cpu - * @cpu: Kernel logical cpu number + * find_acpi_cpu_topology() - Determine a unique topology value for a given CPU + * @cpu: Kernel logical CPU number * @level: The topological level for which we would like a unique ID * * Determine a topology unique ID for each thread/core/cluster/mc_grouping @@ -596,7 +596,7 @@ int cache_setup_acpi(unsigned int cpu) * other levels beyond this use a generated value to uniquely identify * a topological feature. * - * Return: -ENOENT if the PPTT doesn't exist, or the cpu cannot be found. + * Return: -ENOENT if the PPTT doesn't exist, or the CPU cannot be found. * Otherwise returns a value which represents a unique topological feature. */ int find_acpi_cpu_topology(unsigned int cpu, int level) @@ -606,12 +606,12 @@ int find_acpi_cpu_topology(unsigned int cpu, int level) /** * find_acpi_cpu_cache_topology() - Determine a unique cache topology value - * @cpu: Kernel logical cpu number + * @cpu: Kernel logical CPU number * @level: The cache level for which we would like a unique ID * * Determine a unique ID for each unified cache in the system * - * Return: -ENOENT if the PPTT doesn't exist, or the cpu cannot be found. + * Return: -ENOENT if the PPTT doesn't exist, or the CPU cannot be found. * Otherwise returns a value which represents a unique topological feature. */ int find_acpi_cpu_cache_topology(unsigned int cpu, int level) @@ -643,17 +643,17 @@ int find_acpi_cpu_cache_topology(unsigned int cpu, int level) /** - * find_acpi_cpu_topology_package() - Determine a unique cpu package value - * @cpu: Kernel logical cpu number + * find_acpi_cpu_topology_package() - Determine a unique CPU package value + * @cpu: Kernel logical CPU number * - * Determine a topology unique package ID for the given cpu. + * Determine a topology unique package ID for the given CPU. * This ID can then be used to group peers, which will have matching ids. * * The search terminates when either a level is found with the PHYSICAL_PACKAGE * flag set or we reach a root node. * - * Return: -ENOENT if the PPTT doesn't exist, or the cpu cannot be found. - * Otherwise returns a value which represents the package for this cpu. + * Return: -ENOENT if the PPTT doesn't exist, or the CPU cannot be found. + * Otherwise returns a value which represents the package for this CPU. */ int find_acpi_cpu_topology_package(unsigned int cpu) { diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index 446c959a8f08..1b66fc835e39 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -895,7 +895,7 @@ static void acpi_bus_get_wakeup_device_flags(struct acpi_device *device) /* * Call _PSW/_DSW object to disable its ability to wake the sleeping * system for the ACPI device with the _PRW object. - * The _PSW object is depreciated in ACPI 3.0 and is replaced by _DSW. + * The _PSW object is deprecated in ACPI 3.0 and is replaced by _DSW. * So it is necessary to call _DSW object first. Only when it is not * present will the _PSW object used. */ diff --git a/drivers/acpi/spcr.c b/drivers/acpi/spcr.c index c336784d0bcb..b34d05e365b7 100644 --- a/drivers/acpi/spcr.c +++ b/drivers/acpi/spcr.c @@ -28,7 +28,7 @@ EXPORT_SYMBOL(qdf2400_e44_present); /* * Some Qualcomm Datacenter Technologies SoCs have a defective UART BUSY bit. - * Detect them by examining the OEM fields in the SPCR header, similiar to PCI + * Detect them by examining the OEM fields in the SPCR header, similar to PCI * quirk detection in pci_mcfg.c. */ static bool qdf2400_erratum_44_present(struct acpi_table_header *h) diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 43587ac680e4..cc2888930fe9 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -112,7 +112,7 @@ static int video_detect_force_none(const struct dmi_system_id *d) static const struct dmi_system_id video_detect_dmi_table[] = { /* On Samsung X360, the BIOS will set a flag (VDRV) if generic * ACPI backlight device is used. This flag will definitively break - * the backlight interface (even the vendor interface) untill next + * the backlight interface (even the vendor interface) until next * reboot. It's why we should prevent video.ko from being used here * and we can't rely on a later call to acpi_video_unregister(). */ -- cgit v1.2.3-59-g8ed1b From 40381a3c1fa3ed37458c7f745e51fc81e9b48fe2 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Mon, 25 Mar 2019 13:34:02 -0500 Subject: ACPI / scan: Simplify acpi_bus_extract_wakeup_device_power_package() acpi_bus_extract_wakeup_device_power_package() is a static function with a single caller that supplies (device->handle, &device->wakeup). Simplify the interface so the caller need only supply "device". This makes it obvious that "wakeup", i.e., &device->wakeup, can never be NULL, so remove the unnecessary check for that. Signed-off-by: Bjorn Helgaas Signed-off-by: Rafael J. Wysocki --- drivers/acpi/scan.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index 446c959a8f08..f3fb1fa79429 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -763,18 +763,16 @@ acpi_bus_get_ejd(acpi_handle handle, acpi_handle *ejd) } EXPORT_SYMBOL_GPL(acpi_bus_get_ejd); -static int acpi_bus_extract_wakeup_device_power_package(acpi_handle handle, - struct acpi_device_wakeup *wakeup) +static int acpi_bus_extract_wakeup_device_power_package(struct acpi_device *dev) { + acpi_handle handle = dev->handle; + struct acpi_device_wakeup *wakeup = &dev->wakeup; struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL }; union acpi_object *package = NULL; union acpi_object *element = NULL; acpi_status status; int err = -ENODATA; - if (!wakeup) - return -EINVAL; - INIT_LIST_HEAD(&wakeup->resources); /* _PRW */ @@ -883,8 +881,7 @@ static void acpi_bus_get_wakeup_device_flags(struct acpi_device *device) if (!acpi_has_method(device->handle, "_PRW")) return; - err = acpi_bus_extract_wakeup_device_power_package(device->handle, - &device->wakeup); + err = acpi_bus_extract_wakeup_device_power_package(device); if (err) { dev_err(&device->dev, "_PRW evaluation error: %d\n", err); return; -- cgit v1.2.3-59-g8ed1b From 5ceb5f0522bdc20d507fef2cd77fec2caa4e541e Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Mon, 25 Mar 2019 13:34:03 -0500 Subject: ACPI / scan: Add labels for PNP button devices Subsequent code treats button_device_ids[] entries differently, and it's hard to follow without a hint as to which is which. Add comments to identify the power button, lid, and sleep button devices. The "PNP" prefix is owned by Microsoft, so they distribute the canonical list of "PNP" IDs. Link: https://uefi.org/PNP_ACPI_Registry Link: https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/devids.txt Signed-off-by: Bjorn Helgaas Signed-off-by: Rafael J. Wysocki --- drivers/acpi/scan.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index f3fb1fa79429..2297440a0622 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -846,9 +846,9 @@ static int acpi_bus_extract_wakeup_device_power_package(struct acpi_device *dev) static bool acpi_wakeup_gpe_init(struct acpi_device *device) { static const struct acpi_device_id button_device_ids[] = { - {"PNP0C0C", 0}, - {"PNP0C0D", 0}, - {"PNP0C0E", 0}, + {"PNP0C0C", 0}, /* Power button */ + {"PNP0C0D", 0}, /* Lid */ + {"PNP0C0E", 0}, /* Sleep button */ {"", 0}, }; struct acpi_device_wakeup *wakeup = &device->wakeup; -- cgit v1.2.3-59-g8ed1b From 2e018c59fe8fbc4ae1a8db1523ea0f6159f48b4b Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Mon, 25 Mar 2019 13:34:01 -0500 Subject: ACPI / tables: Clean up whitespace Cleanup some whitespace to match the rest of the file. No functional change intended. Signed-off-by: Bjorn Helgaas Signed-off-by: Rafael J. Wysocki --- drivers/acpi/tables.c | 18 +++++------------- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c index 8fccbe49612a..4672f9ef183a 100644 --- a/drivers/acpi/tables.c +++ b/drivers/acpi/tables.c @@ -240,8 +240,7 @@ void acpi_table_print_madt_entry(struct acpi_subtable_header *header) * On success returns sum of all matching entries for all proc handlers. * Otherwise, -ENODEV or -EINVAL is returned. */ -static int __init -acpi_parse_entries_array(char *id, unsigned long table_size, +static int __init acpi_parse_entries_array(char *id, unsigned long table_size, struct acpi_table_header *table_header, struct acpi_subtable_proc *proc, int proc_num, unsigned int max_entries) @@ -314,8 +313,7 @@ acpi_parse_entries_array(char *id, unsigned long table_size, return errs ? -EINVAL : count; } -int __init -acpi_table_parse_entries_array(char *id, +int __init acpi_table_parse_entries_array(char *id, unsigned long table_size, struct acpi_subtable_proc *proc, int proc_num, unsigned int max_entries) @@ -346,8 +344,7 @@ acpi_table_parse_entries_array(char *id, return count; } -int __init -acpi_table_parse_entries(char *id, +int __init acpi_table_parse_entries(char *id, unsigned long table_size, int entry_id, acpi_tbl_entry_handler handler, @@ -362,8 +359,7 @@ acpi_table_parse_entries(char *id, max_entries); } -int __init -acpi_table_parse_madt(enum acpi_madt_type id, +int __init acpi_table_parse_madt(enum acpi_madt_type id, acpi_tbl_entry_handler handler, unsigned int max_entries) { return acpi_table_parse_entries(ACPI_SIG_MADT, @@ -725,8 +721,7 @@ static void *amlcode __attribute__ ((weakref("AmlCode"))); static void *dsdt_amlcode __attribute__ ((weakref("dsdt_aml_code"))); #endif -acpi_status -acpi_os_table_override(struct acpi_table_header *existing_table, +acpi_status acpi_os_table_override(struct acpi_table_header *existing_table, struct acpi_table_header **new_table) { if (!existing_table || !new_table) @@ -788,7 +783,6 @@ static int __init acpi_parse_apic_instance(char *str) return 0; } - early_param("acpi_apic_instance", acpi_parse_apic_instance); static int __init acpi_force_table_verification_setup(char *s) @@ -797,7 +791,6 @@ static int __init acpi_force_table_verification_setup(char *s) return 0; } - early_param("acpi_force_table_verification", acpi_force_table_verification_setup); static int __init acpi_force_32bit_fadt_addr(char *s) @@ -807,5 +800,4 @@ static int __init acpi_force_32bit_fadt_addr(char *s) return 0; } - early_param("acpi_force_32bit_fadt_addr", acpi_force_32bit_fadt_addr); -- cgit v1.2.3-59-g8ed1b From 4d720e2a8c5f5829ca6d79e02f653ca8b1470b8b Mon Sep 17 00:00:00 2001 From: Thomas Preston Date: Mon, 25 Mar 2019 16:53:38 +0000 Subject: Documentation: acpi: Add an example for PRP0001 Add an example for the magic PRP0001 device ID which allows matching ACPI devices against drivers using OF Device Tree compatible property. Signed-off-by: Thomas Preston Reviewed-by: Andy Shevchenko Acked-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/enumeration.txt | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index 7bcf9c3d9fbe..1395b844649c 100644 --- a/Documentation/acpi/enumeration.txt +++ b/Documentation/acpi/enumeration.txt @@ -410,6 +410,32 @@ Specifically, the device IDs returned by _HID and preceding PRP0001 in the _CID return package will be checked first. Also in that case the bus type the device will be enumerated to depends on the device ID returned by _HID. +For example, the following ACPI sample might be used to enumerate an lm75-type +I2C temperature sensor and match it to the driver using the Device Tree +namespace link: + + Device (TMP0) + { + Name (_HID, "PRP0001") + Name (_DSD, Package() { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package (2) { "compatible", "ti,tmp75" }, + } + }) + Method (_CRS, 0, Serialized) + { + Name (SBUF, ResourceTemplate () + { + I2cSerialBusV2 (0x48, ControllerInitiated, + 400000, AddressingMode7Bit, + "\\_SB.PCI0.I2C1", 0x00, + ResourceConsumer, , Exclusive,) + }) + Return (SBUF) + } + } + It is valid to define device objects with a _HID returning PRP0001 and without the "compatible" property in the _DSD or a _CID as long as one of their ancestors provides a _DSD with a valid "compatible" property. Such device -- cgit v1.2.3-59-g8ed1b From 817b4d64da036f5559297a2fdb82b8b14f4ffdcd Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Mon, 18 Mar 2019 23:00:54 +0300 Subject: ACPI / utils: Introduce acpi_dev_get_first_match_dev() helper The acpi_dev_get_first_match_name() is missing put_device() call and thus keeping reference counting unbalanced. In order to fix the issue introduce a new helper to convert existing users one-by-one to a better API. Signed-off-by: Andy Shevchenko Reviewed-by: Hans de Goede Reviewed-by: Mika Westerberg Acked-by: Mark Brown Signed-off-by: Rafael J. Wysocki --- drivers/acpi/utils.c | 24 ++++++++++++++++++++++-- include/acpi/acpi_bus.h | 3 +++ include/linux/acpi.h | 6 ++++++ 3 files changed, 31 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c index c4b06cc075f9..5a2bae2b6c3a 100644 --- a/drivers/acpi/utils.c +++ b/drivers/acpi/utils.c @@ -739,6 +739,7 @@ EXPORT_SYMBOL(acpi_dev_found); struct acpi_dev_match_info { const char *dev_name; + struct acpi_device *adev; struct acpi_device_id hid[2]; const char *uid; s64 hrv; @@ -759,6 +760,7 @@ static int acpi_dev_match_cb(struct device *dev, void *data) return 0; match->dev_name = acpi_dev_name(adev); + match->adev = adev; if (match->hrv == -1) return 1; @@ -806,16 +808,34 @@ bool acpi_dev_present(const char *hid, const char *uid, s64 hrv) EXPORT_SYMBOL(acpi_dev_present); /** - * acpi_dev_get_first_match_name - Return name of first match of ACPI device + * acpi_dev_get_first_match_dev - Return the first match of ACPI device * @hid: Hardware ID of the device. * @uid: Unique ID of the device, pass NULL to not check _UID * @hrv: Hardware Revision of the device, pass -1 to not check _HRV * - * Return device name if a matching device was present + * Return the first match of ACPI device if a matching device was present * at the moment of invocation, or NULL otherwise. * + * The caller is responsible to call put_device() on the returned device. + * * See additional information in acpi_dev_present() as well. */ +struct acpi_device * +acpi_dev_get_first_match_dev(const char *hid, const char *uid, s64 hrv) +{ + struct acpi_dev_match_info match = {}; + struct device *dev; + + strlcpy(match.hid[0].id, hid, sizeof(match.hid[0].id)); + match.uid = uid; + match.hrv = hrv; + + dev = bus_find_device(&acpi_bus_type, NULL, &match, acpi_dev_match_cb); + return dev ? match.adev : NULL; +} +EXPORT_SYMBOL(acpi_dev_get_first_match_dev); + +/* DEPRECATED, use acpi_dev_get_first_match_dev() instead */ const char * acpi_dev_get_first_match_name(const char *hid, const char *uid, s64 hrv) { diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h index 0300374101cd..2063e9e2f384 100644 --- a/include/acpi/acpi_bus.h +++ b/include/acpi/acpi_bus.h @@ -91,6 +91,9 @@ acpi_evaluate_dsm_typed(acpi_handle handle, const guid_t *guid, u64 rev, bool acpi_dev_found(const char *hid); bool acpi_dev_present(const char *hid, const char *uid, s64 hrv); +struct acpi_device * +acpi_dev_get_first_match_dev(const char *hid, const char *uid, s64 hrv); + const char * acpi_dev_get_first_match_name(const char *hid, const char *uid, s64 hrv); diff --git a/include/linux/acpi.h b/include/linux/acpi.h index d5dcebd7aad3..3e1d16b00513 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -669,6 +669,12 @@ static inline bool acpi_dev_present(const char *hid, const char *uid, s64 hrv) return false; } +static inline struct acpi_device * +acpi_dev_get_first_match_dev(const char *hid, const char *uid, s64 hrv) +{ + return NULL; +} + static inline const char * acpi_dev_get_first_match_name(const char *hid, const char *uid, s64 hrv) { -- cgit v1.2.3-59-g8ed1b From 0cf064db948aca1e760fc513594536f761dee1cd Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Thu, 28 Mar 2019 19:17:21 +0200 Subject: extcon: axp288: Convert to use acpi_dev_get_first_match_dev() acpi_dev_get_first_match_name() is deprecated and going to be removed because it leaks a reference. Convert the driver to use acpi_dev_get_first_match_dev() instead. Signed-off-by: Andy Shevchenko Acked-by: Chanwoo Choi Reviewed-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki --- drivers/extcon/extcon-axp288.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c index a983708b77a6..50f9402fb325 100644 --- a/drivers/extcon/extcon-axp288.c +++ b/drivers/extcon/extcon-axp288.c @@ -333,7 +333,7 @@ static int axp288_extcon_probe(struct platform_device *pdev) struct axp288_extcon_info *info; struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent); struct device *dev = &pdev->dev; - const char *name; + struct acpi_device *adev; int ret, i, pirq; info = devm_kzalloc(&pdev->dev, sizeof(*info), GFP_KERNEL); @@ -357,9 +357,10 @@ static int axp288_extcon_probe(struct platform_device *pdev) if (ret) return ret; - name = acpi_dev_get_first_match_name("INT3496", NULL, -1); - if (name) { - info->id_extcon = extcon_get_extcon_dev(name); + adev = acpi_dev_get_first_match_dev("INT3496", NULL, -1); + if (adev) { + info->id_extcon = extcon_get_extcon_dev(acpi_dev_name(adev)); + put_device(&adev->dev); if (!info->id_extcon) return -EPROBE_DEFER; -- cgit v1.2.3-59-g8ed1b From d00d2109c3679bf87d412b1667bcb6d42c1ac12f Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Thu, 28 Mar 2019 19:17:22 +0200 Subject: gpio: merrifield: Convert to use acpi_dev_get_first_match_dev() acpi_dev_get_first_match_name() is deprecated and going to be removed because it leaks a reference. Convert the driver to use acpi_dev_get_first_match_dev() instead. Signed-off-by: Andy Shevchenko Reviewed-by: Hans de Goede Reviewed-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki --- drivers/gpio/gpio-merrifield.c | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/drivers/gpio/gpio-merrifield.c b/drivers/gpio/gpio-merrifield.c index 7c659fdaa6d5..2383dc78b123 100644 --- a/drivers/gpio/gpio-merrifield.c +++ b/drivers/gpio/gpio-merrifield.c @@ -377,10 +377,20 @@ static void mrfld_irq_init_hw(struct mrfld_gpio *priv) } } -static const char *mrfld_gpio_get_pinctrl_dev_name(void) +static const char *mrfld_gpio_get_pinctrl_dev_name(struct mrfld_gpio *priv) { - const char *dev_name = acpi_dev_get_first_match_name("INTC1002", NULL, -1); - return dev_name ? dev_name : "pinctrl-merrifield"; + struct acpi_device *adev; + const char *name; + + adev = acpi_dev_get_first_match_dev("INTC1002", NULL, -1); + if (adev) { + name = devm_kstrdup(priv->dev, acpi_dev_name(adev), GFP_KERNEL); + put_device(&adev->dev); + } else { + name = "pinctrl-merrifield"; + } + + return name; } static int mrfld_gpio_probe(struct pci_dev *pdev, const struct pci_device_id *id) @@ -441,7 +451,7 @@ static int mrfld_gpio_probe(struct pci_dev *pdev, const struct pci_device_id *id return retval; } - pinctrl_dev_name = mrfld_gpio_get_pinctrl_dev_name(); + pinctrl_dev_name = mrfld_gpio_get_pinctrl_dev_name(priv); for (i = 0; i < ARRAY_SIZE(mrfld_gpio_ranges); i++) { range = &mrfld_gpio_ranges[i]; retval = gpiochip_add_pin_range(&priv->chip, -- cgit v1.2.3-59-g8ed1b From 1b55f1c6fd64efd7b1339664edc1222ad99f9c9b Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Thu, 28 Mar 2019 19:17:23 +0200 Subject: ASoC: Intel: bytcht_da7213: Convert to use acpi_dev_get_first_match_dev() acpi_dev_get_first_match_name() is deprecated and going to be removed because it leaks a reference. Convert the driver to use acpi_dev_get_first_match_dev() instead. Signed-off-by: Andy Shevchenko Acked-by: Pierre-Louis Bossart Reviewed-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki --- sound/soc/intel/boards/bytcht_da7213.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/sound/soc/intel/boards/bytcht_da7213.c b/sound/soc/intel/boards/bytcht_da7213.c index b8e884803777..4decba338156 100644 --- a/sound/soc/intel/boards/bytcht_da7213.c +++ b/sound/soc/intel/boards/bytcht_da7213.c @@ -226,7 +226,7 @@ static int bytcht_da7213_probe(struct platform_device *pdev) struct snd_soc_card *card; struct snd_soc_acpi_mach *mach; const char *platform_name; - const char *i2c_name = NULL; + struct acpi_device *adev; int dai_index = 0; int ret_val = 0; int i; @@ -244,10 +244,11 @@ static int bytcht_da7213_probe(struct platform_device *pdev) } /* fixup codec name based on HID */ - i2c_name = acpi_dev_get_first_match_name(mach->id, NULL, -1); - if (i2c_name) { + adev = acpi_dev_get_first_match_dev(mach->id, NULL, -1); + if (adev) { snprintf(codec_name, sizeof(codec_name), - "%s%s", "i2c-", i2c_name); + "i2c-%s", acpi_dev_name(adev)); + put_device(&adev->dev); dailink[dai_index].codec_name = codec_name; } -- cgit v1.2.3-59-g8ed1b From 645056da677082811b978f6285bf1ec0be947340 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Thu, 28 Mar 2019 19:17:24 +0200 Subject: ASoC: Intel: bytcht_es8316: Convert to use acpi_dev_get_first_match_dev() acpi_dev_get_first_match_name() is deprecated and going to be removed because it leaks a reference. Convert the driver to use acpi_dev_get_first_match_dev() instead. Signed-off-by: Andy Shevchenko Acked-by: Pierre-Louis Bossart Reviewed-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki --- sound/soc/intel/boards/bytcht_es8316.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/sound/soc/intel/boards/bytcht_es8316.c b/sound/soc/intel/boards/bytcht_es8316.c index d2a7e6ba11ae..6937c00cf63d 100644 --- a/sound/soc/intel/boards/bytcht_es8316.c +++ b/sound/soc/intel/boards/bytcht_es8316.c @@ -442,7 +442,7 @@ static int snd_byt_cht_es8316_mc_probe(struct platform_device *pdev) struct device *dev = &pdev->dev; struct snd_soc_acpi_mach *mach; const char *platform_name; - const char *i2c_name = NULL; + struct acpi_device *adev; struct device *codec_dev; int dai_index = 0; int i; @@ -463,10 +463,11 @@ static int snd_byt_cht_es8316_mc_probe(struct platform_device *pdev) } /* fixup codec name based on HID */ - i2c_name = acpi_dev_get_first_match_name(mach->id, NULL, -1); - if (i2c_name) { + adev = acpi_dev_get_first_match_dev(mach->id, NULL, -1); + if (adev) { snprintf(codec_name, sizeof(codec_name), - "%s%s", "i2c-", i2c_name); + "i2c-%s", acpi_dev_name(adev)); + put_device(&adev->dev); byt_cht_es8316_dais[dai_index].codec_name = codec_name; } -- cgit v1.2.3-59-g8ed1b From a320d89e67d6a08af18603b538021087a41bb182 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Thu, 28 Mar 2019 19:17:25 +0200 Subject: ASoC: Intel: bytcr_rt5640: Convert to use acpi_dev_get_first_match_dev() acpi_dev_get_first_match_name() is deprecated and going to be removed because it leaks a reference. Convert the driver to use acpi_dev_get_first_match_dev() instead. Signed-off-by: Andy Shevchenko Acked-by: Pierre-Louis Bossart Reviewed-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki --- sound/soc/intel/boards/bytcr_rt5640.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/sound/soc/intel/boards/bytcr_rt5640.c b/sound/soc/intel/boards/bytcr_rt5640.c index 940eb27158da..f9175cf6747e 100644 --- a/sound/soc/intel/boards/bytcr_rt5640.c +++ b/sound/soc/intel/boards/bytcr_rt5640.c @@ -1154,7 +1154,7 @@ static int snd_byt_rt5640_mc_probe(struct platform_device *pdev) struct byt_rt5640_private *priv; struct snd_soc_acpi_mach *mach; const char *platform_name; - const char *i2c_name = NULL; + struct acpi_device *adev; int ret_val = 0; int dai_index = 0; int i; @@ -1178,11 +1178,11 @@ static int snd_byt_rt5640_mc_probe(struct platform_device *pdev) } /* fixup codec name based on HID */ - i2c_name = acpi_dev_get_first_match_name(mach->id, NULL, -1); - if (i2c_name) { + adev = acpi_dev_get_first_match_dev(mach->id, NULL, -1); + if (adev) { snprintf(byt_rt5640_codec_name, sizeof(byt_rt5640_codec_name), - "%s%s", "i2c-", i2c_name); - + "i2c-%s", acpi_dev_name(adev)); + put_device(&adev->dev); byt_rt5640_dais[dai_index].codec_name = byt_rt5640_codec_name; } -- cgit v1.2.3-59-g8ed1b From 7075e9babb5db302907cf32b1db688eb83c85f77 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Thu, 28 Mar 2019 19:17:26 +0200 Subject: ASoC: Intel: bytcr_rt5651: Convert to use acpi_dev_get_first_match_dev() acpi_dev_get_first_match_name() is deprecated and going to be removed because it leaks a reference. Convert the driver to use acpi_dev_get_first_match_dev() instead. Signed-off-by: Andy Shevchenko Acked-by: Pierre-Louis Bossart Reviewed-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki --- sound/soc/intel/boards/bytcr_rt5651.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/sound/soc/intel/boards/bytcr_rt5651.c b/sound/soc/intel/boards/bytcr_rt5651.c index b0a4d297176e..b744add01d12 100644 --- a/sound/soc/intel/boards/bytcr_rt5651.c +++ b/sound/soc/intel/boards/bytcr_rt5651.c @@ -867,8 +867,8 @@ static int snd_byt_rt5651_mc_probe(struct platform_device *pdev) struct byt_rt5651_private *priv; struct snd_soc_acpi_mach *mach; const char *platform_name; + struct acpi_device *adev; struct device *codec_dev; - const char *i2c_name = NULL; const char *hp_swapped; bool is_bytcr = false; int ret_val = 0; @@ -894,14 +894,16 @@ static int snd_byt_rt5651_mc_probe(struct platform_device *pdev) } /* fixup codec name based on HID */ - i2c_name = acpi_dev_get_first_match_name(mach->id, NULL, -1); - if (!i2c_name) { + adev = acpi_dev_get_first_match_dev(mach->id, NULL, -1); + if (adev) { + snprintf(byt_rt5651_codec_name, sizeof(byt_rt5651_codec_name), + "i2c-%s", acpi_dev_name(adev)); + put_device(&adev->dev); + byt_rt5651_dais[dai_index].codec_name = byt_rt5651_codec_name; + } else { dev_err(&pdev->dev, "Error cannot find '%s' dev\n", mach->id); return -ENODEV; } - snprintf(byt_rt5651_codec_name, sizeof(byt_rt5651_codec_name), - "%s%s", "i2c-", i2c_name); - byt_rt5651_dais[dai_index].codec_name = byt_rt5651_codec_name; codec_dev = bus_find_device_by_name(&i2c_bus_type, NULL, byt_rt5651_codec_name); -- cgit v1.2.3-59-g8ed1b From fe4c283a79db91ac0d4402a363024789275c3fd1 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Thu, 28 Mar 2019 19:17:27 +0200 Subject: ASoC: Intel: cht_bsw_rt5645: Convert to use acpi_dev_get_first_match_dev() acpi_dev_get_first_match_name() is deprecated and going to be removed because it leaks a reference. Convert the driver to use acpi_dev_get_first_match_dev() instead. Signed-off-by: Andy Shevchenko Acked-by: Pierre-Louis Bossart Reviewed-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki --- sound/soc/intel/boards/cht_bsw_rt5645.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/sound/soc/intel/boards/cht_bsw_rt5645.c b/sound/soc/intel/boards/cht_bsw_rt5645.c index cbc2d458483f..32dbeaf1ab94 100644 --- a/sound/soc/intel/boards/cht_bsw_rt5645.c +++ b/sound/soc/intel/boards/cht_bsw_rt5645.c @@ -532,7 +532,7 @@ static int snd_cht_mc_probe(struct platform_device *pdev) struct snd_soc_acpi_mach *mach; const char *platform_name; struct cht_mc_private *drv; - const char *i2c_name = NULL; + struct acpi_device *adev; bool found = false; bool is_bytcr = false; int dai_index = 0; @@ -573,10 +573,11 @@ static int snd_cht_mc_probe(struct platform_device *pdev) } /* fixup codec name based on HID */ - i2c_name = acpi_dev_get_first_match_name(mach->id, NULL, -1); - if (i2c_name) { + adev = acpi_dev_get_first_match_dev(mach->id, NULL, -1); + if (adev) { snprintf(cht_rt5645_codec_name, sizeof(cht_rt5645_codec_name), - "%s%s", "i2c-", i2c_name); + "i2c-%s", acpi_dev_name(adev)); + put_device(&adev->dev); cht_dailink[dai_index].codec_name = cht_rt5645_codec_name; } -- cgit v1.2.3-59-g8ed1b From b664e6fe2225972e0eb3df0bb8dbedd1a0fc641f Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Thu, 28 Mar 2019 19:17:28 +0200 Subject: ASoC: Intel: cht_bsw_rt5672: Convert to use acpi_dev_get_first_match_dev() acpi_dev_get_first_match_name() is deprecated and going to be removed because it leaks a reference. Convert the driver to use acpi_dev_get_first_match_dev() instead. Signed-off-by: Andy Shevchenko Acked-by: Pierre-Louis Bossart Reviewed-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki --- sound/soc/intel/boards/cht_bsw_rt5672.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/sound/soc/intel/boards/cht_bsw_rt5672.c b/sound/soc/intel/boards/cht_bsw_rt5672.c index 3d5a2b3a06f0..0f7770822388 100644 --- a/sound/soc/intel/boards/cht_bsw_rt5672.c +++ b/sound/soc/intel/boards/cht_bsw_rt5672.c @@ -401,7 +401,7 @@ static int snd_cht_mc_probe(struct platform_device *pdev) struct cht_mc_private *drv; struct snd_soc_acpi_mach *mach = pdev->dev.platform_data; const char *platform_name; - const char *i2c_name; + struct acpi_device *adev; int i; drv = devm_kzalloc(&pdev->dev, sizeof(*drv), GFP_KERNEL); @@ -411,10 +411,11 @@ static int snd_cht_mc_probe(struct platform_device *pdev) strcpy(drv->codec_name, RT5672_I2C_DEFAULT); /* fixup codec name based on HID */ - i2c_name = acpi_dev_get_first_match_name(mach->id, NULL, -1); - if (i2c_name) { + adev = acpi_dev_get_first_match_dev(mach->id, NULL, -1); + if (adev) { snprintf(drv->codec_name, sizeof(drv->codec_name), - "i2c-%s", i2c_name); + "i2c-%s", acpi_dev_name(adev)); + put_device(&adev->dev); for (i = 0; i < ARRAY_SIZE(cht_dailink); i++) { if (!strcmp(cht_dailink[i].codec_name, RT5672_I2C_DEFAULT)) { -- cgit v1.2.3-59-g8ed1b From 257f9053c0204ea47491aa236004fd1226f75fa8 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Thu, 28 Mar 2019 19:17:29 +0200 Subject: ACPI / utils: Remove deprecated function since no user left There is no more user of acpi_dev_get_first_match_name(), which is deprecated and has no user left, so, remove it for good. Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki --- drivers/acpi/utils.c | 16 ---------------- include/acpi/acpi_bus.h | 3 --- include/linux/acpi.h | 6 ------ 3 files changed, 25 deletions(-) diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c index 5a2bae2b6c3a..89363b245489 100644 --- a/drivers/acpi/utils.c +++ b/drivers/acpi/utils.c @@ -835,22 +835,6 @@ acpi_dev_get_first_match_dev(const char *hid, const char *uid, s64 hrv) } EXPORT_SYMBOL(acpi_dev_get_first_match_dev); -/* DEPRECATED, use acpi_dev_get_first_match_dev() instead */ -const char * -acpi_dev_get_first_match_name(const char *hid, const char *uid, s64 hrv) -{ - struct acpi_dev_match_info match = {}; - struct device *dev; - - strlcpy(match.hid[0].id, hid, sizeof(match.hid[0].id)); - match.uid = uid; - match.hrv = hrv; - - dev = bus_find_device(&acpi_bus_type, NULL, &match, acpi_dev_match_cb); - return dev ? match.dev_name : NULL; -} -EXPORT_SYMBOL(acpi_dev_get_first_match_name); - /* * acpi_backlight= handling, this is done here rather then in video_detect.c * because __setup cannot be used in modules. diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h index 2063e9e2f384..f7981751ac77 100644 --- a/include/acpi/acpi_bus.h +++ b/include/acpi/acpi_bus.h @@ -94,9 +94,6 @@ bool acpi_dev_present(const char *hid, const char *uid, s64 hrv); struct acpi_device * acpi_dev_get_first_match_dev(const char *hid, const char *uid, s64 hrv); -const char * -acpi_dev_get_first_match_name(const char *hid, const char *uid, s64 hrv); - #ifdef CONFIG_ACPI #include diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 3e1d16b00513..392413075cc0 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -675,12 +675,6 @@ acpi_dev_get_first_match_dev(const char *hid, const char *uid, s64 hrv) return NULL; } -static inline const char * -acpi_dev_get_first_match_name(const char *hid, const char *uid, s64 hrv) -{ - return NULL; -} - static inline bool is_acpi_node(struct fwnode_handle *fwnode) { return false; -- cgit v1.2.3-59-g8ed1b From aefa763b18a220f5fc1d5ab02af09158b6cc36ea Mon Sep 17 00:00:00 2001 From: Zhang Rui Date: Mon, 1 Apr 2019 09:24:39 +0800 Subject: ACPI: video: Use vendor backlight on Sony VPCEH3U1E On Sony Vaio VPCEH3U1E, ACPI backlight control does not work, and native backlight works. Thus force use vendor backlight control on this system. Link: https://bugzilla.kernel.org/show_bug.cgi?id=202401 Signed-off-by: Zhang Rui Signed-off-by: Rafael J. Wysocki --- drivers/acpi/video_detect.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 43587ac680e4..0e0a3929e34e 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -141,6 +141,14 @@ static const struct dmi_system_id video_detect_dmi_table[] = { DMI_MATCH(DMI_PRODUCT_NAME, "UL30A"), }, }, + { + .callback = video_detect_force_vendor, + .ident = "Sony VPCEH3U1E", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"), + DMI_MATCH(DMI_PRODUCT_NAME, "VPCEH3U1E"), + }, + }, /* * These models have a working acpi_video backlight control, and using -- cgit v1.2.3-59-g8ed1b From fbc9418f099d457b91bf14aef8c4bfc498bb2437 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Wed, 3 Apr 2019 23:58:01 +0200 Subject: ACPI: PM: Print debug messages when enabling GPEs for wakeup In sufficiently complicated GPE configurations it is hard to determine which GPE could be the source of system wakeup from a sleep state, so make __acpi_device_wakeup_enable() print that information to the kernel log if debugging is enabled. Signed-off-by: Rafael J. Wysocki --- drivers/acpi/device_pm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c index 824ae985ad93..5b50f884712c 100644 --- a/drivers/acpi/device_pm.c +++ b/drivers/acpi/device_pm.c @@ -728,6 +728,9 @@ static int __acpi_device_wakeup_enable(struct acpi_device *adev, goto out; } + acpi_handle_debug(adev->handle, "GPE%2X enabled for wakeup\n", + (unsigned int)wakeup->gpe_number); + inc: wakeup->enable_count++; -- cgit v1.2.3-59-g8ed1b From a3ce7a8e0dd9baa5932c480b789ab54afa3ab116 Mon Sep 17 00:00:00 2001 From: Bob Moore Date: Mon, 8 Apr 2019 13:42:23 -0700 Subject: ACPICA: Rename nameseg copy macro for clarity ACPICA commit 19c18d3157945d1b8b64a826f0a8e848b7dbb127 ACPI_MOVE_NAME changed to ACPI_COPY_NAMESEG This clarifies (1) this is a copy operation, and (2) it operates on ACPI name_segs. Improves understanding of the code. Link: https://github.com/acpica/acpica/commit/19c18d31 Signed-off-by: Bob Moore Signed-off-by: Erik Schmauss Signed-off-by: Rafael J. Wysocki --- drivers/acpi/acpica/nsnames.c | 2 +- drivers/acpi/acpica/nsutils.c | 4 ++-- drivers/acpi/acpica/tbfind.c | 2 +- drivers/acpi/acpica/utstring.c | 2 +- include/acpi/actypes.h | 4 ++-- tools/power/acpi/os_specific/service_layers/oslinuxtbl.c | 4 ++-- tools/power/acpi/tools/acpidump/apfiles.c | 4 ++-- 7 files changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/acpi/acpica/nsnames.c b/drivers/acpi/acpica/nsnames.c index 289c15bb8c6a..c384320a0f26 100644 --- a/drivers/acpi/acpica/nsnames.c +++ b/drivers/acpi/acpica/nsnames.c @@ -108,7 +108,7 @@ acpi_ns_handle_to_name(acpi_handle target_handle, struct acpi_buffer *buffer) /* Just copy the ACPI name from the Node and zero terminate it */ node_name = acpi_ut_get_node_name(node); - ACPI_MOVE_NAME(buffer->pointer, node_name); + ACPI_COPY_NAMESEG(buffer->pointer, node_name); ((char *)buffer->pointer)[ACPI_NAME_SIZE] = 0; ACPI_DEBUG_PRINT((ACPI_DB_EXEC, "%4.4s\n", (char *)buffer->pointer)); diff --git a/drivers/acpi/acpica/nsutils.c b/drivers/acpi/acpica/nsutils.c index e5cef1edf49f..6f5940b02a4f 100644 --- a/drivers/acpi/acpica/nsutils.c +++ b/drivers/acpi/acpica/nsutils.c @@ -489,8 +489,8 @@ acpi_ns_externalize_name(u32 internal_name_length, /* Copy and validate the 4-char name segment */ - ACPI_MOVE_NAME(&(*converted_name)[j], - &internal_name[names_index]); + ACPI_COPY_NAMESEG(&(*converted_name)[j], + &internal_name[names_index]); acpi_ut_repair_name(&(*converted_name)[j]); j += ACPI_NAME_SIZE; diff --git a/drivers/acpi/acpica/tbfind.c b/drivers/acpi/acpica/tbfind.c index 951bd8e1c50a..ddc88aaca376 100644 --- a/drivers/acpi/acpica/tbfind.c +++ b/drivers/acpi/acpica/tbfind.c @@ -56,7 +56,7 @@ acpi_tb_find_table(char *signature, /* Normalize the input strings */ memset(&header, 0, sizeof(struct acpi_table_header)); - ACPI_MOVE_NAME(header.signature, signature); + ACPI_COPY_NAMESEG(header.signature, signature); strncpy(header.oem_id, oem_id, ACPI_OEM_ID_SIZE); strncpy(header.oem_table_id, oem_table_id, ACPI_OEM_TABLE_ID_SIZE); diff --git a/drivers/acpi/acpica/utstring.c b/drivers/acpi/acpica/utstring.c index 5bef0b059406..89dc79798d38 100644 --- a/drivers/acpi/acpica/utstring.c +++ b/drivers/acpi/acpica/utstring.c @@ -145,7 +145,7 @@ void acpi_ut_repair_name(char *name) return; } - ACPI_MOVE_NAME(&original_name, name); + ACPI_COPY_NAMESEG(&original_name, name); /* Check each character in the name */ diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h index f73382e82c26..bfe54189f242 100644 --- a/include/acpi/actypes.h +++ b/include/acpi/actypes.h @@ -516,10 +516,10 @@ typedef u64 acpi_integer; #ifndef ACPI_MISALIGNMENT_NOT_SUPPORTED #define ACPI_COMPARE_NAME(a,b) (*ACPI_CAST_PTR (u32, (a)) == *ACPI_CAST_PTR (u32, (b))) -#define ACPI_MOVE_NAME(dest,src) (*ACPI_CAST_PTR (u32, (dest)) = *ACPI_CAST_PTR (u32, (src))) +#define ACPI_COPY_NAMESEG(dest,src) (*ACPI_CAST_PTR (u32, (dest)) = *ACPI_CAST_PTR (u32, (src))) #else #define ACPI_COMPARE_NAME(a,b) (!strncmp (ACPI_CAST_PTR (char, (a)), ACPI_CAST_PTR (char, (b)), ACPI_NAME_SIZE)) -#define ACPI_MOVE_NAME(dest,src) (strncpy (ACPI_CAST_PTR (char, (dest)), ACPI_CAST_PTR (char, (src)), ACPI_NAME_SIZE)) +#define ACPI_COPY_NAMESEG(dest,src) (strncpy (ACPI_CAST_PTR (char, (dest)), ACPI_CAST_PTR (char, (src)), ACPI_NAME_SIZE)) #endif /* Support for the special RSDP signature (8 characters) */ diff --git a/tools/power/acpi/os_specific/service_layers/oslinuxtbl.c b/tools/power/acpi/os_specific/service_layers/oslinuxtbl.c index 2a1fd9182f94..587b701a7edb 100644 --- a/tools/power/acpi/os_specific/service_layers/oslinuxtbl.c +++ b/tools/power/acpi/os_specific/service_layers/oslinuxtbl.c @@ -286,7 +286,7 @@ static acpi_status osl_add_table_to_list(char *signature, u32 instance) return (AE_NO_MEMORY); } - ACPI_MOVE_NAME(new_info->signature, signature); + ACPI_COPY_NAMESEG(new_info->signature, signature); if (!gbl_table_list_head) { gbl_table_list_head = new_info; @@ -1174,7 +1174,7 @@ osl_table_name_from_file(char *filename, char *signature, u32 *instance) /* Extract signature */ - ACPI_MOVE_NAME(signature, filename); + ACPI_COPY_NAMESEG(signature, filename); return (AE_OK); } diff --git a/tools/power/acpi/tools/acpidump/apfiles.c b/tools/power/acpi/tools/acpidump/apfiles.c index 49972bc78bc5..8abc8f998abd 100644 --- a/tools/power/acpi/tools/acpidump/apfiles.c +++ b/tools/power/acpi/tools/acpidump/apfiles.c @@ -110,9 +110,9 @@ int ap_write_to_binary_file(struct acpi_table_header *table, u32 instance) /* Construct lower-case filename from the table local signature */ if (ACPI_VALIDATE_RSDP_SIG(table->signature)) { - ACPI_MOVE_NAME(filename, ACPI_RSDP_NAME); + ACPI_COPY_NAMESEG(filename, ACPI_RSDP_NAME); } else { - ACPI_MOVE_NAME(filename, table->signature); + ACPI_COPY_NAMESEG(filename, table->signature); } filename[0] = (char)tolower((int)filename[0]); -- cgit v1.2.3-59-g8ed1b From 5599fb69355d7a558f32206dac7539e945a1f604 Mon Sep 17 00:00:00 2001 From: Bob Moore Date: Mon, 8 Apr 2019 13:42:24 -0700 Subject: ACPICA: Rename nameseg compare macro for clarity ACPICA commit 92ec0935f27e217dff0b176fca02c2ec3d782bb5 ACPI_COMPARE_NAME changed to ACPI_COMPARE_NAMESEG This clarifies (1) this is a compare on 4-byte namesegs, not a generic compare. Improves understanding of the code. Link: https://github.com/acpica/acpica/commit/92ec0935 Signed-off-by: Bob Moore Signed-off-by: Erik Schmauss Signed-off-by: Rafael J. Wysocki --- arch/x86/boot/compressed/acpi.c | 2 +- drivers/acpi/acpica/dbexec.c | 2 +- drivers/acpi/acpica/dsinit.c | 2 +- drivers/acpi/acpica/nsinit.c | 4 +-- drivers/acpi/acpica/nsparse.c | 2 +- drivers/acpi/acpica/nsrepair.c | 2 +- drivers/acpi/acpica/nsrepair2.c | 2 +- drivers/acpi/acpica/nsxfname.c | 4 +-- drivers/acpi/acpica/rsxface.c | 8 +++--- drivers/acpi/acpica/tbdata.c | 3 ++- drivers/acpi/acpica/tbinstal.c | 2 +- drivers/acpi/acpica/tbprint.c | 6 ++--- drivers/acpi/acpica/tbutils.c | 6 ++--- drivers/acpi/acpica/tbxface.c | 4 +-- drivers/acpi/acpica/tbxfload.c | 15 ++++++----- drivers/acpi/acpica/utmisc.c | 8 +++--- drivers/acpi/acpica/utpredef.c | 4 +-- drivers/acpi/acpica/utstring.c | 2 +- drivers/acpi/scan.c | 2 +- drivers/acpi/sysfs.c | 8 +++--- drivers/acpi/tables.c | 4 +-- include/acpi/actypes.h | 4 +-- .../acpi/os_specific/service_layers/oslinuxtbl.c | 30 +++++++++++----------- tools/power/acpi/tools/acpidump/apdump.c | 4 +-- 24 files changed, 66 insertions(+), 64 deletions(-) diff --git a/arch/x86/boot/compressed/acpi.c b/arch/x86/boot/compressed/acpi.c index 0ef4ad55b29b..ad84239e595e 100644 --- a/arch/x86/boot/compressed/acpi.c +++ b/arch/x86/boot/compressed/acpi.c @@ -276,7 +276,7 @@ static unsigned long get_acpi_srat_table(void) if (acpi_table) { header = (struct acpi_table_header *)acpi_table; - if (ACPI_COMPARE_NAME(header->signature, ACPI_SIG_SRAT)) + if (ACPI_COMPARE_NAMESEG(header->signature, ACPI_SIG_SRAT)) return acpi_table; } entry += size; diff --git a/drivers/acpi/acpica/dbexec.c b/drivers/acpi/acpica/dbexec.c index bb43305cb215..4027eaab18a4 100644 --- a/drivers/acpi/acpica/dbexec.c +++ b/drivers/acpi/acpica/dbexec.c @@ -453,7 +453,7 @@ acpi_db_execute(char *name, char **args, acpi_object_type *types, u32 flags) /* Dump a _PLD buffer if present */ - if (ACPI_COMPARE_NAME + if (ACPI_COMPARE_NAMESEG ((ACPI_CAST_PTR (struct acpi_namespace_node, acpi_gbl_db_method_info.method)->name.ascii), diff --git a/drivers/acpi/acpica/dsinit.c b/drivers/acpi/acpica/dsinit.c index a4a24ffe5fae..4ebd23700bbc 100644 --- a/drivers/acpi/acpica/dsinit.c +++ b/drivers/acpi/acpica/dsinit.c @@ -200,7 +200,7 @@ acpi_ds_initialize_objects(u32 table_index, /* DSDT is always the first AML table */ - if (ACPI_COMPARE_NAME(table->signature, ACPI_SIG_DSDT)) { + if (ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_DSDT)) { ACPI_DEBUG_PRINT_RAW((ACPI_DB_INIT, "\nInitializing Namespace objects:\n")); } diff --git a/drivers/acpi/acpica/nsinit.c b/drivers/acpi/acpica/nsinit.c index 19fb8dda870f..53e5d00d3a5e 100644 --- a/drivers/acpi/acpica/nsinit.c +++ b/drivers/acpi/acpica/nsinit.c @@ -478,7 +478,7 @@ acpi_ns_find_ini_methods(acpi_handle obj_handle, /* We are only looking for methods named _INI */ - if (!ACPI_COMPARE_NAME(node->name.ascii, METHOD_NAME__INI)) { + if (!ACPI_COMPARE_NAMESEG(node->name.ascii, METHOD_NAME__INI)) { return (AE_OK); } @@ -641,7 +641,7 @@ acpi_ns_init_one_device(acpi_handle obj_handle, * Note: We know there is an _INI within this subtree, but it may not be * under this particular device, it may be lower in the branch. */ - if (!ACPI_COMPARE_NAME(device_node->name.ascii, "_SB_") || + if (!ACPI_COMPARE_NAMESEG(device_node->name.ascii, "_SB_") || device_node->parent != acpi_gbl_root_node) { ACPI_DEBUG_EXEC(acpi_ut_display_init_pathname (ACPI_TYPE_METHOD, device_node, diff --git a/drivers/acpi/acpica/nsparse.c b/drivers/acpi/acpica/nsparse.c index c0b4f7bedfab..f16cf5e4742c 100644 --- a/drivers/acpi/acpica/nsparse.c +++ b/drivers/acpi/acpica/nsparse.c @@ -203,7 +203,7 @@ acpi_ns_one_complete_parse(u32 pass_number, /* Found OSDT table, enable the namespace override feature */ - if (ACPI_COMPARE_NAME(table->signature, ACPI_SIG_OSDT) && + if (ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_OSDT) && pass_number == ACPI_IMODE_LOAD_PASS1) { walk_state->namespace_override = TRUE; } diff --git a/drivers/acpi/acpica/nsrepair.c b/drivers/acpi/acpica/nsrepair.c index 0aacfa48e20d..be86fea8e4d4 100644 --- a/drivers/acpi/acpica/nsrepair.c +++ b/drivers/acpi/acpica/nsrepair.c @@ -316,7 +316,7 @@ static const struct acpi_simple_repair_info *acpi_ns_match_simple_repair(struct this_name = acpi_object_repair_info; while (this_name->object_converter) { - if (ACPI_COMPARE_NAME(node->name.ascii, this_name->name)) { + if (ACPI_COMPARE_NAMESEG(node->name.ascii, this_name->name)) { /* Check if we can actually repair this name/type combination */ diff --git a/drivers/acpi/acpica/nsrepair2.c b/drivers/acpi/acpica/nsrepair2.c index d5804a6d1d65..4c285e918465 100644 --- a/drivers/acpi/acpica/nsrepair2.c +++ b/drivers/acpi/acpica/nsrepair2.c @@ -188,7 +188,7 @@ static const struct acpi_repair_info *acpi_ns_match_complex_repair(struct this_name = acpi_ns_repairable_names; while (this_name->repair_function) { - if (ACPI_COMPARE_NAME(node->name.ascii, this_name->name)) { + if (ACPI_COMPARE_NAMESEG(node->name.ascii, this_name->name)) { return (this_name); } diff --git a/drivers/acpi/acpica/nsxfname.c b/drivers/acpi/acpica/nsxfname.c index de2d3135d6a9..55b4a5b3331f 100644 --- a/drivers/acpi/acpica/nsxfname.c +++ b/drivers/acpi/acpica/nsxfname.c @@ -495,8 +495,8 @@ acpi_status acpi_install_method(u8 *buffer) /* Table must be a DSDT or SSDT */ - if (!ACPI_COMPARE_NAME(table->signature, ACPI_SIG_DSDT) && - !ACPI_COMPARE_NAME(table->signature, ACPI_SIG_SSDT)) { + if (!ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_DSDT) && + !ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_SSDT)) { return (AE_BAD_HEADER); } diff --git a/drivers/acpi/acpica/rsxface.c b/drivers/acpi/acpica/rsxface.c index 1d6f136e4068..c62be3d91712 100644 --- a/drivers/acpi/acpica/rsxface.c +++ b/drivers/acpi/acpica/rsxface.c @@ -603,10 +603,10 @@ acpi_walk_resources(acpi_handle device_handle, /* Parameter validation */ if (!device_handle || !user_function || !name || - (!ACPI_COMPARE_NAME(name, METHOD_NAME__CRS) && - !ACPI_COMPARE_NAME(name, METHOD_NAME__PRS) && - !ACPI_COMPARE_NAME(name, METHOD_NAME__AEI) && - !ACPI_COMPARE_NAME(name, METHOD_NAME__DMA))) { + (!ACPI_COMPARE_NAMESEG(name, METHOD_NAME__CRS) && + !ACPI_COMPARE_NAMESEG(name, METHOD_NAME__PRS) && + !ACPI_COMPARE_NAMESEG(name, METHOD_NAME__AEI) && + !ACPI_COMPARE_NAMESEG(name, METHOD_NAME__DMA))) { return_ACPI_STATUS(AE_BAD_PARAMETER); } diff --git a/drivers/acpi/acpica/tbdata.c b/drivers/acpi/acpica/tbdata.c index 0cecd0039acf..933f81316ad2 100644 --- a/drivers/acpi/acpica/tbdata.c +++ b/drivers/acpi/acpica/tbdata.c @@ -480,7 +480,8 @@ acpi_tb_verify_temp_table(struct acpi_table_desc *table_desc, /* If a particular signature is expected (DSDT/FACS), it must match */ - if (signature && !ACPI_COMPARE_NAME(&table_desc->signature, signature)) { + if (signature && + !ACPI_COMPARE_NAMESEG(&table_desc->signature, signature)) { ACPI_BIOS_ERROR((AE_INFO, "Invalid signature 0x%X for ACPI table, expected [%s]", table_desc->signature.integer, signature)); diff --git a/drivers/acpi/acpica/tbinstal.c b/drivers/acpi/acpica/tbinstal.c index be6642bf6366..ef1ffd36ab3f 100644 --- a/drivers/acpi/acpica/tbinstal.c +++ b/drivers/acpi/acpica/tbinstal.c @@ -120,7 +120,7 @@ acpi_tb_install_standard_table(acpi_physical_address address, */ if (!reload && acpi_gbl_disable_ssdt_table_install && - ACPI_COMPARE_NAME(&new_table_desc.signature, ACPI_SIG_SSDT)) { + ACPI_COMPARE_NAMESEG(&new_table_desc.signature, ACPI_SIG_SSDT)) { ACPI_INFO(("Ignoring installation of %4.4s at %8.8X%8.8X", new_table_desc.signature.ascii, ACPI_FORMAT_UINT64(address))); diff --git a/drivers/acpi/acpica/tbprint.c b/drivers/acpi/acpica/tbprint.c index 9b5df95d881b..0bc18fd5cd71 100644 --- a/drivers/acpi/acpica/tbprint.c +++ b/drivers/acpi/acpica/tbprint.c @@ -94,7 +94,7 @@ acpi_tb_print_table_header(acpi_physical_address address, { struct acpi_table_header local_header; - if (ACPI_COMPARE_NAME(header->signature, ACPI_SIG_FACS)) { + if (ACPI_COMPARE_NAMESEG(header->signature, ACPI_SIG_FACS)) { /* FACS only has signature and length fields */ @@ -158,8 +158,8 @@ acpi_status acpi_tb_verify_checksum(struct acpi_table_header *table, u32 length) * They are the odd tables, have no standard ACPI header and no checksum */ - if (ACPI_COMPARE_NAME(table->signature, ACPI_SIG_S3PT) || - ACPI_COMPARE_NAME(table->signature, ACPI_SIG_FACS)) { + if (ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_S3PT) || + ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_FACS)) { return (AE_OK); } diff --git a/drivers/acpi/acpica/tbutils.c b/drivers/acpi/acpica/tbutils.c index 2469e01310e2..c5f0b8ec70cc 100644 --- a/drivers/acpi/acpica/tbutils.c +++ b/drivers/acpi/acpica/tbutils.c @@ -332,9 +332,9 @@ acpi_tb_parse_root_table(acpi_physical_address rsdp_address) &table_index); if (ACPI_SUCCESS(status) && - ACPI_COMPARE_NAME(&acpi_gbl_root_table_list. - tables[table_index].signature, - ACPI_SIG_FADT)) { + ACPI_COMPARE_NAMESEG(&acpi_gbl_root_table_list. + tables[table_index].signature, + ACPI_SIG_FADT)) { acpi_gbl_fadt_index = table_index; acpi_tb_parse_fadt(); } diff --git a/drivers/acpi/acpica/tbxface.c b/drivers/acpi/acpica/tbxface.c index 36592888f0e7..1640685bf4ae 100644 --- a/drivers/acpi/acpica/tbxface.c +++ b/drivers/acpi/acpica/tbxface.c @@ -230,7 +230,7 @@ acpi_get_table_header(char *signature, for (i = 0, j = 0; i < acpi_gbl_root_table_list.current_table_count; i++) { - if (!ACPI_COMPARE_NAME + if (!ACPI_COMPARE_NAMESEG (&(acpi_gbl_root_table_list.tables[i].signature), signature)) { continue; @@ -323,7 +323,7 @@ acpi_get_table(char *signature, i++) { table_desc = &acpi_gbl_root_table_list.tables[i]; - if (!ACPI_COMPARE_NAME(&table_desc->signature, signature)) { + if (!ACPI_COMPARE_NAMESEG(&table_desc->signature, signature)) { continue; } diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c index 1a2592cc3245..4f30f06a6f78 100644 --- a/drivers/acpi/acpica/tbxfload.c +++ b/drivers/acpi/acpica/tbxfload.c @@ -118,7 +118,7 @@ acpi_status acpi_tb_load_namespace(void) table = &acpi_gbl_root_table_list.tables[acpi_gbl_dsdt_index]; if (!acpi_gbl_root_table_list.current_table_count || - !ACPI_COMPARE_NAME(table->signature.ascii, ACPI_SIG_DSDT) || + !ACPI_COMPARE_NAMESEG(table->signature.ascii, ACPI_SIG_DSDT) || ACPI_FAILURE(acpi_tb_validate_table(table))) { status = AE_NO_ACPI_TABLES; goto unlock_and_exit; @@ -170,11 +170,12 @@ acpi_status acpi_tb_load_namespace(void) table = &acpi_gbl_root_table_list.tables[i]; if (!table->address || - (!ACPI_COMPARE_NAME(table->signature.ascii, ACPI_SIG_SSDT) - && !ACPI_COMPARE_NAME(table->signature.ascii, - ACPI_SIG_PSDT) - && !ACPI_COMPARE_NAME(table->signature.ascii, - ACPI_SIG_OSDT)) + (!ACPI_COMPARE_NAMESEG + (table->signature.ascii, ACPI_SIG_SSDT) + && !ACPI_COMPARE_NAMESEG(table->signature.ascii, + ACPI_SIG_PSDT) + && !ACPI_COMPARE_NAMESEG(table->signature.ascii, + ACPI_SIG_OSDT)) || ACPI_FAILURE(acpi_tb_validate_table(table))) { continue; } @@ -364,7 +365,7 @@ acpi_status acpi_unload_parent_table(acpi_handle object) * only these types can contain AML and thus are the only types * that can create namespace objects. */ - if (ACPI_COMPARE_NAME + if (ACPI_COMPARE_NAMESEG (acpi_gbl_root_table_list.tables[i].signature.ascii, ACPI_SIG_DSDT)) { status = AE_TYPE; diff --git a/drivers/acpi/acpica/utmisc.c b/drivers/acpi/acpica/utmisc.c index afaadc73196b..8638efacdbf4 100644 --- a/drivers/acpi/acpica/utmisc.c +++ b/drivers/acpi/acpica/utmisc.c @@ -59,10 +59,10 @@ u8 acpi_ut_is_aml_table(struct acpi_table_header *table) /* These are the only tables that contain executable AML */ - if (ACPI_COMPARE_NAME(table->signature, ACPI_SIG_DSDT) || - ACPI_COMPARE_NAME(table->signature, ACPI_SIG_PSDT) || - ACPI_COMPARE_NAME(table->signature, ACPI_SIG_SSDT) || - ACPI_COMPARE_NAME(table->signature, ACPI_SIG_OSDT) || + if (ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_DSDT) || + ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_PSDT) || + ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_SSDT) || + ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_OSDT) || ACPI_IS_OEM_SIG(table->signature)) { return (TRUE); } diff --git a/drivers/acpi/acpica/utpredef.c b/drivers/acpi/acpica/utpredef.c index a9f08f43c685..1b0f68f5ed8c 100644 --- a/drivers/acpi/acpica/utpredef.c +++ b/drivers/acpi/acpica/utpredef.c @@ -84,7 +84,7 @@ const union acpi_predefined_info *acpi_ut_match_predefined_method(char *name) this_name = acpi_gbl_predefined_methods; while (this_name->info.name[0]) { - if (ACPI_COMPARE_NAME(name, this_name->info.name)) { + if (ACPI_COMPARE_NAMESEG(name, this_name->info.name)) { return (this_name); } @@ -201,7 +201,7 @@ const union acpi_predefined_info *acpi_ut_match_resource_name(char *name) this_name = acpi_gbl_resource_names; while (this_name->info.name[0]) { - if (ACPI_COMPARE_NAME(name, this_name->info.name)) { + if (ACPI_COMPARE_NAMESEG(name, this_name->info.name)) { return (this_name); } diff --git a/drivers/acpi/acpica/utstring.c b/drivers/acpi/acpica/utstring.c index 89dc79798d38..927797355da9 100644 --- a/drivers/acpi/acpica/utstring.c +++ b/drivers/acpi/acpica/utstring.c @@ -141,7 +141,7 @@ void acpi_ut_repair_name(char *name) * Special case for the root node. This can happen if we get an * error during the execution of module-level code. */ - if (ACPI_COMPARE_NAME(name, ACPI_ROOT_PATHNAME)) { + if (ACPI_COMPARE_NAMESEG(name, ACPI_ROOT_PATHNAME)) { return; } diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index 446c959a8f08..3fb331fb6e82 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -2260,7 +2260,7 @@ int __init __acpi_probe_device_table(struct acpi_probe_entry *ap_head, int nr) mutex_lock(&acpi_probe_mutex); for (ape = ap_head; nr; ape++, nr--) { - if (ACPI_COMPARE_NAME(ACPI_SIG_MADT, ape->id)) { + if (ACPI_COMPARE_NAMESEG(ACPI_SIG_MADT, ape->id)) { acpi_probe_count = 0; acpi_table_parse_madt(ape->type, acpi_match_madt, 0); count += acpi_probe_count; diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c index fa76f5e41b5c..262d6ee4735d 100644 --- a/drivers/acpi/sysfs.c +++ b/drivers/acpi/sysfs.c @@ -368,10 +368,10 @@ static int acpi_table_attr_init(struct kobject *tables_obj, char instance_str[ACPI_INST_SIZE]; sysfs_attr_init(&table_attr->attr.attr); - ACPI_MOVE_NAME(table_attr->name, table_header->signature); + ACPI_COPY_NAMESEG(table_attr->name, table_header->signature); list_for_each_entry(attr, &acpi_table_attr_list, node) { - if (ACPI_COMPARE_NAME(table_attr->name, attr->name)) + if (ACPI_COMPARE_NAMESEG(table_attr->name, attr->name)) if (table_attr->instance < attr->instance) table_attr->instance = attr->instance; } @@ -382,7 +382,7 @@ static int acpi_table_attr_init(struct kobject *tables_obj, return -ERANGE; } - ACPI_MOVE_NAME(table_attr->filename, table_header->signature); + ACPI_COPY_NAMESEG(table_attr->filename, table_header->signature); table_attr->filename[ACPI_NAME_SIZE] = '\0'; if (table_attr->instance > 1 || (table_attr->instance == 1 && !acpi_get_table @@ -484,7 +484,7 @@ static int acpi_table_data_init(struct acpi_table_header *th) int i; for (i = 0; i < NUM_ACPI_DATA_OBJS; i++) { - if (ACPI_COMPARE_NAME(th->signature, acpi_data_objs[i].name)) { + if (ACPI_COMPARE_NAMESEG(th->signature, acpi_data_objs[i].name)) { data_attr = kzalloc(sizeof(*data_attr), GFP_KERNEL); if (!data_attr) return -ENOMEM; diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c index 8fccbe49612a..1ffd7b9eefc5 100644 --- a/drivers/acpi/tables.c +++ b/drivers/acpi/tables.c @@ -670,8 +670,8 @@ static void __init acpi_table_initrd_scan(void) table_length = table->length; /* Skip RSDT/XSDT which should only be used for override */ - if (ACPI_COMPARE_NAME(table->signature, ACPI_SIG_RSDT) || - ACPI_COMPARE_NAME(table->signature, ACPI_SIG_XSDT)) { + if (ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_RSDT) || + ACPI_COMPARE_NAMESEG(table->signature, ACPI_SIG_XSDT)) { acpi_os_unmap_memory(table, ACPI_HEADER_SIZE); goto next_table; } diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h index bfe54189f242..cb51172a47a3 100644 --- a/include/acpi/actypes.h +++ b/include/acpi/actypes.h @@ -515,10 +515,10 @@ typedef u64 acpi_integer; /* Optimizations for 4-character (32-bit) acpi_name manipulation */ #ifndef ACPI_MISALIGNMENT_NOT_SUPPORTED -#define ACPI_COMPARE_NAME(a,b) (*ACPI_CAST_PTR (u32, (a)) == *ACPI_CAST_PTR (u32, (b))) +#define ACPI_COMPARE_NAMESEG(a,b) (*ACPI_CAST_PTR (u32, (a)) == *ACPI_CAST_PTR (u32, (b))) #define ACPI_COPY_NAMESEG(dest,src) (*ACPI_CAST_PTR (u32, (dest)) = *ACPI_CAST_PTR (u32, (src))) #else -#define ACPI_COMPARE_NAME(a,b) (!strncmp (ACPI_CAST_PTR (char, (a)), ACPI_CAST_PTR (char, (b)), ACPI_NAME_SIZE)) +#define ACPI_COMPARE_NAMESEG(a,b) (!strncmp (ACPI_CAST_PTR (char, (a)), ACPI_CAST_PTR (char, (b)), ACPI_NAME_SIZE)) #define ACPI_COPY_NAMESEG(dest,src) (strncpy (ACPI_CAST_PTR (char, (dest)), ACPI_CAST_PTR (char, (src)), ACPI_NAME_SIZE)) #endif diff --git a/tools/power/acpi/os_specific/service_layers/oslinuxtbl.c b/tools/power/acpi/os_specific/service_layers/oslinuxtbl.c index 587b701a7edb..2686d858225a 100644 --- a/tools/power/acpi/os_specific/service_layers/oslinuxtbl.c +++ b/tools/power/acpi/os_specific/service_layers/oslinuxtbl.c @@ -293,7 +293,7 @@ static acpi_status osl_add_table_to_list(char *signature, u32 instance) } else { next = gbl_table_list_head; while (1) { - if (ACPI_COMPARE_NAME(next->signature, signature)) { + if (ACPI_COMPARE_NAMESEG(next->signature, signature)) { if (next->instance == instance) { found = TRUE; } @@ -782,11 +782,11 @@ osl_get_bios_table(char *signature, /* Handle special tables whose addresses are not in RSDT/XSDT */ - if (ACPI_COMPARE_NAME(signature, ACPI_RSDP_NAME) || - ACPI_COMPARE_NAME(signature, ACPI_SIG_RSDT) || - ACPI_COMPARE_NAME(signature, ACPI_SIG_XSDT) || - ACPI_COMPARE_NAME(signature, ACPI_SIG_DSDT) || - ACPI_COMPARE_NAME(signature, ACPI_SIG_FACS)) { + if (ACPI_COMPARE_NAMESEG(signature, ACPI_RSDP_NAME) || + ACPI_COMPARE_NAMESEG(signature, ACPI_SIG_RSDT) || + ACPI_COMPARE_NAMESEG(signature, ACPI_SIG_XSDT) || + ACPI_COMPARE_NAMESEG(signature, ACPI_SIG_DSDT) || + ACPI_COMPARE_NAMESEG(signature, ACPI_SIG_FACS)) { find_next_instance: @@ -797,7 +797,7 @@ find_next_instance: * careful about the FADT length and validate table addresses. * Note: The 64-bit addresses have priority. */ - if (ACPI_COMPARE_NAME(signature, ACPI_SIG_DSDT)) { + if (ACPI_COMPARE_NAMESEG(signature, ACPI_SIG_DSDT)) { if (current_instance < 2) { if ((gbl_fadt->header.length >= MIN_FADT_FOR_XDSDT) && gbl_fadt->Xdsdt @@ -815,7 +815,7 @@ find_next_instance: dsdt; } } - } else if (ACPI_COMPARE_NAME(signature, ACPI_SIG_FACS)) { + } else if (ACPI_COMPARE_NAMESEG(signature, ACPI_SIG_FACS)) { if (current_instance < 2) { if ((gbl_fadt->header.length >= MIN_FADT_FOR_XFACS) && gbl_fadt->Xfacs @@ -833,7 +833,7 @@ find_next_instance: facs; } } - } else if (ACPI_COMPARE_NAME(signature, ACPI_SIG_XSDT)) { + } else if (ACPI_COMPARE_NAMESEG(signature, ACPI_SIG_XSDT)) { if (!gbl_revision) { return (AE_BAD_SIGNATURE); } @@ -842,7 +842,7 @@ find_next_instance: (acpi_physical_address)gbl_rsdp. xsdt_physical_address; } - } else if (ACPI_COMPARE_NAME(signature, ACPI_SIG_RSDT)) { + } else if (ACPI_COMPARE_NAMESEG(signature, ACPI_SIG_RSDT)) { if (current_instance == 0) { table_address = (acpi_physical_address)gbl_rsdp. @@ -931,7 +931,7 @@ find_next_instance: /* Does this table match the requested signature? */ - if (!ACPI_COMPARE_NAME + if (!ACPI_COMPARE_NAMESEG (mapped_table->signature, signature)) { osl_unmap_table(mapped_table); mapped_table = NULL; @@ -1086,8 +1086,8 @@ osl_map_table(acpi_size address, return (AE_BAD_SIGNATURE); } } else - if (!ACPI_COMPARE_NAME(signature, mapped_table->signature)) - { + if (!ACPI_COMPARE_NAMESEG + (signature, mapped_table->signature)) { acpi_os_unmap_memory(mapped_table, sizeof(struct acpi_table_header)); return (AE_BAD_SIGNATURE); @@ -1236,7 +1236,7 @@ osl_read_table_from_file(char *filename, status = AE_BAD_SIGNATURE; goto exit; } - } else if (!ACPI_COMPARE_NAME(signature, header.signature)) { + } else if (!ACPI_COMPARE_NAMESEG(signature, header.signature)) { fprintf(stderr, "Incorrect signature: Expecting %4.4s, found %4.4s\n", signature, header.signature); @@ -1329,7 +1329,7 @@ osl_get_customized_table(char *pathname, /* Ignore meaningless files */ - if (!ACPI_COMPARE_NAME(filename, signature)) { + if (!ACPI_COMPARE_NAMESEG(filename, signature)) { continue; } diff --git a/tools/power/acpi/tools/acpidump/apdump.c b/tools/power/acpi/tools/acpidump/apdump.c index e256c2ac5ddc..9dfcc0329d34 100644 --- a/tools/power/acpi/tools/acpidump/apdump.c +++ b/tools/power/acpi/tools/acpidump/apdump.c @@ -310,9 +310,9 @@ int ap_dump_table_by_name(char *signature) /* To be friendly, handle tables whose signatures do not match the name */ - if (ACPI_COMPARE_NAME(local_signature, "FADT")) { + if (ACPI_COMPARE_NAMESEG(local_signature, "FADT")) { strcpy(local_signature, ACPI_SIG_FADT); - } else if (ACPI_COMPARE_NAME(local_signature, "MADT")) { + } else if (ACPI_COMPARE_NAMESEG(local_signature, "MADT")) { strcpy(local_signature, ACPI_SIG_MADT); } -- cgit v1.2.3-59-g8ed1b From 3278675567dfb901d831d46849c386a4f932905e Mon Sep 17 00:00:00 2001 From: Bob Moore Date: Mon, 8 Apr 2019 13:42:25 -0700 Subject: ACPICA: Rename nameseg length macro/define for clarity ACPICA commit 24870bd9e73d71e2a1ff0a1e94519f8f8409e57d ACPI_NAME_SIZE changed to ACPI_NAMESEG_SIZE This clarifies that this is the length of an individual nameseg, not the length of a generic namestring/namepath. Improves understanding of the code. Link: https://github.com/acpica/acpica/commit/24870bd9 Signed-off-by: Bob Moore Signed-off-by: Erik Schmauss Signed-off-by: Rafael J. Wysocki --- drivers/acpi/acpi_configfs.c | 4 ++-- drivers/acpi/acpica/aclocal.h | 4 ++-- drivers/acpi/acpica/dbnames.c | 2 +- drivers/acpi/acpica/evgpeinit.c | 4 ++-- drivers/acpi/acpica/exnames.c | 6 +++--- drivers/acpi/acpica/nsaccess.c | 2 +- drivers/acpi/acpica/nsdump.c | 2 +- drivers/acpi/acpica/nsnames.c | 6 +++--- drivers/acpi/acpica/nsrepair2.c | 2 +- drivers/acpi/acpica/nsutils.c | 10 +++++----- drivers/acpi/acpica/psargs.c | 8 ++++---- drivers/acpi/acpica/tbfind.c | 18 +++++++++--------- drivers/acpi/acpica/tbprint.c | 4 ++-- drivers/acpi/acpica/utascii.c | 2 +- drivers/acpi/acpica/utdecode.c | 2 +- drivers/acpi/acpica/utstring.c | 2 +- drivers/acpi/sysfs.c | 6 +++--- drivers/firmware/iscsi_ibft.c | 2 +- .../thermal/intel/int340x_thermal/acpi_thermal_rel.c | 2 +- include/acpi/actbl.h | 4 ++-- include/acpi/actypes.h | 8 ++++---- .../power/acpi/os_specific/service_layers/oslinuxtbl.c | 14 +++++++------- tools/power/acpi/tools/acpidump/apdump.c | 4 ++-- tools/power/acpi/tools/acpidump/apfiles.c | 4 ++-- 24 files changed, 61 insertions(+), 61 deletions(-) diff --git a/drivers/acpi/acpi_configfs.c b/drivers/acpi/acpi_configfs.c index 81bfc6197293..f92033661239 100644 --- a/drivers/acpi/acpi_configfs.c +++ b/drivers/acpi/acpi_configfs.c @@ -109,7 +109,7 @@ static ssize_t acpi_table_signature_show(struct config_item *cfg, char *str) if (!h) return -EINVAL; - return sprintf(str, "%.*s\n", ACPI_NAME_SIZE, h->signature); + return sprintf(str, "%.*s\n", ACPI_NAMESEG_SIZE, h->signature); } static ssize_t acpi_table_length_show(struct config_item *cfg, char *str) @@ -170,7 +170,7 @@ static ssize_t acpi_table_asl_compiler_id_show(struct config_item *cfg, if (!h) return -EINVAL; - return sprintf(str, "%.*s\n", ACPI_NAME_SIZE, h->asl_compiler_id); + return sprintf(str, "%.*s\n", ACPI_NAMESEG_SIZE, h->asl_compiler_id); } static ssize_t acpi_table_asl_compiler_revision_show(struct config_item *cfg, diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h index a2dfbf6b004e..13d513b81589 100644 --- a/drivers/acpi/acpica/aclocal.h +++ b/drivers/acpi/acpica/aclocal.h @@ -293,7 +293,7 @@ acpi_status (*acpi_internal_method) (struct acpi_walk_state * walk_state); * expected_return_btypes - Allowed type(s) for the return value */ struct acpi_name_info { - char name[ACPI_NAME_SIZE]; + char name[ACPI_NAMESEG_SIZE]; u16 argument_list; u8 expected_btypes; }; @@ -370,7 +370,7 @@ typedef acpi_status (*acpi_object_converter) (struct acpi_namespace_node * converted_object); struct acpi_simple_repair_info { - char name[ACPI_NAME_SIZE]; + char name[ACPI_NAMESEG_SIZE]; u32 unexpected_btypes; u32 package_index; acpi_object_converter object_converter; diff --git a/drivers/acpi/acpica/dbnames.c b/drivers/acpi/acpica/dbnames.c index 004d34d9369b..63fe30e86807 100644 --- a/drivers/acpi/acpica/dbnames.c +++ b/drivers/acpi/acpica/dbnames.c @@ -354,7 +354,7 @@ acpi_status acpi_db_find_name_in_namespace(char *name_arg) char acpi_name[5] = "____"; char *acpi_name_ptr = acpi_name; - if (strlen(name_arg) > ACPI_NAME_SIZE) { + if (strlen(name_arg) > ACPI_NAMESEG_SIZE) { acpi_os_printf("Name must be no longer than 4 characters\n"); return (AE_OK); } diff --git a/drivers/acpi/acpica/evgpeinit.c b/drivers/acpi/acpica/evgpeinit.c index c92d2f6ebe01..b04f982e59fa 100644 --- a/drivers/acpi/acpica/evgpeinit.c +++ b/drivers/acpi/acpica/evgpeinit.c @@ -292,7 +292,7 @@ acpi_ev_match_gpe_method(acpi_handle obj_handle, acpi_status status; u32 gpe_number; u8 temp_gpe_number; - char name[ACPI_NAME_SIZE + 1]; + char name[ACPI_NAMESEG_SIZE + 1]; u8 type; ACPI_FUNCTION_TRACE(ev_match_gpe_method); @@ -310,7 +310,7 @@ acpi_ev_match_gpe_method(acpi_handle obj_handle, * 1) Extract the method name and null terminate it */ ACPI_MOVE_32_TO_32(name, &method_node->name.integer); - name[ACPI_NAME_SIZE] = 0; + name[ACPI_NAMESEG_SIZE] = 0; /* 2) Name must begin with an underscore */ diff --git a/drivers/acpi/acpica/exnames.c b/drivers/acpi/acpica/exnames.c index bd68d66e89f0..6b76be5212a4 100644 --- a/drivers/acpi/acpica/exnames.c +++ b/drivers/acpi/acpica/exnames.c @@ -53,10 +53,10 @@ static char *acpi_ex_allocate_name_string(u32 prefix_count, u32 num_name_segs) /* Special case for root */ - size_needed = 1 + (ACPI_NAME_SIZE * num_name_segs) + 2 + 1; + size_needed = 1 + (ACPI_NAMESEG_SIZE * num_name_segs) + 2 + 1; } else { size_needed = - prefix_count + (ACPI_NAME_SIZE * num_name_segs) + 2 + 1; + prefix_count + (ACPI_NAMESEG_SIZE * num_name_segs) + 2 + 1; } /* @@ -141,7 +141,7 @@ static acpi_status acpi_ex_name_segment(u8 ** in_aml_address, char *name_string) } for (index = 0; - (index < ACPI_NAME_SIZE) + (index < ACPI_NAMESEG_SIZE) && (acpi_ut_valid_name_char(*aml_address, 0)); index++) { char_buf[index] = *aml_address++; } diff --git a/drivers/acpi/acpica/nsaccess.c b/drivers/acpi/acpica/nsaccess.c index 75192b958544..7b855603f81a 100644 --- a/drivers/acpi/acpica/nsaccess.c +++ b/drivers/acpi/acpica/nsaccess.c @@ -683,7 +683,7 @@ acpi_ns_lookup(union acpi_generic_state *scope_info, /* Point to next name segment and make this node current */ - path += ACPI_NAME_SIZE; + path += ACPI_NAMESEG_SIZE; current_node = this_node; } diff --git a/drivers/acpi/acpica/nsdump.c b/drivers/acpi/acpica/nsdump.c index 15070bd0c28a..1b12c172e115 100644 --- a/drivers/acpi/acpica/nsdump.c +++ b/drivers/acpi/acpica/nsdump.c @@ -70,7 +70,7 @@ void acpi_ns_print_pathname(u32 num_segments, const char *pathname) acpi_os_printf("?"); } - pathname += ACPI_NAME_SIZE; + pathname += ACPI_NAMESEG_SIZE; num_segments--; if (num_segments) { acpi_os_printf("."); diff --git a/drivers/acpi/acpica/nsnames.c b/drivers/acpi/acpica/nsnames.c index c384320a0f26..370bbc867745 100644 --- a/drivers/acpi/acpica/nsnames.c +++ b/drivers/acpi/acpica/nsnames.c @@ -109,7 +109,7 @@ acpi_ns_handle_to_name(acpi_handle target_handle, struct acpi_buffer *buffer) node_name = acpi_ut_get_node_name(node); ACPI_COPY_NAMESEG(buffer->pointer, node_name); - ((char *)buffer->pointer)[ACPI_NAME_SIZE] = 0; + ((char *)buffer->pointer)[ACPI_NAMESEG_SIZE] = 0; ACPI_DEBUG_PRINT((ACPI_DB_EXEC, "%4.4s\n", (char *)buffer->pointer)); return_ACPI_STATUS(AE_OK); @@ -198,7 +198,7 @@ acpi_ns_build_normalized_path(struct acpi_namespace_node *node, char *full_path, u32 path_size, u8 no_trailing) { u32 length = 0, i; - char name[ACPI_NAME_SIZE]; + char name[ACPI_NAMESEG_SIZE]; u8 do_no_trailing; char c, *left, *right; struct acpi_namespace_node *next_node; @@ -446,7 +446,7 @@ static void acpi_ns_normalize_pathname(char *original_path) /* Do one nameseg at a time */ - for (i = 0; (i < ACPI_NAME_SIZE) && *input_path; i++) { + for (i = 0; (i < ACPI_NAMESEG_SIZE) && *input_path; i++) { if ((i == 0) || (*input_path != '_')) { /* First char is allowed to be underscore */ *new_path = *input_path; new_path++; diff --git a/drivers/acpi/acpica/nsrepair2.c b/drivers/acpi/acpica/nsrepair2.c index 4c285e918465..8d776256b213 100644 --- a/drivers/acpi/acpica/nsrepair2.c +++ b/drivers/acpi/acpica/nsrepair2.c @@ -25,7 +25,7 @@ acpi_status (*acpi_repair_function) (struct acpi_evaluate_info * info, return_object_ptr); typedef struct acpi_repair_info { - char name[ACPI_NAME_SIZE]; + char name[ACPI_NAMESEG_SIZE]; acpi_repair_function repair_function; } acpi_repair_info; diff --git a/drivers/acpi/acpica/nsutils.c b/drivers/acpi/acpica/nsutils.c index 6f5940b02a4f..6bc90d46db5c 100644 --- a/drivers/acpi/acpica/nsutils.c +++ b/drivers/acpi/acpica/nsutils.c @@ -178,7 +178,7 @@ void acpi_ns_get_internal_name_length(struct acpi_namestring_info *info) } } - info->length = (ACPI_NAME_SIZE * info->num_segments) + + info->length = (ACPI_NAMESEG_SIZE * info->num_segments) + 4 + info->num_carats; info->next_external_char = next_external_char; @@ -249,7 +249,7 @@ acpi_status acpi_ns_build_internal_name(struct acpi_namestring_info *info) /* Build the name (minus path separators) */ for (; num_segments; num_segments--) { - for (i = 0; i < ACPI_NAME_SIZE; i++) { + for (i = 0; i < ACPI_NAMESEG_SIZE; i++) { if (ACPI_IS_PATH_SEPARATOR(*external_name) || (*external_name == 0)) { @@ -274,7 +274,7 @@ acpi_status acpi_ns_build_internal_name(struct acpi_namestring_info *info) /* Move on the next segment */ external_name++; - result += ACPI_NAME_SIZE; + result += ACPI_NAMESEG_SIZE; } /* Terminate the string */ @@ -493,8 +493,8 @@ acpi_ns_externalize_name(u32 internal_name_length, &internal_name[names_index]); acpi_ut_repair_name(&(*converted_name)[j]); - j += ACPI_NAME_SIZE; - names_index += ACPI_NAME_SIZE; + j += ACPI_NAMESEG_SIZE; + names_index += ACPI_NAMESEG_SIZE; } } diff --git a/drivers/acpi/acpica/psargs.c b/drivers/acpi/acpica/psargs.c index 9d9d442cd999..e62c7897fdf1 100644 --- a/drivers/acpi/acpica/psargs.c +++ b/drivers/acpi/acpica/psargs.c @@ -150,21 +150,21 @@ char *acpi_ps_get_next_namestring(struct acpi_parse_state *parser_state) /* Two name segments */ - end += 1 + (2 * ACPI_NAME_SIZE); + end += 1 + (2 * ACPI_NAMESEG_SIZE); break; case AML_MULTI_NAME_PREFIX: /* Multiple name segments, 4 chars each, count in next byte */ - end += 2 + (*(end + 1) * ACPI_NAME_SIZE); + end += 2 + (*(end + 1) * ACPI_NAMESEG_SIZE); break; default: /* Single name segment */ - end += ACPI_NAME_SIZE; + end += ACPI_NAMESEG_SIZE; break; } @@ -522,7 +522,7 @@ static union acpi_parse_object *acpi_ps_get_next_field(struct acpi_parse_state ACPI_MOVE_32_TO_32(&name, parser_state->aml); acpi_ps_set_name(field, name); - parser_state->aml += ACPI_NAME_SIZE; + parser_state->aml += ACPI_NAMESEG_SIZE; ASL_CV_CAPTURE_COMMENTS_ONLY(parser_state); diff --git a/drivers/acpi/acpica/tbfind.c b/drivers/acpi/acpica/tbfind.c index ddc88aaca376..b2abb40023a6 100644 --- a/drivers/acpi/acpica/tbfind.c +++ b/drivers/acpi/acpica/tbfind.c @@ -65,7 +65,7 @@ acpi_tb_find_table(char *signature, (void)acpi_ut_acquire_mutex(ACPI_MTX_TABLES); for (i = 0; i < acpi_gbl_root_table_list.current_table_count; ++i) { if (memcmp(&(acpi_gbl_root_table_list.tables[i].signature), - header.signature, ACPI_NAME_SIZE)) { + header.signature, ACPI_NAMESEG_SIZE)) { /* Not the requested table */ @@ -94,14 +94,14 @@ acpi_tb_find_table(char *signature, if (!memcmp (acpi_gbl_root_table_list.tables[i].pointer->signature, - header.signature, ACPI_NAME_SIZE) && (!oem_id[0] - || - !memcmp - (acpi_gbl_root_table_list. - tables[i].pointer-> - oem_id, - header.oem_id, - ACPI_OEM_ID_SIZE)) + header.signature, ACPI_NAMESEG_SIZE) && (!oem_id[0] + || + !memcmp + (acpi_gbl_root_table_list. + tables[i]. + pointer->oem_id, + header.oem_id, + ACPI_OEM_ID_SIZE)) && (!oem_table_id[0] || !memcmp(acpi_gbl_root_table_list.tables[i].pointer-> oem_table_id, header.oem_table_id, diff --git a/drivers/acpi/acpica/tbprint.c b/drivers/acpi/acpica/tbprint.c index 0bc18fd5cd71..4764f849cb78 100644 --- a/drivers/acpi/acpica/tbprint.c +++ b/drivers/acpi/acpica/tbprint.c @@ -69,10 +69,10 @@ acpi_tb_cleanup_table_header(struct acpi_table_header *out_header, memcpy(out_header, header, sizeof(struct acpi_table_header)); - acpi_tb_fix_string(out_header->signature, ACPI_NAME_SIZE); + acpi_tb_fix_string(out_header->signature, ACPI_NAMESEG_SIZE); acpi_tb_fix_string(out_header->oem_id, ACPI_OEM_ID_SIZE); acpi_tb_fix_string(out_header->oem_table_id, ACPI_OEM_TABLE_ID_SIZE); - acpi_tb_fix_string(out_header->asl_compiler_id, ACPI_NAME_SIZE); + acpi_tb_fix_string(out_header->asl_compiler_id, ACPI_NAMESEG_SIZE); } /******************************************************************************* diff --git a/drivers/acpi/acpica/utascii.c b/drivers/acpi/acpica/utascii.c index 79d7426fd7bf..f6cd7d4f698b 100644 --- a/drivers/acpi/acpica/utascii.c +++ b/drivers/acpi/acpica/utascii.c @@ -30,7 +30,7 @@ u8 acpi_ut_valid_nameseg(char *name) /* Validate each character in the signature */ - for (i = 0; i < ACPI_NAME_SIZE; i++) { + for (i = 0; i < ACPI_NAMESEG_SIZE; i++) { if (!acpi_ut_valid_name_char(name[i], i)) { return (FALSE); } diff --git a/drivers/acpi/acpica/utdecode.c b/drivers/acpi/acpica/utdecode.c index ad9f77eb554f..76e054c83c39 100644 --- a/drivers/acpi/acpica/utdecode.c +++ b/drivers/acpi/acpica/utdecode.c @@ -239,7 +239,7 @@ const char *acpi_ut_get_node_name(void *object) { struct acpi_namespace_node *node = (struct acpi_namespace_node *)object; - /* Must return a string of exactly 4 characters == ACPI_NAME_SIZE */ + /* Must return a string of exactly 4 characters == ACPI_NAMESEG_SIZE */ if (!object) { return ("NULL"); diff --git a/drivers/acpi/acpica/utstring.c b/drivers/acpi/acpica/utstring.c index 927797355da9..c39b5483045d 100644 --- a/drivers/acpi/acpica/utstring.c +++ b/drivers/acpi/acpica/utstring.c @@ -149,7 +149,7 @@ void acpi_ut_repair_name(char *name) /* Check each character in the name */ - for (i = 0; i < ACPI_NAME_SIZE; i++) { + for (i = 0; i < ACPI_NAMESEG_SIZE; i++) { if (acpi_ut_valid_name_char(name[i], i)) { continue; } diff --git a/drivers/acpi/sysfs.c b/drivers/acpi/sysfs.c index 262d6ee4735d..75948a3f1a20 100644 --- a/drivers/acpi/sysfs.c +++ b/drivers/acpi/sysfs.c @@ -327,9 +327,9 @@ static struct kobject *hotplug_kobj; struct acpi_table_attr { struct bin_attribute attr; - char name[ACPI_NAME_SIZE]; + char name[ACPI_NAMESEG_SIZE]; int instance; - char filename[ACPI_NAME_SIZE+ACPI_INST_SIZE]; + char filename[ACPI_NAMESEG_SIZE+ACPI_INST_SIZE]; struct list_head node; }; @@ -383,7 +383,7 @@ static int acpi_table_attr_init(struct kobject *tables_obj, } ACPI_COPY_NAMESEG(table_attr->filename, table_header->signature); - table_attr->filename[ACPI_NAME_SIZE] = '\0'; + table_attr->filename[ACPI_NAMESEG_SIZE] = '\0'; if (table_attr->instance > 1 || (table_attr->instance == 1 && !acpi_get_table (table_header->signature, 2, &header))) { diff --git a/drivers/firmware/iscsi_ibft.c b/drivers/firmware/iscsi_ibft.c index c51462f5aa1e..a5dc0629f225 100644 --- a/drivers/firmware/iscsi_ibft.c +++ b/drivers/firmware/iscsi_ibft.c @@ -425,7 +425,7 @@ static ssize_t ibft_attr_show_acpitbl(void *data, int type, char *buf) switch (type) { case ISCSI_BOOT_ACPITBL_SIGNATURE: - str += sprintf_string(str, ACPI_NAME_SIZE, + str += sprintf_string(str, ACPI_NAMESEG_SIZE, entry->header->header.signature); break; case ISCSI_BOOT_ACPITBL_OEM_ID: diff --git a/drivers/thermal/intel/int340x_thermal/acpi_thermal_rel.c b/drivers/thermal/intel/int340x_thermal/acpi_thermal_rel.c index 45e7e5cbdffb..7c71ffb733a1 100644 --- a/drivers/thermal/intel/int340x_thermal/acpi_thermal_rel.c +++ b/drivers/thermal/intel/int340x_thermal/acpi_thermal_rel.c @@ -230,7 +230,7 @@ static void get_single_name(acpi_handle handle, char *name) if (ACPI_FAILURE(acpi_get_name(handle, ACPI_SINGLE_NAME, &buffer))) pr_warn("Failed to get device name from acpi handle\n"); else { - memcpy(name, buffer.pointer, ACPI_NAME_SIZE); + memcpy(name, buffer.pointer, ACPI_NAMESEG_SIZE); kfree(buffer.pointer); } } diff --git a/include/acpi/actbl.h b/include/acpi/actbl.h index 65cc9cbf1141..d568128025df 100644 --- a/include/acpi/actbl.h +++ b/include/acpi/actbl.h @@ -66,14 +66,14 @@ ******************************************************************************/ struct acpi_table_header { - char signature[ACPI_NAME_SIZE]; /* ASCII table signature */ + char signature[ACPI_NAMESEG_SIZE]; /* ASCII table signature */ u32 length; /* Length of table in bytes, including this header */ u8 revision; /* ACPI Specification minor version number */ u8 checksum; /* To make sum of entire table == 0 */ char oem_id[ACPI_OEM_ID_SIZE]; /* ASCII OEM identification */ char oem_table_id[ACPI_OEM_TABLE_ID_SIZE]; /* ASCII OEM table identification */ u32 oem_revision; /* OEM revision number */ - char asl_compiler_id[ACPI_NAME_SIZE]; /* ASCII ASL compiler vendor ID */ + char asl_compiler_id[ACPI_NAMESEG_SIZE]; /* ASCII ASL compiler vendor ID */ u32 asl_compiler_revision; /* ASL compiler version */ }; diff --git a/include/acpi/actypes.h b/include/acpi/actypes.h index cb51172a47a3..ad6892a24015 100644 --- a/include/acpi/actypes.h +++ b/include/acpi/actypes.h @@ -375,7 +375,7 @@ typedef u64 acpi_physical_address; /* Names within the namespace are 4 bytes long */ -#define ACPI_NAME_SIZE 4 +#define ACPI_NAMESEG_SIZE 4 /* Fixed by ACPI spec */ #define ACPI_PATH_SEGMENT_LENGTH 5 /* 4 chars for name + 1 char for separator */ #define ACPI_PATH_SEPARATOR '.' @@ -518,8 +518,8 @@ typedef u64 acpi_integer; #define ACPI_COMPARE_NAMESEG(a,b) (*ACPI_CAST_PTR (u32, (a)) == *ACPI_CAST_PTR (u32, (b))) #define ACPI_COPY_NAMESEG(dest,src) (*ACPI_CAST_PTR (u32, (dest)) = *ACPI_CAST_PTR (u32, (src))) #else -#define ACPI_COMPARE_NAMESEG(a,b) (!strncmp (ACPI_CAST_PTR (char, (a)), ACPI_CAST_PTR (char, (b)), ACPI_NAME_SIZE)) -#define ACPI_COPY_NAMESEG(dest,src) (strncpy (ACPI_CAST_PTR (char, (dest)), ACPI_CAST_PTR (char, (src)), ACPI_NAME_SIZE)) +#define ACPI_COMPARE_NAMESEG(a,b) (!strncmp (ACPI_CAST_PTR (char, (a)), ACPI_CAST_PTR (char, (b)), ACPI_NAMESEG_SIZE)) +#define ACPI_COPY_NAMESEG(dest,src) (strncpy (ACPI_CAST_PTR (char, (dest)), ACPI_CAST_PTR (char, (src)), ACPI_NAMESEG_SIZE)) #endif /* Support for the special RSDP signature (8 characters) */ @@ -529,7 +529,7 @@ typedef u64 acpi_integer; /* Support for OEMx signature (x can be any character) */ #define ACPI_IS_OEM_SIG(a) (!strncmp (ACPI_CAST_PTR (char, (a)), ACPI_OEM_NAME, 3) &&\ - strnlen (a, ACPI_NAME_SIZE) == ACPI_NAME_SIZE) + strnlen (a, ACPI_NAMESEG_SIZE) == ACPI_NAMESEG_SIZE) /* * Algorithm to obtain access bit width. diff --git a/tools/power/acpi/os_specific/service_layers/oslinuxtbl.c b/tools/power/acpi/os_specific/service_layers/oslinuxtbl.c index 2686d858225a..d1f3d44e315e 100644 --- a/tools/power/acpi/os_specific/service_layers/oslinuxtbl.c +++ b/tools/power/acpi/os_specific/service_layers/oslinuxtbl.c @@ -19,7 +19,7 @@ ACPI_MODULE_NAME("oslinuxtbl") typedef struct osl_table_info { struct osl_table_info *next; u32 instance; - char signature[ACPI_NAME_SIZE]; + char signature[ACPI_NAMESEG_SIZE]; } osl_table_info; @@ -995,7 +995,7 @@ static acpi_status osl_list_customized_tables(char *directory) { void *table_dir; u32 instance; - char temp_name[ACPI_NAME_SIZE]; + char temp_name[ACPI_NAMESEG_SIZE]; char *filename; acpi_status status = AE_OK; @@ -1158,15 +1158,15 @@ osl_table_name_from_file(char *filename, char *signature, u32 *instance) /* Ignore meaningless files */ - if (strlen(filename) < ACPI_NAME_SIZE) { + if (strlen(filename) < ACPI_NAMESEG_SIZE) { return (AE_BAD_SIGNATURE); } /* Extract instance number */ - if (isdigit((int)filename[ACPI_NAME_SIZE])) { - sscanf(&filename[ACPI_NAME_SIZE], "%u", instance); - } else if (strlen(filename) != ACPI_NAME_SIZE) { + if (isdigit((int)filename[ACPI_NAMESEG_SIZE])) { + sscanf(&filename[ACPI_NAMESEG_SIZE], "%u", instance); + } else if (strlen(filename) != ACPI_NAMESEG_SIZE) { return (AE_BAD_SIGNATURE); } else { *instance = 0; @@ -1311,7 +1311,7 @@ osl_get_customized_table(char *pathname, { void *table_dir; u32 current_instance = 0; - char temp_name[ACPI_NAME_SIZE]; + char temp_name[ACPI_NAMESEG_SIZE]; char table_filename[PATH_MAX]; char *filename; acpi_status status; diff --git a/tools/power/acpi/tools/acpidump/apdump.c b/tools/power/acpi/tools/acpidump/apdump.c index 9dfcc0329d34..820baeb5092b 100644 --- a/tools/power/acpi/tools/acpidump/apdump.c +++ b/tools/power/acpi/tools/acpidump/apdump.c @@ -289,14 +289,14 @@ int ap_dump_table_by_address(char *ascii_address) int ap_dump_table_by_name(char *signature) { - char local_signature[ACPI_NAME_SIZE + 1]; + char local_signature[ACPI_NAMESEG_SIZE + 1]; u32 instance; struct acpi_table_header *table; acpi_physical_address address; acpi_status status; int table_status; - if (strlen(signature) != ACPI_NAME_SIZE) { + if (strlen(signature) != ACPI_NAMESEG_SIZE) { fprintf(stderr, "Invalid table signature [%s]: must be exactly 4 characters\n", signature); diff --git a/tools/power/acpi/tools/acpidump/apfiles.c b/tools/power/acpi/tools/acpidump/apfiles.c index 8abc8f998abd..a42cfcaa3293 100644 --- a/tools/power/acpi/tools/acpidump/apfiles.c +++ b/tools/power/acpi/tools/acpidump/apfiles.c @@ -97,7 +97,7 @@ int ap_open_output_file(char *pathname) int ap_write_to_binary_file(struct acpi_table_header *table, u32 instance) { - char filename[ACPI_NAME_SIZE + 16]; + char filename[ACPI_NAMESEG_SIZE + 16]; char instance_str[16]; ACPI_FILE file; acpi_size actual; @@ -119,7 +119,7 @@ int ap_write_to_binary_file(struct acpi_table_header *table, u32 instance) filename[1] = (char)tolower((int)filename[1]); filename[2] = (char)tolower((int)filename[2]); filename[3] = (char)tolower((int)filename[3]); - filename[ACPI_NAME_SIZE] = 0; + filename[ACPI_NAMESEG_SIZE] = 0; /* Handle multiple SSDts - create different filenames for each */ -- cgit v1.2.3-59-g8ed1b From f49c90e8958ef2745224e36c3158ead27289d645 Mon Sep 17 00:00:00 2001 From: Erik Schmauss Date: Mon, 8 Apr 2019 13:42:27 -0700 Subject: ACPICA: utilities: fix spelling of PCC to platform_comm_channel ACPICA commit 5e5c349e73982aea5d9f74416c0b2eea1b0767a1 Link: https://github.com/acpica/acpica/commit/5e5c349e Signed-off-by: Erik Schmauss Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki --- drivers/acpi/acpica/utdecode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/acpica/utdecode.c b/drivers/acpi/acpica/utdecode.c index 76e054c83c39..65beaa237669 100644 --- a/drivers/acpi/acpica/utdecode.c +++ b/drivers/acpi/acpica/utdecode.c @@ -78,7 +78,7 @@ const char *acpi_gbl_region_types[ACPI_NUM_PREDEFINED_REGIONS] = { "IPMI", /* 0x07 */ "GeneralPurposeIo", /* 0x08 */ "GenericSerialBus", /* 0x09 */ - "PCC" /* 0x0A */ + "PlatformCommChannel" /* 0x0A */ }; const char *acpi_ut_get_region_name(u8 space_id) -- cgit v1.2.3-59-g8ed1b From 985d5124bfb0773edb8353237e5e8ddb614c3442 Mon Sep 17 00:00:00 2001 From: Bob Moore Date: Mon, 8 Apr 2019 13:42:28 -0700 Subject: ACPICA: Update version to 20190329 ACPICA commit 802ec363be67580f52251219ef90613008495392 Version 20190329. Link: https://github.com/acpica/acpica/commit/802ec363 Signed-off-by: Bob Moore Signed-off-by: Erik Schmauss Signed-off-by: Rafael J. Wysocki --- include/acpi/acpixf.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h index 24dbb4e742a6..60b4067391e3 100644 --- a/include/acpi/acpixf.h +++ b/include/acpi/acpixf.h @@ -12,7 +12,7 @@ /* Current ACPICA subsystem version in YYYYMMDD format */ -#define ACPI_CA_VERSION 0x20190215 +#define ACPI_CA_VERSION 0x20190329 #include #include -- cgit v1.2.3-59-g8ed1b From df9271d69f4016c1169699de9a826745688103bd Mon Sep 17 00:00:00 2001 From: Erik Schmauss Date: Mon, 8 Apr 2019 13:42:29 -0700 Subject: ACPICA: Namespace: add check to avoid null pointer dereference ACPICA commit 7586a625f9c34c3169efd88470192bf63119e31a Some ACPICA userspace tools call acpi_ut_subsystem_shutdown() during cleanup and dereference a null pointer when cleaning up the namespace. Link: https://github.com/acpica/acpica/commit/7586a625 Signed-off-by: Erik Schmauss Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki --- drivers/acpi/acpica/nsalloc.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/acpi/acpica/nsalloc.c b/drivers/acpi/acpica/nsalloc.c index 5470213b8e64..6eb63db72249 100644 --- a/drivers/acpi/acpica/nsalloc.c +++ b/drivers/acpi/acpica/nsalloc.c @@ -74,6 +74,10 @@ void acpi_ns_delete_node(struct acpi_namespace_node *node) ACPI_FUNCTION_NAME(ns_delete_node); + if (!node) { + return_VOID; + } + /* Detach an object if there is one */ acpi_ns_detach_object(node); -- cgit v1.2.3-59-g8ed1b From 6c6a828f86d67c157c7a2b26d46ebca0ed0d9c47 Mon Sep 17 00:00:00 2001 From: Bob Moore Date: Mon, 8 Apr 2019 13:42:30 -0700 Subject: ACPICA: Update version to 20190405 ACPICA commit 0c1495275a35071b957ab59549761c6cd3f413b7 Version 20190405. Link: https://github.com/acpica/acpica/commit/0c149527 Signed-off-by: Bob Moore Signed-off-by: Erik Schmauss Signed-off-by: Rafael J. Wysocki --- include/acpi/acpixf.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h index 60b4067391e3..3b1b1d0e4c33 100644 --- a/include/acpi/acpixf.h +++ b/include/acpi/acpixf.h @@ -12,7 +12,7 @@ /* Current ACPICA subsystem version in YYYYMMDD format */ -#define ACPI_CA_VERSION 0x20190329 +#define ACPI_CA_VERSION 0x20190405 #include #include -- cgit v1.2.3-59-g8ed1b From 13e962140be671f31a011543f11477af67a6c33e Mon Sep 17 00:00:00 2001 From: Zhang Rui Date: Tue, 2 Apr 2019 21:38:32 +0800 Subject: ACPI: button: reinitialize button state upon resume With commit dfa46c50f65b ("ACPI / button: Fix an issue in button.lid_init_state=ignore mode"), the lid device is considered to be not compliant to SW_LID if the Lid state is unchanged when updating it. This is not wrong, but we overlooked the resume case, where Lid state is updated unconditionally in the button driver .resume() callback. And this results in warning message "ACPI: button: The lid device is not compliant to SW_LID." after resume, if the machine is suspended with Lid opened and then resumed with Lid opened. Fix this by flushing the cached lid state before updating the Lid device in .resume() callback. Fixes: dfa46c50f65b ("ACPI / button: Fix an issue in button.lid_init_state=ignore mode") Reported-and-tested-by: Zhao Lijian Signed-off-by: Zhang Rui Signed-off-by: Rafael J. Wysocki --- drivers/acpi/button.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c index a19ff3977ac4..623998a8d722 100644 --- a/drivers/acpi/button.c +++ b/drivers/acpi/button.c @@ -456,8 +456,11 @@ static int acpi_button_resume(struct device *dev) struct acpi_button *button = acpi_driver_data(device); button->suspended = false; - if (button->type == ACPI_BUTTON_TYPE_LID && button->input->users) + if (button->type == ACPI_BUTTON_TYPE_LID && button->input->users) { + button->last_state = !!acpi_lid_evaluate_state(device); + button->last_time = ktime_get(); acpi_lid_initialize_state(device); + } return 0; } #endif -- cgit v1.2.3-59-g8ed1b From c8afd03486c26accdda4846e5561aa3f8e862a9d Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Thu, 18 Apr 2019 13:39:33 +0200 Subject: ACPI / LPSS: Use acpi_lpss_* instead of acpi_subsys_* functions for hibernate Commit 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from resume_noirq") makes acpi_lpss_{suspend_late,resume_early}() bail early on BYT/CHT as resume_from_noirq is set. This means that on resume from hibernate dw_i2c_plat_resume() doesn't get called by the restore_early callback, acpi_lpss_resume_early(). Instead it should be called by the restore_noirq callback matching how things are done when resume_from_noirq is set and we are doing a regular resume. Change the restore_noirq callback to acpi_lpss_resume_noirq so that dw_i2c_plat_resume() gets properly called when resume_from_noirq is set and we are resuming from hibernate. Likewise also change the poweroff_noirq callback so that dw_i2c_plat_suspend gets called properly. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202139 Fixes: 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from resume_noirq") Reported-by: Kai-Heng Feng Signed-off-by: Hans de Goede Cc: 4.20+ # 4.20+ Signed-off-by: Rafael J. Wysocki --- drivers/acpi/acpi_lpss.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c index 1e2a10a06b9d..cf768608437e 100644 --- a/drivers/acpi/acpi_lpss.c +++ b/drivers/acpi/acpi_lpss.c @@ -1142,8 +1142,8 @@ static struct dev_pm_domain acpi_lpss_pm_domain = { .thaw_noirq = acpi_subsys_thaw_noirq, .poweroff = acpi_subsys_suspend, .poweroff_late = acpi_lpss_suspend_late, - .poweroff_noirq = acpi_subsys_suspend_noirq, - .restore_noirq = acpi_subsys_resume_noirq, + .poweroff_noirq = acpi_lpss_suspend_noirq, + .restore_noirq = acpi_lpss_resume_noirq, .restore_early = acpi_lpss_resume_early, #endif .runtime_suspend = acpi_lpss_runtime_suspend, -- cgit v1.2.3-59-g8ed1b From c7d5f21e8d184f255785e02760139037a97fd796 Mon Sep 17 00:00:00 2001 From: "Gustavo A. R. Silva" Date: Mon, 22 Apr 2019 11:39:34 -0500 Subject: ACPI: event: replace strcpy() by strscpy() The strcpy() function is being deprecated. Replace it by the safer strscpy() and fix the following Coverity warnings: "You might overrun the 15-character fixed-size string event->bus_id by copying bus_id without checking the length." "You might overrun the 20-character fixed-size string event->device_class by copying device_class without checking the length." Addresses-Coverity-ID: 139001 ("Copy into fixed size buffer") Signed-off-by: Gustavo A. R. Silva Signed-off-by: Rafael J. Wysocki --- drivers/acpi/event.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/event.c b/drivers/acpi/event.c index 5a127f3f2d5c..47f21599f2ab 100644 --- a/drivers/acpi/event.c +++ b/drivers/acpi/event.c @@ -131,8 +131,8 @@ int acpi_bus_generate_netlink_event(const char *device_class, event = nla_data(attr); memset(event, 0, sizeof(struct acpi_genl_event)); - strcpy(event->device_class, device_class); - strcpy(event->bus_id, bus_id); + strscpy(event->device_class, device_class, sizeof(event->device_class)); + strscpy(event->bus_id, bus_id, sizeof(event->bus_id)); event->type = type; event->data = data; -- cgit v1.2.3-59-g8ed1b From b0f65b917987dee71d0b1d3c65c0b52db00a55e0 Mon Sep 17 00:00:00 2001 From: Kefeng Wang Date: Tue, 23 Apr 2019 15:49:56 +0800 Subject: ACPI / DPTF: Use dev_get_drvdata() Skip conversion to platform_device and use dev_get_drvdata() directly. Signed-off-by: Kefeng Wang [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki --- drivers/acpi/dptf/dptf_power.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/acpi/dptf/dptf_power.c b/drivers/acpi/dptf/dptf_power.c index e1c242568341..0c081390930a 100644 --- a/drivers/acpi/dptf/dptf_power.c +++ b/drivers/acpi/dptf/dptf_power.c @@ -31,8 +31,7 @@ static ssize_t name##_show(struct device *dev,\ struct device_attribute *attr,\ char *buf)\ {\ - struct platform_device *pdev = to_platform_device(dev);\ - struct acpi_device *acpi_dev = platform_get_drvdata(pdev);\ + struct acpi_device *acpi_dev = dev_get_drvdata(dev);\ unsigned long long val;\ acpi_status status;\ \ -- cgit v1.2.3-59-g8ed1b From fe066621c7966fe47fa17c6be6fd81adb3c0509f Mon Sep 17 00:00:00 2001 From: YueHaibing Date: Fri, 12 Apr 2019 23:19:11 +0800 Subject: gpio: merrifield: Fix build err without CONFIG_ACPI When building CONFIG_ACPI is not set gcc warn this: drivers/gpio/gpio-merrifield.c: In function mrfld_gpio_get_pinctrl_dev_name: drivers/gpio/gpio-merrifield.c:388:19: error: dereferencing pointer to incomplete type struct acpi_device put_device(&adev->dev); ^~ Reported-by: Hulk Robot Fixes: d00d2109c367 ("gpio: merrifield: Convert to use acpi_dev_get_first_match_dev()") Suggested-by: Andy Shevchenko Signed-off-by: YueHaibing Reviewed-by: Andy Shevchenko Acked-by: Linus Walleij Signed-off-by: Rafael J. Wysocki --- drivers/gpio/gpio-merrifield.c | 2 +- include/acpi/acpi_bus.h | 4 ++++ include/linux/acpi.h | 2 ++ 3 files changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpio/gpio-merrifield.c b/drivers/gpio/gpio-merrifield.c index 2383dc78b123..3302125e5265 100644 --- a/drivers/gpio/gpio-merrifield.c +++ b/drivers/gpio/gpio-merrifield.c @@ -385,7 +385,7 @@ static const char *mrfld_gpio_get_pinctrl_dev_name(struct mrfld_gpio *priv) adev = acpi_dev_get_first_match_dev("INTC1002", NULL, -1); if (adev) { name = devm_kstrdup(priv->dev, acpi_dev_name(adev), GFP_KERNEL); - put_device(&adev->dev); + acpi_dev_put(adev); } else { name = "pinctrl-merrifield"; } diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h index f7981751ac77..2a462cf4eaa9 100644 --- a/include/acpi/acpi_bus.h +++ b/include/acpi/acpi_bus.h @@ -687,6 +687,10 @@ static inline bool acpi_device_can_poweroff(struct acpi_device *adev) adev->power.states[ACPI_STATE_D3_HOT].flags.explicit_set); } +static inline void acpi_dev_put(struct acpi_device *adev) +{ + put_device(&adev->dev); +} #else /* CONFIG_ACPI */ static inline int register_acpi_bus_type(void *bus) { return 0; } diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 392413075cc0..ca55ae00f8c9 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -675,6 +675,8 @@ acpi_dev_get_first_match_dev(const char *hid, const char *uid, s64 hrv) return NULL; } +static inline void acpi_dev_put(struct acpi_device *adev) {} + static inline bool is_acpi_node(struct fwnode_handle *fwnode) { return false; -- cgit v1.2.3-59-g8ed1b From 680e6ffa15103ab610c0fc1241d2f98c801b13e2 Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 23:30:54 +0800 Subject: Documentation: add Linux ACPI to Sphinx TOC tree Add below index.rst files for ACPI subsystem. More docs will be added later. o admin-guide/acpi/index.rst o driver-api/acpi/index.rst o firmware-guide/index.rst Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Rafael J. Wysocki --- Documentation/admin-guide/acpi/index.rst | 10 ++++++++++ Documentation/admin-guide/index.rst | 1 + Documentation/driver-api/acpi/index.rst | 7 +++++++ Documentation/driver-api/index.rst | 1 + Documentation/firmware-guide/acpi/index.rst | 9 +++++++++ Documentation/firmware-guide/index.rst | 13 +++++++++++++ Documentation/index.rst | 10 ++++++++++ 7 files changed, 51 insertions(+) create mode 100644 Documentation/admin-guide/acpi/index.rst create mode 100644 Documentation/driver-api/acpi/index.rst create mode 100644 Documentation/firmware-guide/acpi/index.rst create mode 100644 Documentation/firmware-guide/index.rst diff --git a/Documentation/admin-guide/acpi/index.rst b/Documentation/admin-guide/acpi/index.rst new file mode 100644 index 000000000000..3e041206089d --- /dev/null +++ b/Documentation/admin-guide/acpi/index.rst @@ -0,0 +1,10 @@ +============ +ACPI Support +============ + +Here we document in detail how to interact with various mechanisms in +the Linux ACPI support. + +.. toctree:: + :maxdepth: 1 + diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst index 0a491676685e..5b8286fdd91b 100644 --- a/Documentation/admin-guide/index.rst +++ b/Documentation/admin-guide/index.rst @@ -77,6 +77,7 @@ configure specific aspects of kernel behavior to your liking. LSM/index mm/index perf-security + acpi/index .. only:: subproject and html diff --git a/Documentation/driver-api/acpi/index.rst b/Documentation/driver-api/acpi/index.rst new file mode 100644 index 000000000000..898b0c60671a --- /dev/null +++ b/Documentation/driver-api/acpi/index.rst @@ -0,0 +1,7 @@ +============ +ACPI Support +============ + +.. toctree:: + :maxdepth: 2 + diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index c0b600ed9961..aa87075c7846 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -56,6 +56,7 @@ available subsections can be seen below. slimbus soundwire/index fpga/index + acpi/index .. only:: subproject and html diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst new file mode 100644 index 000000000000..0ec7d072ba22 --- /dev/null +++ b/Documentation/firmware-guide/acpi/index.rst @@ -0,0 +1,9 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============ +ACPI Support +============ + +.. toctree:: + :maxdepth: 1 + diff --git a/Documentation/firmware-guide/index.rst b/Documentation/firmware-guide/index.rst new file mode 100644 index 000000000000..5355784ca0a2 --- /dev/null +++ b/Documentation/firmware-guide/index.rst @@ -0,0 +1,13 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=============================== +The Linux kernel firmware guide +=============================== + +This section describes the ACPI subsystem in Linux from firmware perspective. + +.. toctree:: + :maxdepth: 1 + + acpi/index + diff --git a/Documentation/index.rst b/Documentation/index.rst index 80a421cb935e..fdfa85c56a50 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -35,6 +35,16 @@ trying to get it to work optimally on a given system. admin-guide/index +Firmware-related documentation +------------------------------ +The following holds information on the kernel's expectations regarding the +platform firmwares. + +.. toctree:: + :maxdepth: 2 + + firmware-guide/index + Application-developer documentation ----------------------------------- -- cgit v1.2.3-59-g8ed1b From 8a2fe04b446f909ffffadb84b886199edbe408c2 Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 01:52:44 +0800 Subject: Documentation: ACPI: move namespace.txt to firmware-guide/acpi and convert to reST This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/namespace.txt | 388 ----------------------- Documentation/firmware-guide/acpi/index.rst | 1 + Documentation/firmware-guide/acpi/namespace.rst | 400 ++++++++++++++++++++++++ 3 files changed, 401 insertions(+), 388 deletions(-) delete mode 100644 Documentation/acpi/namespace.txt create mode 100644 Documentation/firmware-guide/acpi/namespace.rst diff --git a/Documentation/acpi/namespace.txt b/Documentation/acpi/namespace.txt deleted file mode 100644 index 1860cb3865c6..000000000000 --- a/Documentation/acpi/namespace.txt +++ /dev/null @@ -1,388 +0,0 @@ -ACPI Device Tree - Representation of ACPI Namespace - -Copyright (C) 2013, Intel Corporation -Author: Lv Zheng - - -Abstract: - -The Linux ACPI subsystem converts ACPI namespace objects into a Linux -device tree under the /sys/devices/LNXSYSTEM:00 and updates it upon -receiving ACPI hotplug notification events. For each device object in this -hierarchy there is a corresponding symbolic link in the -/sys/bus/acpi/devices. -This document illustrates the structure of the ACPI device tree. - - -Credit: - -Thanks for the help from Zhang Rui and Rafael J. -Wysocki . - - -1. ACPI Definition Blocks - - The ACPI firmware sets up RSDP (Root System Description Pointer) in the - system memory address space pointing to the XSDT (Extended System - Description Table). The XSDT always points to the FADT (Fixed ACPI - Description Table) using its first entry, the data within the FADT - includes various fixed-length entries that describe fixed ACPI features - of the hardware. The FADT contains a pointer to the DSDT - (Differentiated System Descripition Table). The XSDT also contains - entries pointing to possibly multiple SSDTs (Secondary System - Description Table). - - The DSDT and SSDT data is organized in data structures called definition - blocks that contain definitions of various objects, including ACPI - control methods, encoded in AML (ACPI Machine Language). The data block - of the DSDT along with the contents of SSDTs represents a hierarchical - data structure called the ACPI namespace whose topology reflects the - structure of the underlying hardware platform. - - The relationships between ACPI System Definition Tables described above - are illustrated in the following diagram. - - +---------+ +-------+ +--------+ +------------------------+ - | RSDP | +->| XSDT | +->| FADT | | +-------------------+ | - +---------+ | +-------+ | +--------+ +-|->| DSDT | | - | Pointer | | | Entry |-+ | ...... | | | +-------------------+ | - +---------+ | +-------+ | X_DSDT |--+ | | Definition Blocks | | - | Pointer |-+ | ..... | | ...... | | +-------------------+ | - +---------+ +-------+ +--------+ | +-------------------+ | - | Entry |------------------|->| SSDT | | - +- - - -+ | +-------------------| | - | Entry | - - - - - - - -+ | | Definition Blocks | | - +- - - -+ | | +-------------------+ | - | | +- - - - - - - - - -+ | - +-|->| SSDT | | - | +-------------------+ | - | | Definition Blocks | | - | +- - - - - - - - - -+ | - +------------------------+ - | - OSPM Loading | - \|/ - +----------------+ - | ACPI Namespace | - +----------------+ - - Figure 1. ACPI Definition Blocks - - NOTE: RSDP can also contain a pointer to the RSDT (Root System - Description Table). Platforms provide RSDT to enable - compatibility with ACPI 1.0 operating systems. The OS is expected - to use XSDT, if present. - - -2. Example ACPI Namespace - - All definition blocks are loaded into a single namespace. The namespace - is a hierarchy of objects identified by names and paths. - The following naming conventions apply to object names in the ACPI - namespace: - 1. All names are 32 bits long. - 2. The first byte of a name must be one of 'A' - 'Z', '_'. - 3. Each of the remaining bytes of a name must be one of 'A' - 'Z', '0' - - '9', '_'. - 4. Names starting with '_' are reserved by the ACPI specification. - 5. The '\' symbol represents the root of the namespace (i.e. names - prepended with '\' are relative to the namespace root). - 6. The '^' symbol represents the parent of the current namespace node - (i.e. names prepended with '^' are relative to the parent of the - current namespace node). - - The figure below shows an example ACPI namespace. - - +------+ - | \ | Root - +------+ - | - | +------+ - +-| _PR | Scope(_PR): the processor namespace - | +------+ - | | - | | +------+ - | +-| CPU0 | Processor(CPU0): the first processor - | +------+ - | - | +------+ - +-| _SB | Scope(_SB): the system bus namespace - | +------+ - | | - | | +------+ - | +-| LID0 | Device(LID0); the lid device - | | +------+ - | | | - | | | +------+ - | | +-| _HID | Name(_HID, "PNP0C0D"): the hardware ID - | | | +------+ - | | | - | | | +------+ - | | +-| _STA | Method(_STA): the status control method - | | +------+ - | | - | | +------+ - | +-| PCI0 | Device(PCI0); the PCI root bridge - | +------+ - | | - | | +------+ - | +-| _HID | Name(_HID, "PNP0A08"): the hardware ID - | | +------+ - | | - | | +------+ - | +-| _CID | Name(_CID, "PNP0A03"): the compatible ID - | | +------+ - | | - | | +------+ - | +-| RP03 | Scope(RP03): the PCI0 power scope - | | +------+ - | | | - | | | +------+ - | | +-| PXP3 | PowerResource(PXP3): the PCI0 power resource - | | +------+ - | | - | | +------+ - | +-| GFX0 | Device(GFX0): the graphics adapter - | +------+ - | | - | | +------+ - | +-| _ADR | Name(_ADR, 0x00020000): the PCI bus address - | | +------+ - | | - | | +------+ - | +-| DD01 | Device(DD01): the LCD output device - | +------+ - | | - | | +------+ - | +-| _BCL | Method(_BCL): the backlight control method - | +------+ - | - | +------+ - +-| _TZ | Scope(_TZ): the thermal zone namespace - | +------+ - | | - | | +------+ - | +-| FN00 | PowerResource(FN00): the FAN0 power resource - | | +------+ - | | - | | +------+ - | +-| FAN0 | Device(FAN0): the FAN0 cooling device - | | +------+ - | | | - | | | +------+ - | | +-| _HID | Name(_HID, "PNP0A0B"): the hardware ID - | | +------+ - | | - | | +------+ - | +-| TZ00 | ThermalZone(TZ00); the FAN thermal zone - | +------+ - | - | +------+ - +-| _GPE | Scope(_GPE): the GPE namespace - +------+ - - Figure 2. Example ACPI Namespace - - -3. Linux ACPI Device Objects - - The Linux kernel's core ACPI subsystem creates struct acpi_device - objects for ACPI namespace objects representing devices, power resources - processors, thermal zones. Those objects are exported to user space via - sysfs as directories in the subtree under /sys/devices/LNXSYSTM:00. The - format of their names is , where 'bus_id' refers to the - ACPI namespace representation of the given object and 'instance' is used - for distinguishing different object of the same 'bus_id' (it is - two-digit decimal representation of an unsigned integer). - - The value of 'bus_id' depends on the type of the object whose name it is - part of as listed in the table below. - - +---+-----------------+-------+----------+ - | | Object/Feature | Table | bus_id | - +---+-----------------+-------+----------+ - | N | Root | xSDT | LNXSYSTM | - +---+-----------------+-------+----------+ - | N | Device | xSDT | _HID | - +---+-----------------+-------+----------+ - | N | Processor | xSDT | LNXCPU | - +---+-----------------+-------+----------+ - | N | ThermalZone | xSDT | LNXTHERM | - +---+-----------------+-------+----------+ - | N | PowerResource | xSDT | LNXPOWER | - +---+-----------------+-------+----------+ - | N | Other Devices | xSDT | device | - +---+-----------------+-------+----------+ - | F | PWR_BUTTON | FADT | LNXPWRBN | - +---+-----------------+-------+----------+ - | F | SLP_BUTTON | FADT | LNXSLPBN | - +---+-----------------+-------+----------+ - | M | Video Extension | xSDT | LNXVIDEO | - +---+-----------------+-------+----------+ - | M | ATA Controller | xSDT | LNXIOBAY | - +---+-----------------+-------+----------+ - | M | Docking Station | xSDT | LNXDOCK | - +---+-----------------+-------+----------+ - - Table 1. ACPI Namespace Objects Mapping - - The following rules apply when creating struct acpi_device objects on - the basis of the contents of ACPI System Description Tables (as - indicated by the letter in the first column and the notation in the - second column of the table above): - N: - The object's source is an ACPI namespace node (as indicated by the - named object's type in the second column). In that case the object's - directory in sysfs will contain the 'path' attribute whose value is - the full path to the node from the namespace root. - F: - The struct acpi_device object is created for a fixed hardware - feature (as indicated by the fixed feature flag's name in the second - column), so its sysfs directory will not contain the 'path' - attribute. - M: - The struct acpi_device object is created for an ACPI namespace node - with specific control methods (as indicated by the ACPI defined - device's type in the second column). The 'path' attribute containing - its namespace path will be present in its sysfs directory. For - example, if the _BCL method is present for an ACPI namespace node, a - struct acpi_device object with LNXVIDEO 'bus_id' will be created for - it. - - The third column of the above table indicates which ACPI System - Description Tables contain information used for the creation of the - struct acpi_device objects represented by the given row (xSDT means DSDT - or SSDT). - - The forth column of the above table indicates the 'bus_id' generation - rule of the struct acpi_device object: - _HID: - _HID in the last column of the table means that the object's bus_id - is derived from the _HID/_CID identification objects present under - the corresponding ACPI namespace node. The object's sysfs directory - will then contain the 'hid' and 'modalias' attributes that can be - used to retrieve the _HID and _CIDs of that object. - LNXxxxxx: - The 'modalias' attribute is also present for struct acpi_device - objects having bus_id of the "LNXxxxxx" form (pseudo devices), in - which cases it contains the bus_id string itself. - device: - 'device' in the last column of the table indicates that the object's - bus_id cannot be determined from _HID/_CID of the corresponding - ACPI namespace node, although that object represents a device (for - example, it may be a PCI device with _ADR defined and without _HID - or _CID). In that case the string 'device' will be used as the - object's bus_id. - - -4. Linux ACPI Physical Device Glue - - ACPI device (i.e. struct acpi_device) objects may be linked to other - objects in the Linux' device hierarchy that represent "physical" devices - (for example, devices on the PCI bus). If that happens, it means that - the ACPI device object is a "companion" of a device otherwise - represented in a different way and is used (1) to provide configuration - information on that device which cannot be obtained by other means and - (2) to do specific things to the device with the help of its ACPI - control methods. One ACPI device object may be linked this way to - multiple "physical" devices. - - If an ACPI device object is linked to a "physical" device, its sysfs - directory contains the "physical_node" symbolic link to the sysfs - directory of the target device object. In turn, the target device's - sysfs directory will then contain the "firmware_node" symbolic link to - the sysfs directory of the companion ACPI device object. - The linking mechanism relies on device identification provided by the - ACPI namespace. For example, if there's an ACPI namespace object - representing a PCI device (i.e. a device object under an ACPI namespace - object representing a PCI bridge) whose _ADR returns 0x00020000 and the - bus number of the parent PCI bridge is 0, the sysfs directory - representing the struct acpi_device object created for that ACPI - namespace object will contain the 'physical_node' symbolic link to the - /sys/devices/pci0000:00/0000:00:02:0/ sysfs directory of the - corresponding PCI device. - - The linking mechanism is generally bus-specific. The core of its - implementation is located in the drivers/acpi/glue.c file, but there are - complementary parts depending on the bus types in question located - elsewhere. For example, the PCI-specific part of it is located in - drivers/pci/pci-acpi.c. - - -5. Example Linux ACPI Device Tree - - The sysfs hierarchy of struct acpi_device objects corresponding to the - example ACPI namespace illustrated in Figure 2 with the addition of - fixed PWR_BUTTON/SLP_BUTTON devices is shown below. - - +--------------+---+-----------------+ - | LNXSYSTEM:00 | \ | acpi:LNXSYSTEM: | - +--------------+---+-----------------+ - | - | +-------------+-----+----------------+ - +-| LNXPWRBN:00 | N/A | acpi:LNXPWRBN: | - | +-------------+-----+----------------+ - | - | +-------------+-----+----------------+ - +-| LNXSLPBN:00 | N/A | acpi:LNXSLPBN: | - | +-------------+-----+----------------+ - | - | +-----------+------------+--------------+ - +-| LNXCPU:00 | \_PR_.CPU0 | acpi:LNXCPU: | - | +-----------+------------+--------------+ - | - | +-------------+-------+----------------+ - +-| LNXSYBUS:00 | \_SB_ | acpi:LNXSYBUS: | - | +-------------+-------+----------------+ - | | - | | +- - - - - - - +- - - - - - +- - - - - - - -+ - | +-| PNP0C0D:00 | \_SB_.LID0 | acpi:PNP0C0D: | - | | +- - - - - - - +- - - - - - +- - - - - - - -+ - | | - | | +------------+------------+-----------------------+ - | +-| PNP0A08:00 | \_SB_.PCI0 | acpi:PNP0A08:PNP0A03: | - | +------------+------------+-----------------------+ - | | - | | +-----------+-----------------+-----+ - | +-| device:00 | \_SB_.PCI0.RP03 | N/A | - | | +-----------+-----------------+-----+ - | | | - | | | +-------------+----------------------+----------------+ - | | +-| LNXPOWER:00 | \_SB_.PCI0.RP03.PXP3 | acpi:LNXPOWER: | - | | +-------------+----------------------+----------------+ - | | - | | +-------------+-----------------+----------------+ - | +-| LNXVIDEO:00 | \_SB_.PCI0.GFX0 | acpi:LNXVIDEO: | - | +-------------+-----------------+----------------+ - | | - | | +-----------+-----------------+-----+ - | +-| device:01 | \_SB_.PCI0.DD01 | N/A | - | +-----------+-----------------+-----+ - | - | +-------------+-------+----------------+ - +-| LNXSYBUS:01 | \_TZ_ | acpi:LNXSYBUS: | - +-------------+-------+----------------+ - | - | +-------------+------------+----------------+ - +-| LNXPOWER:0a | \_TZ_.FN00 | acpi:LNXPOWER: | - | +-------------+------------+----------------+ - | - | +------------+------------+---------------+ - +-| PNP0C0B:00 | \_TZ_.FAN0 | acpi:PNP0C0B: | - | +------------+------------+---------------+ - | - | +-------------+------------+----------------+ - +-| LNXTHERM:00 | \_TZ_.TZ00 | acpi:LNXTHERM: | - +-------------+------------+----------------+ - - Figure 3. Example Linux ACPI Device Tree - - NOTE: Each node is represented as "object/path/modalias", where: - 1. 'object' is the name of the object's directory in sysfs. - 2. 'path' is the ACPI namespace path of the corresponding - ACPI namespace object, as returned by the object's 'path' - sysfs attribute. - 3. 'modalias' is the value of the object's 'modalias' sysfs - attribute (as described earlier in this document). - NOTE: N/A indicates the device object does not have the 'path' or the - 'modalias' attribute. diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst index 0ec7d072ba22..210ad8acd6df 100644 --- a/Documentation/firmware-guide/acpi/index.rst +++ b/Documentation/firmware-guide/acpi/index.rst @@ -7,3 +7,4 @@ ACPI Support .. toctree:: :maxdepth: 1 + namespace diff --git a/Documentation/firmware-guide/acpi/namespace.rst b/Documentation/firmware-guide/acpi/namespace.rst new file mode 100644 index 000000000000..835521baeb89 --- /dev/null +++ b/Documentation/firmware-guide/acpi/namespace.rst @@ -0,0 +1,400 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: + +=================================================== +ACPI Device Tree - Representation of ACPI Namespace +=================================================== + +:Copyright: |copy| 2013, Intel Corporation + +:Author: Lv Zheng + +:Credit: Thanks for the help from Zhang Rui and + Rafael J.Wysocki . + +Abstract +======== +The Linux ACPI subsystem converts ACPI namespace objects into a Linux +device tree under the /sys/devices/LNXSYSTEM:00 and updates it upon +receiving ACPI hotplug notification events. For each device object +in this hierarchy there is a corresponding symbolic link in the +/sys/bus/acpi/devices. + +This document illustrates the structure of the ACPI device tree. + +ACPI Definition Blocks +====================== + +The ACPI firmware sets up RSDP (Root System Description Pointer) in the +system memory address space pointing to the XSDT (Extended System +Description Table). The XSDT always points to the FADT (Fixed ACPI +Description Table) using its first entry, the data within the FADT +includes various fixed-length entries that describe fixed ACPI features +of the hardware. The FADT contains a pointer to the DSDT +(Differentiated System Descripition Table). The XSDT also contains +entries pointing to possibly multiple SSDTs (Secondary System +Description Table). + +The DSDT and SSDT data is organized in data structures called definition +blocks that contain definitions of various objects, including ACPI +control methods, encoded in AML (ACPI Machine Language). The data block +of the DSDT along with the contents of SSDTs represents a hierarchical +data structure called the ACPI namespace whose topology reflects the +structure of the underlying hardware platform. + +The relationships between ACPI System Definition Tables described above +are illustrated in the following diagram:: + + +---------+ +-------+ +--------+ +------------------------+ + | RSDP | +->| XSDT | +->| FADT | | +-------------------+ | + +---------+ | +-------+ | +--------+ +-|->| DSDT | | + | Pointer | | | Entry |-+ | ...... | | | +-------------------+ | + +---------+ | +-------+ | X_DSDT |--+ | | Definition Blocks | | + | Pointer |-+ | ..... | | ...... | | +-------------------+ | + +---------+ +-------+ +--------+ | +-------------------+ | + | Entry |------------------|->| SSDT | | + +- - - -+ | +-------------------| | + | Entry | - - - - - - - -+ | | Definition Blocks | | + +- - - -+ | | +-------------------+ | + | | +- - - - - - - - - -+ | + +-|->| SSDT | | + | +-------------------+ | + | | Definition Blocks | | + | +- - - - - - - - - -+ | + +------------------------+ + | + OSPM Loading | + \|/ + +----------------+ + | ACPI Namespace | + +----------------+ + + Figure 1. ACPI Definition Blocks + +.. note:: RSDP can also contain a pointer to the RSDT (Root System + Description Table). Platforms provide RSDT to enable + compatibility with ACPI 1.0 operating systems. The OS is expected + to use XSDT, if present. + + +Example ACPI Namespace +====================== + +All definition blocks are loaded into a single namespace. The namespace +is a hierarchy of objects identified by names and paths. +The following naming conventions apply to object names in the ACPI +namespace: + + 1. All names are 32 bits long. + 2. The first byte of a name must be one of 'A' - 'Z', '_'. + 3. Each of the remaining bytes of a name must be one of 'A' - 'Z', '0' + - '9', '_'. + 4. Names starting with '_' are reserved by the ACPI specification. + 5. The '\' symbol represents the root of the namespace (i.e. names + prepended with '\' are relative to the namespace root). + 6. The '^' symbol represents the parent of the current namespace node + (i.e. names prepended with '^' are relative to the parent of the + current namespace node). + +The figure below shows an example ACPI namespace:: + + +------+ + | \ | Root + +------+ + | + | +------+ + +-| _PR | Scope(_PR): the processor namespace + | +------+ + | | + | | +------+ + | +-| CPU0 | Processor(CPU0): the first processor + | +------+ + | + | +------+ + +-| _SB | Scope(_SB): the system bus namespace + | +------+ + | | + | | +------+ + | +-| LID0 | Device(LID0); the lid device + | | +------+ + | | | + | | | +------+ + | | +-| _HID | Name(_HID, "PNP0C0D"): the hardware ID + | | | +------+ + | | | + | | | +------+ + | | +-| _STA | Method(_STA): the status control method + | | +------+ + | | + | | +------+ + | +-| PCI0 | Device(PCI0); the PCI root bridge + | +------+ + | | + | | +------+ + | +-| _HID | Name(_HID, "PNP0A08"): the hardware ID + | | +------+ + | | + | | +------+ + | +-| _CID | Name(_CID, "PNP0A03"): the compatible ID + | | +------+ + | | + | | +------+ + | +-| RP03 | Scope(RP03): the PCI0 power scope + | | +------+ + | | | + | | | +------+ + | | +-| PXP3 | PowerResource(PXP3): the PCI0 power resource + | | +------+ + | | + | | +------+ + | +-| GFX0 | Device(GFX0): the graphics adapter + | +------+ + | | + | | +------+ + | +-| _ADR | Name(_ADR, 0x00020000): the PCI bus address + | | +------+ + | | + | | +------+ + | +-| DD01 | Device(DD01): the LCD output device + | +------+ + | | + | | +------+ + | +-| _BCL | Method(_BCL): the backlight control method + | +------+ + | + | +------+ + +-| _TZ | Scope(_TZ): the thermal zone namespace + | +------+ + | | + | | +------+ + | +-| FN00 | PowerResource(FN00): the FAN0 power resource + | | +------+ + | | + | | +------+ + | +-| FAN0 | Device(FAN0): the FAN0 cooling device + | | +------+ + | | | + | | | +------+ + | | +-| _HID | Name(_HID, "PNP0A0B"): the hardware ID + | | +------+ + | | + | | +------+ + | +-| TZ00 | ThermalZone(TZ00); the FAN thermal zone + | +------+ + | + | +------+ + +-| _GPE | Scope(_GPE): the GPE namespace + +------+ + + Figure 2. Example ACPI Namespace + + +Linux ACPI Device Objects +========================= + +The Linux kernel's core ACPI subsystem creates struct acpi_device +objects for ACPI namespace objects representing devices, power resources +processors, thermal zones. Those objects are exported to user space via +sysfs as directories in the subtree under /sys/devices/LNXSYSTM:00. The +format of their names is , where 'bus_id' refers to the +ACPI namespace representation of the given object and 'instance' is used +for distinguishing different object of the same 'bus_id' (it is +two-digit decimal representation of an unsigned integer). + +The value of 'bus_id' depends on the type of the object whose name it is +part of as listed in the table below:: + + +---+-----------------+-------+----------+ + | | Object/Feature | Table | bus_id | + +---+-----------------+-------+----------+ + | N | Root | xSDT | LNXSYSTM | + +---+-----------------+-------+----------+ + | N | Device | xSDT | _HID | + +---+-----------------+-------+----------+ + | N | Processor | xSDT | LNXCPU | + +---+-----------------+-------+----------+ + | N | ThermalZone | xSDT | LNXTHERM | + +---+-----------------+-------+----------+ + | N | PowerResource | xSDT | LNXPOWER | + +---+-----------------+-------+----------+ + | N | Other Devices | xSDT | device | + +---+-----------------+-------+----------+ + | F | PWR_BUTTON | FADT | LNXPWRBN | + +---+-----------------+-------+----------+ + | F | SLP_BUTTON | FADT | LNXSLPBN | + +---+-----------------+-------+----------+ + | M | Video Extension | xSDT | LNXVIDEO | + +---+-----------------+-------+----------+ + | M | ATA Controller | xSDT | LNXIOBAY | + +---+-----------------+-------+----------+ + | M | Docking Station | xSDT | LNXDOCK | + +---+-----------------+-------+----------+ + + Table 1. ACPI Namespace Objects Mapping + +The following rules apply when creating struct acpi_device objects on +the basis of the contents of ACPI System Description Tables (as +indicated by the letter in the first column and the notation in the +second column of the table above): + + N: + The object's source is an ACPI namespace node (as indicated by the + named object's type in the second column). In that case the object's + directory in sysfs will contain the 'path' attribute whose value is + the full path to the node from the namespace root. + F: + The struct acpi_device object is created for a fixed hardware + feature (as indicated by the fixed feature flag's name in the second + column), so its sysfs directory will not contain the 'path' + attribute. + M: + The struct acpi_device object is created for an ACPI namespace node + with specific control methods (as indicated by the ACPI defined + device's type in the second column). The 'path' attribute containing + its namespace path will be present in its sysfs directory. For + example, if the _BCL method is present for an ACPI namespace node, a + struct acpi_device object with LNXVIDEO 'bus_id' will be created for + it. + +The third column of the above table indicates which ACPI System +Description Tables contain information used for the creation of the +struct acpi_device objects represented by the given row (xSDT means DSDT +or SSDT). + +The forth column of the above table indicates the 'bus_id' generation +rule of the struct acpi_device object: + + _HID: + _HID in the last column of the table means that the object's bus_id + is derived from the _HID/_CID identification objects present under + the corresponding ACPI namespace node. The object's sysfs directory + will then contain the 'hid' and 'modalias' attributes that can be + used to retrieve the _HID and _CIDs of that object. + LNXxxxxx: + The 'modalias' attribute is also present for struct acpi_device + objects having bus_id of the "LNXxxxxx" form (pseudo devices), in + which cases it contains the bus_id string itself. + device: + 'device' in the last column of the table indicates that the object's + bus_id cannot be determined from _HID/_CID of the corresponding + ACPI namespace node, although that object represents a device (for + example, it may be a PCI device with _ADR defined and without _HID + or _CID). In that case the string 'device' will be used as the + object's bus_id. + + +Linux ACPI Physical Device Glue +=============================== + +ACPI device (i.e. struct acpi_device) objects may be linked to other +objects in the Linux' device hierarchy that represent "physical" devices +(for example, devices on the PCI bus). If that happens, it means that +the ACPI device object is a "companion" of a device otherwise +represented in a different way and is used (1) to provide configuration +information on that device which cannot be obtained by other means and +(2) to do specific things to the device with the help of its ACPI +control methods. One ACPI device object may be linked this way to +multiple "physical" devices. + +If an ACPI device object is linked to a "physical" device, its sysfs +directory contains the "physical_node" symbolic link to the sysfs +directory of the target device object. In turn, the target device's +sysfs directory will then contain the "firmware_node" symbolic link to +the sysfs directory of the companion ACPI device object. +The linking mechanism relies on device identification provided by the +ACPI namespace. For example, if there's an ACPI namespace object +representing a PCI device (i.e. a device object under an ACPI namespace +object representing a PCI bridge) whose _ADR returns 0x00020000 and the +bus number of the parent PCI bridge is 0, the sysfs directory +representing the struct acpi_device object created for that ACPI +namespace object will contain the 'physical_node' symbolic link to the +/sys/devices/pci0000:00/0000:00:02:0/ sysfs directory of the +corresponding PCI device. + +The linking mechanism is generally bus-specific. The core of its +implementation is located in the drivers/acpi/glue.c file, but there are +complementary parts depending on the bus types in question located +elsewhere. For example, the PCI-specific part of it is located in +drivers/pci/pci-acpi.c. + + +Example Linux ACPI Device Tree +================================= + +The sysfs hierarchy of struct acpi_device objects corresponding to the +example ACPI namespace illustrated in Figure 2 with the addition of +fixed PWR_BUTTON/SLP_BUTTON devices is shown below:: + + +--------------+---+-----------------+ + | LNXSYSTEM:00 | \ | acpi:LNXSYSTEM: | + +--------------+---+-----------------+ + | + | +-------------+-----+----------------+ + +-| LNXPWRBN:00 | N/A | acpi:LNXPWRBN: | + | +-------------+-----+----------------+ + | + | +-------------+-----+----------------+ + +-| LNXSLPBN:00 | N/A | acpi:LNXSLPBN: | + | +-------------+-----+----------------+ + | + | +-----------+------------+--------------+ + +-| LNXCPU:00 | \_PR_.CPU0 | acpi:LNXCPU: | + | +-----------+------------+--------------+ + | + | +-------------+-------+----------------+ + +-| LNXSYBUS:00 | \_SB_ | acpi:LNXSYBUS: | + | +-------------+-------+----------------+ + | | + | | +- - - - - - - +- - - - - - +- - - - - - - -+ + | +-| PNP0C0D:00 | \_SB_.LID0 | acpi:PNP0C0D: | + | | +- - - - - - - +- - - - - - +- - - - - - - -+ + | | + | | +------------+------------+-----------------------+ + | +-| PNP0A08:00 | \_SB_.PCI0 | acpi:PNP0A08:PNP0A03: | + | +------------+------------+-----------------------+ + | | + | | +-----------+-----------------+-----+ + | +-| device:00 | \_SB_.PCI0.RP03 | N/A | + | | +-----------+-----------------+-----+ + | | | + | | | +-------------+----------------------+----------------+ + | | +-| LNXPOWER:00 | \_SB_.PCI0.RP03.PXP3 | acpi:LNXPOWER: | + | | +-------------+----------------------+----------------+ + | | + | | +-------------+-----------------+----------------+ + | +-| LNXVIDEO:00 | \_SB_.PCI0.GFX0 | acpi:LNXVIDEO: | + | +-------------+-----------------+----------------+ + | | + | | +-----------+-----------------+-----+ + | +-| device:01 | \_SB_.PCI0.DD01 | N/A | + | +-----------+-----------------+-----+ + | + | +-------------+-------+----------------+ + +-| LNXSYBUS:01 | \_TZ_ | acpi:LNXSYBUS: | + +-------------+-------+----------------+ + | + | +-------------+------------+----------------+ + +-| LNXPOWER:0a | \_TZ_.FN00 | acpi:LNXPOWER: | + | +-------------+------------+----------------+ + | + | +------------+------------+---------------+ + +-| PNP0C0B:00 | \_TZ_.FAN0 | acpi:PNP0C0B: | + | +------------+------------+---------------+ + | + | +-------------+------------+----------------+ + +-| LNXTHERM:00 | \_TZ_.TZ00 | acpi:LNXTHERM: | + +-------------+------------+----------------+ + + Figure 3. Example Linux ACPI Device Tree + +.. note:: Each node is represented as "object/path/modalias", where: + + 1. 'object' is the name of the object's directory in sysfs. + 2. 'path' is the ACPI namespace path of the corresponding + ACPI namespace object, as returned by the object's 'path' + sysfs attribute. + 3. 'modalias' is the value of the object's 'modalias' sysfs + attribute (as described earlier in this document). + +.. note:: N/A indicates the device object does not have the 'path' or the + 'modalias' attribute. -- cgit v1.2.3-59-g8ed1b From c24bc66e8157ca4956b8be1ed62493d70dfdb547 Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 01:52:45 +0800 Subject: Documentation: ACPI: move enumeration.txt to firmware-guide/acpi and convert to reST This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/enumeration.txt | 452 --------------------- Documentation/firmware-guide/acpi/enumeration.rst | 463 ++++++++++++++++++++++ Documentation/firmware-guide/acpi/index.rst | 1 + 3 files changed, 464 insertions(+), 452 deletions(-) delete mode 100644 Documentation/acpi/enumeration.txt create mode 100644 Documentation/firmware-guide/acpi/enumeration.rst diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt deleted file mode 100644 index 1395b844649c..000000000000 --- a/Documentation/acpi/enumeration.txt +++ /dev/null @@ -1,452 +0,0 @@ -ACPI based device enumeration -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -ACPI 5 introduced a set of new resources (UartTSerialBus, I2cSerialBus, -SpiSerialBus, GpioIo and GpioInt) which can be used in enumerating slave -devices behind serial bus controllers. - -In addition we are starting to see peripherals integrated in the -SoC/Chipset to appear only in ACPI namespace. These are typically devices -that are accessed through memory-mapped registers. - -In order to support this and re-use the existing drivers as much as -possible we decided to do following: - - o Devices that have no bus connector resource are represented as - platform devices. - - o Devices behind real busses where there is a connector resource - are represented as struct spi_device or struct i2c_device - (standard UARTs are not busses so there is no struct uart_device). - -As both ACPI and Device Tree represent a tree of devices (and their -resources) this implementation follows the Device Tree way as much as -possible. - -The ACPI implementation enumerates devices behind busses (platform, SPI and -I2C), creates the physical devices and binds them to their ACPI handle in -the ACPI namespace. - -This means that when ACPI_HANDLE(dev) returns non-NULL the device was -enumerated from ACPI namespace. This handle can be used to extract other -device-specific configuration. There is an example of this below. - -Platform bus support -~~~~~~~~~~~~~~~~~~~~ -Since we are using platform devices to represent devices that are not -connected to any physical bus we only need to implement a platform driver -for the device and add supported ACPI IDs. If this same IP-block is used on -some other non-ACPI platform, the driver might work out of the box or needs -some minor changes. - -Adding ACPI support for an existing driver should be pretty -straightforward. Here is the simplest example: - - #ifdef CONFIG_ACPI - static const struct acpi_device_id mydrv_acpi_match[] = { - /* ACPI IDs here */ - { } - }; - MODULE_DEVICE_TABLE(acpi, mydrv_acpi_match); - #endif - - static struct platform_driver my_driver = { - ... - .driver = { - .acpi_match_table = ACPI_PTR(mydrv_acpi_match), - }, - }; - -If the driver needs to perform more complex initialization like getting and -configuring GPIOs it can get its ACPI handle and extract this information -from ACPI tables. - -DMA support -~~~~~~~~~~~ -DMA controllers enumerated via ACPI should be registered in the system to -provide generic access to their resources. For example, a driver that would -like to be accessible to slave devices via generic API call -dma_request_slave_channel() must register itself at the end of the probe -function like this: - - err = devm_acpi_dma_controller_register(dev, xlate_func, dw); - /* Handle the error if it's not a case of !CONFIG_ACPI */ - -and implement custom xlate function if needed (usually acpi_dma_simple_xlate() -is enough) which converts the FixedDMA resource provided by struct -acpi_dma_spec into the corresponding DMA channel. A piece of code for that case -could look like: - - #ifdef CONFIG_ACPI - struct filter_args { - /* Provide necessary information for the filter_func */ - ... - }; - - static bool filter_func(struct dma_chan *chan, void *param) - { - /* Choose the proper channel */ - ... - } - - static struct dma_chan *xlate_func(struct acpi_dma_spec *dma_spec, - struct acpi_dma *adma) - { - dma_cap_mask_t cap; - struct filter_args args; - - /* Prepare arguments for filter_func */ - ... - return dma_request_channel(cap, filter_func, &args); - } - #else - static struct dma_chan *xlate_func(struct acpi_dma_spec *dma_spec, - struct acpi_dma *adma) - { - return NULL; - } - #endif - -dma_request_slave_channel() will call xlate_func() for each registered DMA -controller. In the xlate function the proper channel must be chosen based on -information in struct acpi_dma_spec and the properties of the controller -provided by struct acpi_dma. - -Clients must call dma_request_slave_channel() with the string parameter that -corresponds to a specific FixedDMA resource. By default "tx" means the first -entry of the FixedDMA resource array, "rx" means the second entry. The table -below shows a layout: - - Device (I2C0) - { - ... - Method (_CRS, 0, NotSerialized) - { - Name (DBUF, ResourceTemplate () - { - FixedDMA (0x0018, 0x0004, Width32bit, _Y48) - FixedDMA (0x0019, 0x0005, Width32bit, ) - }) - ... - } - } - -So, the FixedDMA with request line 0x0018 is "tx" and next one is "rx" in -this example. - -In robust cases the client unfortunately needs to call -acpi_dma_request_slave_chan_by_index() directly and therefore choose the -specific FixedDMA resource by its index. - -SPI serial bus support -~~~~~~~~~~~~~~~~~~~~~~ -Slave devices behind SPI bus have SpiSerialBus resource attached to them. -This is extracted automatically by the SPI core and the slave devices are -enumerated once spi_register_master() is called by the bus driver. - -Here is what the ACPI namespace for a SPI slave might look like: - - Device (EEP0) - { - Name (_ADR, 1) - Name (_CID, Package() { - "ATML0025", - "AT25", - }) - ... - Method (_CRS, 0, NotSerialized) - { - SPISerialBus(1, PolarityLow, FourWireMode, 8, - ControllerInitiated, 1000000, ClockPolarityLow, - ClockPhaseFirst, "\\_SB.PCI0.SPI1",) - } - ... - -The SPI device drivers only need to add ACPI IDs in a similar way than with -the platform device drivers. Below is an example where we add ACPI support -to at25 SPI eeprom driver (this is meant for the above ACPI snippet): - - #ifdef CONFIG_ACPI - static const struct acpi_device_id at25_acpi_match[] = { - { "AT25", 0 }, - { }, - }; - MODULE_DEVICE_TABLE(acpi, at25_acpi_match); - #endif - - static struct spi_driver at25_driver = { - .driver = { - ... - .acpi_match_table = ACPI_PTR(at25_acpi_match), - }, - }; - -Note that this driver actually needs more information like page size of the -eeprom etc. but at the time writing this there is no standard way of -passing those. One idea is to return this in _DSM method like: - - Device (EEP0) - { - ... - Method (_DSM, 4, NotSerialized) - { - Store (Package (6) - { - "byte-len", 1024, - "addr-mode", 2, - "page-size, 32 - }, Local0) - - // Check UUIDs etc. - - Return (Local0) - } - -Then the at25 SPI driver can get this configuration by calling _DSM on its -ACPI handle like: - - struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL }; - struct acpi_object_list input; - acpi_status status; - - /* Fill in the input buffer */ - - status = acpi_evaluate_object(ACPI_HANDLE(&spi->dev), "_DSM", - &input, &output); - if (ACPI_FAILURE(status)) - /* Handle the error */ - - /* Extract the data here */ - - kfree(output.pointer); - -I2C serial bus support -~~~~~~~~~~~~~~~~~~~~~~ -The slaves behind I2C bus controller only need to add the ACPI IDs like -with the platform and SPI drivers. The I2C core automatically enumerates -any slave devices behind the controller device once the adapter is -registered. - -Below is an example of how to add ACPI support to the existing mpu3050 -input driver: - - #ifdef CONFIG_ACPI - static const struct acpi_device_id mpu3050_acpi_match[] = { - { "MPU3050", 0 }, - { }, - }; - MODULE_DEVICE_TABLE(acpi, mpu3050_acpi_match); - #endif - - static struct i2c_driver mpu3050_i2c_driver = { - .driver = { - .name = "mpu3050", - .owner = THIS_MODULE, - .pm = &mpu3050_pm, - .of_match_table = mpu3050_of_match, - .acpi_match_table = ACPI_PTR(mpu3050_acpi_match), - }, - .probe = mpu3050_probe, - .remove = mpu3050_remove, - .id_table = mpu3050_ids, - }; - -GPIO support -~~~~~~~~~~~~ -ACPI 5 introduced two new resources to describe GPIO connections: GpioIo -and GpioInt. These resources can be used to pass GPIO numbers used by -the device to the driver. ACPI 5.1 extended this with _DSD (Device -Specific Data) which made it possible to name the GPIOs among other things. - -For example: - -Device (DEV) -{ - Method (_CRS, 0, NotSerialized) - { - Name (SBUF, ResourceTemplate() - { - ... - // Used to power on/off the device - GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, - IoRestrictionOutputOnly, "\\_SB.PCI0.GPI0", - 0x00, ResourceConsumer,,) - { - // Pin List - 0x0055 - } - - // Interrupt for the device - GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone, - 0x0000, "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer,,) - { - // Pin list - 0x0058 - } - - ... - - } - - Return (SBUF) - } - - // ACPI 5.1 _DSD used for naming the GPIOs - Name (_DSD, Package () - { - ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), - Package () - { - Package () {"power-gpios", Package() {^DEV, 0, 0, 0 }}, - Package () {"irq-gpios", Package() {^DEV, 1, 0, 0 }}, - } - }) - ... - -These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0" -specifies the path to the controller. In order to use these GPIOs in Linux -we need to translate them to the corresponding Linux GPIO descriptors. - -There is a standard GPIO API for that and is documented in -Documentation/gpio/. - -In the above example we can get the corresponding two GPIO descriptors with -a code like this: - - #include - ... - - struct gpio_desc *irq_desc, *power_desc; - - irq_desc = gpiod_get(dev, "irq"); - if (IS_ERR(irq_desc)) - /* handle error */ - - power_desc = gpiod_get(dev, "power"); - if (IS_ERR(power_desc)) - /* handle error */ - - /* Now we can use the GPIO descriptors */ - -There are also devm_* versions of these functions which release the -descriptors once the device is released. - -See Documentation/acpi/gpio-properties.txt for more information about the -_DSD binding related to GPIOs. - -MFD devices -~~~~~~~~~~~ -The MFD devices register their children as platform devices. For the child -devices there needs to be an ACPI handle that they can use to reference -parts of the ACPI namespace that relate to them. In the Linux MFD subsystem -we provide two ways: - - o The children share the parent ACPI handle. - o The MFD cell can specify the ACPI id of the device. - -For the first case, the MFD drivers do not need to do anything. The -resulting child platform device will have its ACPI_COMPANION() set to point -to the parent device. - -If the ACPI namespace has a device that we can match using an ACPI id or ACPI -adr, the cell should be set like: - - static struct mfd_cell_acpi_match my_subdevice_cell_acpi_match = { - .pnpid = "XYZ0001", - .adr = 0, - }; - - static struct mfd_cell my_subdevice_cell = { - .name = "my_subdevice", - /* set the resources relative to the parent */ - .acpi_match = &my_subdevice_cell_acpi_match, - }; - -The ACPI id "XYZ0001" is then used to lookup an ACPI device directly under -the MFD device and if found, that ACPI companion device is bound to the -resulting child platform device. - -Device Tree namespace link device ID -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The Device Tree protocol uses device identification based on the "compatible" -property whose value is a string or an array of strings recognized as device -identifiers by drivers and the driver core. The set of all those strings may be -regarded as a device identification namespace analogous to the ACPI/PNP device -ID namespace. Consequently, in principle it should not be necessary to allocate -a new (and arguably redundant) ACPI/PNP device ID for a devices with an existing -identification string in the Device Tree (DT) namespace, especially if that ID -is only needed to indicate that a given device is compatible with another one, -presumably having a matching driver in the kernel already. - -In ACPI, the device identification object called _CID (Compatible ID) is used to -list the IDs of devices the given one is compatible with, but those IDs must -belong to one of the namespaces prescribed by the ACPI specification (see -Section 6.1.2 of ACPI 6.0 for details) and the DT namespace is not one of them. -Moreover, the specification mandates that either a _HID or an _ADR identification -object be present for all ACPI objects representing devices (Section 6.1 of ACPI -6.0). For non-enumerable bus types that object must be _HID and its value must -be a device ID from one of the namespaces prescribed by the specification too. - -The special DT namespace link device ID, PRP0001, provides a means to use the -existing DT-compatible device identification in ACPI and to satisfy the above -requirements following from the ACPI specification at the same time. Namely, -if PRP0001 is returned by _HID, the ACPI subsystem will look for the -"compatible" property in the device object's _DSD and will use the value of that -property to identify the corresponding device in analogy with the original DT -device identification algorithm. If the "compatible" property is not present -or its value is not valid, the device will not be enumerated by the ACPI -subsystem. Otherwise, it will be enumerated automatically as a platform device -(except when an I2C or SPI link from the device to its parent is present, in -which case the ACPI core will leave the device enumeration to the parent's -driver) and the identification strings from the "compatible" property value will -be used to find a driver for the device along with the device IDs listed by _CID -(if present). - -Analogously, if PRP0001 is present in the list of device IDs returned by _CID, -the identification strings listed by the "compatible" property value (if present -and valid) will be used to look for a driver matching the device, but in that -case their relative priority with respect to the other device IDs listed by -_HID and _CID depends on the position of PRP0001 in the _CID return package. -Specifically, the device IDs returned by _HID and preceding PRP0001 in the _CID -return package will be checked first. Also in that case the bus type the device -will be enumerated to depends on the device ID returned by _HID. - -For example, the following ACPI sample might be used to enumerate an lm75-type -I2C temperature sensor and match it to the driver using the Device Tree -namespace link: - - Device (TMP0) - { - Name (_HID, "PRP0001") - Name (_DSD, Package() { - ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), - Package () { - Package (2) { "compatible", "ti,tmp75" }, - } - }) - Method (_CRS, 0, Serialized) - { - Name (SBUF, ResourceTemplate () - { - I2cSerialBusV2 (0x48, ControllerInitiated, - 400000, AddressingMode7Bit, - "\\_SB.PCI0.I2C1", 0x00, - ResourceConsumer, , Exclusive,) - }) - Return (SBUF) - } - } - -It is valid to define device objects with a _HID returning PRP0001 and without -the "compatible" property in the _DSD or a _CID as long as one of their -ancestors provides a _DSD with a valid "compatible" property. Such device -objects are then simply regarded as additional "blocks" providing hierarchical -configuration information to the driver of the composite ancestor device. - -However, PRP0001 can only be returned from either _HID or _CID of a device -object if all of the properties returned by the _DSD associated with it (either -the _DSD of the device object itself or the _DSD of its ancestor in the -"composite device" case described above) can be used in the ACPI environment. -Otherwise, the _DSD itself is regarded as invalid and therefore the "compatible" -property returned by it is meaningless. - -Refer to DSD-properties-rules.txt for more information. diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst new file mode 100644 index 000000000000..6b32b7be8c85 --- /dev/null +++ b/Documentation/firmware-guide/acpi/enumeration.rst @@ -0,0 +1,463 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================= +ACPI Based Device Enumeration +============================= + +ACPI 5 introduced a set of new resources (UartTSerialBus, I2cSerialBus, +SpiSerialBus, GpioIo and GpioInt) which can be used in enumerating slave +devices behind serial bus controllers. + +In addition we are starting to see peripherals integrated in the +SoC/Chipset to appear only in ACPI namespace. These are typically devices +that are accessed through memory-mapped registers. + +In order to support this and re-use the existing drivers as much as +possible we decided to do following: + + - Devices that have no bus connector resource are represented as + platform devices. + + - Devices behind real busses where there is a connector resource + are represented as struct spi_device or struct i2c_device + (standard UARTs are not busses so there is no struct uart_device). + +As both ACPI and Device Tree represent a tree of devices (and their +resources) this implementation follows the Device Tree way as much as +possible. + +The ACPI implementation enumerates devices behind busses (platform, SPI and +I2C), creates the physical devices and binds them to their ACPI handle in +the ACPI namespace. + +This means that when ACPI_HANDLE(dev) returns non-NULL the device was +enumerated from ACPI namespace. This handle can be used to extract other +device-specific configuration. There is an example of this below. + +Platform bus support +==================== + +Since we are using platform devices to represent devices that are not +connected to any physical bus we only need to implement a platform driver +for the device and add supported ACPI IDs. If this same IP-block is used on +some other non-ACPI platform, the driver might work out of the box or needs +some minor changes. + +Adding ACPI support for an existing driver should be pretty +straightforward. Here is the simplest example:: + + #ifdef CONFIG_ACPI + static const struct acpi_device_id mydrv_acpi_match[] = { + /* ACPI IDs here */ + { } + }; + MODULE_DEVICE_TABLE(acpi, mydrv_acpi_match); + #endif + + static struct platform_driver my_driver = { + ... + .driver = { + .acpi_match_table = ACPI_PTR(mydrv_acpi_match), + }, + }; + +If the driver needs to perform more complex initialization like getting and +configuring GPIOs it can get its ACPI handle and extract this information +from ACPI tables. + +DMA support +=========== + +DMA controllers enumerated via ACPI should be registered in the system to +provide generic access to their resources. For example, a driver that would +like to be accessible to slave devices via generic API call +dma_request_slave_channel() must register itself at the end of the probe +function like this:: + + err = devm_acpi_dma_controller_register(dev, xlate_func, dw); + /* Handle the error if it's not a case of !CONFIG_ACPI */ + +and implement custom xlate function if needed (usually acpi_dma_simple_xlate() +is enough) which converts the FixedDMA resource provided by struct +acpi_dma_spec into the corresponding DMA channel. A piece of code for that case +could look like:: + + #ifdef CONFIG_ACPI + struct filter_args { + /* Provide necessary information for the filter_func */ + ... + }; + + static bool filter_func(struct dma_chan *chan, void *param) + { + /* Choose the proper channel */ + ... + } + + static struct dma_chan *xlate_func(struct acpi_dma_spec *dma_spec, + struct acpi_dma *adma) + { + dma_cap_mask_t cap; + struct filter_args args; + + /* Prepare arguments for filter_func */ + ... + return dma_request_channel(cap, filter_func, &args); + } + #else + static struct dma_chan *xlate_func(struct acpi_dma_spec *dma_spec, + struct acpi_dma *adma) + { + return NULL; + } + #endif + +dma_request_slave_channel() will call xlate_func() for each registered DMA +controller. In the xlate function the proper channel must be chosen based on +information in struct acpi_dma_spec and the properties of the controller +provided by struct acpi_dma. + +Clients must call dma_request_slave_channel() with the string parameter that +corresponds to a specific FixedDMA resource. By default "tx" means the first +entry of the FixedDMA resource array, "rx" means the second entry. The table +below shows a layout:: + + Device (I2C0) + { + ... + Method (_CRS, 0, NotSerialized) + { + Name (DBUF, ResourceTemplate () + { + FixedDMA (0x0018, 0x0004, Width32bit, _Y48) + FixedDMA (0x0019, 0x0005, Width32bit, ) + }) + ... + } + } + +So, the FixedDMA with request line 0x0018 is "tx" and next one is "rx" in +this example. + +In robust cases the client unfortunately needs to call +acpi_dma_request_slave_chan_by_index() directly and therefore choose the +specific FixedDMA resource by its index. + +SPI serial bus support +====================== + +Slave devices behind SPI bus have SpiSerialBus resource attached to them. +This is extracted automatically by the SPI core and the slave devices are +enumerated once spi_register_master() is called by the bus driver. + +Here is what the ACPI namespace for a SPI slave might look like:: + + Device (EEP0) + { + Name (_ADR, 1) + Name (_CID, Package() { + "ATML0025", + "AT25", + }) + ... + Method (_CRS, 0, NotSerialized) + { + SPISerialBus(1, PolarityLow, FourWireMode, 8, + ControllerInitiated, 1000000, ClockPolarityLow, + ClockPhaseFirst, "\\_SB.PCI0.SPI1",) + } + ... + +The SPI device drivers only need to add ACPI IDs in a similar way than with +the platform device drivers. Below is an example where we add ACPI support +to at25 SPI eeprom driver (this is meant for the above ACPI snippet):: + + #ifdef CONFIG_ACPI + static const struct acpi_device_id at25_acpi_match[] = { + { "AT25", 0 }, + { }, + }; + MODULE_DEVICE_TABLE(acpi, at25_acpi_match); + #endif + + static struct spi_driver at25_driver = { + .driver = { + ... + .acpi_match_table = ACPI_PTR(at25_acpi_match), + }, + }; + +Note that this driver actually needs more information like page size of the +eeprom etc. but at the time writing this there is no standard way of +passing those. One idea is to return this in _DSM method like:: + + Device (EEP0) + { + ... + Method (_DSM, 4, NotSerialized) + { + Store (Package (6) + { + "byte-len", 1024, + "addr-mode", 2, + "page-size, 32 + }, Local0) + + // Check UUIDs etc. + + Return (Local0) + } + +Then the at25 SPI driver can get this configuration by calling _DSM on its +ACPI handle like:: + + struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL }; + struct acpi_object_list input; + acpi_status status; + + /* Fill in the input buffer */ + + status = acpi_evaluate_object(ACPI_HANDLE(&spi->dev), "_DSM", + &input, &output); + if (ACPI_FAILURE(status)) + /* Handle the error */ + + /* Extract the data here */ + + kfree(output.pointer); + +I2C serial bus support +====================== + +The slaves behind I2C bus controller only need to add the ACPI IDs like +with the platform and SPI drivers. The I2C core automatically enumerates +any slave devices behind the controller device once the adapter is +registered. + +Below is an example of how to add ACPI support to the existing mpu3050 +input driver:: + + #ifdef CONFIG_ACPI + static const struct acpi_device_id mpu3050_acpi_match[] = { + { "MPU3050", 0 }, + { }, + }; + MODULE_DEVICE_TABLE(acpi, mpu3050_acpi_match); + #endif + + static struct i2c_driver mpu3050_i2c_driver = { + .driver = { + .name = "mpu3050", + .owner = THIS_MODULE, + .pm = &mpu3050_pm, + .of_match_table = mpu3050_of_match, + .acpi_match_table = ACPI_PTR(mpu3050_acpi_match), + }, + .probe = mpu3050_probe, + .remove = mpu3050_remove, + .id_table = mpu3050_ids, + }; + +GPIO support +============ + +ACPI 5 introduced two new resources to describe GPIO connections: GpioIo +and GpioInt. These resources can be used to pass GPIO numbers used by +the device to the driver. ACPI 5.1 extended this with _DSD (Device +Specific Data) which made it possible to name the GPIOs among other things. + +For example:: + + Device (DEV) + { + Method (_CRS, 0, NotSerialized) + { + Name (SBUF, ResourceTemplate() + { + ... + // Used to power on/off the device + GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, + IoRestrictionOutputOnly, "\\_SB.PCI0.GPI0", + 0x00, ResourceConsumer,,) + { + // Pin List + 0x0055 + } + + // Interrupt for the device + GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone, + 0x0000, "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer,,) + { + // Pin list + 0x0058 + } + + ... + + } + + Return (SBUF) + } + + // ACPI 5.1 _DSD used for naming the GPIOs + Name (_DSD, Package () + { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () + { + Package () {"power-gpios", Package() {^DEV, 0, 0, 0 }}, + Package () {"irq-gpios", Package() {^DEV, 1, 0, 0 }}, + } + }) + ... + +These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0" +specifies the path to the controller. In order to use these GPIOs in Linux +we need to translate them to the corresponding Linux GPIO descriptors. + +There is a standard GPIO API for that and is documented in +Documentation/gpio/. + +In the above example we can get the corresponding two GPIO descriptors with +a code like this:: + + #include + ... + + struct gpio_desc *irq_desc, *power_desc; + + irq_desc = gpiod_get(dev, "irq"); + if (IS_ERR(irq_desc)) + /* handle error */ + + power_desc = gpiod_get(dev, "power"); + if (IS_ERR(power_desc)) + /* handle error */ + + /* Now we can use the GPIO descriptors */ + +There are also devm_* versions of these functions which release the +descriptors once the device is released. + +See Documentation/acpi/gpio-properties.txt for more information about the +_DSD binding related to GPIOs. + +MFD devices +=========== + +The MFD devices register their children as platform devices. For the child +devices there needs to be an ACPI handle that they can use to reference +parts of the ACPI namespace that relate to them. In the Linux MFD subsystem +we provide two ways: + + - The children share the parent ACPI handle. + - The MFD cell can specify the ACPI id of the device. + +For the first case, the MFD drivers do not need to do anything. The +resulting child platform device will have its ACPI_COMPANION() set to point +to the parent device. + +If the ACPI namespace has a device that we can match using an ACPI id or ACPI +adr, the cell should be set like:: + + static struct mfd_cell_acpi_match my_subdevice_cell_acpi_match = { + .pnpid = "XYZ0001", + .adr = 0, + }; + + static struct mfd_cell my_subdevice_cell = { + .name = "my_subdevice", + /* set the resources relative to the parent */ + .acpi_match = &my_subdevice_cell_acpi_match, + }; + +The ACPI id "XYZ0001" is then used to lookup an ACPI device directly under +the MFD device and if found, that ACPI companion device is bound to the +resulting child platform device. + +Device Tree namespace link device ID +==================================== + +The Device Tree protocol uses device identification based on the "compatible" +property whose value is a string or an array of strings recognized as device +identifiers by drivers and the driver core. The set of all those strings may be +regarded as a device identification namespace analogous to the ACPI/PNP device +ID namespace. Consequently, in principle it should not be necessary to allocate +a new (and arguably redundant) ACPI/PNP device ID for a devices with an existing +identification string in the Device Tree (DT) namespace, especially if that ID +is only needed to indicate that a given device is compatible with another one, +presumably having a matching driver in the kernel already. + +In ACPI, the device identification object called _CID (Compatible ID) is used to +list the IDs of devices the given one is compatible with, but those IDs must +belong to one of the namespaces prescribed by the ACPI specification (see +Section 6.1.2 of ACPI 6.0 for details) and the DT namespace is not one of them. +Moreover, the specification mandates that either a _HID or an _ADR identification +object be present for all ACPI objects representing devices (Section 6.1 of ACPI +6.0). For non-enumerable bus types that object must be _HID and its value must +be a device ID from one of the namespaces prescribed by the specification too. + +The special DT namespace link device ID, PRP0001, provides a means to use the +existing DT-compatible device identification in ACPI and to satisfy the above +requirements following from the ACPI specification at the same time. Namely, +if PRP0001 is returned by _HID, the ACPI subsystem will look for the +"compatible" property in the device object's _DSD and will use the value of that +property to identify the corresponding device in analogy with the original DT +device identification algorithm. If the "compatible" property is not present +or its value is not valid, the device will not be enumerated by the ACPI +subsystem. Otherwise, it will be enumerated automatically as a platform device +(except when an I2C or SPI link from the device to its parent is present, in +which case the ACPI core will leave the device enumeration to the parent's +driver) and the identification strings from the "compatible" property value will +be used to find a driver for the device along with the device IDs listed by _CID +(if present). + +Analogously, if PRP0001 is present in the list of device IDs returned by _CID, +the identification strings listed by the "compatible" property value (if present +and valid) will be used to look for a driver matching the device, but in that +case their relative priority with respect to the other device IDs listed by +_HID and _CID depends on the position of PRP0001 in the _CID return package. +Specifically, the device IDs returned by _HID and preceding PRP0001 in the _CID +return package will be checked first. Also in that case the bus type the device +will be enumerated to depends on the device ID returned by _HID. + +For example, the following ACPI sample might be used to enumerate an lm75-type +I2C temperature sensor and match it to the driver using the Device Tree +namespace link: + + Device (TMP0) + { + Name (_HID, "PRP0001") + Name (_DSD, Package() { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package (2) { "compatible", "ti,tmp75" }, + } + }) + Method (_CRS, 0, Serialized) + { + Name (SBUF, ResourceTemplate () + { + I2cSerialBusV2 (0x48, ControllerInitiated, + 400000, AddressingMode7Bit, + "\\_SB.PCI0.I2C1", 0x00, + ResourceConsumer, , Exclusive,) + }) + Return (SBUF) + } + } + +It is valid to define device objects with a _HID returning PRP0001 and without +the "compatible" property in the _DSD or a _CID as long as one of their +ancestors provides a _DSD with a valid "compatible" property. Such device +objects are then simply regarded as additional "blocks" providing hierarchical +configuration information to the driver of the composite ancestor device. + +However, PRP0001 can only be returned from either _HID or _CID of a device +object if all of the properties returned by the _DSD associated with it (either +the _DSD of the device object itself or the _DSD of its ancestor in the +"composite device" case described above) can be used in the ACPI environment. +Otherwise, the _DSD itself is regarded as invalid and therefore the "compatible" +property returned by it is meaningless. + +Refer to :doc:`DSD-properties-rules` for more information. diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst index 210ad8acd6df..99677c73f1fb 100644 --- a/Documentation/firmware-guide/acpi/index.rst +++ b/Documentation/firmware-guide/acpi/index.rst @@ -8,3 +8,4 @@ ACPI Support :maxdepth: 1 namespace + enumeration -- cgit v1.2.3-59-g8ed1b From 1cf70ae6f07b071affcd4e324803e928e3336a8d Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 01:52:46 +0800 Subject: Documentation: ACPI: move osi.txt to firmware-guide/acpi and convert to reST This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/osi.txt | 187 --------------------------- Documentation/firmware-guide/acpi/index.rst | 1 + Documentation/firmware-guide/acpi/osi.rst | 190 ++++++++++++++++++++++++++++ 3 files changed, 191 insertions(+), 187 deletions(-) delete mode 100644 Documentation/acpi/osi.txt create mode 100644 Documentation/firmware-guide/acpi/osi.rst diff --git a/Documentation/acpi/osi.txt b/Documentation/acpi/osi.txt deleted file mode 100644 index 50cde0ceb9b0..000000000000 --- a/Documentation/acpi/osi.txt +++ /dev/null @@ -1,187 +0,0 @@ -ACPI _OSI and _REV methods --------------------------- - -An ACPI BIOS can use the "Operating System Interfaces" method (_OSI) -to find out what the operating system supports. Eg. If BIOS -AML code includes _OSI("XYZ"), the kernel's AML interpreter -can evaluate that method, look to see if it supports 'XYZ' -and answer YES or NO to the BIOS. - -The ACPI _REV method returns the "Revision of the ACPI specification -that OSPM supports" - -This document explains how and why the BIOS and Linux should use these methods. -It also explains how and why they are widely misused. - -How to use _OSI ---------------- - -Linux runs on two groups of machines -- those that are tested by the OEM -to be compatible with Linux, and those that were never tested with Linux, -but where Linux was installed to replace the original OS (Windows or OSX). - -The larger group is the systems tested to run only Windows. Not only that, -but many were tested to run with just one specific version of Windows. -So even though the BIOS may use _OSI to query what version of Windows is running, -only a single path through the BIOS has actually been tested. -Experience shows that taking untested paths through the BIOS -exposes Linux to an entire category of BIOS bugs. -For this reason, Linux _OSI defaults must continue to claim compatibility -with all versions of Windows. - -But Linux isn't actually compatible with Windows, and the Linux community -has also been hurt with regressions when Linux adds the latest version of -Windows to its list of _OSI strings. So it is possible that additional strings -will be more thoroughly vetted before shipping upstream in the future. -But it is likely that they will all eventually be added. - -What should an OEM do if they want to support Linux and Windows -using the same BIOS image? Often they need to do something different -for Linux to deal with how Linux is different from Windows. -Here the BIOS should ask exactly what it wants to know: - -_OSI("Linux-OEM-my_interface_name") -where 'OEM' is needed if this is an OEM-specific hook, -and 'my_interface_name' describes the hook, which could be a -quirk, a bug, or a bug-fix. - -In addition, the OEM should send a patch to upstream Linux -via the linux-acpi@vger.kernel.org mailing list. When that patch -is checked into Linux, the OS will answer "YES" when the BIOS -on the OEM's system uses _OSI to ask if the interface is supported -by the OS. Linux distributors can back-port that patch for Linux -pre-installs, and it will be included by all distributions that -re-base to upstream. If the distribution can not update the kernel binary, -they can also add an acpi_osi=Linux-OEM-my_interface_name -cmdline parameter to the boot loader, as needed. - -If the string refers to a feature where the upstream kernel -eventually grows support, a patch should be sent to remove -the string when that support is added to the kernel. - -That was easy. Read on, to find out how to do it wrong. - -Before _OSI, there was _OS --------------------------- - -ACPI 1.0 specified "_OS" as an -"object that evaluates to a string that identifies the operating system." - -The ACPI BIOS flow would include an evaluation of _OS, and the AML -interpreter in the kernel would return to it a string identifying the OS: - -Windows 98, SE: "Microsoft Windows" -Windows ME: "Microsoft WindowsME:Millenium Edition" -Windows NT: "Microsoft Windows NT" - -The idea was on a platform tasked with running multiple OS's, -the BIOS could use _OS to enable devices that an OS -might support, or enable quirks or bug workarounds -necessary to make the platform compatible with that pre-existing OS. - -But _OS had fundamental problems. First, the BIOS needed to know the name -of every possible version of the OS that would run on it, and needed to know -all the quirks of those OS's. Certainly it would make more sense -for the BIOS to ask *specific* things of the OS, such -"do you support a specific interface", and thus in ACPI 3.0, -_OSI was born to replace _OS. - -_OS was abandoned, though even today, many BIOS look for -_OS "Microsoft Windows NT", though it seems somewhat far-fetched -that anybody would install those old operating systems -over what came with the machine. - -Linux answers "Microsoft Windows NT" to please that BIOS idiom. -That is the *only* viable strategy, as that is what modern Windows does, -and so doing otherwise could steer the BIOS down an untested path. - -_OSI is born, and immediately misused --------------------------------------- - -With _OSI, the *BIOS* provides the string describing an interface, -and asks the OS: "YES/NO, are you compatible with this interface?" - -eg. _OSI("3.0 Thermal Model") would return TRUE if the OS knows how -to deal with the thermal extensions made to the ACPI 3.0 specification. -An old OS that doesn't know about those extensions would answer FALSE, -and a new OS may be able to return TRUE. - -For an OS-specific interface, the ACPI spec said that the BIOS and the OS -were to agree on a string of the form such as "Windows-interface_name". - -But two bad things happened. First, the Windows ecosystem used _OSI -not as designed, but as a direct replacement for _OS -- identifying -the OS version, rather than an OS supported interface. Indeed, right -from the start, the ACPI 3.0 spec itself codified this misuse -in example code using _OSI("Windows 2001"). - -This misuse was adopted and continues today. - -Linux had no choice but to also return TRUE to _OSI("Windows 2001") -and its successors. To do otherwise would virtually guarantee breaking -a BIOS that has been tested only with that _OSI returning TRUE. - -This strategy is problematic, as Linux is never completely compatible with -the latest version of Windows, and sometimes it takes more than a year -to iron out incompatibilities. - -Not to be out-done, the Linux community made things worse by returning TRUE -to _OSI("Linux"). Doing so is even worse than the Windows misuse -of _OSI, as "Linux" does not even contain any version information. -_OSI("Linux") led to some BIOS' malfunctioning due to BIOS writer's -using it in untested BIOS flows. But some OEM's used _OSI("Linux") -in tested flows to support real Linux features. In 2009, Linux -removed _OSI("Linux"), and added a cmdline parameter to restore it -for legacy systems still needed it. Further a BIOS_BUG warning prints -for all BIOS's that invoke it. - -No BIOS should use _OSI("Linux"). - -The result is a strategy for Linux to maximize compatibility with -ACPI BIOS that are tested on Windows machines. There is a real risk -of over-stating that compatibility; but the alternative has often been -catastrophic failure resulting from the BIOS taking paths that -were never validated under *any* OS. - -Do not use _REV ---------------- - -Since _OSI("Linux") went away, some BIOS writers used _REV -to support Linux and Windows differences in the same BIOS. - -_REV was defined in ACPI 1.0 to return the version of ACPI -supported by the OS and the OS AML interpreter. - -Modern Windows returns _REV = 2. Linux used ACPI_CA_SUPPORT_LEVEL, -which would increment, based on the version of the spec supported. - -Unfortunately, _REV was also misused. eg. some BIOS would check -for _REV = 3, and do something for Linux, but when Linux returned -_REV = 4, that support broke. - -In response to this problem, Linux returns _REV = 2 always, -from mid-2015 onward. The ACPI specification will also be updated -to reflect that _REV is deprecated, and always returns 2. - -Apple Mac and _OSI("Darwin") ----------------------------- - -On Apple's Mac platforms, the ACPI BIOS invokes _OSI("Darwin") -to determine if the machine is running Apple OSX. - -Like Linux's _OSI("*Windows*") strategy, Linux defaults to -answering YES to _OSI("Darwin") to enable full access -to the hardware and validated BIOS paths seen by OSX. -Just like on Windows-tested platforms, this strategy has risks. - -Starting in Linux-3.18, the kernel answered YES to _OSI("Darwin") -for the purpose of enabling Mac Thunderbolt support. Further, -if the kernel noticed _OSI("Darwin") being invoked, it additionally -disabled all _OSI("*Windows*") to keep poorly written Mac BIOS -from going down untested combinations of paths. - -The Linux-3.18 change in default caused power regressions on Mac -laptops, and the 3.18 implementation did not allow changing -the default via cmdline "acpi_osi=!Darwin". Linux-4.7 fixed -the ability to use acpi_osi=!Darwin as a workaround, and -we hope to see Mac Thunderbolt power management support in Linux-4.11. diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst index 99677c73f1fb..868bd25a3398 100644 --- a/Documentation/firmware-guide/acpi/index.rst +++ b/Documentation/firmware-guide/acpi/index.rst @@ -9,3 +9,4 @@ ACPI Support namespace enumeration + osi diff --git a/Documentation/firmware-guide/acpi/osi.rst b/Documentation/firmware-guide/acpi/osi.rst new file mode 100644 index 000000000000..29e9ef79ebc0 --- /dev/null +++ b/Documentation/firmware-guide/acpi/osi.rst @@ -0,0 +1,190 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================== +ACPI _OSI and _REV methods +========================== + +An ACPI BIOS can use the "Operating System Interfaces" method (_OSI) +to find out what the operating system supports. Eg. If BIOS +AML code includes _OSI("XYZ"), the kernel's AML interpreter +can evaluate that method, look to see if it supports 'XYZ' +and answer YES or NO to the BIOS. + +The ACPI _REV method returns the "Revision of the ACPI specification +that OSPM supports" + +This document explains how and why the BIOS and Linux should use these methods. +It also explains how and why they are widely misused. + +How to use _OSI +=============== + +Linux runs on two groups of machines -- those that are tested by the OEM +to be compatible with Linux, and those that were never tested with Linux, +but where Linux was installed to replace the original OS (Windows or OSX). + +The larger group is the systems tested to run only Windows. Not only that, +but many were tested to run with just one specific version of Windows. +So even though the BIOS may use _OSI to query what version of Windows is running, +only a single path through the BIOS has actually been tested. +Experience shows that taking untested paths through the BIOS +exposes Linux to an entire category of BIOS bugs. +For this reason, Linux _OSI defaults must continue to claim compatibility +with all versions of Windows. + +But Linux isn't actually compatible with Windows, and the Linux community +has also been hurt with regressions when Linux adds the latest version of +Windows to its list of _OSI strings. So it is possible that additional strings +will be more thoroughly vetted before shipping upstream in the future. +But it is likely that they will all eventually be added. + +What should an OEM do if they want to support Linux and Windows +using the same BIOS image? Often they need to do something different +for Linux to deal with how Linux is different from Windows. +Here the BIOS should ask exactly what it wants to know: + +_OSI("Linux-OEM-my_interface_name") +where 'OEM' is needed if this is an OEM-specific hook, +and 'my_interface_name' describes the hook, which could be a +quirk, a bug, or a bug-fix. + +In addition, the OEM should send a patch to upstream Linux +via the linux-acpi@vger.kernel.org mailing list. When that patch +is checked into Linux, the OS will answer "YES" when the BIOS +on the OEM's system uses _OSI to ask if the interface is supported +by the OS. Linux distributors can back-port that patch for Linux +pre-installs, and it will be included by all distributions that +re-base to upstream. If the distribution can not update the kernel binary, +they can also add an acpi_osi=Linux-OEM-my_interface_name +cmdline parameter to the boot loader, as needed. + +If the string refers to a feature where the upstream kernel +eventually grows support, a patch should be sent to remove +the string when that support is added to the kernel. + +That was easy. Read on, to find out how to do it wrong. + +Before _OSI, there was _OS +========================== + +ACPI 1.0 specified "_OS" as an +"object that evaluates to a string that identifies the operating system." + +The ACPI BIOS flow would include an evaluation of _OS, and the AML +interpreter in the kernel would return to it a string identifying the OS: + +Windows 98, SE: "Microsoft Windows" +Windows ME: "Microsoft WindowsME:Millenium Edition" +Windows NT: "Microsoft Windows NT" + +The idea was on a platform tasked with running multiple OS's, +the BIOS could use _OS to enable devices that an OS +might support, or enable quirks or bug workarounds +necessary to make the platform compatible with that pre-existing OS. + +But _OS had fundamental problems. First, the BIOS needed to know the name +of every possible version of the OS that would run on it, and needed to know +all the quirks of those OS's. Certainly it would make more sense +for the BIOS to ask *specific* things of the OS, such +"do you support a specific interface", and thus in ACPI 3.0, +_OSI was born to replace _OS. + +_OS was abandoned, though even today, many BIOS look for +_OS "Microsoft Windows NT", though it seems somewhat far-fetched +that anybody would install those old operating systems +over what came with the machine. + +Linux answers "Microsoft Windows NT" to please that BIOS idiom. +That is the *only* viable strategy, as that is what modern Windows does, +and so doing otherwise could steer the BIOS down an untested path. + +_OSI is born, and immediately misused +===================================== + +With _OSI, the *BIOS* provides the string describing an interface, +and asks the OS: "YES/NO, are you compatible with this interface?" + +eg. _OSI("3.0 Thermal Model") would return TRUE if the OS knows how +to deal with the thermal extensions made to the ACPI 3.0 specification. +An old OS that doesn't know about those extensions would answer FALSE, +and a new OS may be able to return TRUE. + +For an OS-specific interface, the ACPI spec said that the BIOS and the OS +were to agree on a string of the form such as "Windows-interface_name". + +But two bad things happened. First, the Windows ecosystem used _OSI +not as designed, but as a direct replacement for _OS -- identifying +the OS version, rather than an OS supported interface. Indeed, right +from the start, the ACPI 3.0 spec itself codified this misuse +in example code using _OSI("Windows 2001"). + +This misuse was adopted and continues today. + +Linux had no choice but to also return TRUE to _OSI("Windows 2001") +and its successors. To do otherwise would virtually guarantee breaking +a BIOS that has been tested only with that _OSI returning TRUE. + +This strategy is problematic, as Linux is never completely compatible with +the latest version of Windows, and sometimes it takes more than a year +to iron out incompatibilities. + +Not to be out-done, the Linux community made things worse by returning TRUE +to _OSI("Linux"). Doing so is even worse than the Windows misuse +of _OSI, as "Linux" does not even contain any version information. +_OSI("Linux") led to some BIOS' malfunctioning due to BIOS writer's +using it in untested BIOS flows. But some OEM's used _OSI("Linux") +in tested flows to support real Linux features. In 2009, Linux +removed _OSI("Linux"), and added a cmdline parameter to restore it +for legacy systems still needed it. Further a BIOS_BUG warning prints +for all BIOS's that invoke it. + +No BIOS should use _OSI("Linux"). + +The result is a strategy for Linux to maximize compatibility with +ACPI BIOS that are tested on Windows machines. There is a real risk +of over-stating that compatibility; but the alternative has often been +catastrophic failure resulting from the BIOS taking paths that +were never validated under *any* OS. + +Do not use _REV +=============== + +Since _OSI("Linux") went away, some BIOS writers used _REV +to support Linux and Windows differences in the same BIOS. + +_REV was defined in ACPI 1.0 to return the version of ACPI +supported by the OS and the OS AML interpreter. + +Modern Windows returns _REV = 2. Linux used ACPI_CA_SUPPORT_LEVEL, +which would increment, based on the version of the spec supported. + +Unfortunately, _REV was also misused. eg. some BIOS would check +for _REV = 3, and do something for Linux, but when Linux returned +_REV = 4, that support broke. + +In response to this problem, Linux returns _REV = 2 always, +from mid-2015 onward. The ACPI specification will also be updated +to reflect that _REV is deprecated, and always returns 2. + +Apple Mac and _OSI("Darwin") +============================ + +On Apple's Mac platforms, the ACPI BIOS invokes _OSI("Darwin") +to determine if the machine is running Apple OSX. + +Like Linux's _OSI("*Windows*") strategy, Linux defaults to +answering YES to _OSI("Darwin") to enable full access +to the hardware and validated BIOS paths seen by OSX. +Just like on Windows-tested platforms, this strategy has risks. + +Starting in Linux-3.18, the kernel answered YES to _OSI("Darwin") +for the purpose of enabling Mac Thunderbolt support. Further, +if the kernel noticed _OSI("Darwin") being invoked, it additionally +disabled all _OSI("*Windows*") to keep poorly written Mac BIOS +from going down untested combinations of paths. + +The Linux-3.18 change in default caused power regressions on Mac +laptops, and the 3.18 implementation did not allow changing +the default via cmdline "acpi_osi=!Darwin". Linux-4.7 fixed +the ability to use acpi_osi=!Darwin as a workaround, and +we hope to see Mac Thunderbolt power management support in Linux-4.11. -- cgit v1.2.3-59-g8ed1b From 25710e23cdee4d4cfc140d34dd627b76be62c9c1 Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 01:52:47 +0800 Subject: Documentation: ACPI: move linuxized-acpica.txt to driver-api/acpi and convert to reST This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/linuxized-acpica.txt | 262 ------------------- Documentation/driver-api/acpi/index.rst | 1 + Documentation/driver-api/acpi/linuxized-acpica.rst | 279 +++++++++++++++++++++ 3 files changed, 280 insertions(+), 262 deletions(-) delete mode 100644 Documentation/acpi/linuxized-acpica.txt create mode 100644 Documentation/driver-api/acpi/linuxized-acpica.rst diff --git a/Documentation/acpi/linuxized-acpica.txt b/Documentation/acpi/linuxized-acpica.txt deleted file mode 100644 index 3ad7b0dfb083..000000000000 --- a/Documentation/acpi/linuxized-acpica.txt +++ /dev/null @@ -1,262 +0,0 @@ -Linuxized ACPICA - Introduction to ACPICA Release Automation - -Copyright (C) 2013-2016, Intel Corporation -Author: Lv Zheng - - -Abstract: - -This document describes the ACPICA project and the relationship between -ACPICA and Linux. It also describes how ACPICA code in drivers/acpi/acpica, -include/acpi and tools/power/acpi is automatically updated to follow the -upstream. - - -1. ACPICA Project - - The ACPI Component Architecture (ACPICA) project provides an operating - system (OS)-independent reference implementation of the Advanced - Configuration and Power Interface Specification (ACPI). It has been - adapted by various host OSes. By directly integrating ACPICA, Linux can - also benefit from the application experiences of ACPICA from other host - OSes. - - The homepage of ACPICA project is: www.acpica.org, it is maintained and - supported by Intel Corporation. - - The following figure depicts the Linux ACPI subsystem where the ACPICA - adaptation is included: - - +---------------------------------------------------------+ - | | - | +---------------------------------------------------+ | - | | +------------------+ | | - | | | Table Management | | | - | | +------------------+ | | - | | +----------------------+ | | - | | | Namespace Management | | | - | | +----------------------+ | | - | | +------------------+ ACPICA Components | | - | | | Event Management | | | - | | +------------------+ | | - | | +---------------------+ | | - | | | Resource Management | | | - | | +---------------------+ | | - | | +---------------------+ | | - | | | Hardware Management | | | - | | +---------------------+ | | - | +---------------------------------------------------+ | | - | | | +------------------+ | | | - | | | | OS Service Layer | | | | - | | | +------------------+ | | | - | | +-------------------------------------------------|-+ | - | | +--------------------+ | | - | | | Device Enumeration | | | - | | +--------------------+ | | - | | +------------------+ | | - | | | Power Management | | | - | | +------------------+ Linux/ACPI Components | | - | | +--------------------+ | | - | | | Thermal Management | | | - | | +--------------------+ | | - | | +--------------------------+ | | - | | | Drivers for ACPI Devices | | | - | | +--------------------------+ | | - | | +--------+ | | - | | | ...... | | | - | | +--------+ | | - | +---------------------------------------------------+ | - | | - +---------------------------------------------------------+ - - Figure 1. Linux ACPI Software Components - - NOTE: - A. OS Service Layer - Provided by Linux to offer OS dependent - implementation of the predefined ACPICA interfaces (acpi_os_*). - include/acpi/acpiosxf.h - drivers/acpi/osl.c - include/acpi/platform - include/asm/acenv.h - B. ACPICA Functionality - Released from ACPICA code base to offer - OS independent implementation of the ACPICA interfaces (acpi_*). - drivers/acpi/acpica - include/acpi/ac*.h - tools/power/acpi - C. Linux/ACPI Functionality - Providing Linux specific ACPI - functionality to the other Linux kernel subsystems and user space - programs. - drivers/acpi - include/linux/acpi.h - include/linux/acpi*.h - include/acpi - tools/power/acpi - D. Architecture Specific ACPICA/ACPI Functionalities - Provided by the - ACPI subsystem to offer architecture specific implementation of the - ACPI interfaces. They are Linux specific components and are out of - the scope of this document. - include/asm/acpi.h - include/asm/acpi*.h - arch/*/acpi - -2. ACPICA Release - - The ACPICA project maintains its code base at the following repository URL: - https://github.com/acpica/acpica.git. As a rule, a release is made every - month. - - As the coding style adopted by the ACPICA project is not acceptable by - Linux, there is a release process to convert the ACPICA git commits into - Linux patches. The patches generated by this process are referred to as - "linuxized ACPICA patches". The release process is carried out on a local - copy the ACPICA git repository. Each commit in the monthly release is - converted into a linuxized ACPICA patch. Together, they form the monthly - ACPICA release patchset for the Linux ACPI community. This process is - illustrated in the following figure: - - +-----------------------------+ - | acpica / master (-) commits | - +-----------------------------+ - /|\ | - | \|/ - | /---------------------\ +----------------------+ - | < Linuxize repo Utility >-->| old linuxized acpica |--+ - | \---------------------/ +----------------------+ | - | | - /---------\ | - < git reset > \ - \---------/ \ - /|\ /+-+ - | / | - +-----------------------------+ | | - | acpica / master (+) commits | | | - +-----------------------------+ | | - | | | - \|/ | | - /-----------------------\ +----------------------+ | | - < Linuxize repo Utilities >-->| new linuxized acpica |--+ | - \-----------------------/ +----------------------+ | - \|/ - +--------------------------+ /----------------------\ - | Linuxized ACPICA Patches |<----------------< Linuxize patch Utility > - +--------------------------+ \----------------------/ - | - \|/ - /---------------------------\ - < Linux ACPI Community Review > - \---------------------------/ - | - \|/ - +-----------------------+ /------------------\ +----------------+ - | linux-pm / linux-next |-->< Linux Merge Window >-->| linux / master | - +-----------------------+ \------------------/ +----------------+ - - Figure 2. ACPICA -> Linux Upstream Process - - NOTE: - A. Linuxize Utilities - Provided by the ACPICA repository, including a - utility located in source/tools/acpisrc folder and a number of - scripts located in generate/linux folder. - B. acpica / master - "master" branch of the git repository at - . - C. linux-pm / linux-next - "linux-next" branch of the git repository at - . - D. linux / master - "master" branch of the git repository at - . - - Before the linuxized ACPICA patches are sent to the Linux ACPI community - for review, there is a quality assurance build test process to reduce - porting issues. Currently this build process only takes care of the - following kernel configuration options: - CONFIG_ACPI/CONFIG_ACPI_DEBUG/CONFIG_ACPI_DEBUGGER - -3. ACPICA Divergences - - Ideally, all of the ACPICA commits should be converted into Linux patches - automatically without manual modifications, the "linux / master" tree should - contain the ACPICA code that exactly corresponds to the ACPICA code - contained in "new linuxized acpica" tree and it should be possible to run - the release process fully automatically. - - As a matter of fact, however, there are source code differences between - the ACPICA code in Linux and the upstream ACPICA code, referred to as - "ACPICA Divergences". - - The various sources of ACPICA divergences include: - 1. Legacy divergences - Before the current ACPICA release process was - established, there already had been divergences between Linux and - ACPICA. Over the past several years those divergences have been greatly - reduced, but there still are several ones and it takes time to figure - out the underlying reasons for their existence. - 2. Manual modifications - Any manual modification (eg. coding style fixes) - made directly in the Linux sources obviously hurts the ACPICA release - automation. Thus it is recommended to fix such issues in the ACPICA - upstream source code and generate the linuxized fix using the ACPICA - release utilities (please refer to Section 4 below for the details). - 3. Linux specific features - Sometimes it's impossible to use the - current ACPICA APIs to implement features required by the Linux kernel, - so Linux developers occasionally have to change ACPICA code directly. - Those changes may not be acceptable by ACPICA upstream and in such cases - they are left as committed ACPICA divergences unless the ACPICA side can - implement new mechanisms as replacements for them. - 4. ACPICA release fixups - ACPICA only tests commits using a set of the - user space simulation utilities, thus the linuxized ACPICA patches may - break the Linux kernel, leaving us build/boot failures. In order to - avoid breaking Linux bisection, fixes are applied directly to the - linuxized ACPICA patches during the release process. When the release - fixups are backported to the upstream ACPICA sources, they must follow - the upstream ACPICA rules and so further modifications may appear. - That may result in the appearance of new divergences. - 5. Fast tracking of ACPICA commits - Some ACPICA commits are regression - fixes or stable-candidate material, so they are applied in advance with - respect to the ACPICA release process. If such commits are reverted or - rebased on the ACPICA side in order to offer better solutions, new ACPICA - divergences are generated. - -4. ACPICA Development - - This paragraph guides Linux developers to use the ACPICA upstream release - utilities to obtain Linux patches corresponding to upstream ACPICA commits - before they become available from the ACPICA release process. - - 1. Cherry-pick an ACPICA commit - - First you need to git clone the ACPICA repository and the ACPICA change - you want to cherry pick must be committed into the local repository. - - Then the gen-patch.sh command can help to cherry-pick an ACPICA commit - from the ACPICA local repository: - - $ git clone https://github.com/acpica/acpica - $ cd acpica - $ generate/linux/gen-patch.sh -u [commit ID] - - Here the commit ID is the ACPICA local repository commit ID you want to - cherry pick. It can be omitted if the commit is "HEAD". - - 2. Cherry-pick recent ACPICA commits - - Sometimes you need to rebase your code on top of the most recent ACPICA - changes that haven't been applied to Linux yet. - - You can generate the ACPICA release series yourself and rebase your code on - top of the generated ACPICA release patches: - - $ git clone https://github.com/acpica/acpica - $ cd acpica - $ generate/linux/make-patches.sh -u [commit ID] - - The commit ID should be the last ACPICA commit accepted by Linux. Usually, - it is the commit modifying ACPI_CA_VERSION. It can be found by executing - "git blame source/include/acpixf.h" and referencing the line that contains - "ACPI_CA_VERSION". - - 3. Inspect the current divergences - - If you have local copies of both Linux and upstream ACPICA, you can generate - a diff file indicating the state of the current divergences: - - # git clone https://github.com/acpica/acpica - # git clone http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git - # cd acpica - # generate/linux/divergences.sh -s ../linux diff --git a/Documentation/driver-api/acpi/index.rst b/Documentation/driver-api/acpi/index.rst index 898b0c60671a..12649947b19b 100644 --- a/Documentation/driver-api/acpi/index.rst +++ b/Documentation/driver-api/acpi/index.rst @@ -5,3 +5,4 @@ ACPI Support .. toctree:: :maxdepth: 2 + linuxized-acpica diff --git a/Documentation/driver-api/acpi/linuxized-acpica.rst b/Documentation/driver-api/acpi/linuxized-acpica.rst new file mode 100644 index 000000000000..0ca8f1538519 --- /dev/null +++ b/Documentation/driver-api/acpi/linuxized-acpica.rst @@ -0,0 +1,279 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: + +============================================================ +Linuxized ACPICA - Introduction to ACPICA Release Automation +============================================================ + +:Copyright: |copy| 2013-2016, Intel Corporation + +:Author: Lv Zheng + + +Abstract +======== +This document describes the ACPICA project and the relationship between +ACPICA and Linux. It also describes how ACPICA code in drivers/acpi/acpica, +include/acpi and tools/power/acpi is automatically updated to follow the +upstream. + +ACPICA Project +============== + +The ACPI Component Architecture (ACPICA) project provides an operating +system (OS)-independent reference implementation of the Advanced +Configuration and Power Interface Specification (ACPI). It has been +adapted by various host OSes. By directly integrating ACPICA, Linux can +also benefit from the application experiences of ACPICA from other host +OSes. + +The homepage of ACPICA project is: www.acpica.org, it is maintained and +supported by Intel Corporation. + +The following figure depicts the Linux ACPI subsystem where the ACPICA +adaptation is included:: + + +---------------------------------------------------------+ + | | + | +---------------------------------------------------+ | + | | +------------------+ | | + | | | Table Management | | | + | | +------------------+ | | + | | +----------------------+ | | + | | | Namespace Management | | | + | | +----------------------+ | | + | | +------------------+ ACPICA Components | | + | | | Event Management | | | + | | +------------------+ | | + | | +---------------------+ | | + | | | Resource Management | | | + | | +---------------------+ | | + | | +---------------------+ | | + | | | Hardware Management | | | + | | +---------------------+ | | + | +---------------------------------------------------+ | | + | | | +------------------+ | | | + | | | | OS Service Layer | | | | + | | | +------------------+ | | | + | | +-------------------------------------------------|-+ | + | | +--------------------+ | | + | | | Device Enumeration | | | + | | +--------------------+ | | + | | +------------------+ | | + | | | Power Management | | | + | | +------------------+ Linux/ACPI Components | | + | | +--------------------+ | | + | | | Thermal Management | | | + | | +--------------------+ | | + | | +--------------------------+ | | + | | | Drivers for ACPI Devices | | | + | | +--------------------------+ | | + | | +--------+ | | + | | | ...... | | | + | | +--------+ | | + | +---------------------------------------------------+ | + | | + +---------------------------------------------------------+ + + Figure 1. Linux ACPI Software Components + +.. note:: + A. OS Service Layer - Provided by Linux to offer OS dependent + implementation of the predefined ACPICA interfaces (acpi_os_*). + :: + + include/acpi/acpiosxf.h + drivers/acpi/osl.c + include/acpi/platform + include/asm/acenv.h + B. ACPICA Functionality - Released from ACPICA code base to offer + OS independent implementation of the ACPICA interfaces (acpi_*). + :: + + drivers/acpi/acpica + include/acpi/ac*.h + tools/power/acpi + C. Linux/ACPI Functionality - Providing Linux specific ACPI + functionality to the other Linux kernel subsystems and user space + programs. + :: + + drivers/acpi + include/linux/acpi.h + include/linux/acpi*.h + include/acpi + tools/power/acpi + D. Architecture Specific ACPICA/ACPI Functionalities - Provided by the + ACPI subsystem to offer architecture specific implementation of the + ACPI interfaces. They are Linux specific components and are out of + the scope of this document. + :: + + include/asm/acpi.h + include/asm/acpi*.h + arch/*/acpi + +ACPICA Release +============== + +The ACPICA project maintains its code base at the following repository URL: +https://github.com/acpica/acpica.git. As a rule, a release is made every +month. + +As the coding style adopted by the ACPICA project is not acceptable by +Linux, there is a release process to convert the ACPICA git commits into +Linux patches. The patches generated by this process are referred to as +"linuxized ACPICA patches". The release process is carried out on a local +copy the ACPICA git repository. Each commit in the monthly release is +converted into a linuxized ACPICA patch. Together, they form the monthly +ACPICA release patchset for the Linux ACPI community. This process is +illustrated in the following figure:: + + +-----------------------------+ + | acpica / master (-) commits | + +-----------------------------+ + /|\ | + | \|/ + | /---------------------\ +----------------------+ + | < Linuxize repo Utility >-->| old linuxized acpica |--+ + | \---------------------/ +----------------------+ | + | | + /---------\ | + < git reset > \ + \---------/ \ + /|\ /+-+ + | / | + +-----------------------------+ | | + | acpica / master (+) commits | | | + +-----------------------------+ | | + | | | + \|/ | | + /-----------------------\ +----------------------+ | | + < Linuxize repo Utilities >-->| new linuxized acpica |--+ | + \-----------------------/ +----------------------+ | + \|/ + +--------------------------+ /----------------------\ + | Linuxized ACPICA Patches |<----------------< Linuxize patch Utility > + +--------------------------+ \----------------------/ + | + \|/ + /---------------------------\ + < Linux ACPI Community Review > + \---------------------------/ + | + \|/ + +-----------------------+ /------------------\ +----------------+ + | linux-pm / linux-next |-->< Linux Merge Window >-->| linux / master | + +-----------------------+ \------------------/ +----------------+ + + Figure 2. ACPICA -> Linux Upstream Process + +.. note:: + A. Linuxize Utilities - Provided by the ACPICA repository, including a + utility located in source/tools/acpisrc folder and a number of + scripts located in generate/linux folder. + B. acpica / master - "master" branch of the git repository at + . + C. linux-pm / linux-next - "linux-next" branch of the git repository at + . + D. linux / master - "master" branch of the git repository at + . + + Before the linuxized ACPICA patches are sent to the Linux ACPI community + for review, there is a quality assurance build test process to reduce + porting issues. Currently this build process only takes care of the + following kernel configuration options: + CONFIG_ACPI/CONFIG_ACPI_DEBUG/CONFIG_ACPI_DEBUGGER + +ACPICA Divergences +================== + +Ideally, all of the ACPICA commits should be converted into Linux patches +automatically without manual modifications, the "linux / master" tree should +contain the ACPICA code that exactly corresponds to the ACPICA code +contained in "new linuxized acpica" tree and it should be possible to run +the release process fully automatically. + +As a matter of fact, however, there are source code differences between +the ACPICA code in Linux and the upstream ACPICA code, referred to as +"ACPICA Divergences". + +The various sources of ACPICA divergences include: + 1. Legacy divergences - Before the current ACPICA release process was + established, there already had been divergences between Linux and + ACPICA. Over the past several years those divergences have been greatly + reduced, but there still are several ones and it takes time to figure + out the underlying reasons for their existence. + 2. Manual modifications - Any manual modification (eg. coding style fixes) + made directly in the Linux sources obviously hurts the ACPICA release + automation. Thus it is recommended to fix such issues in the ACPICA + upstream source code and generate the linuxized fix using the ACPICA + release utilities (please refer to Section 4 below for the details). + 3. Linux specific features - Sometimes it's impossible to use the + current ACPICA APIs to implement features required by the Linux kernel, + so Linux developers occasionally have to change ACPICA code directly. + Those changes may not be acceptable by ACPICA upstream and in such cases + they are left as committed ACPICA divergences unless the ACPICA side can + implement new mechanisms as replacements for them. + 4. ACPICA release fixups - ACPICA only tests commits using a set of the + user space simulation utilities, thus the linuxized ACPICA patches may + break the Linux kernel, leaving us build/boot failures. In order to + avoid breaking Linux bisection, fixes are applied directly to the + linuxized ACPICA patches during the release process. When the release + fixups are backported to the upstream ACPICA sources, they must follow + the upstream ACPICA rules and so further modifications may appear. + That may result in the appearance of new divergences. + 5. Fast tracking of ACPICA commits - Some ACPICA commits are regression + fixes or stable-candidate material, so they are applied in advance with + respect to the ACPICA release process. If such commits are reverted or + rebased on the ACPICA side in order to offer better solutions, new ACPICA + divergences are generated. + +ACPICA Development +================== + +This paragraph guides Linux developers to use the ACPICA upstream release +utilities to obtain Linux patches corresponding to upstream ACPICA commits +before they become available from the ACPICA release process. + + 1. Cherry-pick an ACPICA commit + + First you need to git clone the ACPICA repository and the ACPICA change + you want to cherry pick must be committed into the local repository. + + Then the gen-patch.sh command can help to cherry-pick an ACPICA commit + from the ACPICA local repository:: + + $ git clone https://github.com/acpica/acpica + $ cd acpica + $ generate/linux/gen-patch.sh -u [commit ID] + + Here the commit ID is the ACPICA local repository commit ID you want to + cherry pick. It can be omitted if the commit is "HEAD". + + 2. Cherry-pick recent ACPICA commits + + Sometimes you need to rebase your code on top of the most recent ACPICA + changes that haven't been applied to Linux yet. + + You can generate the ACPICA release series yourself and rebase your code on + top of the generated ACPICA release patches:: + + $ git clone https://github.com/acpica/acpica + $ cd acpica + $ generate/linux/make-patches.sh -u [commit ID] + + The commit ID should be the last ACPICA commit accepted by Linux. Usually, + it is the commit modifying ACPI_CA_VERSION. It can be found by executing + "git blame source/include/acpixf.h" and referencing the line that contains + "ACPI_CA_VERSION". + + 3. Inspect the current divergences + + If you have local copies of both Linux and upstream ACPICA, you can generate + a diff file indicating the state of the current divergences:: + + # git clone https://github.com/acpica/acpica + # git clone http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git + # cd acpica + # generate/linux/divergences.sh -s ../linux -- cgit v1.2.3-59-g8ed1b From 97a63dd43477a93fa0fc53ff082af8d64ff618e1 Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 01:52:48 +0800 Subject: Documentation: ACPI: move scan_handlers.txt to driver-api/acpi and convert to reST This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/scan_handlers.txt | 77 ----------------------- Documentation/driver-api/acpi/index.rst | 1 + Documentation/driver-api/acpi/scan_handlers.rst | 83 +++++++++++++++++++++++++ 3 files changed, 84 insertions(+), 77 deletions(-) delete mode 100644 Documentation/acpi/scan_handlers.txt create mode 100644 Documentation/driver-api/acpi/scan_handlers.rst diff --git a/Documentation/acpi/scan_handlers.txt b/Documentation/acpi/scan_handlers.txt deleted file mode 100644 index 3246ccf15992..000000000000 --- a/Documentation/acpi/scan_handlers.txt +++ /dev/null @@ -1,77 +0,0 @@ -ACPI Scan Handlers - -Copyright (C) 2012, Intel Corporation -Author: Rafael J. Wysocki - -During system initialization and ACPI-based device hot-add, the ACPI namespace -is scanned in search of device objects that generally represent various pieces -of hardware. This causes a struct acpi_device object to be created and -registered with the driver core for every device object in the ACPI namespace -and the hierarchy of those struct acpi_device objects reflects the namespace -layout (i.e. parent device objects in the namespace are represented by parent -struct acpi_device objects and analogously for their children). Those struct -acpi_device objects are referred to as "device nodes" in what follows, but they -should not be confused with struct device_node objects used by the Device Trees -parsing code (although their role is analogous to the role of those objects). - -During ACPI-based device hot-remove device nodes representing pieces of hardware -being removed are unregistered and deleted. - -The core ACPI namespace scanning code in drivers/acpi/scan.c carries out basic -initialization of device nodes, such as retrieving common configuration -information from the device objects represented by them and populating them with -appropriate data, but some of them require additional handling after they have -been registered. For example, if the given device node represents a PCI host -bridge, its registration should cause the PCI bus under that bridge to be -enumerated and PCI devices on that bus to be registered with the driver core. -Similarly, if the device node represents a PCI interrupt link, it is necessary -to configure that link so that the kernel can use it. - -Those additional configuration tasks usually depend on the type of the hardware -component represented by the given device node which can be determined on the -basis of the device node's hardware ID (HID). They are performed by objects -called ACPI scan handlers represented by the following structure: - -struct acpi_scan_handler { - const struct acpi_device_id *ids; - struct list_head list_node; - int (*attach)(struct acpi_device *dev, const struct acpi_device_id *id); - void (*detach)(struct acpi_device *dev); -}; - -where ids is the list of IDs of device nodes the given handler is supposed to -take care of, list_node is the hook to the global list of ACPI scan handlers -maintained by the ACPI core and the .attach() and .detach() callbacks are -executed, respectively, after registration of new device nodes and before -unregistration of device nodes the handler attached to previously. - -The namespace scanning function, acpi_bus_scan(), first registers all of the -device nodes in the given namespace scope with the driver core. Then, it tries -to match a scan handler against each of them using the ids arrays of the -available scan handlers. If a matching scan handler is found, its .attach() -callback is executed for the given device node. If that callback returns 1, -that means that the handler has claimed the device node and is now responsible -for carrying out any additional configuration tasks related to it. It also will -be responsible for preparing the device node for unregistration in that case. -The device node's handler field is then populated with the address of the scan -handler that has claimed it. - -If the .attach() callback returns 0, it means that the device node is not -interesting to the given scan handler and may be matched against the next scan -handler in the list. If it returns a (negative) error code, that means that -the namespace scan should be terminated due to a serious error. The error code -returned should then reflect the type of the error. - -The namespace trimming function, acpi_bus_trim(), first executes .detach() -callbacks from the scan handlers of all device nodes in the given namespace -scope (if they have scan handlers). Next, it unregisters all of the device -nodes in that scope. - -ACPI scan handlers can be added to the list maintained by the ACPI core with the -help of the acpi_scan_add_handler() function taking a pointer to the new scan -handler as an argument. The order in which scan handlers are added to the list -is the order in which they are matched against device nodes during namespace -scans. - -All scan handles must be added to the list before acpi_bus_scan() is run for the -first time and they cannot be removed from it. diff --git a/Documentation/driver-api/acpi/index.rst b/Documentation/driver-api/acpi/index.rst index 12649947b19b..ace0008e54c2 100644 --- a/Documentation/driver-api/acpi/index.rst +++ b/Documentation/driver-api/acpi/index.rst @@ -6,3 +6,4 @@ ACPI Support :maxdepth: 2 linuxized-acpica + scan_handlers diff --git a/Documentation/driver-api/acpi/scan_handlers.rst b/Documentation/driver-api/acpi/scan_handlers.rst new file mode 100644 index 000000000000..7a197b3a33fc --- /dev/null +++ b/Documentation/driver-api/acpi/scan_handlers.rst @@ -0,0 +1,83 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: + +================== +ACPI Scan Handlers +================== + +:Copyright: |copy| 2012, Intel Corporation + +:Author: Rafael J. Wysocki + +During system initialization and ACPI-based device hot-add, the ACPI namespace +is scanned in search of device objects that generally represent various pieces +of hardware. This causes a struct acpi_device object to be created and +registered with the driver core for every device object in the ACPI namespace +and the hierarchy of those struct acpi_device objects reflects the namespace +layout (i.e. parent device objects in the namespace are represented by parent +struct acpi_device objects and analogously for their children). Those struct +acpi_device objects are referred to as "device nodes" in what follows, but they +should not be confused with struct device_node objects used by the Device Trees +parsing code (although their role is analogous to the role of those objects). + +During ACPI-based device hot-remove device nodes representing pieces of hardware +being removed are unregistered and deleted. + +The core ACPI namespace scanning code in drivers/acpi/scan.c carries out basic +initialization of device nodes, such as retrieving common configuration +information from the device objects represented by them and populating them with +appropriate data, but some of them require additional handling after they have +been registered. For example, if the given device node represents a PCI host +bridge, its registration should cause the PCI bus under that bridge to be +enumerated and PCI devices on that bus to be registered with the driver core. +Similarly, if the device node represents a PCI interrupt link, it is necessary +to configure that link so that the kernel can use it. + +Those additional configuration tasks usually depend on the type of the hardware +component represented by the given device node which can be determined on the +basis of the device node's hardware ID (HID). They are performed by objects +called ACPI scan handlers represented by the following structure:: + + struct acpi_scan_handler { + const struct acpi_device_id *ids; + struct list_head list_node; + int (*attach)(struct acpi_device *dev, const struct acpi_device_id *id); + void (*detach)(struct acpi_device *dev); + }; + +where ids is the list of IDs of device nodes the given handler is supposed to +take care of, list_node is the hook to the global list of ACPI scan handlers +maintained by the ACPI core and the .attach() and .detach() callbacks are +executed, respectively, after registration of new device nodes and before +unregistration of device nodes the handler attached to previously. + +The namespace scanning function, acpi_bus_scan(), first registers all of the +device nodes in the given namespace scope with the driver core. Then, it tries +to match a scan handler against each of them using the ids arrays of the +available scan handlers. If a matching scan handler is found, its .attach() +callback is executed for the given device node. If that callback returns 1, +that means that the handler has claimed the device node and is now responsible +for carrying out any additional configuration tasks related to it. It also will +be responsible for preparing the device node for unregistration in that case. +The device node's handler field is then populated with the address of the scan +handler that has claimed it. + +If the .attach() callback returns 0, it means that the device node is not +interesting to the given scan handler and may be matched against the next scan +handler in the list. If it returns a (negative) error code, that means that +the namespace scan should be terminated due to a serious error. The error code +returned should then reflect the type of the error. + +The namespace trimming function, acpi_bus_trim(), first executes .detach() +callbacks from the scan handlers of all device nodes in the given namespace +scope (if they have scan handlers). Next, it unregisters all of the device +nodes in that scope. + +ACPI scan handlers can be added to the list maintained by the ACPI core with the +help of the acpi_scan_add_handler() function taking a pointer to the new scan +handler as an argument. The order in which scan handlers are added to the list +is the order in which they are matched against device nodes during namespace +scans. + +All scan handles must be added to the list before acpi_bus_scan() is run for the +first time and they cannot be removed from it. -- cgit v1.2.3-59-g8ed1b From 538f6f76b9ca5cbcd521db80e137d1c43e55556b Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 01:52:49 +0800 Subject: Documentation: ACPI: move DSD-properties-rules.txt to firmware-guide/acpi and covert to reST This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/DSD-properties-rules.txt | 97 -------------------- .../firmware-guide/acpi/DSD-properties-rules.rst | 100 +++++++++++++++++++++ Documentation/firmware-guide/acpi/index.rst | 1 + 3 files changed, 101 insertions(+), 97 deletions(-) delete mode 100644 Documentation/acpi/DSD-properties-rules.txt create mode 100644 Documentation/firmware-guide/acpi/DSD-properties-rules.rst diff --git a/Documentation/acpi/DSD-properties-rules.txt b/Documentation/acpi/DSD-properties-rules.txt deleted file mode 100644 index 3e4862bdad98..000000000000 --- a/Documentation/acpi/DSD-properties-rules.txt +++ /dev/null @@ -1,97 +0,0 @@ -_DSD Device Properties Usage Rules ----------------------------------- - -Properties, Property Sets and Property Subsets ----------------------------------------------- - -The _DSD (Device Specific Data) configuration object, introduced in ACPI 5.1, -allows any type of device configuration data to be provided via the ACPI -namespace. In principle, the format of the data may be arbitrary, but it has to -be identified by a UUID which must be recognized by the driver processing the -_DSD output. However, there are generic UUIDs defined for _DSD recognized by -the ACPI subsystem in the Linux kernel which automatically processes the data -packages associated with them and makes those data available to device drivers -as "device properties". - -A device property is a data item consisting of a string key and a value (of a -specific type) associated with it. - -In the ACPI _DSD context it is an element of the sub-package following the -generic Device Properties UUID in the _DSD return package as specified in the -Device Properties UUID definition document [1]. - -It also may be regarded as the definition of a key and the associated data type -that can be returned by _DSD in the Device Properties UUID sub-package for a -given device. - -A property set is a collection of properties applicable to a hardware entity -like a device. In the ACPI _DSD context it is the set of all properties that -can be returned in the Device Properties UUID sub-package for the device in -question. - -Property subsets are nested collections of properties. Each of them is -associated with an additional key (name) allowing the subset to be referred -to as a whole (and to be treated as a separate entity). The canonical -representation of property subsets is via the mechanism specified in the -Hierarchical Properties Extension UUID definition document [2]. - -Property sets may be hierarchical. That is, a property set may contain -multiple property subsets that each may contain property subsets of its -own and so on. - -General Validity Rule for Property Sets ---------------------------------------- - -Valid property sets must follow the guidance given by the Device Properties UUID -definition document [1]. - -_DSD properties are intended to be used in addition to, and not instead of, the -existing mechanisms defined by the ACPI specification. Therefore, as a rule, -they should only be used if the ACPI specification does not make direct -provisions for handling the underlying use case. It generally is invalid to -return property sets which do not follow that rule from _DSD in data packages -associated with the Device Properties UUID. - -Additional Considerations -------------------------- - -There are cases in which, even if the general rule given above is followed in -principle, the property set may still not be regarded as a valid one. - -For example, that applies to device properties which may cause kernel code -(either a device driver or a library/subsystem) to access hardware in a way -possibly leading to a conflict with AML methods in the ACPI namespace. In -particular, that may happen if the kernel code uses device properties to -manipulate hardware normally controlled by ACPI methods related to power -management, like _PSx and _DSW (for device objects) or _ON and _OFF (for power -resource objects), or by ACPI device disabling/enabling methods, like _DIS and -_SRS. - -In all cases in which kernel code may do something that will confuse AML as a -result of using device properties, the device properties in question are not -suitable for the ACPI environment and consequently they cannot belong to a valid -property set. - -Property Sets and Device Tree Bindings --------------------------------------- - -It often is useful to make _DSD return property sets that follow Device Tree -bindings. - -In those cases, however, the above validity considerations must be taken into -account in the first place and returning invalid property sets from _DSD must be -avoided. For this reason, it may not be possible to make _DSD return a property -set following the given DT binding literally and completely. Still, for the -sake of code re-use, it may make sense to provide as much of the configuration -data as possible in the form of device properties and complement that with an -ACPI-specific mechanism suitable for the use case at hand. - -In any case, property sets following DT bindings literally should not be -expected to automatically work in the ACPI environment regardless of their -contents. - -References ----------- - -[1] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf -[2] http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf diff --git a/Documentation/firmware-guide/acpi/DSD-properties-rules.rst b/Documentation/firmware-guide/acpi/DSD-properties-rules.rst new file mode 100644 index 000000000000..4306f29b6103 --- /dev/null +++ b/Documentation/firmware-guide/acpi/DSD-properties-rules.rst @@ -0,0 +1,100 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================== +_DSD Device Properties Usage Rules +================================== + +Properties, Property Sets and Property Subsets +============================================== + +The _DSD (Device Specific Data) configuration object, introduced in ACPI 5.1, +allows any type of device configuration data to be provided via the ACPI +namespace. In principle, the format of the data may be arbitrary, but it has to +be identified by a UUID which must be recognized by the driver processing the +_DSD output. However, there are generic UUIDs defined for _DSD recognized by +the ACPI subsystem in the Linux kernel which automatically processes the data +packages associated with them and makes those data available to device drivers +as "device properties". + +A device property is a data item consisting of a string key and a value (of a +specific type) associated with it. + +In the ACPI _DSD context it is an element of the sub-package following the +generic Device Properties UUID in the _DSD return package as specified in the +Device Properties UUID definition document [1]_. + +It also may be regarded as the definition of a key and the associated data type +that can be returned by _DSD in the Device Properties UUID sub-package for a +given device. + +A property set is a collection of properties applicable to a hardware entity +like a device. In the ACPI _DSD context it is the set of all properties that +can be returned in the Device Properties UUID sub-package for the device in +question. + +Property subsets are nested collections of properties. Each of them is +associated with an additional key (name) allowing the subset to be referred +to as a whole (and to be treated as a separate entity). The canonical +representation of property subsets is via the mechanism specified in the +Hierarchical Properties Extension UUID definition document [2]_. + +Property sets may be hierarchical. That is, a property set may contain +multiple property subsets that each may contain property subsets of its +own and so on. + +General Validity Rule for Property Sets +======================================= + +Valid property sets must follow the guidance given by the Device Properties UUID +definition document [1]. + +_DSD properties are intended to be used in addition to, and not instead of, the +existing mechanisms defined by the ACPI specification. Therefore, as a rule, +they should only be used if the ACPI specification does not make direct +provisions for handling the underlying use case. It generally is invalid to +return property sets which do not follow that rule from _DSD in data packages +associated with the Device Properties UUID. + +Additional Considerations +------------------------- + +There are cases in which, even if the general rule given above is followed in +principle, the property set may still not be regarded as a valid one. + +For example, that applies to device properties which may cause kernel code +(either a device driver or a library/subsystem) to access hardware in a way +possibly leading to a conflict with AML methods in the ACPI namespace. In +particular, that may happen if the kernel code uses device properties to +manipulate hardware normally controlled by ACPI methods related to power +management, like _PSx and _DSW (for device objects) or _ON and _OFF (for power +resource objects), or by ACPI device disabling/enabling methods, like _DIS and +_SRS. + +In all cases in which kernel code may do something that will confuse AML as a +result of using device properties, the device properties in question are not +suitable for the ACPI environment and consequently they cannot belong to a valid +property set. + +Property Sets and Device Tree Bindings +====================================== + +It often is useful to make _DSD return property sets that follow Device Tree +bindings. + +In those cases, however, the above validity considerations must be taken into +account in the first place and returning invalid property sets from _DSD must be +avoided. For this reason, it may not be possible to make _DSD return a property +set following the given DT binding literally and completely. Still, for the +sake of code re-use, it may make sense to provide as much of the configuration +data as possible in the form of device properties and complement that with an +ACPI-specific mechanism suitable for the use case at hand. + +In any case, property sets following DT bindings literally should not be +expected to automatically work in the ACPI environment regardless of their +contents. + +References +========== + +.. [1] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf +.. [2] http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst index 868bd25a3398..0e05b843521c 100644 --- a/Documentation/firmware-guide/acpi/index.rst +++ b/Documentation/firmware-guide/acpi/index.rst @@ -10,3 +10,4 @@ ACPI Support namespace enumeration osi + DSD-properties-rules -- cgit v1.2.3-59-g8ed1b From b6dff0e153e919b62e2a1c90fd6e5a4ba922f99b Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 01:52:50 +0800 Subject: Documentation: ACPI: move gpio-properties.txt to firmware-guide/acpi and convert to reST This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/gpio-properties.txt | 223 -------------------- .../firmware-guide/acpi/gpio-properties.rst | 233 +++++++++++++++++++++ Documentation/firmware-guide/acpi/index.rst | 1 + MAINTAINERS | 2 +- 4 files changed, 235 insertions(+), 224 deletions(-) delete mode 100644 Documentation/acpi/gpio-properties.txt create mode 100644 Documentation/firmware-guide/acpi/gpio-properties.rst diff --git a/Documentation/acpi/gpio-properties.txt b/Documentation/acpi/gpio-properties.txt deleted file mode 100644 index 88c65cb5bf0a..000000000000 --- a/Documentation/acpi/gpio-properties.txt +++ /dev/null @@ -1,223 +0,0 @@ -_DSD Device Properties Related to GPIO --------------------------------------- - -With the release of ACPI 5.1, the _DSD configuration object finally -allows names to be given to GPIOs (and other things as well) returned -by _CRS. Previously, we were only able to use an integer index to find -the corresponding GPIO, which is pretty error prone (it depends on -the _CRS output ordering, for example). - -With _DSD we can now query GPIOs using a name instead of an integer -index, like the ASL example below shows: - - // Bluetooth device with reset and shutdown GPIOs - Device (BTH) - { - Name (_HID, ...) - - Name (_CRS, ResourceTemplate () - { - GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly, - "\\_SB.GPO0", 0, ResourceConsumer) {15} - GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly, - "\\_SB.GPO0", 0, ResourceConsumer) {27, 31} - }) - - Name (_DSD, Package () - { - ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), - Package () - { - Package () {"reset-gpios", Package() {^BTH, 1, 1, 0 }}, - Package () {"shutdown-gpios", Package() {^BTH, 0, 0, 0 }}, - } - }) - } - -The format of the supported GPIO property is: - - Package () { "name", Package () { ref, index, pin, active_low }} - - ref - The device that has _CRS containing GpioIo()/GpioInt() resources, - typically this is the device itself (BTH in our case). - index - Index of the GpioIo()/GpioInt() resource in _CRS starting from zero. - pin - Pin in the GpioIo()/GpioInt() resource. Typically this is zero. - active_low - If 1 the GPIO is marked as active_low. - -Since ACPI GpioIo() resource does not have a field saying whether it is -active low or high, the "active_low" argument can be used here. Setting -it to 1 marks the GPIO as active low. - -In our Bluetooth example the "reset-gpios" refers to the second GpioIo() -resource, second pin in that resource with the GPIO number of 31. - -It is possible to leave holes in the array of GPIOs. This is useful in -cases like with SPI host controllers where some chip selects may be -implemented as GPIOs and some as native signals. For example a SPI host -controller can have chip selects 0 and 2 implemented as GPIOs and 1 as -native: - - Package () { - "cs-gpios", - Package () { - ^GPIO, 19, 0, 0, // chip select 0: GPIO - 0, // chip select 1: native signal - ^GPIO, 20, 0, 0, // chip select 2: GPIO - } - } - -Other supported properties --------------------------- - -Following Device Tree compatible device properties are also supported by -_DSD device properties for GPIO controllers: - -- gpio-hog -- output-high -- output-low -- input -- line-name - -Example: - - Name (_DSD, Package () { - // _DSD Hierarchical Properties Extension UUID - ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), - Package () { - Package () {"hog-gpio8", "G8PU"} - } - }) - - Name (G8PU, Package () { - ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), - Package () { - Package () {"gpio-hog", 1}, - Package () {"gpios", Package () {8, 0}}, - Package () {"output-high", 1}, - Package () {"line-name", "gpio8-pullup"}, - } - }) - -- gpio-line-names - -Example: - - Package () { - "gpio-line-names", - Package () { - "SPI0_CS_N", "EXP2_INT", "MUX6_IO", "UART0_RXD", "MUX7_IO", - "LVL_C_A1", "MUX0_IO", "SPI1_MISO" - } - } - -See Documentation/devicetree/bindings/gpio/gpio.txt for more information -about these properties. - -ACPI GPIO Mappings Provided by Drivers --------------------------------------- - -There are systems in which the ACPI tables do not contain _DSD but provide _CRS -with GpioIo()/GpioInt() resources and device drivers still need to work with -them. - -In those cases ACPI device identification objects, _HID, _CID, _CLS, _SUB, _HRV, -available to the driver can be used to identify the device and that is supposed -to be sufficient to determine the meaning and purpose of all of the GPIO lines -listed by the GpioIo()/GpioInt() resources returned by _CRS. In other words, -the driver is supposed to know what to use the GpioIo()/GpioInt() resources for -once it has identified the device. Having done that, it can simply assign names -to the GPIO lines it is going to use and provide the GPIO subsystem with a -mapping between those names and the ACPI GPIO resources corresponding to them. - -To do that, the 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, in analogy with the _DSD GPIO property format specified above. - -For the example Bluetooth device discussed previously the data structures in -question would look like this: - -static const struct acpi_gpio_params reset_gpio = { 1, 1, false }; -static const struct acpi_gpio_params shutdown_gpio = { 0, 0, false }; - -static const struct acpi_gpio_mapping bluetooth_acpi_gpios[] = { - { "reset-gpios", &reset_gpio, 1 }, - { "shutdown-gpios", &shutdown_gpio, 1 }, - { }, -}; - -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. - -Using the _CRS fallback ------------------------ - -If a device does not have _DSD or the driver does not create ACPI GPIO -mapping, the Linux GPIO framework refuses to return any GPIOs. This is -because the driver does not know what it actually gets. For example if we -have a device like below: - - Device (BTH) - { - Name (_HID, ...) - - Name (_CRS, ResourceTemplate () { - GpioIo (Exclusive, PullNone, 0, 0, IoRestrictionNone, - "\\_SB.GPO0", 0, ResourceConsumer) {15} - GpioIo (Exclusive, PullNone, 0, 0, IoRestrictionNone, - "\\_SB.GPO0", 0, ResourceConsumer) {27} - }) - } - -The driver might expect to get the right GPIO when it does: - - desc = gpiod_get(dev, "reset", GPIOD_OUT_LOW); - -but since there is no way to know the mapping between "reset" and -the GpioIo() in _CRS desc will hold ERR_PTR(-ENOENT). - -The driver author can solve this by passing the mapping explictly -(the recommended way and documented in the above chapter). - -The ACPI GPIO mapping tables should not contaminate drivers that are not -knowing about which exact device they are servicing on. It implies that -the ACPI GPIO mapping tables are hardly linked to ACPI ID and certain -objects, as listed in the above chapter, of the device in question. - -Getting GPIO descriptor ------------------------ - -There are two main approaches to get GPIO resource from ACPI: - desc = gpiod_get(dev, connection_id, flags); - desc = gpiod_get_index(dev, connection_id, index, flags); - -We may consider two different cases here, i.e. when connection ID is -provided and otherwise. - -Case 1: - desc = gpiod_get(dev, "non-null-connection-id", flags); - desc = gpiod_get_index(dev, "non-null-connection-id", index, flags); - -Case 2: - desc = gpiod_get(dev, NULL, flags); - desc = gpiod_get_index(dev, NULL, index, flags); - -Case 1 assumes that corresponding ACPI device description must have -defined device properties and will prevent to getting any GPIO resources -otherwise. - -Case 2 explicitly tells GPIO core to look for resources in _CRS. - -Be aware that gpiod_get_index() in cases 1 and 2, assuming that there -are two versions of ACPI device description provided and no mapping is -present in the driver, will return different resources. That's why a -certain driver has to handle them carefully as explained in previous -chapter. diff --git a/Documentation/firmware-guide/acpi/gpio-properties.rst b/Documentation/firmware-guide/acpi/gpio-properties.rst new file mode 100644 index 000000000000..bb6d74f23ee0 --- /dev/null +++ b/Documentation/firmware-guide/acpi/gpio-properties.rst @@ -0,0 +1,233 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================================== +_DSD Device Properties Related to GPIO +====================================== + +With the release of ACPI 5.1, the _DSD configuration object finally +allows names to be given to GPIOs (and other things as well) returned +by _CRS. Previously, we were only able to use an integer index to find +the corresponding GPIO, which is pretty error prone (it depends on +the _CRS output ordering, for example). + +With _DSD we can now query GPIOs using a name instead of an integer +index, like the ASL example below shows:: + + // Bluetooth device with reset and shutdown GPIOs + Device (BTH) + { + Name (_HID, ...) + + Name (_CRS, ResourceTemplate () + { + GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly, + "\\_SB.GPO0", 0, ResourceConsumer) {15} + GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly, + "\\_SB.GPO0", 0, ResourceConsumer) {27, 31} + }) + + Name (_DSD, Package () + { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () + { + Package () {"reset-gpios", Package() {^BTH, 1, 1, 0 }}, + Package () {"shutdown-gpios", Package() {^BTH, 0, 0, 0 }}, + } + }) + } + +The format of the supported GPIO property is:: + + Package () { "name", Package () { ref, index, pin, active_low }} + +ref + The device that has _CRS containing GpioIo()/GpioInt() resources, + typically this is the device itself (BTH in our case). +index + Index of the GpioIo()/GpioInt() resource in _CRS starting from zero. +pin + Pin in the GpioIo()/GpioInt() resource. Typically this is zero. +active_low + If 1 the GPIO is marked as active_low. + +Since ACPI GpioIo() resource does not have a field saying whether it is +active low or high, the "active_low" argument can be used here. Setting +it to 1 marks the GPIO as active low. + +In our Bluetooth example the "reset-gpios" refers to the second GpioIo() +resource, second pin in that resource with the GPIO number of 31. + +It is possible to leave holes in the array of GPIOs. This is useful in +cases like with SPI host controllers where some chip selects may be +implemented as GPIOs and some as native signals. For example a SPI host +controller can have chip selects 0 and 2 implemented as GPIOs and 1 as +native:: + + Package () { + "cs-gpios", + Package () { + ^GPIO, 19, 0, 0, // chip select 0: GPIO + 0, // chip select 1: native signal + ^GPIO, 20, 0, 0, // chip select 2: GPIO + } + } + +Other supported properties +========================== + +Following Device Tree compatible device properties are also supported by +_DSD device properties for GPIO controllers: + +- gpio-hog +- output-high +- output-low +- input +- line-name + +Example:: + + Name (_DSD, Package () { + // _DSD Hierarchical Properties Extension UUID + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), + Package () { + Package () {"hog-gpio8", "G8PU"} + } + }) + + Name (G8PU, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () {"gpio-hog", 1}, + Package () {"gpios", Package () {8, 0}}, + Package () {"output-high", 1}, + Package () {"line-name", "gpio8-pullup"}, + } + }) + +- gpio-line-names + +Example:: + + Package () { + "gpio-line-names", + Package () { + "SPI0_CS_N", "EXP2_INT", "MUX6_IO", "UART0_RXD", "MUX7_IO", + "LVL_C_A1", "MUX0_IO", "SPI1_MISO" + } + } + +See Documentation/devicetree/bindings/gpio/gpio.txt for more information +about these properties. + +ACPI GPIO Mappings Provided by Drivers +====================================== + +There are systems in which the ACPI tables do not contain _DSD but provide _CRS +with GpioIo()/GpioInt() resources and device drivers still need to work with +them. + +In those cases ACPI device identification objects, _HID, _CID, _CLS, _SUB, _HRV, +available to the driver can be used to identify the device and that is supposed +to be sufficient to determine the meaning and purpose of all of the GPIO lines +listed by the GpioIo()/GpioInt() resources returned by _CRS. In other words, +the driver is supposed to know what to use the GpioIo()/GpioInt() resources for +once it has identified the device. Having done that, it can simply assign names +to the GPIO lines it is going to use and provide the GPIO subsystem with a +mapping between those names and the ACPI GPIO resources corresponding to them. + +To do that, the 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, in analogy with the _DSD GPIO property format specified above. + +For the example Bluetooth device discussed previously the data structures in +question would look like this:: + + static const struct acpi_gpio_params reset_gpio = { 1, 1, false }; + static const struct acpi_gpio_params shutdown_gpio = { 0, 0, false }; + + static const struct acpi_gpio_mapping bluetooth_acpi_gpios[] = { + { "reset-gpios", &reset_gpio, 1 }, + { "shutdown-gpios", &shutdown_gpio, 1 }, + { }, + }; + +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. + +Using the _CRS fallback +======================= + +If a device does not have _DSD or the driver does not create ACPI GPIO +mapping, the Linux GPIO framework refuses to return any GPIOs. This is +because the driver does not know what it actually gets. For example if we +have a device like below:: + + Device (BTH) + { + Name (_HID, ...) + + Name (_CRS, ResourceTemplate () { + GpioIo (Exclusive, PullNone, 0, 0, IoRestrictionNone, + "\\_SB.GPO0", 0, ResourceConsumer) {15} + GpioIo (Exclusive, PullNone, 0, 0, IoRestrictionNone, + "\\_SB.GPO0", 0, ResourceConsumer) {27} + }) + } + +The driver might expect to get the right GPIO when it does:: + + desc = gpiod_get(dev, "reset", GPIOD_OUT_LOW); + +but since there is no way to know the mapping between "reset" and +the GpioIo() in _CRS desc will hold ERR_PTR(-ENOENT). + +The driver author can solve this by passing the mapping explictly +(the recommended way and documented in the above chapter). + +The ACPI GPIO mapping tables should not contaminate drivers that are not +knowing about which exact device they are servicing on. It implies that +the ACPI GPIO mapping tables are hardly linked to ACPI ID and certain +objects, as listed in the above chapter, of the device in question. + +Getting GPIO descriptor +======================= + +There are two main approaches to get GPIO resource from ACPI:: + + desc = gpiod_get(dev, connection_id, flags); + desc = gpiod_get_index(dev, connection_id, index, flags); + +We may consider two different cases here, i.e. when connection ID is +provided and otherwise. + +Case 1:: + + desc = gpiod_get(dev, "non-null-connection-id", flags); + desc = gpiod_get_index(dev, "non-null-connection-id", index, flags); + +Case 2:: + + desc = gpiod_get(dev, NULL, flags); + desc = gpiod_get_index(dev, NULL, index, flags); + +Case 1 assumes that corresponding ACPI device description must have +defined device properties and will prevent to getting any GPIO resources +otherwise. + +Case 2 explicitly tells GPIO core to look for resources in _CRS. + +Be aware that gpiod_get_index() in cases 1 and 2, assuming that there +are two versions of ACPI device description provided and no mapping is +present in the driver, will return different resources. That's why a +certain driver has to handle them carefully as explained in previous +chapter. diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst index 0e05b843521c..61d67763851b 100644 --- a/Documentation/firmware-guide/acpi/index.rst +++ b/Documentation/firmware-guide/acpi/index.rst @@ -11,3 +11,4 @@ ACPI Support enumeration osi DSD-properties-rules + gpio-properties diff --git a/MAINTAINERS b/MAINTAINERS index 3e5a5d263f29..89c13e1ed648 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6593,7 +6593,7 @@ M: Andy Shevchenko L: linux-gpio@vger.kernel.org L: linux-acpi@vger.kernel.org S: Maintained -F: Documentation/acpi/gpio-properties.txt +F: Documentation/firmware-guide/acpi/gpio-properties.rst F: drivers/gpio/gpiolib-acpi.c GPIO IR Transmitter -- cgit v1.2.3-59-g8ed1b From eea7803278619d1a3bda6306cd8470497cd2c5e3 Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 01:52:51 +0800 Subject: Documentation: ACPI: move method-customizing.txt to firmware-guide/acpi and convert to reST This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/method-customizing.txt | 73 ------------------ Documentation/firmware-guide/acpi/index.rst | 3 +- .../firmware-guide/acpi/method-customizing.rst | 89 ++++++++++++++++++++++ 3 files changed, 91 insertions(+), 74 deletions(-) delete mode 100644 Documentation/acpi/method-customizing.txt create mode 100644 Documentation/firmware-guide/acpi/method-customizing.rst diff --git a/Documentation/acpi/method-customizing.txt b/Documentation/acpi/method-customizing.txt deleted file mode 100644 index 7235da975f23..000000000000 --- a/Documentation/acpi/method-customizing.txt +++ /dev/null @@ -1,73 +0,0 @@ -Linux ACPI Custom Control Method How To -======================================= - -Written by Zhang Rui - - -Linux supports customizing ACPI control methods at runtime. - -Users can use this to -1. override an existing method which may not work correctly, - or just for debugging purposes. -2. insert a completely new method in order to create a missing - method such as _OFF, _ON, _STA, _INI, etc. -For these cases, it is far simpler to dynamically install a single -control method rather than override the entire DSDT, because kernel -rebuild/reboot is not needed and test result can be got in minutes. - -Note: Only ACPI METHOD can be overridden, any other object types like - "Device", "OperationRegion", are not recognized. Methods - declared inside scope operators are also not supported. -Note: The same ACPI control method can be overridden for many times, - and it's always the latest one that used by Linux/kernel. -Note: To get the ACPI debug object output (Store (AAAA, Debug)), - please run "echo 1 > /sys/module/acpi/parameters/aml_debug_output". - -1. override an existing method - a) get the ACPI table via ACPI sysfs I/F. e.g. to get the DSDT, - just run "cat /sys/firmware/acpi/tables/DSDT > /tmp/dsdt.dat" - b) disassemble the table by running "iasl -d dsdt.dat". - c) rewrite the ASL code of the method and save it in a new file, - d) package the new file (psr.asl) to an ACPI table format. - Here is an example of a customized \_SB._AC._PSR method, - - DefinitionBlock ("", "SSDT", 1, "", "", 0x20080715) - { - Method (\_SB_.AC._PSR, 0, NotSerialized) - { - Store ("In AC _PSR", Debug) - Return (ACON) - } - } - Note that the full pathname of the method in ACPI namespace - should be used. - e) assemble the file to generate the AML code of the method. - e.g. "iasl -vw 6084 psr.asl" (psr.aml is generated as a result) - If parameter "-vw 6084" is not supported by your iASL compiler, - please try a newer version. - f) mount debugfs by "mount -t debugfs none /sys/kernel/debug" - g) override the old method via the debugfs by running - "cat /tmp/psr.aml > /sys/kernel/debug/acpi/custom_method" - -2. insert a new method - This is easier than overriding an existing method. - We just need to create the ASL code of the method we want to - insert and then follow the step c) ~ g) in section 1. - -3. undo your changes - The "undo" operation is not supported for a new inserted method - right now, i.e. we can not remove a method currently. - For an overridden method, in order to undo your changes, please - save a copy of the method original ASL code in step c) section 1, - and redo step c) ~ g) to override the method with the original one. - - -Note: We can use a kernel with multiple custom ACPI method running, - But each individual write to debugfs can implement a SINGLE - method override. i.e. if we want to insert/override multiple - ACPI methods, we need to redo step c) ~ g) for multiple times. - -Note: Be aware that root can mis-use this driver to modify arbitrary - memory and gain additional rights, if root's privileges got - restricted (for example if root is not allowed to load additional - modules after boot). diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst index 61d67763851b..d1d069b26bbc 100644 --- a/Documentation/firmware-guide/acpi/index.rst +++ b/Documentation/firmware-guide/acpi/index.rst @@ -10,5 +10,6 @@ ACPI Support namespace enumeration osi + method-customizing DSD-properties-rules - gpio-properties + gpio-properties \ No newline at end of file diff --git a/Documentation/firmware-guide/acpi/method-customizing.rst b/Documentation/firmware-guide/acpi/method-customizing.rst new file mode 100644 index 000000000000..de3ebcaed4cf --- /dev/null +++ b/Documentation/firmware-guide/acpi/method-customizing.rst @@ -0,0 +1,89 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================================= +Linux ACPI Custom Control Method How To +======================================= + +:Author: Zhang Rui + + +Linux supports customizing ACPI control methods at runtime. + +Users can use this to: + +1. override an existing method which may not work correctly, + or just for debugging purposes. +2. insert a completely new method in order to create a missing + method such as _OFF, _ON, _STA, _INI, etc. + +For these cases, it is far simpler to dynamically install a single +control method rather than override the entire DSDT, because kernel +rebuild/reboot is not needed and test result can be got in minutes. + +.. note:: + + - Only ACPI METHOD can be overridden, any other object types like + "Device", "OperationRegion", are not recognized. Methods + declared inside scope operators are also not supported. + + - The same ACPI control method can be overridden for many times, + and it's always the latest one that used by Linux/kernel. + + - To get the ACPI debug object output (Store (AAAA, Debug)), + please run:: + + echo 1 > /sys/module/acpi/parameters/aml_debug_output + + +1. override an existing method +============================== +a) get the ACPI table via ACPI sysfs I/F. e.g. to get the DSDT, + just run "cat /sys/firmware/acpi/tables/DSDT > /tmp/dsdt.dat" +b) disassemble the table by running "iasl -d dsdt.dat". +c) rewrite the ASL code of the method and save it in a new file, +d) package the new file (psr.asl) to an ACPI table format. + Here is an example of a customized \_SB._AC._PSR method:: + + DefinitionBlock ("", "SSDT", 1, "", "", 0x20080715) + { + Method (\_SB_.AC._PSR, 0, NotSerialized) + { + Store ("In AC _PSR", Debug) + Return (ACON) + } + } + + Note that the full pathname of the method in ACPI namespace + should be used. +e) assemble the file to generate the AML code of the method. + e.g. "iasl -vw 6084 psr.asl" (psr.aml is generated as a result) + If parameter "-vw 6084" is not supported by your iASL compiler, + please try a newer version. +f) mount debugfs by "mount -t debugfs none /sys/kernel/debug" +g) override the old method via the debugfs by running + "cat /tmp/psr.aml > /sys/kernel/debug/acpi/custom_method" + +2. insert a new method +====================== +This is easier than overriding an existing method. +We just need to create the ASL code of the method we want to +insert and then follow the step c) ~ g) in section 1. + +3. undo your changes +==================== +The "undo" operation is not supported for a new inserted method +right now, i.e. we can not remove a method currently. +For an overridden method, in order to undo your changes, please +save a copy of the method original ASL code in step c) section 1, +and redo step c) ~ g) to override the method with the original one. + + +.. note:: We can use a kernel with multiple custom ACPI method running, + But each individual write to debugfs can implement a SINGLE + method override. i.e. if we want to insert/override multiple + ACPI methods, we need to redo step c) ~ g) for multiple times. + +.. note:: Be aware that root can mis-use this driver to modify arbitrary + memory and gain additional rights, if root's privileges got + restricted (for example if root is not allowed to load additional + modules after boot). -- cgit v1.2.3-59-g8ed1b From 59bcdcccf31f5a42cd23ea46154f9b3546d66009 Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 01:52:52 +0800 Subject: Documentation: ACPI: move initrd_table_override.txt to admin-guide/acpi and convert to reST This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/initrd_table_override.txt | 111 -------------------- Documentation/admin-guide/acpi/index.rst | 1 + .../admin-guide/acpi/initrd_table_override.rst | 115 +++++++++++++++++++++ 3 files changed, 116 insertions(+), 111 deletions(-) delete mode 100644 Documentation/acpi/initrd_table_override.txt create mode 100644 Documentation/admin-guide/acpi/initrd_table_override.rst diff --git a/Documentation/acpi/initrd_table_override.txt b/Documentation/acpi/initrd_table_override.txt deleted file mode 100644 index 30437a6db373..000000000000 --- a/Documentation/acpi/initrd_table_override.txt +++ /dev/null @@ -1,111 +0,0 @@ -Upgrading ACPI tables via initrd -================================ - -1) Introduction (What is this about) -2) What is this for -3) How does it work -4) References (Where to retrieve userspace tools) - -1) What is this about ---------------------- - -If the ACPI_TABLE_UPGRADE compile option is true, it is possible to -upgrade the ACPI execution environment that is defined by the ACPI tables -via upgrading the ACPI tables provided by the BIOS with an instrumented, -modified, more recent version one, or installing brand new ACPI tables. - -When building initrd with kernel in a single image, option -ACPI_TABLE_OVERRIDE_VIA_BUILTIN_INITRD should also be true for this -feature to work. - -For a full list of ACPI tables that can be upgraded/installed, take a look -at the char *table_sigs[MAX_ACPI_SIGNATURE]; definition in -drivers/acpi/tables.c. -All ACPI tables iasl (Intel's ACPI compiler and disassembler) knows should -be overridable, except: - - ACPI_SIG_RSDP (has a signature of 6 bytes) - - ACPI_SIG_FACS (does not have an ordinary ACPI table header) -Both could get implemented as well. - - -2) What is this for -------------------- - -Complain to your platform/BIOS vendor if you find a bug which is so severe -that a workaround is not accepted in the Linux kernel. And this facility -allows you to upgrade the buggy tables before your platform/BIOS vendor -releases an upgraded BIOS binary. - -This facility can be used by platform/BIOS vendors to provide a Linux -compatible environment without modifying the underlying platform firmware. - -This facility also provides a powerful feature to easily debug and test -ACPI BIOS table compatibility with the Linux kernel by modifying old -platform provided ACPI tables or inserting new ACPI tables. - -It can and should be enabled in any kernel because there is no functional -change with not instrumented initrds. - - -3) How does it work -------------------- - -# Extract the machine's ACPI tables: -cd /tmp -acpidump >acpidump -acpixtract -a acpidump -# Disassemble, modify and recompile them: -iasl -d *.dat -# For example add this statement into a _PRT (PCI Routing Table) function -# of the DSDT: -Store("HELLO WORLD", debug) -# And increase the OEM Revision. For example, before modification: -DefinitionBlock ("DSDT.aml", "DSDT", 2, "INTEL ", "TEMPLATE", 0x00000000) -# After modification: -DefinitionBlock ("DSDT.aml", "DSDT", 2, "INTEL ", "TEMPLATE", 0x00000001) -iasl -sa dsdt.dsl -# Add the raw ACPI tables to an uncompressed cpio archive. -# They must be put into a /kernel/firmware/acpi directory inside the cpio -# archive. Note that if the table put here matches a platform table -# (similar Table Signature, and similar OEMID, and similar OEM Table ID) -# with a more recent OEM Revision, the platform table will be upgraded by -# this table. If the table put here doesn't match a platform table -# (dissimilar Table Signature, or dissimilar OEMID, or dissimilar OEM Table -# ID), this table will be appended. -mkdir -p kernel/firmware/acpi -cp dsdt.aml kernel/firmware/acpi -# A maximum of "NR_ACPI_INITRD_TABLES (64)" tables are currently allowed -# (see osl.c): -iasl -sa facp.dsl -iasl -sa ssdt1.dsl -cp facp.aml kernel/firmware/acpi -cp ssdt1.aml kernel/firmware/acpi -# The uncompressed cpio archive must be the first. Other, typically -# compressed cpio archives, must be concatenated on top of the uncompressed -# one. Following command creates the uncompressed cpio archive and -# concatenates the original initrd on top: -find kernel | cpio -H newc --create > /boot/instrumented_initrd -cat /boot/initrd >>/boot/instrumented_initrd -# reboot with increased acpi debug level, e.g. boot params: -acpi.debug_level=0x2 acpi.debug_layer=0xFFFFFFFF -# and check your syslog: -[ 1.268089] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] -[ 1.272091] [ACPI Debug] String [0x0B] "HELLO WORLD" - -iasl is able to disassemble and recompile quite a lot different, -also static ACPI tables. - - -4) Where to retrieve userspace tools ------------------------------------- - -iasl and acpixtract are part of Intel's ACPICA project: -http://acpica.org/ -and should be packaged by distributions (for example in the acpica package -on SUSE). - -acpidump can be found in Len Browns pmtools: -ftp://kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools/acpidump -This tool is also part of the acpica package on SUSE. -Alternatively, used ACPI tables can be retrieved via sysfs in latest kernels: -/sys/firmware/acpi/tables diff --git a/Documentation/admin-guide/acpi/index.rst b/Documentation/admin-guide/acpi/index.rst index 3e041206089d..09e4e81e4fb7 100644 --- a/Documentation/admin-guide/acpi/index.rst +++ b/Documentation/admin-guide/acpi/index.rst @@ -8,3 +8,4 @@ the Linux ACPI support. .. toctree:: :maxdepth: 1 + initrd_table_override diff --git a/Documentation/admin-guide/acpi/initrd_table_override.rst b/Documentation/admin-guide/acpi/initrd_table_override.rst new file mode 100644 index 000000000000..cbd768207631 --- /dev/null +++ b/Documentation/admin-guide/acpi/initrd_table_override.rst @@ -0,0 +1,115 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================ +Upgrading ACPI tables via initrd +================================ + +What is this about +================== + +If the ACPI_TABLE_UPGRADE compile option is true, it is possible to +upgrade the ACPI execution environment that is defined by the ACPI tables +via upgrading the ACPI tables provided by the BIOS with an instrumented, +modified, more recent version one, or installing brand new ACPI tables. + +When building initrd with kernel in a single image, option +ACPI_TABLE_OVERRIDE_VIA_BUILTIN_INITRD should also be true for this +feature to work. + +For a full list of ACPI tables that can be upgraded/installed, take a look +at the char `*table_sigs[MAX_ACPI_SIGNATURE];` definition in +drivers/acpi/tables.c. + +All ACPI tables iasl (Intel's ACPI compiler and disassembler) knows should +be overridable, except: + + - ACPI_SIG_RSDP (has a signature of 6 bytes) + - ACPI_SIG_FACS (does not have an ordinary ACPI table header) + +Both could get implemented as well. + + +What is this for +================ + +Complain to your platform/BIOS vendor if you find a bug which is so severe +that a workaround is not accepted in the Linux kernel. And this facility +allows you to upgrade the buggy tables before your platform/BIOS vendor +releases an upgraded BIOS binary. + +This facility can be used by platform/BIOS vendors to provide a Linux +compatible environment without modifying the underlying platform firmware. + +This facility also provides a powerful feature to easily debug and test +ACPI BIOS table compatibility with the Linux kernel by modifying old +platform provided ACPI tables or inserting new ACPI tables. + +It can and should be enabled in any kernel because there is no functional +change with not instrumented initrds. + + +How does it work +================ +:: + + # Extract the machine's ACPI tables: + cd /tmp + acpidump >acpidump + acpixtract -a acpidump + # Disassemble, modify and recompile them: + iasl -d *.dat + # For example add this statement into a _PRT (PCI Routing Table) function + # of the DSDT: + Store("HELLO WORLD", debug) + # And increase the OEM Revision. For example, before modification: + DefinitionBlock ("DSDT.aml", "DSDT", 2, "INTEL ", "TEMPLATE", 0x00000000) + # After modification: + DefinitionBlock ("DSDT.aml", "DSDT", 2, "INTEL ", "TEMPLATE", 0x00000001) + iasl -sa dsdt.dsl + # Add the raw ACPI tables to an uncompressed cpio archive. + # They must be put into a /kernel/firmware/acpi directory inside the cpio + # archive. Note that if the table put here matches a platform table + # (similar Table Signature, and similar OEMID, and similar OEM Table ID) + # with a more recent OEM Revision, the platform table will be upgraded by + # this table. If the table put here doesn't match a platform table + # (dissimilar Table Signature, or dissimilar OEMID, or dissimilar OEM Table + # ID), this table will be appended. + mkdir -p kernel/firmware/acpi + cp dsdt.aml kernel/firmware/acpi + # A maximum of "NR_ACPI_INITRD_TABLES (64)" tables are currently allowed + # (see osl.c): + iasl -sa facp.dsl + iasl -sa ssdt1.dsl + cp facp.aml kernel/firmware/acpi + cp ssdt1.aml kernel/firmware/acpi + # The uncompressed cpio archive must be the first. Other, typically + # compressed cpio archives, must be concatenated on top of the uncompressed + # one. Following command creates the uncompressed cpio archive and + # concatenates the original initrd on top: + find kernel | cpio -H newc --create > /boot/instrumented_initrd + cat /boot/initrd >>/boot/instrumented_initrd + # reboot with increased acpi debug level, e.g. boot params: + acpi.debug_level=0x2 acpi.debug_layer=0xFFFFFFFF + # and check your syslog: + [ 1.268089] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] + [ 1.272091] [ACPI Debug] String [0x0B] "HELLO WORLD" + +iasl is able to disassemble and recompile quite a lot different, +also static ACPI tables. + + +Where to retrieve userspace tools +================================= + +iasl and acpixtract are part of Intel's ACPICA project: +http://acpica.org/ + +and should be packaged by distributions (for example in the acpica package +on SUSE). + +acpidump can be found in Len Browns pmtools: +ftp://kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools/acpidump + +This tool is also part of the acpica package on SUSE. +Alternatively, used ACPI tables can be retrieved via sysfs in latest kernels: +/sys/firmware/acpi/tables -- cgit v1.2.3-59-g8ed1b From 34bf473baef086ec0e277ffb0dbddb697da9f02e Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 01:52:53 +0800 Subject: Documentation: ACPI: move dsdt-override.txt to admin-guide/acpi and convert to reST This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/dsdt-override.txt | 7 ------- Documentation/admin-guide/acpi/dsdt-override.rst | 13 +++++++++++++ Documentation/admin-guide/acpi/index.rst | 1 + 3 files changed, 14 insertions(+), 7 deletions(-) delete mode 100644 Documentation/acpi/dsdt-override.txt create mode 100644 Documentation/admin-guide/acpi/dsdt-override.rst diff --git a/Documentation/acpi/dsdt-override.txt b/Documentation/acpi/dsdt-override.txt deleted file mode 100644 index 784841caa6e6..000000000000 --- a/Documentation/acpi/dsdt-override.txt +++ /dev/null @@ -1,7 +0,0 @@ -Linux supports a method of overriding the BIOS DSDT: - -CONFIG_ACPI_CUSTOM_DSDT builds the image into the kernel. - -When to use this method is described in detail on the -Linux/ACPI home page: -https://01.org/linux-acpi/documentation/overriding-dsdt diff --git a/Documentation/admin-guide/acpi/dsdt-override.rst b/Documentation/admin-guide/acpi/dsdt-override.rst new file mode 100644 index 000000000000..50bd7f194bf4 --- /dev/null +++ b/Documentation/admin-guide/acpi/dsdt-override.rst @@ -0,0 +1,13 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=============== +Overriding DSDT +=============== + +Linux supports a method of overriding the BIOS DSDT: + +CONFIG_ACPI_CUSTOM_DSDT - builds the image into the kernel. + +When to use this method is described in detail on the +Linux/ACPI home page: +https://01.org/linux-acpi/documentation/overriding-dsdt diff --git a/Documentation/admin-guide/acpi/index.rst b/Documentation/admin-guide/acpi/index.rst index 09e4e81e4fb7..d68e9914c5ff 100644 --- a/Documentation/admin-guide/acpi/index.rst +++ b/Documentation/admin-guide/acpi/index.rst @@ -9,3 +9,4 @@ the Linux ACPI support. :maxdepth: 1 initrd_table_override + dsdt-override -- cgit v1.2.3-59-g8ed1b From 572c9fa516f532d6cfd7123d7753fe52730f1c59 Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 01:52:54 +0800 Subject: Documentation: ACPI: move i2c-muxes.txt to firmware-guide/acpi and convert to reST This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/i2c-muxes.txt | 58 ----------------------- Documentation/firmware-guide/acpi/i2c-muxes.rst | 61 +++++++++++++++++++++++++ Documentation/firmware-guide/acpi/index.rst | 3 +- 3 files changed, 63 insertions(+), 59 deletions(-) delete mode 100644 Documentation/acpi/i2c-muxes.txt create mode 100644 Documentation/firmware-guide/acpi/i2c-muxes.rst diff --git a/Documentation/acpi/i2c-muxes.txt b/Documentation/acpi/i2c-muxes.txt deleted file mode 100644 index 9fcc4f0b885e..000000000000 --- a/Documentation/acpi/i2c-muxes.txt +++ /dev/null @@ -1,58 +0,0 @@ -ACPI I2C Muxes --------------- - -Describing an I2C device hierarchy that includes I2C muxes requires an ACPI -Device () scope per mux channel. - -Consider this topology: - -+------+ +------+ -| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50) -| | | 0x70 |--CH01--> i2c client B (0x50) -+------+ +------+ - -which corresponds to the following ASL: - -Device (SMB1) -{ - Name (_HID, ...) - Device (MUX0) - { - Name (_HID, ...) - Name (_CRS, ResourceTemplate () { - I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED, - AddressingMode7Bit, "^SMB1", 0x00, - ResourceConsumer,,) - } - - Device (CH00) - { - Name (_ADR, 0) - - Device (CLIA) - { - Name (_HID, ...) - Name (_CRS, ResourceTemplate () { - I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED, - AddressingMode7Bit, "^CH00", 0x00, - ResourceConsumer,,) - } - } - } - - Device (CH01) - { - Name (_ADR, 1) - - Device (CLIB) - { - Name (_HID, ...) - Name (_CRS, ResourceTemplate () { - I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED, - AddressingMode7Bit, "^CH01", 0x00, - ResourceConsumer,,) - } - } - } - } -} diff --git a/Documentation/firmware-guide/acpi/i2c-muxes.rst b/Documentation/firmware-guide/acpi/i2c-muxes.rst new file mode 100644 index 000000000000..3a8997ccd7c4 --- /dev/null +++ b/Documentation/firmware-guide/acpi/i2c-muxes.rst @@ -0,0 +1,61 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============== +ACPI I2C Muxes +============== + +Describing an I2C device hierarchy that includes I2C muxes requires an ACPI +Device () scope per mux channel. + +Consider this topology:: + + +------+ +------+ + | SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50) + | | | 0x70 |--CH01--> i2c client B (0x50) + +------+ +------+ + +which corresponds to the following ASL:: + + Device (SMB1) + { + Name (_HID, ...) + Device (MUX0) + { + Name (_HID, ...) + Name (_CRS, ResourceTemplate () { + I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED, + AddressingMode7Bit, "^SMB1", 0x00, + ResourceConsumer,,) + } + + Device (CH00) + { + Name (_ADR, 0) + + Device (CLIA) + { + Name (_HID, ...) + Name (_CRS, ResourceTemplate () { + I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED, + AddressingMode7Bit, "^CH00", 0x00, + ResourceConsumer,,) + } + } + } + + Device (CH01) + { + Name (_ADR, 1) + + Device (CLIB) + { + Name (_HID, ...) + Name (_CRS, ResourceTemplate () { + I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED, + AddressingMode7Bit, "^CH01", 0x00, + ResourceConsumer,,) + } + } + } + } + } diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst index d1d069b26bbc..1c89888f6ee8 100644 --- a/Documentation/firmware-guide/acpi/index.rst +++ b/Documentation/firmware-guide/acpi/index.rst @@ -12,4 +12,5 @@ ACPI Support osi method-customizing DSD-properties-rules - gpio-properties \ No newline at end of file + gpio-properties + i2c-muxes -- cgit v1.2.3-59-g8ed1b From 011eed59ba6df428a1380fd1419a2a422f0d807a Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 01:52:55 +0800 Subject: Documentation: ACPI: move acpi-lid.txt to firmware-guide/acpi and convert to reST This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/acpi-lid.txt | 96 --------------------- Documentation/firmware-guide/acpi/acpi-lid.rst | 114 +++++++++++++++++++++++++ Documentation/firmware-guide/acpi/index.rst | 1 + 3 files changed, 115 insertions(+), 96 deletions(-) delete mode 100644 Documentation/acpi/acpi-lid.txt create mode 100644 Documentation/firmware-guide/acpi/acpi-lid.rst diff --git a/Documentation/acpi/acpi-lid.txt b/Documentation/acpi/acpi-lid.txt deleted file mode 100644 index effe7af3a5af..000000000000 --- a/Documentation/acpi/acpi-lid.txt +++ /dev/null @@ -1,96 +0,0 @@ -Special Usage Model of the ACPI Control Method Lid Device - -Copyright (C) 2016, Intel Corporation -Author: Lv Zheng - - -Abstract: - -Platforms containing lids convey lid state (open/close) to OSPMs using a -control method lid device. To implement this, the AML tables issue -Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has -changed. The _LID control method for the lid device must be implemented to -report the "current" state of the lid as either "opened" or "closed". - -For most platforms, both the _LID method and the lid notifications are -reliable. However, there are exceptions. In order to work with these -exceptional buggy platforms, special restrictions and expections should be -taken into account. This document describes the restrictions and the -expections of the Linux ACPI lid device driver. - - -1. Restrictions of the returning value of the _LID control method - -The _LID control method is described to return the "current" lid state. -However the word of "current" has ambiguity, some buggy AML tables return -the lid state upon the last lid notification instead of returning the lid -state upon the last _LID evaluation. There won't be difference when the -_LID control method is evaluated during the runtime, the problem is its -initial returning value. When the AML tables implement this control method -with cached value, the initial returning value is likely not reliable. -There are platforms always retun "closed" as initial lid state. - -2. Restrictions of the lid state change notifications - -There are buggy AML tables never notifying when the lid device state is -changed to "opened". Thus the "opened" notification is not guaranteed. But -it is guaranteed that the AML tables always notify "closed" when the lid -state is changed to "closed". The "closed" notification is normally used to -trigger some system power saving operations on Windows. Since it is fully -tested, it is reliable from all AML tables. - -3. Expections for the userspace users of the ACPI lid device driver - -The ACPI button driver exports the lid state to the userspace via the -following file: - /proc/acpi/button/lid/LID0/state -This file actually calls the _LID control method described above. And given -the previous explanation, it is not reliable enough on some platforms. So -it is advised for the userspace program to not to solely rely on this file -to determine the actual lid state. - -The ACPI button driver emits the following input event to the userspace: - SW_LID -The ACPI lid device driver is implemented to try to deliver the platform -triggered events to the userspace. However, given the fact that the buggy -firmware cannot make sure "opened"/"closed" events are paired, the ACPI -button driver uses the following 3 modes in order not to trigger issues. - -If the userspace hasn't been prepared to ignore the unreliable "opened" -events and the unreliable initial state notification, Linux users can use -the following kernel parameters to handle the possible issues: -A. button.lid_init_state=method: - When this option is specified, the ACPI button driver reports the - initial lid state using the returning value of the _LID control method - and whether the "opened"/"closed" events are paired fully relies on the - firmware implementation. - This option can be used to fix some platforms where the returning value - of the _LID control method is reliable but the initial lid state - notification is missing. - This option is the default behavior during the period the userspace - isn't ready to handle the buggy AML tables. -B. button.lid_init_state=open: - When this option is specified, the ACPI button driver always reports the - initial lid state as "opened" and whether the "opened"/"closed" events - are paired fully relies on the firmware implementation. - This may fix some platforms where the returning value of the _LID - control method is not reliable and the initial lid state notification is - missing. - -If the userspace has been prepared to ignore the unreliable "opened" events -and the unreliable initial state notification, Linux users should always -use the following kernel parameter: -C. button.lid_init_state=ignore: - When this option is specified, the ACPI button driver never reports the - initial lid state and there is a compensation mechanism implemented to - ensure that the reliable "closed" notifications can always be delievered - to the userspace by always pairing "closed" input events with complement - "opened" input events. But there is still no guarantee that the "opened" - notifications can be delivered to the userspace when the lid is actually - opens given that some AML tables do not send "opened" notifications - reliably. - In this mode, if everything is correctly implemented by the platform - firmware, the old userspace programs should still work. Otherwise, the - new userspace programs are required to work with the ACPI button driver. - This option will be the default behavior after the userspace is ready to - handle the buggy AML tables. diff --git a/Documentation/firmware-guide/acpi/acpi-lid.rst b/Documentation/firmware-guide/acpi/acpi-lid.rst new file mode 100644 index 000000000000..874ce0ed340d --- /dev/null +++ b/Documentation/firmware-guide/acpi/acpi-lid.rst @@ -0,0 +1,114 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: + +========================================================= +Special Usage Model of the ACPI Control Method Lid Device +========================================================= + +:Copyright: |copy| 2016, Intel Corporation + +:Author: Lv Zheng + +Abstract +======== +Platforms containing lids convey lid state (open/close) to OSPMs +using a control method lid device. To implement this, the AML tables issue +Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has +changed. The _LID control method for the lid device must be implemented to +report the "current" state of the lid as either "opened" or "closed". + +For most platforms, both the _LID method and the lid notifications are +reliable. However, there are exceptions. In order to work with these +exceptional buggy platforms, special restrictions and expections should be +taken into account. This document describes the restrictions and the +expections of the Linux ACPI lid device driver. + + +Restrictions of the returning value of the _LID control method +============================================================== + +The _LID control method is described to return the "current" lid state. +However the word of "current" has ambiguity, some buggy AML tables return +the lid state upon the last lid notification instead of returning the lid +state upon the last _LID evaluation. There won't be difference when the +_LID control method is evaluated during the runtime, the problem is its +initial returning value. When the AML tables implement this control method +with cached value, the initial returning value is likely not reliable. +There are platforms always retun "closed" as initial lid state. + +Restrictions of the lid state change notifications +================================================== + +There are buggy AML tables never notifying when the lid device state is +changed to "opened". Thus the "opened" notification is not guaranteed. But +it is guaranteed that the AML tables always notify "closed" when the lid +state is changed to "closed". The "closed" notification is normally used to +trigger some system power saving operations on Windows. Since it is fully +tested, it is reliable from all AML tables. + +Expections for the userspace users of the ACPI lid device driver +================================================================ + +The ACPI button driver exports the lid state to the userspace via the +following file:: + + /proc/acpi/button/lid/LID0/state + +This file actually calls the _LID control method described above. And given +the previous explanation, it is not reliable enough on some platforms. So +it is advised for the userspace program to not to solely rely on this file +to determine the actual lid state. + +The ACPI button driver emits the following input event to the userspace: + * SW_LID + +The ACPI lid device driver is implemented to try to deliver the platform +triggered events to the userspace. However, given the fact that the buggy +firmware cannot make sure "opened"/"closed" events are paired, the ACPI +button driver uses the following 3 modes in order not to trigger issues. + +If the userspace hasn't been prepared to ignore the unreliable "opened" +events and the unreliable initial state notification, Linux users can use +the following kernel parameters to handle the possible issues: + +A. button.lid_init_state=method: + When this option is specified, the ACPI button driver reports the + initial lid state using the returning value of the _LID control method + and whether the "opened"/"closed" events are paired fully relies on the + firmware implementation. + + This option can be used to fix some platforms where the returning value + of the _LID control method is reliable but the initial lid state + notification is missing. + + This option is the default behavior during the period the userspace + isn't ready to handle the buggy AML tables. + +B. button.lid_init_state=open: + When this option is specified, the ACPI button driver always reports the + initial lid state as "opened" and whether the "opened"/"closed" events + are paired fully relies on the firmware implementation. + + This may fix some platforms where the returning value of the _LID + control method is not reliable and the initial lid state notification is + missing. + +If the userspace has been prepared to ignore the unreliable "opened" events +and the unreliable initial state notification, Linux users should always +use the following kernel parameter: + +C. button.lid_init_state=ignore: + When this option is specified, the ACPI button driver never reports the + initial lid state and there is a compensation mechanism implemented to + ensure that the reliable "closed" notifications can always be delievered + to the userspace by always pairing "closed" input events with complement + "opened" input events. But there is still no guarantee that the "opened" + notifications can be delivered to the userspace when the lid is actually + opens given that some AML tables do not send "opened" notifications + reliably. + + In this mode, if everything is correctly implemented by the platform + firmware, the old userspace programs should still work. Otherwise, the + new userspace programs are required to work with the ACPI button driver. + This option will be the default behavior after the userspace is ready to + handle the buggy AML tables. diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst index 1c89888f6ee8..bedcb0b242a2 100644 --- a/Documentation/firmware-guide/acpi/index.rst +++ b/Documentation/firmware-guide/acpi/index.rst @@ -14,3 +14,4 @@ ACPI Support DSD-properties-rules gpio-properties i2c-muxes + acpi-lid \ No newline at end of file -- cgit v1.2.3-59-g8ed1b From f2dde1ed0f2818405b371c2b65a98fece221b7a0 Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 01:52:56 +0800 Subject: Documentation: ACPI: move dsd/graph.txt to firmware-guide/acpi and convert to reST This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/dsd/graph.txt | 174 ----------------------- Documentation/firmware-guide/acpi/dsd/graph.rst | 177 ++++++++++++++++++++++++ Documentation/firmware-guide/acpi/index.rst | 1 + 3 files changed, 178 insertions(+), 174 deletions(-) delete mode 100644 Documentation/acpi/dsd/graph.txt create mode 100644 Documentation/firmware-guide/acpi/dsd/graph.rst diff --git a/Documentation/acpi/dsd/graph.txt b/Documentation/acpi/dsd/graph.txt deleted file mode 100644 index b9ce910781dc..000000000000 --- a/Documentation/acpi/dsd/graph.txt +++ /dev/null @@ -1,174 +0,0 @@ -Graphs - - -_DSD ----- - -_DSD (Device Specific Data) [7] is a predefined ACPI device -configuration object that can be used to convey information on -hardware features which are not specifically covered by the ACPI -specification [1][6]. There are two _DSD extensions that are relevant -for graphs: property [4] and hierarchical data extensions [5]. The -property extension provides generic key-value pairs whereas the -hierarchical data extension supports nodes with references to other -nodes, forming a tree. The nodes in the tree may contain properties as -defined by the property extension. The two extensions together provide -a tree-like structure with zero or more properties (key-value pairs) -in each node of the tree. - -The data structure may be accessed at runtime by using the device_* -and fwnode_* functions defined in include/linux/fwnode.h . - -Fwnode represents a generic firmware node object. It is independent on -the firmware type. In ACPI, fwnodes are _DSD hierarchical data -extensions objects. A device's _DSD object is represented by an -fwnode. - -The data structure may be referenced to elsewhere in the ACPI tables -by using a hard reference to the device itself and an index to the -hierarchical data extension array on each depth. - - -Ports and endpoints -------------------- - -The port and endpoint concepts are very similar to those in Devicetree -[3]. A port represents an interface in a device, and an endpoint -represents a connection to that interface. - -All port nodes are located under the device's "_DSD" node in the hierarchical -data extension tree. The data extension related to each port node must begin -with "port" and must be followed by the "@" character and the number of the port -as its key. The target object it refers to should be called "PRTX", where "X" is -the number of the port. An example of such a package would be: - - Package() { "port@4", PRT4 } - -Further on, endpoints are located under the port nodes. The hierarchical -data extension key of the endpoint nodes must begin with -"endpoint" and must be followed by the "@" character and the number of the -endpoint. The object it refers to should be called "EPXY", where "X" is the -number of the port and "Y" is the number of the endpoint. An example of such a -package would be: - - Package() { "endpoint@0", EP40 } - -Each port node contains a property extension key "port", the value of which is -the number of the port. Each endpoint is similarly numbered with a property -extension key "reg", the value of which is the number of the endpoint. Port -numbers must be unique within a device and endpoint numbers must be unique -within a port. If a device object may only has a single port, then the number -of that port shall be zero. Similarly, if a port may only have a single -endpoint, the number of that endpoint shall be zero. - -The endpoint reference uses property extension with "remote-endpoint" property -name followed by a reference in the same package. Such references consist of the -the remote device reference, the first package entry of the port data extension -reference under the device and finally the first package entry of the endpoint -data extension reference under the port. Individual references thus appear as: - - Package() { device, "port@X", "endpoint@Y" } - -In the above example, "X" is the number of the port and "Y" is the number of the -endpoint. - -The references to endpoints must be always done both ways, to the -remote endpoint and back from the referred remote endpoint node. - -A simple example of this is show below: - - Scope (\_SB.PCI0.I2C2) - { - Device (CAM0) - { - Name (_DSD, Package () { - ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), - Package () { - Package () { "compatible", Package () { "nokia,smia" } }, - }, - ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), - Package () { - Package () { "port@0", PRT0 }, - } - }) - Name (PRT0, Package() { - ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), - Package () { - Package () { "reg", 0 }, - }, - ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), - Package () { - Package () { "endpoint@0", EP00 }, - } - }) - Name (EP00, Package() { - ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), - Package () { - Package () { "reg", 0 }, - Package () { "remote-endpoint", Package() { \_SB.PCI0.ISP, "port@4", "endpoint@0" } }, - } - }) - } - } - - Scope (\_SB.PCI0) - { - Device (ISP) - { - Name (_DSD, Package () { - ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), - Package () { - Package () { "port@4", PRT4 }, - } - }) - - Name (PRT4, Package() { - ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), - Package () { - Package () { "reg", 4 }, /* CSI-2 port number */ - }, - ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), - Package () { - Package () { "endpoint@0", EP40 }, - } - }) - - Name (EP40, Package() { - ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), - Package () { - Package () { "reg", 0 }, - Package () { "remote-endpoint", Package () { \_SB.PCI0.I2C2.CAM0, "port@0", "endpoint@0" } }, - } - }) - } - } - -Here, the port 0 of the "CAM0" device is connected to the port 4 of -the "ISP" device and vice versa. - - -References ----------- - -[1] _DSD (Device Specific Data) Implementation Guide. - , - referenced 2016-10-03. - -[2] Devicetree. , referenced 2016-10-03. - -[3] Documentation/devicetree/bindings/graph.txt - -[4] Device Properties UUID For _DSD. - , - referenced 2016-10-04. - -[5] Hierarchical Data Extension UUID For _DSD. - , - referenced 2016-10-04. - -[6] Advanced Configuration and Power Interface Specification. - , - referenced 2016-10-04. - -[7] _DSD Device Properties Usage Rules. - Documentation/acpi/DSD-properties-rules.txt diff --git a/Documentation/firmware-guide/acpi/dsd/graph.rst b/Documentation/firmware-guide/acpi/dsd/graph.rst new file mode 100644 index 000000000000..e0baed35b037 --- /dev/null +++ b/Documentation/firmware-guide/acpi/dsd/graph.rst @@ -0,0 +1,177 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====== +Graphs +====== + +_DSD +==== + +_DSD (Device Specific Data) [7] is a predefined ACPI device +configuration object that can be used to convey information on +hardware features which are not specifically covered by the ACPI +specification [1][6]. There are two _DSD extensions that are relevant +for graphs: property [4] and hierarchical data extensions [5]. The +property extension provides generic key-value pairs whereas the +hierarchical data extension supports nodes with references to other +nodes, forming a tree. The nodes in the tree may contain properties as +defined by the property extension. The two extensions together provide +a tree-like structure with zero or more properties (key-value pairs) +in each node of the tree. + +The data structure may be accessed at runtime by using the device_* +and fwnode_* functions defined in include/linux/fwnode.h . + +Fwnode represents a generic firmware node object. It is independent on +the firmware type. In ACPI, fwnodes are _DSD hierarchical data +extensions objects. A device's _DSD object is represented by an +fwnode. + +The data structure may be referenced to elsewhere in the ACPI tables +by using a hard reference to the device itself and an index to the +hierarchical data extension array on each depth. + + +Ports and endpoints +=================== + +The port and endpoint concepts are very similar to those in Devicetree +[3]. A port represents an interface in a device, and an endpoint +represents a connection to that interface. + +All port nodes are located under the device's "_DSD" node in the hierarchical +data extension tree. The data extension related to each port node must begin +with "port" and must be followed by the "@" character and the number of the +port as its key. The target object it refers to should be called "PRTX", where +"X" is the number of the port. An example of such a package would be:: + + Package() { "port@4", PRT4 } + +Further on, endpoints are located under the port nodes. The hierarchical +data extension key of the endpoint nodes must begin with +"endpoint" and must be followed by the "@" character and the number of the +endpoint. The object it refers to should be called "EPXY", where "X" is the +number of the port and "Y" is the number of the endpoint. An example of such a +package would be:: + + Package() { "endpoint@0", EP40 } + +Each port node contains a property extension key "port", the value of which is +the number of the port. Each endpoint is similarly numbered with a property +extension key "reg", the value of which is the number of the endpoint. Port +numbers must be unique within a device and endpoint numbers must be unique +within a port. If a device object may only has a single port, then the number +of that port shall be zero. Similarly, if a port may only have a single +endpoint, the number of that endpoint shall be zero. + +The endpoint reference uses property extension with "remote-endpoint" property +name followed by a reference in the same package. Such references consist of +the remote device reference, the first package entry of the port data extension +reference under the device and finally the first package entry of the endpoint +data extension reference under the port. Individual references thus appear as:: + + Package() { device, "port@X", "endpoint@Y" } + +In the above example, "X" is the number of the port and "Y" is the number of +the endpoint. + +The references to endpoints must be always done both ways, to the +remote endpoint and back from the referred remote endpoint node. + +A simple example of this is show below:: + + Scope (\_SB.PCI0.I2C2) + { + Device (CAM0) + { + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "compatible", Package () { "nokia,smia" } }, + }, + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), + Package () { + Package () { "port@0", PRT0 }, + } + }) + Name (PRT0, Package() { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "reg", 0 }, + }, + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), + Package () { + Package () { "endpoint@0", EP00 }, + } + }) + Name (EP00, Package() { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "reg", 0 }, + Package () { "remote-endpoint", Package() { \_SB.PCI0.ISP, "port@4", "endpoint@0" } }, + } + }) + } + } + + Scope (\_SB.PCI0) + { + Device (ISP) + { + Name (_DSD, Package () { + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), + Package () { + Package () { "port@4", PRT4 }, + } + }) + + Name (PRT4, Package() { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "reg", 4 }, /* CSI-2 port number */ + }, + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), + Package () { + Package () { "endpoint@0", EP40 }, + } + }) + + Name (EP40, Package() { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "reg", 0 }, + Package () { "remote-endpoint", Package () { \_SB.PCI0.I2C2.CAM0, "port@0", "endpoint@0" } }, + } + }) + } + } + +Here, the port 0 of the "CAM0" device is connected to the port 4 of +the "ISP" device and vice versa. + + +References +========== + +[1] _DSD (Device Specific Data) Implementation Guide. + http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel-1_1.htm, + referenced 2016-10-03. + +[2] Devicetree. http://www.devicetree.org, referenced 2016-10-03. + +[3] Documentation/devicetree/bindings/graph.txt + +[4] Device Properties UUID For _DSD. + http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf, + referenced 2016-10-04. + +[5] Hierarchical Data Extension UUID For _DSD. + http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf, + referenced 2016-10-04. + +[6] Advanced Configuration and Power Interface Specification. + http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf, + referenced 2016-10-04. + +[7] _DSD Device Properties Usage Rules. + :doc:`../DSD-properties-rules` diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst index bedcb0b242a2..f81cfbcb6878 100644 --- a/Documentation/firmware-guide/acpi/index.rst +++ b/Documentation/firmware-guide/acpi/index.rst @@ -8,6 +8,7 @@ ACPI Support :maxdepth: 1 namespace + dsd/graph enumeration osi method-customizing -- cgit v1.2.3-59-g8ed1b From 05000042f33dd8b2afbeedc1d8fd499486d14b0d Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 01:52:57 +0800 Subject: Documentation: ACPI: move dsd/data-node-references.txt to firmware-guide/acpi and convert to reST This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/dsd/data-node-references.txt | 89 --------------------- .../acpi/dsd/data-node-references.rst | 93 ++++++++++++++++++++++ Documentation/firmware-guide/acpi/index.rst | 1 + 3 files changed, 94 insertions(+), 89 deletions(-) delete mode 100644 Documentation/acpi/dsd/data-node-references.txt create mode 100644 Documentation/firmware-guide/acpi/dsd/data-node-references.rst diff --git a/Documentation/acpi/dsd/data-node-references.txt b/Documentation/acpi/dsd/data-node-references.txt deleted file mode 100644 index c3871565c8cf..000000000000 --- a/Documentation/acpi/dsd/data-node-references.txt +++ /dev/null @@ -1,89 +0,0 @@ -Copyright (C) 2018 Intel Corporation -Author: Sakari Ailus - - -Referencing hierarchical data nodes ------------------------------------ - -ACPI in general allows referring to device objects in the tree only. -Hierarchical data extension nodes may not be referred to directly, hence this -document defines a scheme to implement such references. - -A reference consist of the device object name followed by one or more -hierarchical data extension [1] keys. Specifically, the hierarchical data -extension node which is referred to by the key shall lie directly under the -parent object i.e. either the device object or another hierarchical data -extension node. - -The keys in the hierarchical data nodes shall consist of the name of the node, -"@" character and the number of the node in hexadecimal notation (without pre- -or postfixes). The same ACPI object shall include the _DSD property extension -with a property "reg" that shall have the same numerical value as the number of -the node. - -In case a hierarchical data extensions node has no numerical value, then the -"reg" property shall be omitted from the ACPI object's _DSD properties and the -"@" character and the number shall be omitted from the hierarchical data -extension key. - - -Example -------- - - In the ASL snippet below, the "reference" _DSD property [2] contains a - device object reference to DEV0 and under that device object, a - hierarchical data extension key "node@1" referring to the NOD1 object - and lastly, a hierarchical data extension key "anothernode" referring to - the ANOD object which is also the final target node of the reference. - - Device (DEV0) - { - Name (_DSD, Package () { - ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), - Package () { - Package () { "node@0", NOD0 }, - Package () { "node@1", NOD1 }, - } - }) - Name (NOD0, Package() { - ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), - Package () { - Package () { "random-property", 3 }, - } - }) - Name (NOD1, Package() { - ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), - Package () { - Package () { "anothernode", ANOD }, - } - }) - Name (ANOD, Package() { - ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), - Package () { - Package () { "random-property", 0 }, - } - }) - } - - Device (DEV1) - { - Name (_DSD, Package () { - ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), - Package () { - Package () { "reference", ^DEV0, "node@1", "anothernode" }, - } - }) - } - -Please also see a graph example in graph.txt . - -References ----------- - -[1] Hierarchical Data Extension UUID For _DSD. - , - referenced 2018-07-17. - -[2] Device Properties UUID For _DSD. - , - referenced 2016-10-04. diff --git a/Documentation/firmware-guide/acpi/dsd/data-node-references.rst b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst new file mode 100644 index 000000000000..1351984e767c --- /dev/null +++ b/Documentation/firmware-guide/acpi/dsd/data-node-references.rst @@ -0,0 +1,93 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: + +=================================== +Referencing hierarchical data nodes +=================================== + +:Copyright: |copy| 2018 Intel Corporation +:Author: Sakari Ailus + +ACPI in general allows referring to device objects in the tree only. +Hierarchical data extension nodes may not be referred to directly, hence this +document defines a scheme to implement such references. + +A reference consist of the device object name followed by one or more +hierarchical data extension [1] keys. Specifically, the hierarchical data +extension node which is referred to by the key shall lie directly under the +parent object i.e. either the device object or another hierarchical data +extension node. + +The keys in the hierarchical data nodes shall consist of the name of the node, +"@" character and the number of the node in hexadecimal notation (without pre- +or postfixes). The same ACPI object shall include the _DSD property extension +with a property "reg" that shall have the same numerical value as the number of +the node. + +In case a hierarchical data extensions node has no numerical value, then the +"reg" property shall be omitted from the ACPI object's _DSD properties and the +"@" character and the number shall be omitted from the hierarchical data +extension key. + + +Example +======= + +In the ASL snippet below, the "reference" _DSD property [2] contains a +device object reference to DEV0 and under that device object, a +hierarchical data extension key "node@1" referring to the NOD1 object +and lastly, a hierarchical data extension key "anothernode" referring to +the ANOD object which is also the final target node of the reference. +:: + + Device (DEV0) + { + Name (_DSD, Package () { + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), + Package () { + Package () { "node@0", NOD0 }, + Package () { "node@1", NOD1 }, + } + }) + Name (NOD0, Package() { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "random-property", 3 }, + } + }) + Name (NOD1, Package() { + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), + Package () { + Package () { "anothernode", ANOD }, + } + }) + Name (ANOD, Package() { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "random-property", 0 }, + } + }) + } + + Device (DEV1) + { + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () { "reference", ^DEV0, "node@1", "anothernode" }, + } + }) + } + +Please also see a graph example in :doc:`graph`. + +References +========== + +[1] Hierarchical Data Extension UUID For _DSD. +, +referenced 2018-07-17. + +[2] Device Properties UUID For _DSD. +, +referenced 2016-10-04. diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst index f81cfbcb6878..6d4e0df4f063 100644 --- a/Documentation/firmware-guide/acpi/index.rst +++ b/Documentation/firmware-guide/acpi/index.rst @@ -9,6 +9,7 @@ ACPI Support namespace dsd/graph + dsd/data-node-references enumeration osi method-customizing -- cgit v1.2.3-59-g8ed1b From 99ed6bfaa5a0a4bffc10ff3ffe9c599bcf59236e Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 01:52:58 +0800 Subject: Documentation: ACPI: move debug.txt to firmware-guide/acpi and convert to reST This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/debug.txt | 148 --------------------------- Documentation/firmware-guide/acpi/debug.rst | 151 ++++++++++++++++++++++++++++ Documentation/firmware-guide/acpi/index.rst | 3 +- 3 files changed, 153 insertions(+), 149 deletions(-) delete mode 100644 Documentation/acpi/debug.txt create mode 100644 Documentation/firmware-guide/acpi/debug.rst diff --git a/Documentation/acpi/debug.txt b/Documentation/acpi/debug.txt deleted file mode 100644 index 65bf47c46b6d..000000000000 --- a/Documentation/acpi/debug.txt +++ /dev/null @@ -1,148 +0,0 @@ - ACPI Debug Output - - -The ACPI CA, the Linux ACPI core, and some ACPI drivers can generate debug -output. This document describes how to use this facility. - -Compile-time configuration --------------------------- - -ACPI debug output is globally enabled by CONFIG_ACPI_DEBUG. If this config -option is turned off, the debug messages are not even built into the -kernel. - -Boot- and run-time configuration --------------------------------- - -When CONFIG_ACPI_DEBUG=y, you can select the component and level of messages -you're interested in. At boot-time, use the acpi.debug_layer and -acpi.debug_level kernel command line options. After boot, you can use the -debug_layer and debug_level files in /sys/module/acpi/parameters/ to control -the debug messages. - -debug_layer (component) ------------------------ - -The "debug_layer" is a mask that selects components of interest, e.g., a -specific driver or part of the ACPI interpreter. To build the debug_layer -bitmask, look for the "#define _COMPONENT" in an ACPI source file. - -You can set the debug_layer mask at boot-time using the acpi.debug_layer -command line argument, and you can change it after boot by writing values -to /sys/module/acpi/parameters/debug_layer. - -The possible components are defined in include/acpi/acoutput.h and -include/acpi/acpi_drivers.h. Reading /sys/module/acpi/parameters/debug_layer -shows the supported mask values, currently these: - - ACPI_UTILITIES 0x00000001 - ACPI_HARDWARE 0x00000002 - ACPI_EVENTS 0x00000004 - ACPI_TABLES 0x00000008 - ACPI_NAMESPACE 0x00000010 - ACPI_PARSER 0x00000020 - ACPI_DISPATCHER 0x00000040 - ACPI_EXECUTER 0x00000080 - ACPI_RESOURCES 0x00000100 - ACPI_CA_DEBUGGER 0x00000200 - ACPI_OS_SERVICES 0x00000400 - ACPI_CA_DISASSEMBLER 0x00000800 - ACPI_COMPILER 0x00001000 - ACPI_TOOLS 0x00002000 - ACPI_BUS_COMPONENT 0x00010000 - ACPI_AC_COMPONENT 0x00020000 - ACPI_BATTERY_COMPONENT 0x00040000 - ACPI_BUTTON_COMPONENT 0x00080000 - ACPI_SBS_COMPONENT 0x00100000 - ACPI_FAN_COMPONENT 0x00200000 - ACPI_PCI_COMPONENT 0x00400000 - ACPI_POWER_COMPONENT 0x00800000 - ACPI_CONTAINER_COMPONENT 0x01000000 - ACPI_SYSTEM_COMPONENT 0x02000000 - ACPI_THERMAL_COMPONENT 0x04000000 - ACPI_MEMORY_DEVICE_COMPONENT 0x08000000 - ACPI_VIDEO_COMPONENT 0x10000000 - ACPI_PROCESSOR_COMPONENT 0x20000000 - -debug_level ------------ - -The "debug_level" is a mask that selects different types of messages, e.g., -those related to initialization, method execution, informational messages, etc. -To build debug_level, look at the level specified in an ACPI_DEBUG_PRINT() -statement. - -The ACPI interpreter uses several different levels, but the Linux -ACPI core and ACPI drivers generally only use ACPI_LV_INFO. - -You can set the debug_level mask at boot-time using the acpi.debug_level -command line argument, and you can change it after boot by writing values -to /sys/module/acpi/parameters/debug_level. - -The possible levels are defined in include/acpi/acoutput.h. Reading -/sys/module/acpi/parameters/debug_level shows the supported mask values, -currently these: - - ACPI_LV_INIT 0x00000001 - ACPI_LV_DEBUG_OBJECT 0x00000002 - ACPI_LV_INFO 0x00000004 - ACPI_LV_INIT_NAMES 0x00000020 - ACPI_LV_PARSE 0x00000040 - ACPI_LV_LOAD 0x00000080 - ACPI_LV_DISPATCH 0x00000100 - ACPI_LV_EXEC 0x00000200 - ACPI_LV_NAMES 0x00000400 - ACPI_LV_OPREGION 0x00000800 - ACPI_LV_BFIELD 0x00001000 - ACPI_LV_TABLES 0x00002000 - ACPI_LV_VALUES 0x00004000 - ACPI_LV_OBJECTS 0x00008000 - ACPI_LV_RESOURCES 0x00010000 - ACPI_LV_USER_REQUESTS 0x00020000 - ACPI_LV_PACKAGE 0x00040000 - ACPI_LV_ALLOCATIONS 0x00100000 - ACPI_LV_FUNCTIONS 0x00200000 - ACPI_LV_OPTIMIZATIONS 0x00400000 - ACPI_LV_MUTEX 0x01000000 - ACPI_LV_THREADS 0x02000000 - ACPI_LV_IO 0x04000000 - ACPI_LV_INTERRUPTS 0x08000000 - ACPI_LV_AML_DISASSEMBLE 0x10000000 - ACPI_LV_VERBOSE_INFO 0x20000000 - ACPI_LV_FULL_TABLES 0x40000000 - ACPI_LV_EVENTS 0x80000000 - -Examples --------- - -For example, drivers/acpi/bus.c contains this: - - #define _COMPONENT ACPI_BUS_COMPONENT - ... - ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Device insertion detected\n")); - -To turn on this message, set the ACPI_BUS_COMPONENT bit in acpi.debug_layer -and the ACPI_LV_INFO bit in acpi.debug_level. (The ACPI_DEBUG_PRINT -statement uses ACPI_DB_INFO, which is macro based on the ACPI_LV_INFO -definition.) - -Enable all AML "Debug" output (stores to the Debug object while interpreting -AML) during boot: - - acpi.debug_layer=0xffffffff acpi.debug_level=0x2 - -Enable PCI and PCI interrupt routing debug messages: - - acpi.debug_layer=0x400000 acpi.debug_level=0x4 - -Enable all ACPI hardware-related messages: - - acpi.debug_layer=0x2 acpi.debug_level=0xffffffff - -Enable all ACPI_DB_INFO messages after boot: - - # echo 0x4 > /sys/module/acpi/parameters/debug_level - -Show all valid component values: - - # cat /sys/module/acpi/parameters/debug_layer diff --git a/Documentation/firmware-guide/acpi/debug.rst b/Documentation/firmware-guide/acpi/debug.rst new file mode 100644 index 000000000000..1a152dd1d765 --- /dev/null +++ b/Documentation/firmware-guide/acpi/debug.rst @@ -0,0 +1,151 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================= +ACPI Debug Output +================= + +The ACPI CA, the Linux ACPI core, and some ACPI drivers can generate debug +output. This document describes how to use this facility. + +Compile-time configuration +========================== + +ACPI debug output is globally enabled by CONFIG_ACPI_DEBUG. If this config +option is turned off, the debug messages are not even built into the +kernel. + +Boot- and run-time configuration +================================ + +When CONFIG_ACPI_DEBUG=y, you can select the component and level of messages +you're interested in. At boot-time, use the acpi.debug_layer and +acpi.debug_level kernel command line options. After boot, you can use the +debug_layer and debug_level files in /sys/module/acpi/parameters/ to control +the debug messages. + +debug_layer (component) +======================= + +The "debug_layer" is a mask that selects components of interest, e.g., a +specific driver or part of the ACPI interpreter. To build the debug_layer +bitmask, look for the "#define _COMPONENT" in an ACPI source file. + +You can set the debug_layer mask at boot-time using the acpi.debug_layer +command line argument, and you can change it after boot by writing values +to /sys/module/acpi/parameters/debug_layer. + +The possible components are defined in include/acpi/acoutput.h and +include/acpi/acpi_drivers.h. Reading /sys/module/acpi/parameters/debug_layer +shows the supported mask values, currently these:: + + ACPI_UTILITIES 0x00000001 + ACPI_HARDWARE 0x00000002 + ACPI_EVENTS 0x00000004 + ACPI_TABLES 0x00000008 + ACPI_NAMESPACE 0x00000010 + ACPI_PARSER 0x00000020 + ACPI_DISPATCHER 0x00000040 + ACPI_EXECUTER 0x00000080 + ACPI_RESOURCES 0x00000100 + ACPI_CA_DEBUGGER 0x00000200 + ACPI_OS_SERVICES 0x00000400 + ACPI_CA_DISASSEMBLER 0x00000800 + ACPI_COMPILER 0x00001000 + ACPI_TOOLS 0x00002000 + ACPI_BUS_COMPONENT 0x00010000 + ACPI_AC_COMPONENT 0x00020000 + ACPI_BATTERY_COMPONENT 0x00040000 + ACPI_BUTTON_COMPONENT 0x00080000 + ACPI_SBS_COMPONENT 0x00100000 + ACPI_FAN_COMPONENT 0x00200000 + ACPI_PCI_COMPONENT 0x00400000 + ACPI_POWER_COMPONENT 0x00800000 + ACPI_CONTAINER_COMPONENT 0x01000000 + ACPI_SYSTEM_COMPONENT 0x02000000 + ACPI_THERMAL_COMPONENT 0x04000000 + ACPI_MEMORY_DEVICE_COMPONENT 0x08000000 + ACPI_VIDEO_COMPONENT 0x10000000 + ACPI_PROCESSOR_COMPONENT 0x20000000 + +debug_level +=========== + +The "debug_level" is a mask that selects different types of messages, e.g., +those related to initialization, method execution, informational messages, etc. +To build debug_level, look at the level specified in an ACPI_DEBUG_PRINT() +statement. + +The ACPI interpreter uses several different levels, but the Linux +ACPI core and ACPI drivers generally only use ACPI_LV_INFO. + +You can set the debug_level mask at boot-time using the acpi.debug_level +command line argument, and you can change it after boot by writing values +to /sys/module/acpi/parameters/debug_level. + +The possible levels are defined in include/acpi/acoutput.h. Reading +/sys/module/acpi/parameters/debug_level shows the supported mask values, +currently these:: + + ACPI_LV_INIT 0x00000001 + ACPI_LV_DEBUG_OBJECT 0x00000002 + ACPI_LV_INFO 0x00000004 + ACPI_LV_INIT_NAMES 0x00000020 + ACPI_LV_PARSE 0x00000040 + ACPI_LV_LOAD 0x00000080 + ACPI_LV_DISPATCH 0x00000100 + ACPI_LV_EXEC 0x00000200 + ACPI_LV_NAMES 0x00000400 + ACPI_LV_OPREGION 0x00000800 + ACPI_LV_BFIELD 0x00001000 + ACPI_LV_TABLES 0x00002000 + ACPI_LV_VALUES 0x00004000 + ACPI_LV_OBJECTS 0x00008000 + ACPI_LV_RESOURCES 0x00010000 + ACPI_LV_USER_REQUESTS 0x00020000 + ACPI_LV_PACKAGE 0x00040000 + ACPI_LV_ALLOCATIONS 0x00100000 + ACPI_LV_FUNCTIONS 0x00200000 + ACPI_LV_OPTIMIZATIONS 0x00400000 + ACPI_LV_MUTEX 0x01000000 + ACPI_LV_THREADS 0x02000000 + ACPI_LV_IO 0x04000000 + ACPI_LV_INTERRUPTS 0x08000000 + ACPI_LV_AML_DISASSEMBLE 0x10000000 + ACPI_LV_VERBOSE_INFO 0x20000000 + ACPI_LV_FULL_TABLES 0x40000000 + ACPI_LV_EVENTS 0x80000000 + +Examples +======== + +For example, drivers/acpi/bus.c contains this:: + + #define _COMPONENT ACPI_BUS_COMPONENT + ... + ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Device insertion detected\n")); + +To turn on this message, set the ACPI_BUS_COMPONENT bit in acpi.debug_layer +and the ACPI_LV_INFO bit in acpi.debug_level. (The ACPI_DEBUG_PRINT +statement uses ACPI_DB_INFO, which is macro based on the ACPI_LV_INFO +definition.) + +Enable all AML "Debug" output (stores to the Debug object while interpreting +AML) during boot:: + + acpi.debug_layer=0xffffffff acpi.debug_level=0x2 + +Enable PCI and PCI interrupt routing debug messages:: + + acpi.debug_layer=0x400000 acpi.debug_level=0x4 + +Enable all ACPI hardware-related messages:: + + acpi.debug_layer=0x2 acpi.debug_level=0xffffffff + +Enable all ACPI_DB_INFO messages after boot:: + + # echo 0x4 > /sys/module/acpi/parameters/debug_level + +Show all valid component values:: + + # cat /sys/module/acpi/parameters/debug_layer diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst index 6d4e0df4f063..a45fea11f998 100644 --- a/Documentation/firmware-guide/acpi/index.rst +++ b/Documentation/firmware-guide/acpi/index.rst @@ -14,6 +14,7 @@ ACPI Support osi method-customizing DSD-properties-rules + debug gpio-properties i2c-muxes - acpi-lid \ No newline at end of file + acpi-lid -- cgit v1.2.3-59-g8ed1b From 3c03a1bde4dcedef8fb287e348de959d81d04ca6 Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 01:52:59 +0800 Subject: Documentation: ACPI: move method-tracing.txt to firmware-guide/acpi and convert to rsST This converts the plain text documentation to reStructuredText format and add it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/method-tracing.txt | 192 ----------------- Documentation/firmware-guide/acpi/index.rst | 1 + .../firmware-guide/acpi/method-tracing.rst | 238 +++++++++++++++++++++ 3 files changed, 239 insertions(+), 192 deletions(-) delete mode 100644 Documentation/acpi/method-tracing.txt create mode 100644 Documentation/firmware-guide/acpi/method-tracing.rst diff --git a/Documentation/acpi/method-tracing.txt b/Documentation/acpi/method-tracing.txt deleted file mode 100644 index 0aba14c8f459..000000000000 --- a/Documentation/acpi/method-tracing.txt +++ /dev/null @@ -1,192 +0,0 @@ -ACPICA Trace Facility - -Copyright (C) 2015, Intel Corporation -Author: Lv Zheng - - -Abstract: - -This document describes the functions and the interfaces of the method -tracing facility. - -1. Functionalities and usage examples: - - ACPICA provides method tracing capability. And two functions are - currently implemented using this capability. - - A. Log reducer - ACPICA subsystem provides debugging outputs when CONFIG_ACPI_DEBUG is - enabled. The debugging messages which are deployed via - ACPI_DEBUG_PRINT() macro can be reduced at 2 levels - per-component - level (known as debug layer, configured via - /sys/module/acpi/parameters/debug_layer) and per-type level (known as - debug level, configured via /sys/module/acpi/parameters/debug_level). - - But when the particular layer/level is applied to the control method - evaluations, the quantity of the debugging outputs may still be too - large to be put into the kernel log buffer. The idea thus is worked out - to only enable the particular debug layer/level (normally more detailed) - logs when the control method evaluation is started, and disable the - detailed logging when the control method evaluation is stopped. - - The following command examples illustrate the usage of the "log reducer" - functionality: - a. Filter out the debug layer/level matched logs when control methods - are being evaluated: - # cd /sys/module/acpi/parameters - # echo "0xXXXXXXXX" > trace_debug_layer - # echo "0xYYYYYYYY" > trace_debug_level - # echo "enable" > trace_state - b. Filter out the debug layer/level matched logs when the specified - control method is being evaluated: - # cd /sys/module/acpi/parameters - # echo "0xXXXXXXXX" > trace_debug_layer - # echo "0xYYYYYYYY" > trace_debug_level - # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name - # echo "method" > /sys/module/acpi/parameters/trace_state - c. Filter out the debug layer/level matched logs when the specified - control method is being evaluated for the first time: - # cd /sys/module/acpi/parameters - # echo "0xXXXXXXXX" > trace_debug_layer - # echo "0xYYYYYYYY" > trace_debug_level - # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name - # echo "method-once" > /sys/module/acpi/parameters/trace_state - Where: - 0xXXXXXXXX/0xYYYYYYYY: Refer to Documentation/acpi/debug.txt for - possible debug layer/level masking values. - \PPPP.AAAA.TTTT.HHHH: Full path of a control method that can be found - in the ACPI namespace. It needn't be an entry - of a control method evaluation. - - B. AML tracer - - There are special log entries added by the method tracing facility at - the "trace points" the AML interpreter starts/stops to execute a control - method, or an AML opcode. Note that the format of the log entries are - subject to change: - [ 0.186427] exdebug-0398 ex_trace_point : Method Begin [0xf58394d8:\_SB.PCI0.LPCB.ECOK] execution. - [ 0.186630] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905c88:If] execution. - [ 0.186820] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905cc0:LEqual] execution. - [ 0.187010] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905a20:-NamePath-] execution. - [ 0.187214] exdebug-0398 ex_trace_point : Opcode End [0xf5905a20:-NamePath-] execution. - [ 0.187407] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905f60:One] execution. - [ 0.187594] exdebug-0398 ex_trace_point : Opcode End [0xf5905f60:One] execution. - [ 0.187789] exdebug-0398 ex_trace_point : Opcode End [0xf5905cc0:LEqual] execution. - [ 0.187980] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905cc0:Return] execution. - [ 0.188146] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905f60:One] execution. - [ 0.188334] exdebug-0398 ex_trace_point : Opcode End [0xf5905f60:One] execution. - [ 0.188524] exdebug-0398 ex_trace_point : Opcode End [0xf5905cc0:Return] execution. - [ 0.188712] exdebug-0398 ex_trace_point : Opcode End [0xf5905c88:If] execution. - [ 0.188903] exdebug-0398 ex_trace_point : Method End [0xf58394d8:\_SB.PCI0.LPCB.ECOK] execution. - - Developers can utilize these special log entries to track the AML - interpretion, thus can aid issue debugging and performance tuning. Note - that, as the "AML tracer" logs are implemented via ACPI_DEBUG_PRINT() - macro, CONFIG_ACPI_DEBUG is also required to be enabled for enabling - "AML tracer" logs. - - The following command examples illustrate the usage of the "AML tracer" - functionality: - a. Filter out the method start/stop "AML tracer" logs when control - methods are being evaluated: - # cd /sys/module/acpi/parameters - # echo "0x80" > trace_debug_layer - # echo "0x10" > trace_debug_level - # echo "enable" > trace_state - b. Filter out the method start/stop "AML tracer" when the specified - control method is being evaluated: - # cd /sys/module/acpi/parameters - # echo "0x80" > trace_debug_layer - # echo "0x10" > trace_debug_level - # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name - # echo "method" > trace_state - c. Filter out the method start/stop "AML tracer" logs when the specified - control method is being evaluated for the first time: - # cd /sys/module/acpi/parameters - # echo "0x80" > trace_debug_layer - # echo "0x10" > trace_debug_level - # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name - # echo "method-once" > trace_state - d. Filter out the method/opcode start/stop "AML tracer" when the - specified control method is being evaluated: - # cd /sys/module/acpi/parameters - # echo "0x80" > trace_debug_layer - # echo "0x10" > trace_debug_level - # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name - # echo "opcode" > trace_state - e. Filter out the method/opcode start/stop "AML tracer" when the - specified control method is being evaluated for the first time: - # cd /sys/module/acpi/parameters - # echo "0x80" > trace_debug_layer - # echo "0x10" > trace_debug_level - # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name - # echo "opcode-opcode" > trace_state - - Note that all above method tracing facility related module parameters can - be used as the boot parameters, for example: - acpi.trace_debug_layer=0x80 acpi.trace_debug_level=0x10 \ - acpi.trace_method_name=\_SB.LID0._LID acpi.trace_state=opcode-once - -2. Interface descriptions: - - All method tracing functions can be configured via ACPI module - parameters that are accessible at /sys/module/acpi/parameters/: - - trace_method_name - The full path of the AML method that the user wants to trace. - Note that the full path shouldn't contain the trailing "_"s in its - name segments but may contain "\" to form an absolute path. - - trace_debug_layer - The temporary debug_layer used when the tracing feature is enabled. - Using ACPI_EXECUTER (0x80) by default, which is the debug_layer - used to match all "AML tracer" logs. - - trace_debug_level - The temporary debug_level used when the tracing feature is enabled. - Using ACPI_LV_TRACE_POINT (0x10) by default, which is the - debug_level used to match all "AML tracer" logs. - - trace_state - The status of the tracing feature. - Users can enable/disable this debug tracing feature by executing - the following command: - # echo string > /sys/module/acpi/parameters/trace_state - Where "string" should be one of the following: - "disable" - Disable the method tracing feature. - "enable" - Enable the method tracing feature. - ACPICA debugging messages matching - "trace_debug_layer/trace_debug_level" during any method - execution will be logged. - "method" - Enable the method tracing feature. - ACPICA debugging messages matching - "trace_debug_layer/trace_debug_level" during method execution - of "trace_method_name" will be logged. - "method-once" - Enable the method tracing feature. - ACPICA debugging messages matching - "trace_debug_layer/trace_debug_level" during method execution - of "trace_method_name" will be logged only once. - "opcode" - Enable the method tracing feature. - ACPICA debugging messages matching - "trace_debug_layer/trace_debug_level" during method/opcode - execution of "trace_method_name" will be logged. - "opcode-once" - Enable the method tracing feature. - ACPICA debugging messages matching - "trace_debug_layer/trace_debug_level" during method/opcode - execution of "trace_method_name" will be logged only once. - Note that, the difference between the "enable" and other feature - enabling options are: - 1. When "enable" is specified, since - "trace_debug_layer/trace_debug_level" shall apply to all control - method evaluations, after configuring "trace_state" to "enable", - "trace_method_name" will be reset to NULL. - 2. When "method/opcode" is specified, if - "trace_method_name" is NULL when "trace_state" is configured to - these options, the "trace_debug_layer/trace_debug_level" will - apply to all control method evaluations. diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst index a45fea11f998..287a7cbd82ac 100644 --- a/Documentation/firmware-guide/acpi/index.rst +++ b/Documentation/firmware-guide/acpi/index.rst @@ -13,6 +13,7 @@ ACPI Support enumeration osi method-customizing + method-tracing DSD-properties-rules debug gpio-properties diff --git a/Documentation/firmware-guide/acpi/method-tracing.rst b/Documentation/firmware-guide/acpi/method-tracing.rst new file mode 100644 index 000000000000..d0b077b73f5f --- /dev/null +++ b/Documentation/firmware-guide/acpi/method-tracing.rst @@ -0,0 +1,238 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: + +===================== +ACPICA Trace Facility +===================== + +:Copyright: |copy| 2015, Intel Corporation +:Author: Lv Zheng + + +Abstract +======== +This document describes the functions and the interfaces of the +method tracing facility. + +Functionalities and usage examples +================================== + +ACPICA provides method tracing capability. And two functions are +currently implemented using this capability. + +Log reducer +----------- + +ACPICA subsystem provides debugging outputs when CONFIG_ACPI_DEBUG is +enabled. The debugging messages which are deployed via +ACPI_DEBUG_PRINT() macro can be reduced at 2 levels - per-component +level (known as debug layer, configured via +/sys/module/acpi/parameters/debug_layer) and per-type level (known as +debug level, configured via /sys/module/acpi/parameters/debug_level). + +But when the particular layer/level is applied to the control method +evaluations, the quantity of the debugging outputs may still be too +large to be put into the kernel log buffer. The idea thus is worked out +to only enable the particular debug layer/level (normally more detailed) +logs when the control method evaluation is started, and disable the +detailed logging when the control method evaluation is stopped. + +The following command examples illustrate the usage of the "log reducer" +functionality: + +a. Filter out the debug layer/level matched logs when control methods + are being evaluated:: + + # cd /sys/module/acpi/parameters + # echo "0xXXXXXXXX" > trace_debug_layer + # echo "0xYYYYYYYY" > trace_debug_level + # echo "enable" > trace_state + +b. Filter out the debug layer/level matched logs when the specified + control method is being evaluated:: + + # cd /sys/module/acpi/parameters + # echo "0xXXXXXXXX" > trace_debug_layer + # echo "0xYYYYYYYY" > trace_debug_level + # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name + # echo "method" > /sys/module/acpi/parameters/trace_state + +c. Filter out the debug layer/level matched logs when the specified + control method is being evaluated for the first time:: + + # cd /sys/module/acpi/parameters + # echo "0xXXXXXXXX" > trace_debug_layer + # echo "0xYYYYYYYY" > trace_debug_level + # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name + # echo "method-once" > /sys/module/acpi/parameters/trace_state + +Where: + 0xXXXXXXXX/0xYYYYYYYY + Refer to Documentation/acpi/debug.txt for possible debug layer/level + masking values. + \PPPP.AAAA.TTTT.HHHH + Full path of a control method that can be found in the ACPI namespace. + It needn't be an entry of a control method evaluation. + +AML tracer +---------- + +There are special log entries added by the method tracing facility at +the "trace points" the AML interpreter starts/stops to execute a control +method, or an AML opcode. Note that the format of the log entries are +subject to change:: + + [ 0.186427] exdebug-0398 ex_trace_point : Method Begin [0xf58394d8:\_SB.PCI0.LPCB.ECOK] execution. + [ 0.186630] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905c88:If] execution. + [ 0.186820] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905cc0:LEqual] execution. + [ 0.187010] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905a20:-NamePath-] execution. + [ 0.187214] exdebug-0398 ex_trace_point : Opcode End [0xf5905a20:-NamePath-] execution. + [ 0.187407] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905f60:One] execution. + [ 0.187594] exdebug-0398 ex_trace_point : Opcode End [0xf5905f60:One] execution. + [ 0.187789] exdebug-0398 ex_trace_point : Opcode End [0xf5905cc0:LEqual] execution. + [ 0.187980] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905cc0:Return] execution. + [ 0.188146] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905f60:One] execution. + [ 0.188334] exdebug-0398 ex_trace_point : Opcode End [0xf5905f60:One] execution. + [ 0.188524] exdebug-0398 ex_trace_point : Opcode End [0xf5905cc0:Return] execution. + [ 0.188712] exdebug-0398 ex_trace_point : Opcode End [0xf5905c88:If] execution. + [ 0.188903] exdebug-0398 ex_trace_point : Method End [0xf58394d8:\_SB.PCI0.LPCB.ECOK] execution. + +Developers can utilize these special log entries to track the AML +interpretion, thus can aid issue debugging and performance tuning. Note +that, as the "AML tracer" logs are implemented via ACPI_DEBUG_PRINT() +macro, CONFIG_ACPI_DEBUG is also required to be enabled for enabling +"AML tracer" logs. + +The following command examples illustrate the usage of the "AML tracer" +functionality: + +a. Filter out the method start/stop "AML tracer" logs when control + methods are being evaluated:: + + # cd /sys/module/acpi/parameters + # echo "0x80" > trace_debug_layer + # echo "0x10" > trace_debug_level + # echo "enable" > trace_state + +b. Filter out the method start/stop "AML tracer" when the specified + control method is being evaluated:: + + # cd /sys/module/acpi/parameters + # echo "0x80" > trace_debug_layer + # echo "0x10" > trace_debug_level + # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name + # echo "method" > trace_state + +c. Filter out the method start/stop "AML tracer" logs when the specified + control method is being evaluated for the first time:: + + # cd /sys/module/acpi/parameters + # echo "0x80" > trace_debug_layer + # echo "0x10" > trace_debug_level + # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name + # echo "method-once" > trace_state + +d. Filter out the method/opcode start/stop "AML tracer" when the + specified control method is being evaluated:: + + # cd /sys/module/acpi/parameters + # echo "0x80" > trace_debug_layer + # echo "0x10" > trace_debug_level + # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name + # echo "opcode" > trace_state + +e. Filter out the method/opcode start/stop "AML tracer" when the + specified control method is being evaluated for the first time:: + + # cd /sys/module/acpi/parameters + # echo "0x80" > trace_debug_layer + # echo "0x10" > trace_debug_level + # echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name + # echo "opcode-opcode" > trace_state + +Note that all above method tracing facility related module parameters can +be used as the boot parameters, for example:: + + acpi.trace_debug_layer=0x80 acpi.trace_debug_level=0x10 \ + acpi.trace_method_name=\_SB.LID0._LID acpi.trace_state=opcode-once + + +Interface descriptions +====================== + +All method tracing functions can be configured via ACPI module +parameters that are accessible at /sys/module/acpi/parameters/: + +trace_method_name + The full path of the AML method that the user wants to trace. + + Note that the full path shouldn't contain the trailing "_"s in its + name segments but may contain "\" to form an absolute path. + +trace_debug_layer + The temporary debug_layer used when the tracing feature is enabled. + + Using ACPI_EXECUTER (0x80) by default, which is the debug_layer + used to match all "AML tracer" logs. + +trace_debug_level + The temporary debug_level used when the tracing feature is enabled. + + Using ACPI_LV_TRACE_POINT (0x10) by default, which is the + debug_level used to match all "AML tracer" logs. + +trace_state + The status of the tracing feature. + + Users can enable/disable this debug tracing feature by executing + the following command:: + + # echo string > /sys/module/acpi/parameters/trace_state + +Where "string" should be one of the following: + +"disable" + Disable the method tracing feature. + +"enable" + Enable the method tracing feature. + + ACPICA debugging messages matching "trace_debug_layer/trace_debug_level" + during any method execution will be logged. + +"method" + Enable the method tracing feature. + + ACPICA debugging messages matching "trace_debug_layer/trace_debug_level" + during method execution of "trace_method_name" will be logged. + +"method-once" + Enable the method tracing feature. + + ACPICA debugging messages matching "trace_debug_layer/trace_debug_level" + during method execution of "trace_method_name" will be logged only once. + +"opcode" + Enable the method tracing feature. + + ACPICA debugging messages matching "trace_debug_layer/trace_debug_level" + during method/opcode execution of "trace_method_name" will be logged. + +"opcode-once" + Enable the method tracing feature. + + ACPICA debugging messages matching "trace_debug_layer/trace_debug_level" + during method/opcode execution of "trace_method_name" will be logged only + once. + +Note that, the difference between the "enable" and other feature +enabling options are: + +1. When "enable" is specified, since + "trace_debug_layer/trace_debug_level" shall apply to all control + method evaluations, after configuring "trace_state" to "enable", + "trace_method_name" will be reset to NULL. +2. When "method/opcode" is specified, if + "trace_method_name" is NULL when "trace_state" is configured to + these options, the "trace_debug_layer/trace_debug_level" will + apply to all control method evaluations. -- cgit v1.2.3-59-g8ed1b From 472e89b4e1a87cd7f9b5ae99759a635711cf00fb Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 01:53:00 +0800 Subject: Documentation: ACPI: move aml-debugger.txt to firmware-guide/acpi and convert to reST This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/aml-debugger.txt | 66 ------------------- Documentation/firmware-guide/acpi/aml-debugger.rst | 75 ++++++++++++++++++++++ Documentation/firmware-guide/acpi/index.rst | 1 + 3 files changed, 76 insertions(+), 66 deletions(-) delete mode 100644 Documentation/acpi/aml-debugger.txt create mode 100644 Documentation/firmware-guide/acpi/aml-debugger.rst diff --git a/Documentation/acpi/aml-debugger.txt b/Documentation/acpi/aml-debugger.txt deleted file mode 100644 index 75ebeb64ab29..000000000000 --- a/Documentation/acpi/aml-debugger.txt +++ /dev/null @@ -1,66 +0,0 @@ -The AML Debugger - -Copyright (C) 2016, Intel Corporation -Author: Lv Zheng - - -This document describes the usage of the AML debugger embedded in the Linux -kernel. - -1. Build the debugger - - The following kernel configuration items are required to enable the AML - debugger interface from the Linux kernel: - - CONFIG_ACPI_DEBUGGER=y - CONFIG_ACPI_DEBUGGER_USER=m - - The userspace utilities can be built from the kernel source tree using - the following commands: - - $ cd tools - $ make acpi - - The resultant userspace tool binary is then located at: - - tools/power/acpi/acpidbg - - It can be installed to system directories by running "make install" (as a - sufficiently privileged user). - -2. Start the userspace debugger interface - - After booting the kernel with the debugger built-in, the debugger can be - started by using the following commands: - - # mount -t debugfs none /sys/kernel/debug - # modprobe acpi_dbg - # tools/power/acpi/acpidbg - - That spawns the interactive AML debugger environment where you can execute - debugger commands. - - The commands are documented in the "ACPICA Overview and Programmer Reference" - that can be downloaded from - - https://acpica.org/documentation - - The detailed debugger commands reference is located in Chapter 12 "ACPICA - Debugger Reference". The "help" command can be used for a quick reference. - -3. Stop the userspace debugger interface - - The interactive debugger interface can be closed by pressing Ctrl+C or using - the "quit" or "exit" commands. When finished, unload the module with: - - # rmmod acpi_dbg - - The module unloading may fail if there is an acpidbg instance running. - -4. Run the debugger in a script - - It may be useful to run the AML debugger in a test script. "acpidbg" supports - this in a special "batch" mode. For example, the following command outputs - the entire ACPI namespace: - - # acpidbg -b "namespace" diff --git a/Documentation/firmware-guide/acpi/aml-debugger.rst b/Documentation/firmware-guide/acpi/aml-debugger.rst new file mode 100644 index 000000000000..a889d43bc6c5 --- /dev/null +++ b/Documentation/firmware-guide/acpi/aml-debugger.rst @@ -0,0 +1,75 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: + +================ +The AML Debugger +================ + +:Copyright: |copy| 2016, Intel Corporation +:Author: Lv Zheng + + +This document describes the usage of the AML debugger embedded in the Linux +kernel. + +1. Build the debugger +===================== + +The following kernel configuration items are required to enable the AML +debugger interface from the Linux kernel:: + + CONFIG_ACPI_DEBUGGER=y + CONFIG_ACPI_DEBUGGER_USER=m + +The userspace utilities can be built from the kernel source tree using +the following commands:: + + $ cd tools + $ make acpi + +The resultant userspace tool binary is then located at:: + + tools/power/acpi/acpidbg + +It can be installed to system directories by running "make install" (as a +sufficiently privileged user). + +2. Start the userspace debugger interface +========================================= + +After booting the kernel with the debugger built-in, the debugger can be +started by using the following commands:: + + # mount -t debugfs none /sys/kernel/debug + # modprobe acpi_dbg + # tools/power/acpi/acpidbg + +That spawns the interactive AML debugger environment where you can execute +debugger commands. + +The commands are documented in the "ACPICA Overview and Programmer Reference" +that can be downloaded from + +https://acpica.org/documentation + +The detailed debugger commands reference is located in Chapter 12 "ACPICA +Debugger Reference". The "help" command can be used for a quick reference. + +3. Stop the userspace debugger interface +======================================== + +The interactive debugger interface can be closed by pressing Ctrl+C or using +the "quit" or "exit" commands. When finished, unload the module with:: + + # rmmod acpi_dbg + +The module unloading may fail if there is an acpidbg instance running. + +4. Run the debugger in a script +=============================== + +It may be useful to run the AML debugger in a test script. "acpidbg" supports +this in a special "batch" mode. For example, the following command outputs +the entire ACPI namespace:: + + # acpidbg -b "namespace" diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst index 287a7cbd82ac..e9f253d54897 100644 --- a/Documentation/firmware-guide/acpi/index.rst +++ b/Documentation/firmware-guide/acpi/index.rst @@ -16,6 +16,7 @@ ACPI Support method-tracing DSD-properties-rules debug + aml-debugger gpio-properties i2c-muxes acpi-lid -- cgit v1.2.3-59-g8ed1b From deb95169ef4279362f4c6167c4c59c8d68711d97 Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 01:53:01 +0800 Subject: Documentation: ACPI: move apei/output_format.txt to firmware-guide/acpi and convert to reST This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/apei/output_format.txt | 147 -------------------- .../firmware-guide/acpi/apei/output_format.rst | 150 +++++++++++++++++++++ Documentation/firmware-guide/acpi/index.rst | 1 + 3 files changed, 151 insertions(+), 147 deletions(-) delete mode 100644 Documentation/acpi/apei/output_format.txt create mode 100644 Documentation/firmware-guide/acpi/apei/output_format.rst diff --git a/Documentation/acpi/apei/output_format.txt b/Documentation/acpi/apei/output_format.txt deleted file mode 100644 index 0c49c197c47a..000000000000 --- a/Documentation/acpi/apei/output_format.txt +++ /dev/null @@ -1,147 +0,0 @@ - APEI output format - ~~~~~~~~~~~~~~~~~~ - -APEI uses printk as hardware error reporting interface, the output -format is as follow. - - := -APEI generic hardware error status -severity: , -section: , severity: , -flags: -
-fru_id: -fru_text: -section_type:
-
- -* := recoverable | fatal | corrected | info - -
# := -[primary][, containment warning][, reset][, threshold exceeded]\ -[, resource not accessible][, latent error] - -
:= generic processor error | memory error | \ -PCIe error | unknown, - -
:= - | | \ - | - - := -[processor_type: , ] -[processor_isa: , ] -[error_type: -] -[operation: , ] -[flags: -] -[level: ] -[version_info: ] -[processor_id: ] -[target_address: ] -[requestor_id: ] -[responder_id: ] -[IP: ] - -* := IA32/X64 | IA64 - -* := IA32 | IA64 | X64 - -# := -[cache error][, TLB error][, bus error][, micro-architectural error] - -* := unknown or generic | data read | data write | \ -instruction execution - -# := -[restartable][, precise IP][, overflow][, corrected] - - := -[error_status: ] -[physical_address: ] -[physical_address_mask: ] -[node: ] -[card: ] -[module: ] -[bank: ] -[device: ] -[row: ] -[column: ] -[bit_position: ] -[requestor_id: ] -[responder_id: ] -[target_id: ] -[error_type: , ] - -* := -unknown | no error | single-bit ECC | multi-bit ECC | \ -single-symbol chipkill ECC | multi-symbol chipkill ECC | master abort | \ -target abort | parity error | watchdog timeout | invalid address | \ -mirror Broken | memory sparing | scrub corrected error | \ -scrub uncorrected error - - := -[port_type: , ] -[version: .] -[command: , status: ] -[device_id: ::. -slot: -secondary_bus: -vendor_id: , device_id: -class_code: ] -[serial number: , ] -[bridge: secondary_status: , control: ] -[aer_status: , aer_mask: - -[aer_uncor_severity: ] -aer_layer=, aer_agent= -aer_tlp_header: ] - -* := PCIe end point | legacy PCI end point | \ -unknown | unknown | root port | upstream switch port | \ -downstream switch port | PCIe to PCI/PCI-X bridge | \ -PCI/PCI-X to PCIe bridge | root complex integrated endpoint device | \ -root complex event collector - -if section severity is fatal or recoverable -# := -unknown | unknown | unknown | unknown | Data Link Protocol | \ -unknown | unknown | unknown | unknown | unknown | unknown | unknown | \ -Poisoned TLP | Flow Control Protocol | Completion Timeout | \ -Completer Abort | Unexpected Completion | Receiver Overflow | \ -Malformed TLP | ECRC | Unsupported Request -else -# := -Receiver Error | unknown | unknown | unknown | unknown | unknown | \ -Bad TLP | Bad DLLP | RELAY_NUM Rollover | unknown | unknown | unknown | \ -Replay Timer Timeout | Advisory Non-Fatal -fi - - := -Physical Layer | Data Link Layer | Transaction Layer - - := -Receiver ID | Requester ID | Completer ID | Transmitter ID - -Where, [] designate corresponding content is optional - -All description with * has the following format: - -field: , - -Where value of should be the position of "string" in description. Otherwise, will be "unknown". - -All description with # has the following format: - -field: - - -Where each string in corresponding to one set bit of -. The bit position is the position of "string" in description. - -For more detailed explanation of every field, please refer to UEFI -specification version 2.3 or later, section Appendix N: Common -Platform Error Record. diff --git a/Documentation/firmware-guide/acpi/apei/output_format.rst b/Documentation/firmware-guide/acpi/apei/output_format.rst new file mode 100644 index 000000000000..c2e7ebddb529 --- /dev/null +++ b/Documentation/firmware-guide/acpi/apei/output_format.rst @@ -0,0 +1,150 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================== +APEI output format +================== + +APEI uses printk as hardware error reporting interface, the output +format is as follow:: + + := + APEI generic hardware error status + severity: , + section: , severity: , + flags: +
+ fru_id: + fru_text: + section_type:
+
+ + * := recoverable | fatal | corrected | info + +
# := + [primary][, containment warning][, reset][, threshold exceeded]\ + [, resource not accessible][, latent error] + +
:= generic processor error | memory error | \ + PCIe error | unknown, + +
:= + | | \ + | + + := + [processor_type: , ] + [processor_isa: , ] + [error_type: + ] + [operation: , ] + [flags: + ] + [level: ] + [version_info: ] + [processor_id: ] + [target_address: ] + [requestor_id: ] + [responder_id: ] + [IP: ] + + * := IA32/X64 | IA64 + + * := IA32 | IA64 | X64 + + # := + [cache error][, TLB error][, bus error][, micro-architectural error] + + * := unknown or generic | data read | data write | \ + instruction execution + + # := + [restartable][, precise IP][, overflow][, corrected] + + := + [error_status: ] + [physical_address: ] + [physical_address_mask: ] + [node: ] + [card: ] + [module: ] + [bank: ] + [device: ] + [row: ] + [column: ] + [bit_position: ] + [requestor_id: ] + [responder_id: ] + [target_id: ] + [error_type: , ] + + * := + unknown | no error | single-bit ECC | multi-bit ECC | \ + single-symbol chipkill ECC | multi-symbol chipkill ECC | master abort | \ + target abort | parity error | watchdog timeout | invalid address | \ + mirror Broken | memory sparing | scrub corrected error | \ + scrub uncorrected error + + := + [port_type: , ] + [version: .] + [command: , status: ] + [device_id: ::. + slot: + secondary_bus: + vendor_id: , device_id: + class_code: ] + [serial number: , ] + [bridge: secondary_status: , control: ] + [aer_status: , aer_mask: + + [aer_uncor_severity: ] + aer_layer=, aer_agent= + aer_tlp_header: ] + + * := PCIe end point | legacy PCI end point | \ + unknown | unknown | root port | upstream switch port | \ + downstream switch port | PCIe to PCI/PCI-X bridge | \ + PCI/PCI-X to PCIe bridge | root complex integrated endpoint device | \ + root complex event collector + + if section severity is fatal or recoverable + # := + unknown | unknown | unknown | unknown | Data Link Protocol | \ + unknown | unknown | unknown | unknown | unknown | unknown | unknown | \ + Poisoned TLP | Flow Control Protocol | Completion Timeout | \ + Completer Abort | Unexpected Completion | Receiver Overflow | \ + Malformed TLP | ECRC | Unsupported Request + else + # := + Receiver Error | unknown | unknown | unknown | unknown | unknown | \ + Bad TLP | Bad DLLP | RELAY_NUM Rollover | unknown | unknown | unknown | \ + Replay Timer Timeout | Advisory Non-Fatal + fi + + := + Physical Layer | Data Link Layer | Transaction Layer + + := + Receiver ID | Requester ID | Completer ID | Transmitter ID + +Where, [] designate corresponding content is optional + +All description with * has the following format:: + + field: , + +Where value of should be the position of "string" in description. Otherwise, will be "unknown". + +All description with # has the following format:: + + field: + + +Where each string in corresponding to one set bit of +. The bit position is the position of "string" in description. + +For more detailed explanation of every field, please refer to UEFI +specification version 2.3 or later, section Appendix N: Common +Platform Error Record. diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst index e9f253d54897..869badba6d7a 100644 --- a/Documentation/firmware-guide/acpi/index.rst +++ b/Documentation/firmware-guide/acpi/index.rst @@ -17,6 +17,7 @@ ACPI Support DSD-properties-rules debug aml-debugger + apei/output_format gpio-properties i2c-muxes acpi-lid -- cgit v1.2.3-59-g8ed1b From 440ebec745dcbc44866f6b19e5145a12d4494a5f Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 01:53:02 +0800 Subject: Documentation: ACPI: move apei/einj.txt to firmware-guide/acpi and convert to reST This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/apei/einj.txt | 177 ----------------------- Documentation/firmware-guide/acpi/apei/einj.rst | 185 ++++++++++++++++++++++++ Documentation/firmware-guide/acpi/index.rst | 1 + 3 files changed, 186 insertions(+), 177 deletions(-) delete mode 100644 Documentation/acpi/apei/einj.txt create mode 100644 Documentation/firmware-guide/acpi/apei/einj.rst diff --git a/Documentation/acpi/apei/einj.txt b/Documentation/acpi/apei/einj.txt deleted file mode 100644 index e550c8b98139..000000000000 --- a/Documentation/acpi/apei/einj.txt +++ /dev/null @@ -1,177 +0,0 @@ - APEI Error INJection - ~~~~~~~~~~~~~~~~~~~~ - -EINJ provides a hardware error injection mechanism. It is very useful -for debugging and testing APEI and RAS features in general. - -You need to check whether your BIOS supports EINJ first. For that, look -for early boot messages similar to this one: - -ACPI: EINJ 0x000000007370A000 000150 (v01 INTEL 00000001 INTL 00000001) - -which shows that the BIOS is exposing an EINJ table - it is the -mechanism through which the injection is done. - -Alternatively, look in /sys/firmware/acpi/tables for an "EINJ" file, -which is a different representation of the same thing. - -It doesn't necessarily mean that EINJ is not supported if those above -don't exist: before you give up, go into BIOS setup to see if the BIOS -has an option to enable error injection. Look for something called WHEA -or similar. Often, you need to enable an ACPI5 support option prior, in -order to see the APEI,EINJ,... functionality supported and exposed by -the BIOS menu. - -To use EINJ, make sure the following are options enabled in your kernel -configuration: - -CONFIG_DEBUG_FS -CONFIG_ACPI_APEI -CONFIG_ACPI_APEI_EINJ - -The EINJ user interface is in /apei/einj. - -The following files belong to it: - -- available_error_type - - This file shows which error types are supported: - - Error Type Value Error Description - ================ ================= - 0x00000001 Processor Correctable - 0x00000002 Processor Uncorrectable non-fatal - 0x00000004 Processor Uncorrectable fatal - 0x00000008 Memory Correctable - 0x00000010 Memory Uncorrectable non-fatal - 0x00000020 Memory Uncorrectable fatal - 0x00000040 PCI Express Correctable - 0x00000080 PCI Express Uncorrectable fatal - 0x00000100 PCI Express Uncorrectable non-fatal - 0x00000200 Platform Correctable - 0x00000400 Platform Uncorrectable non-fatal - 0x00000800 Platform Uncorrectable fatal - - The format of the file contents are as above, except present are only - the available error types. - -- error_type - - Set the value of the error type being injected. Possible error types - are defined in the file available_error_type above. - -- error_inject - - Write any integer to this file to trigger the error injection. Make - sure you have specified all necessary error parameters, i.e. this - write should be the last step when injecting errors. - -- flags - - Present for kernel versions 3.13 and above. Used to specify which - of param{1..4} are valid and should be used by the firmware during - injection. Value is a bitmask as specified in ACPI5.0 spec for the - SET_ERROR_TYPE_WITH_ADDRESS data structure: - - Bit 0 - Processor APIC field valid (see param3 below). - Bit 1 - Memory address and mask valid (param1 and param2). - Bit 2 - PCIe (seg,bus,dev,fn) valid (see param4 below). - - If set to zero, legacy behavior is mimicked where the type of - injection specifies just one bit set, and param1 is multiplexed. - -- param1 - - This file is used to set the first error parameter value. Its effect - depends on the error type specified in error_type. For example, if - error type is memory related type, the param1 should be a valid - physical memory address. [Unless "flag" is set - see above] - -- param2 - - Same use as param1 above. For example, if error type is of memory - related type, then param2 should be a physical memory address mask. - Linux requires page or narrower granularity, say, 0xfffffffffffff000. - -- param3 - - Used when the 0x1 bit is set in "flags" to specify the APIC id - -- param4 - Used when the 0x4 bit is set in "flags" to specify target PCIe device - -- notrigger - - The error injection mechanism is a two-step process. First inject the - error, then perform some actions to trigger it. Setting "notrigger" - to 1 skips the trigger phase, which *may* allow the user to cause the - error in some other context by a simple access to the CPU, memory - location, or device that is the target of the error injection. Whether - this actually works depends on what operations the BIOS actually - includes in the trigger phase. - -BIOS versions based on the ACPI 4.0 specification have limited options -in controlling where the errors are injected. Your BIOS may support an -extension (enabled with the param_extension=1 module parameter, or boot -command line einj.param_extension=1). This allows the address and mask -for memory injections to be specified by the param1 and param2 files in -apei/einj. - -BIOS versions based on the ACPI 5.0 specification have more control over -the target of the injection. For processor-related errors (type 0x1, 0x2 -and 0x4), you can set flags to 0x3 (param3 for bit 0, and param1 and -param2 for bit 1) so that you have more information added to the error -signature being injected. The actual data passed is this: - - memory_address = param1; - memory_address_range = param2; - apicid = param3; - pcie_sbdf = param4; - -For memory errors (type 0x8, 0x10 and 0x20) the address is set using -param1 with a mask in param2 (0x0 is equivalent to all ones). For PCI -express errors (type 0x40, 0x80 and 0x100) the segment, bus, device and -function are specified using param1: - - 31 24 23 16 15 11 10 8 7 0 - +-------------------------------------------------+ - | segment | bus | device | function | reserved | - +-------------------------------------------------+ - -Anyway, you get the idea, if there's doubt just take a look at the code -in drivers/acpi/apei/einj.c. - -An ACPI 5.0 BIOS may also allow vendor-specific errors to be injected. -In this case a file named vendor will contain identifying information -from the BIOS that hopefully will allow an application wishing to use -the vendor-specific extension to tell that they are running on a BIOS -that supports it. All vendor extensions have the 0x80000000 bit set in -error_type. A file vendor_flags controls the interpretation of param1 -and param2 (1 = PROCESSOR, 2 = MEMORY, 4 = PCI). See your BIOS vendor -documentation for details (and expect changes to this API if vendors -creativity in using this feature expands beyond our expectations). - - -An error injection example: - -# cd /sys/kernel/debug/apei/einj -# cat available_error_type # See which errors can be injected -0x00000002 Processor Uncorrectable non-fatal -0x00000008 Memory Correctable -0x00000010 Memory Uncorrectable non-fatal -# echo 0x12345000 > param1 # Set memory address for injection -# echo $((-1 << 12)) > param2 # Mask 0xfffffffffffff000 - anywhere in this page -# echo 0x8 > error_type # Choose correctable memory error -# echo 1 > error_inject # Inject now - -You should see something like this in dmesg: - -[22715.830801] EDAC sbridge MC3: HANDLING MCE MEMORY ERROR -[22715.834759] EDAC sbridge MC3: CPU 0: Machine Check Event: 0 Bank 7: 8c00004000010090 -[22715.834759] EDAC sbridge MC3: TSC 0 -[22715.834759] EDAC sbridge MC3: ADDR 12345000 EDAC sbridge MC3: MISC 144780c86 -[22715.834759] EDAC sbridge MC3: PROCESSOR 0:306e7 TIME 1422553404 SOCKET 0 APIC 0 -[22716.616173] EDAC MC3: 1 CE memory read error on CPU_SrcID#0_Channel#0_DIMM#0 (channel:0 slot:0 page:0x12345 offset:0x0 grain:32 syndrome:0x0 - area:DRAM err_code:0001:0090 socket:0 channel_mask:1 rank:0) - -For more information about EINJ, please refer to ACPI specification -version 4.0, section 17.5 and ACPI 5.0, section 18.6. diff --git a/Documentation/firmware-guide/acpi/apei/einj.rst b/Documentation/firmware-guide/acpi/apei/einj.rst new file mode 100644 index 000000000000..e588bccf5158 --- /dev/null +++ b/Documentation/firmware-guide/acpi/apei/einj.rst @@ -0,0 +1,185 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==================== +APEI Error INJection +==================== + +EINJ provides a hardware error injection mechanism. It is very useful +for debugging and testing APEI and RAS features in general. + +You need to check whether your BIOS supports EINJ first. For that, look +for early boot messages similar to this one:: + + ACPI: EINJ 0x000000007370A000 000150 (v01 INTEL 00000001 INTL 00000001) + +which shows that the BIOS is exposing an EINJ table - it is the +mechanism through which the injection is done. + +Alternatively, look in /sys/firmware/acpi/tables for an "EINJ" file, +which is a different representation of the same thing. + +It doesn't necessarily mean that EINJ is not supported if those above +don't exist: before you give up, go into BIOS setup to see if the BIOS +has an option to enable error injection. Look for something called WHEA +or similar. Often, you need to enable an ACPI5 support option prior, in +order to see the APEI,EINJ,... functionality supported and exposed by +the BIOS menu. + +To use EINJ, make sure the following are options enabled in your kernel +configuration:: + + CONFIG_DEBUG_FS + CONFIG_ACPI_APEI + CONFIG_ACPI_APEI_EINJ + +The EINJ user interface is in /apei/einj. + +The following files belong to it: + +- available_error_type + + This file shows which error types are supported: + + ================ =================================== + Error Type Value Error Description + ================ =================================== + 0x00000001 Processor Correctable + 0x00000002 Processor Uncorrectable non-fatal + 0x00000004 Processor Uncorrectable fatal + 0x00000008 Memory Correctable + 0x00000010 Memory Uncorrectable non-fatal + 0x00000020 Memory Uncorrectable fatal + 0x00000040 PCI Express Correctable + 0x00000080 PCI Express Uncorrectable fatal + 0x00000100 PCI Express Uncorrectable non-fatal + 0x00000200 Platform Correctable + 0x00000400 Platform Uncorrectable non-fatal + 0x00000800 Platform Uncorrectable fatal + ================ =================================== + + The format of the file contents are as above, except present are only + the available error types. + +- error_type + + Set the value of the error type being injected. Possible error types + are defined in the file available_error_type above. + +- error_inject + + Write any integer to this file to trigger the error injection. Make + sure you have specified all necessary error parameters, i.e. this + write should be the last step when injecting errors. + +- flags + + Present for kernel versions 3.13 and above. Used to specify which + of param{1..4} are valid and should be used by the firmware during + injection. Value is a bitmask as specified in ACPI5.0 spec for the + SET_ERROR_TYPE_WITH_ADDRESS data structure: + + Bit 0 + Processor APIC field valid (see param3 below). + Bit 1 + Memory address and mask valid (param1 and param2). + Bit 2 + PCIe (seg,bus,dev,fn) valid (see param4 below). + + If set to zero, legacy behavior is mimicked where the type of + injection specifies just one bit set, and param1 is multiplexed. + +- param1 + + This file is used to set the first error parameter value. Its effect + depends on the error type specified in error_type. For example, if + error type is memory related type, the param1 should be a valid + physical memory address. [Unless "flag" is set - see above] + +- param2 + + Same use as param1 above. For example, if error type is of memory + related type, then param2 should be a physical memory address mask. + Linux requires page or narrower granularity, say, 0xfffffffffffff000. + +- param3 + + Used when the 0x1 bit is set in "flags" to specify the APIC id + +- param4 + Used when the 0x4 bit is set in "flags" to specify target PCIe device + +- notrigger + + The error injection mechanism is a two-step process. First inject the + error, then perform some actions to trigger it. Setting "notrigger" + to 1 skips the trigger phase, which *may* allow the user to cause the + error in some other context by a simple access to the CPU, memory + location, or device that is the target of the error injection. Whether + this actually works depends on what operations the BIOS actually + includes in the trigger phase. + +BIOS versions based on the ACPI 4.0 specification have limited options +in controlling where the errors are injected. Your BIOS may support an +extension (enabled with the param_extension=1 module parameter, or boot +command line einj.param_extension=1). This allows the address and mask +for memory injections to be specified by the param1 and param2 files in +apei/einj. + +BIOS versions based on the ACPI 5.0 specification have more control over +the target of the injection. For processor-related errors (type 0x1, 0x2 +and 0x4), you can set flags to 0x3 (param3 for bit 0, and param1 and +param2 for bit 1) so that you have more information added to the error +signature being injected. The actual data passed is this:: + + memory_address = param1; + memory_address_range = param2; + apicid = param3; + pcie_sbdf = param4; + +For memory errors (type 0x8, 0x10 and 0x20) the address is set using +param1 with a mask in param2 (0x0 is equivalent to all ones). For PCI +express errors (type 0x40, 0x80 and 0x100) the segment, bus, device and +function are specified using param1:: + + 31 24 23 16 15 11 10 8 7 0 + +-------------------------------------------------+ + | segment | bus | device | function | reserved | + +-------------------------------------------------+ + +Anyway, you get the idea, if there's doubt just take a look at the code +in drivers/acpi/apei/einj.c. + +An ACPI 5.0 BIOS may also allow vendor-specific errors to be injected. +In this case a file named vendor will contain identifying information +from the BIOS that hopefully will allow an application wishing to use +the vendor-specific extension to tell that they are running on a BIOS +that supports it. All vendor extensions have the 0x80000000 bit set in +error_type. A file vendor_flags controls the interpretation of param1 +and param2 (1 = PROCESSOR, 2 = MEMORY, 4 = PCI). See your BIOS vendor +documentation for details (and expect changes to this API if vendors +creativity in using this feature expands beyond our expectations). + + +An error injection example:: + + # cd /sys/kernel/debug/apei/einj + # cat available_error_type # See which errors can be injected + 0x00000002 Processor Uncorrectable non-fatal + 0x00000008 Memory Correctable + 0x00000010 Memory Uncorrectable non-fatal + # echo 0x12345000 > param1 # Set memory address for injection + # echo $((-1 << 12)) > param2 # Mask 0xfffffffffffff000 - anywhere in this page + # echo 0x8 > error_type # Choose correctable memory error + # echo 1 > error_inject # Inject now + +You should see something like this in dmesg:: + + [22715.830801] EDAC sbridge MC3: HANDLING MCE MEMORY ERROR + [22715.834759] EDAC sbridge MC3: CPU 0: Machine Check Event: 0 Bank 7: 8c00004000010090 + [22715.834759] EDAC sbridge MC3: TSC 0 + [22715.834759] EDAC sbridge MC3: ADDR 12345000 EDAC sbridge MC3: MISC 144780c86 + [22715.834759] EDAC sbridge MC3: PROCESSOR 0:306e7 TIME 1422553404 SOCKET 0 APIC 0 + [22716.616173] EDAC MC3: 1 CE memory read error on CPU_SrcID#0_Channel#0_DIMM#0 (channel:0 slot:0 page:0x12345 offset:0x0 grain:32 syndrome:0x0 - area:DRAM err_code:0001:0090 socket:0 channel_mask:1 rank:0) + +For more information about EINJ, please refer to ACPI specification +version 4.0, section 17.5 and ACPI 5.0, section 18.6. diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst index 869badba6d7a..fca854f017d8 100644 --- a/Documentation/firmware-guide/acpi/index.rst +++ b/Documentation/firmware-guide/acpi/index.rst @@ -18,6 +18,7 @@ ACPI Support debug aml-debugger apei/output_format + apei/einj gpio-properties i2c-muxes acpi-lid -- cgit v1.2.3-59-g8ed1b From 3e57460f007c86476c376a08e31da441cae0b195 Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 01:53:03 +0800 Subject: Documentation: ACPI: move cppc_sysfs.txt to admin-guide/acpi and convert to reST This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/cppc_sysfs.txt | 69 ------------------------ Documentation/admin-guide/acpi/cppc_sysfs.rst | 76 +++++++++++++++++++++++++++ Documentation/admin-guide/acpi/index.rst | 1 + 3 files changed, 77 insertions(+), 69 deletions(-) delete mode 100644 Documentation/acpi/cppc_sysfs.txt create mode 100644 Documentation/admin-guide/acpi/cppc_sysfs.rst diff --git a/Documentation/acpi/cppc_sysfs.txt b/Documentation/acpi/cppc_sysfs.txt deleted file mode 100644 index f20fb445135d..000000000000 --- a/Documentation/acpi/cppc_sysfs.txt +++ /dev/null @@ -1,69 +0,0 @@ - - Collaborative Processor Performance Control (CPPC) - -CPPC defined in the ACPI spec describes a mechanism for the OS to manage the -performance of a logical processor on a contigious and abstract performance -scale. CPPC exposes a set of registers to describe abstract performance scale, -to request performance levels and to measure per-cpu delivered performance. - -For more details on CPPC please refer to the ACPI specification at: - -http://uefi.org/specifications - -Some of the CPPC registers are exposed via sysfs under: - -/sys/devices/system/cpu/cpuX/acpi_cppc/ - -for each cpu X - --------------------------------------------------------------------------------- - -$ ls -lR /sys/devices/system/cpu/cpu0/acpi_cppc/ -/sys/devices/system/cpu/cpu0/acpi_cppc/: -total 0 --r--r--r-- 1 root root 65536 Mar 5 19:38 feedback_ctrs --r--r--r-- 1 root root 65536 Mar 5 19:38 highest_perf --r--r--r-- 1 root root 65536 Mar 5 19:38 lowest_freq --r--r--r-- 1 root root 65536 Mar 5 19:38 lowest_nonlinear_perf --r--r--r-- 1 root root 65536 Mar 5 19:38 lowest_perf --r--r--r-- 1 root root 65536 Mar 5 19:38 nominal_freq --r--r--r-- 1 root root 65536 Mar 5 19:38 nominal_perf --r--r--r-- 1 root root 65536 Mar 5 19:38 reference_perf --r--r--r-- 1 root root 65536 Mar 5 19:38 wraparound_time - --------------------------------------------------------------------------------- - -* highest_perf : Highest performance of this processor (abstract scale). -* nominal_perf : Highest sustained performance of this processor (abstract scale). -* lowest_nonlinear_perf : Lowest performance of this processor with nonlinear - power savings (abstract scale). -* lowest_perf : Lowest performance of this processor (abstract scale). - -* lowest_freq : CPU frequency corresponding to lowest_perf (in MHz). -* nominal_freq : CPU frequency corresponding to nominal_perf (in MHz). - The above frequencies should only be used to report processor performance in - freqency instead of abstract scale. These values should not be used for any - functional decisions. - -* feedback_ctrs : Includes both Reference and delivered performance counter. - Reference counter ticks up proportional to processor's reference performance. - Delivered counter ticks up proportional to processor's delivered performance. -* wraparound_time: Minimum time for the feedback counters to wraparound (seconds). -* reference_perf : Performance level at which reference performance counter - accumulates (abstract scale). - --------------------------------------------------------------------------------- - - Computing Average Delivered Performance - -Below describes the steps to compute the average performance delivered by taking -two different snapshots of feedback counters at time T1 and T2. - -T1: Read feedback_ctrs as fbc_t1 - Wait or run some workload -T2: Read feedback_ctrs as fbc_t2 - -delivered_counter_delta = fbc_t2[del] - fbc_t1[del] -reference_counter_delta = fbc_t2[ref] - fbc_t1[ref] - -delivered_perf = (refernce_perf x delivered_counter_delta) / reference_counter_delta diff --git a/Documentation/admin-guide/acpi/cppc_sysfs.rst b/Documentation/admin-guide/acpi/cppc_sysfs.rst new file mode 100644 index 000000000000..a4b99afbe331 --- /dev/null +++ b/Documentation/admin-guide/acpi/cppc_sysfs.rst @@ -0,0 +1,76 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================================== +Collaborative Processor Performance Control (CPPC) +================================================== + +CPPC +==== + +CPPC defined in the ACPI spec describes a mechanism for the OS to manage the +performance of a logical processor on a contigious and abstract performance +scale. CPPC exposes a set of registers to describe abstract performance scale, +to request performance levels and to measure per-cpu delivered performance. + +For more details on CPPC please refer to the ACPI specification at: + +http://uefi.org/specifications + +Some of the CPPC registers are exposed via sysfs under:: + + /sys/devices/system/cpu/cpuX/acpi_cppc/ + +for each cpu X:: + + $ ls -lR /sys/devices/system/cpu/cpu0/acpi_cppc/ + /sys/devices/system/cpu/cpu0/acpi_cppc/: + total 0 + -r--r--r-- 1 root root 65536 Mar 5 19:38 feedback_ctrs + -r--r--r-- 1 root root 65536 Mar 5 19:38 highest_perf + -r--r--r-- 1 root root 65536 Mar 5 19:38 lowest_freq + -r--r--r-- 1 root root 65536 Mar 5 19:38 lowest_nonlinear_perf + -r--r--r-- 1 root root 65536 Mar 5 19:38 lowest_perf + -r--r--r-- 1 root root 65536 Mar 5 19:38 nominal_freq + -r--r--r-- 1 root root 65536 Mar 5 19:38 nominal_perf + -r--r--r-- 1 root root 65536 Mar 5 19:38 reference_perf + -r--r--r-- 1 root root 65536 Mar 5 19:38 wraparound_time + +* highest_perf : Highest performance of this processor (abstract scale). +* nominal_perf : Highest sustained performance of this processor + (abstract scale). +* lowest_nonlinear_perf : Lowest performance of this processor with nonlinear + power savings (abstract scale). +* lowest_perf : Lowest performance of this processor (abstract scale). + +* lowest_freq : CPU frequency corresponding to lowest_perf (in MHz). +* nominal_freq : CPU frequency corresponding to nominal_perf (in MHz). + The above frequencies should only be used to report processor performance in + freqency instead of abstract scale. These values should not be used for any + functional decisions. + +* feedback_ctrs : Includes both Reference and delivered performance counter. + Reference counter ticks up proportional to processor's reference performance. + Delivered counter ticks up proportional to processor's delivered performance. +* wraparound_time: Minimum time for the feedback counters to wraparound + (seconds). +* reference_perf : Performance level at which reference performance counter + accumulates (abstract scale). + + +Computing Average Delivered Performance +======================================= + +Below describes the steps to compute the average performance delivered by +taking two different snapshots of feedback counters at time T1 and T2. + + T1: Read feedback_ctrs as fbc_t1 + Wait or run some workload + + T2: Read feedback_ctrs as fbc_t2 + +:: + + delivered_counter_delta = fbc_t2[del] - fbc_t1[del] + reference_counter_delta = fbc_t2[ref] - fbc_t1[ref] + + delivered_perf = (refernce_perf x delivered_counter_delta) / reference_counter_delta diff --git a/Documentation/admin-guide/acpi/index.rst b/Documentation/admin-guide/acpi/index.rst index d68e9914c5ff..9049a7b9f065 100644 --- a/Documentation/admin-guide/acpi/index.rst +++ b/Documentation/admin-guide/acpi/index.rst @@ -10,3 +10,4 @@ the Linux ACPI support. initrd_table_override dsdt-override + cppc_sysfs -- cgit v1.2.3-59-g8ed1b From 4887954cac779abe38d3ba6446dec341ccca04ea Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 01:53:04 +0800 Subject: Documentation: ACPI: move lpit.txt to firmware-guide/acpi and convert to reST This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/lpit.txt | 25 ---------------------- Documentation/firmware-guide/acpi/index.rst | 1 + Documentation/firmware-guide/acpi/lpit.rst | 33 +++++++++++++++++++++++++++++ 3 files changed, 34 insertions(+), 25 deletions(-) delete mode 100644 Documentation/acpi/lpit.txt create mode 100644 Documentation/firmware-guide/acpi/lpit.rst diff --git a/Documentation/acpi/lpit.txt b/Documentation/acpi/lpit.txt deleted file mode 100644 index b426398d2e97..000000000000 --- a/Documentation/acpi/lpit.txt +++ /dev/null @@ -1,25 +0,0 @@ -To enumerate platform Low Power Idle states, Intel platforms are using -“Low Power Idle Table” (LPIT). More details about this table can be -downloaded from: -http://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf - -Residencies for each low power state can be read via FFH -(Function fixed hardware) or a memory mapped interface. - -On platforms supporting S0ix sleep states, there can be two types of -residencies: -- CPU PKG C10 (Read via FFH interface) -- Platform Controller Hub (PCH) SLP_S0 (Read via memory mapped interface) - -The following attributes are added dynamically to the cpuidle -sysfs attribute group: - /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us - /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us - -The "low_power_idle_cpu_residency_us" attribute shows time spent -by the CPU package in PKG C10 - -The "low_power_idle_system_residency_us" attribute shows SLP_S0 -residency, or system time spent with the SLP_S0# signal asserted. -This is the lowest possible system power state, achieved only when CPU is in -PKG C10 and all functional blocks in PCH are in a low power state. diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst index fca854f017d8..0e60f4b7129a 100644 --- a/Documentation/firmware-guide/acpi/index.rst +++ b/Documentation/firmware-guide/acpi/index.rst @@ -22,3 +22,4 @@ ACPI Support gpio-properties i2c-muxes acpi-lid + lpit diff --git a/Documentation/firmware-guide/acpi/lpit.rst b/Documentation/firmware-guide/acpi/lpit.rst new file mode 100644 index 000000000000..aca928fab027 --- /dev/null +++ b/Documentation/firmware-guide/acpi/lpit.rst @@ -0,0 +1,33 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=========================== +Low Power Idle Table (LPIT) +=========================== + +To enumerate platform Low Power Idle states, Intel platforms are using +“Low Power Idle Table” (LPIT). More details about this table can be +downloaded from: +http://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf + +Residencies for each low power state can be read via FFH +(Function fixed hardware) or a memory mapped interface. + +On platforms supporting S0ix sleep states, there can be two types of +residencies: + + - CPU PKG C10 (Read via FFH interface) + - Platform Controller Hub (PCH) SLP_S0 (Read via memory mapped interface) + +The following attributes are added dynamically to the cpuidle +sysfs attribute group:: + + /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us + /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us + +The "low_power_idle_cpu_residency_us" attribute shows time spent +by the CPU package in PKG C10 + +The "low_power_idle_system_residency_us" attribute shows SLP_S0 +residency, or system time spent with the SLP_S0# signal asserted. +This is the lowest possible system power state, achieved only when CPU is in +PKG C10 and all functional blocks in PCH are in a low power state. -- cgit v1.2.3-59-g8ed1b From 7fe19072df5555425268f9452059d3c514c6780f Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 01:53:05 +0800 Subject: Documentation: ACPI: move ssdt-overlays.txt to admin-guide/acpi and convert to reST This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/ssdt-overlays.txt | 172 ---------------------- Documentation/admin-guide/acpi/index.rst | 1 + Documentation/admin-guide/acpi/ssdt-overlays.rst | 180 +++++++++++++++++++++++ 3 files changed, 181 insertions(+), 172 deletions(-) delete mode 100644 Documentation/acpi/ssdt-overlays.txt create mode 100644 Documentation/admin-guide/acpi/ssdt-overlays.rst diff --git a/Documentation/acpi/ssdt-overlays.txt b/Documentation/acpi/ssdt-overlays.txt deleted file mode 100644 index 5ae13f161ea2..000000000000 --- a/Documentation/acpi/ssdt-overlays.txt +++ /dev/null @@ -1,172 +0,0 @@ - -In order to support ACPI open-ended hardware configurations (e.g. development -boards) we need a way to augment the ACPI configuration provided by the firmware -image. A common example is connecting sensors on I2C / SPI buses on development -boards. - -Although this can be accomplished by creating a kernel platform driver or -recompiling the firmware image with updated ACPI tables, neither is practical: -the former proliferates board specific kernel code while the latter requires -access to firmware tools which are often not publicly available. - -Because ACPI supports external references in AML code a more practical -way to augment firmware ACPI configuration is by dynamically loading -user defined SSDT tables that contain the board specific information. - -For example, to enumerate a Bosch BMA222E accelerometer on the I2C bus of the -Minnowboard MAX development board exposed via the LSE connector [1], the -following ASL code can be used: - -DefinitionBlock ("minnowmax.aml", "SSDT", 1, "Vendor", "Accel", 0x00000003) -{ - External (\_SB.I2C6, DeviceObj) - - Scope (\_SB.I2C6) - { - Device (STAC) - { - Name (_ADR, Zero) - Name (_HID, "BMA222E") - - Method (_CRS, 0, Serialized) - { - Name (RBUF, ResourceTemplate () - { - I2cSerialBus (0x0018, ControllerInitiated, 0x00061A80, - AddressingMode7Bit, "\\_SB.I2C6", 0x00, - ResourceConsumer, ,) - GpioInt (Edge, ActiveHigh, Exclusive, PullDown, 0x0000, - "\\_SB.GPO2", 0x00, ResourceConsumer, , ) - { // Pin list - 0 - } - }) - Return (RBUF) - } - } - } -} - -which can then be compiled to AML binary format: - -$ iasl minnowmax.asl - -Intel ACPI Component Architecture -ASL Optimizing Compiler version 20140214-64 [Mar 29 2014] -Copyright (c) 2000 - 2014 Intel Corporation - -ASL Input: minnomax.asl - 30 lines, 614 bytes, 7 keywords -AML Output: minnowmax.aml - 165 bytes, 6 named objects, 1 executable opcodes - -[1] http://wiki.minnowboard.org/MinnowBoard_MAX#Low_Speed_Expansion_Connector_.28Top.29 - -The resulting AML code can then be loaded by the kernel using one of the methods -below. - -== Loading ACPI SSDTs from initrd == - -This option allows loading of user defined SSDTs from initrd and it is useful -when the system does not support EFI or when there is not enough EFI storage. - -It works in a similar way with initrd based ACPI tables override/upgrade: SSDT -aml code must be placed in the first, uncompressed, initrd under the -"kernel/firmware/acpi" path. Multiple files can be used and this will translate -in loading multiple tables. Only SSDT and OEM tables are allowed. See -initrd_table_override.txt for more details. - -Here is an example: - -# Add the raw ACPI tables to an uncompressed cpio archive. -# They must be put into a /kernel/firmware/acpi directory inside the -# cpio archive. -# The uncompressed cpio archive must be the first. -# Other, typically compressed cpio archives, must be -# concatenated on top of the uncompressed one. -mkdir -p kernel/firmware/acpi -cp ssdt.aml kernel/firmware/acpi - -# Create the uncompressed cpio archive and concatenate the original initrd -# on top: -find kernel | cpio -H newc --create > /boot/instrumented_initrd -cat /boot/initrd >>/boot/instrumented_initrd - -== Loading ACPI SSDTs from EFI variables == - -This is the preferred method, when EFI is supported on the platform, because it -allows a persistent, OS independent way of storing the user defined SSDTs. There -is also work underway to implement EFI support for loading user defined SSDTs -and using this method will make it easier to convert to the EFI loading -mechanism when that will arrive. - -In order to load SSDTs from an EFI variable the efivar_ssdt kernel command line -parameter can be used. The argument for the option is the variable name to -use. If there are multiple variables with the same name but with different -vendor GUIDs, all of them will be loaded. - -In order to store the AML code in an EFI variable the efivarfs filesystem can be -used. It is enabled and mounted by default in /sys/firmware/efi/efivars in all -recent distribution. - -Creating a new file in /sys/firmware/efi/efivars will automatically create a new -EFI variable. Updating a file in /sys/firmware/efi/efivars will update the EFI -variable. Please note that the file name needs to be specially formatted as -"Name-GUID" and that the first 4 bytes in the file (little-endian format) -represent the attributes of the EFI variable (see EFI_VARIABLE_MASK in -include/linux/efi.h). Writing to the file must also be done with one write -operation. - -For example, you can use the following bash script to create/update an EFI -variable with the content from a given file: - -#!/bin/sh -e - -while ! [ -z "$1" ]; do - case "$1" in - "-f") filename="$2"; shift;; - "-g") guid="$2"; shift;; - *) name="$1";; - esac - shift -done - -usage() -{ - echo "Syntax: ${0##*/} -f filename [ -g guid ] name" - exit 1 -} - -[ -n "$name" -a -f "$filename" ] || usage - -EFIVARFS="/sys/firmware/efi/efivars" - -[ -d "$EFIVARFS" ] || exit 2 - -if stat -tf $EFIVARFS | grep -q -v de5e81e4; then - mount -t efivarfs none $EFIVARFS -fi - -# try to pick up an existing GUID -[ -n "$guid" ] || guid=$(find "$EFIVARFS" -name "$name-*" | head -n1 | cut -f2- -d-) - -# use a randomly generated GUID -[ -n "$guid" ] || guid="$(cat /proc/sys/kernel/random/uuid)" - -# efivarfs expects all of the data in one write -tmp=$(mktemp) -/bin/echo -ne "\007\000\000\000" | cat - $filename > $tmp -dd if=$tmp of="$EFIVARFS/$name-$guid" bs=$(stat -c %s $tmp) -rm $tmp - -== Loading ACPI SSDTs from configfs == - -This option allows loading of user defined SSDTs from userspace via the configfs -interface. The CONFIG_ACPI_CONFIGFS option must be select and configfs must be -mounted. In the following examples, we assume that configfs has been mounted in -/config. - -New tables can be loading by creating new directories in /config/acpi/table/ and -writing the SSDT aml code in the aml attribute: - -cd /config/acpi/table -mkdir my_ssdt -cat ~/ssdt.aml > my_ssdt/aml diff --git a/Documentation/admin-guide/acpi/index.rst b/Documentation/admin-guide/acpi/index.rst index 9049a7b9f065..4d13eeea1eca 100644 --- a/Documentation/admin-guide/acpi/index.rst +++ b/Documentation/admin-guide/acpi/index.rst @@ -10,4 +10,5 @@ the Linux ACPI support. initrd_table_override dsdt-override + ssdt-overlays cppc_sysfs diff --git a/Documentation/admin-guide/acpi/ssdt-overlays.rst b/Documentation/admin-guide/acpi/ssdt-overlays.rst new file mode 100644 index 000000000000..da37455f96c9 --- /dev/null +++ b/Documentation/admin-guide/acpi/ssdt-overlays.rst @@ -0,0 +1,180 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============= +SSDT Overlays +============= + +In order to support ACPI open-ended hardware configurations (e.g. development +boards) we need a way to augment the ACPI configuration provided by the firmware +image. A common example is connecting sensors on I2C / SPI buses on development +boards. + +Although this can be accomplished by creating a kernel platform driver or +recompiling the firmware image with updated ACPI tables, neither is practical: +the former proliferates board specific kernel code while the latter requires +access to firmware tools which are often not publicly available. + +Because ACPI supports external references in AML code a more practical +way to augment firmware ACPI configuration is by dynamically loading +user defined SSDT tables that contain the board specific information. + +For example, to enumerate a Bosch BMA222E accelerometer on the I2C bus of the +Minnowboard MAX development board exposed via the LSE connector [1], the +following ASL code can be used:: + + DefinitionBlock ("minnowmax.aml", "SSDT", 1, "Vendor", "Accel", 0x00000003) + { + External (\_SB.I2C6, DeviceObj) + + Scope (\_SB.I2C6) + { + Device (STAC) + { + Name (_ADR, Zero) + Name (_HID, "BMA222E") + + Method (_CRS, 0, Serialized) + { + Name (RBUF, ResourceTemplate () + { + I2cSerialBus (0x0018, ControllerInitiated, 0x00061A80, + AddressingMode7Bit, "\\_SB.I2C6", 0x00, + ResourceConsumer, ,) + GpioInt (Edge, ActiveHigh, Exclusive, PullDown, 0x0000, + "\\_SB.GPO2", 0x00, ResourceConsumer, , ) + { // Pin list + 0 + } + }) + Return (RBUF) + } + } + } + } + +which can then be compiled to AML binary format:: + + $ iasl minnowmax.asl + + Intel ACPI Component Architecture + ASL Optimizing Compiler version 20140214-64 [Mar 29 2014] + Copyright (c) 2000 - 2014 Intel Corporation + + ASL Input: minnomax.asl - 30 lines, 614 bytes, 7 keywords + AML Output: minnowmax.aml - 165 bytes, 6 named objects, 1 executable opcodes + +[1] http://wiki.minnowboard.org/MinnowBoard_MAX#Low_Speed_Expansion_Connector_.28Top.29 + +The resulting AML code can then be loaded by the kernel using one of the methods +below. + +Loading ACPI SSDTs from initrd +============================== + +This option allows loading of user defined SSDTs from initrd and it is useful +when the system does not support EFI or when there is not enough EFI storage. + +It works in a similar way with initrd based ACPI tables override/upgrade: SSDT +aml code must be placed in the first, uncompressed, initrd under the +"kernel/firmware/acpi" path. Multiple files can be used and this will translate +in loading multiple tables. Only SSDT and OEM tables are allowed. See +initrd_table_override.txt for more details. + +Here is an example:: + + # Add the raw ACPI tables to an uncompressed cpio archive. + # They must be put into a /kernel/firmware/acpi directory inside the + # cpio archive. + # The uncompressed cpio archive must be the first. + # Other, typically compressed cpio archives, must be + # concatenated on top of the uncompressed one. + mkdir -p kernel/firmware/acpi + cp ssdt.aml kernel/firmware/acpi + + # Create the uncompressed cpio archive and concatenate the original initrd + # on top: + find kernel | cpio -H newc --create > /boot/instrumented_initrd + cat /boot/initrd >>/boot/instrumented_initrd + +Loading ACPI SSDTs from EFI variables +===================================== + +This is the preferred method, when EFI is supported on the platform, because it +allows a persistent, OS independent way of storing the user defined SSDTs. There +is also work underway to implement EFI support for loading user defined SSDTs +and using this method will make it easier to convert to the EFI loading +mechanism when that will arrive. + +In order to load SSDTs from an EFI variable the efivar_ssdt kernel command line +parameter can be used. The argument for the option is the variable name to +use. If there are multiple variables with the same name but with different +vendor GUIDs, all of them will be loaded. + +In order to store the AML code in an EFI variable the efivarfs filesystem can be +used. It is enabled and mounted by default in /sys/firmware/efi/efivars in all +recent distribution. + +Creating a new file in /sys/firmware/efi/efivars will automatically create a new +EFI variable. Updating a file in /sys/firmware/efi/efivars will update the EFI +variable. Please note that the file name needs to be specially formatted as +"Name-GUID" and that the first 4 bytes in the file (little-endian format) +represent the attributes of the EFI variable (see EFI_VARIABLE_MASK in +include/linux/efi.h). Writing to the file must also be done with one write +operation. + +For example, you can use the following bash script to create/update an EFI +variable with the content from a given file:: + + #!/bin/sh -e + + while ! [ -z "$1" ]; do + case "$1" in + "-f") filename="$2"; shift;; + "-g") guid="$2"; shift;; + *) name="$1";; + esac + shift + done + + usage() + { + echo "Syntax: ${0##*/} -f filename [ -g guid ] name" + exit 1 + } + + [ -n "$name" -a -f "$filename" ] || usage + + EFIVARFS="/sys/firmware/efi/efivars" + + [ -d "$EFIVARFS" ] || exit 2 + + if stat -tf $EFIVARFS | grep -q -v de5e81e4; then + mount -t efivarfs none $EFIVARFS + fi + + # try to pick up an existing GUID + [ -n "$guid" ] || guid=$(find "$EFIVARFS" -name "$name-*" | head -n1 | cut -f2- -d-) + + # use a randomly generated GUID + [ -n "$guid" ] || guid="$(cat /proc/sys/kernel/random/uuid)" + + # efivarfs expects all of the data in one write + tmp=$(mktemp) + /bin/echo -ne "\007\000\000\000" | cat - $filename > $tmp + dd if=$tmp of="$EFIVARFS/$name-$guid" bs=$(stat -c %s $tmp) + rm $tmp + +Loading ACPI SSDTs from configfs +================================ + +This option allows loading of user defined SSDTs from userspace via the configfs +interface. The CONFIG_ACPI_CONFIGFS option must be select and configfs must be +mounted. In the following examples, we assume that configfs has been mounted in +/config. + +New tables can be loading by creating new directories in /config/acpi/table/ and +writing the SSDT aml code in the aml attribute:: + + cd /config/acpi/table + mkdir my_ssdt + cat ~/ssdt.aml > my_ssdt/aml -- cgit v1.2.3-59-g8ed1b From 7fb091f806c55da593b93bc858d81203a9597257 Mon Sep 17 00:00:00 2001 From: Changbin Du Date: Thu, 25 Apr 2019 01:53:06 +0800 Subject: Documentation: ACPI: move video_extension.txt to firmware-guide/acpi and convert to reST This converts the plain text documentation to reStructuredText format and adds it to Sphinx TOC tree. No essential content change. Signed-off-by: Changbin Du Reviewed-by: Mauro Carvalho Chehab Signed-off-by: Rafael J. Wysocki --- Documentation/acpi/video_extension.txt | 106 ------------------ Documentation/firmware-guide/acpi/index.rst | 1 + .../firmware-guide/acpi/video_extension.rst | 121 +++++++++++++++++++++ 3 files changed, 122 insertions(+), 106 deletions(-) delete mode 100644 Documentation/acpi/video_extension.txt create mode 100644 Documentation/firmware-guide/acpi/video_extension.rst diff --git a/Documentation/acpi/video_extension.txt b/Documentation/acpi/video_extension.txt deleted file mode 100644 index 79bf6a4921be..000000000000 --- a/Documentation/acpi/video_extension.txt +++ /dev/null @@ -1,106 +0,0 @@ -ACPI video extensions -~~~~~~~~~~~~~~~~~~~~~ - -This driver implement the ACPI Extensions For Display Adapters for -integrated graphics devices on motherboard, as specified in ACPI 2.0 -Specification, Appendix B, allowing to perform some basic control like -defining the video POST device, retrieving EDID information or to -setup a video output, etc. Note that this is an ref. implementation -only. It may or may not work for your integrated video device. - -The ACPI video driver does 3 things regarding backlight control: - -1 Export a sysfs interface for user space to control backlight level - -If the ACPI table has a video device, and acpi_backlight=vendor kernel -command line is not present, the driver will register a backlight device -and set the required backlight operation structure for it for the sysfs -interface control. For every registered class device, there will be a -directory named acpi_videoX under /sys/class/backlight. - -The backlight sysfs interface has a standard definition here: -Documentation/ABI/stable/sysfs-class-backlight. - -And what ACPI video driver does is: -actual_brightness: on read, control method _BQC will be evaluated to -get the brightness level the firmware thinks it is at; -bl_power: not implemented, will set the current brightness instead; -brightness: on write, control method _BCM will run to set the requested -brightness level; -max_brightness: Derived from the _BCL package(see below); -type: firmware - -Note that ACPI video backlight driver will always use index for -brightness, actual_brightness and max_brightness. So if we have -the following _BCL package: - -Method (_BCL, 0, NotSerialized) -{ - Return (Package (0x0C) - { - 0x64, - 0x32, - 0x0A, - 0x14, - 0x1E, - 0x28, - 0x32, - 0x3C, - 0x46, - 0x50, - 0x5A, - 0x64 - }) -} - -The first two levels are for when laptop are on AC or on battery and are -not used by Linux currently. The remaining 10 levels are supported levels -that we can choose from. The applicable index values are from 0 (that -corresponds to the 0x0A brightness value) to 9 (that corresponds to the -0x64 brightness value) inclusive. Each of those index values is regarded -as a "brightness level" indicator. Thus from the user space perspective -the range of available brightness levels is from 0 to 9 (max_brightness) -inclusive. - -2 Notify user space about hotkey event - -There are generally two cases for hotkey event reporting: -i) For some laptops, when user presses the hotkey, a scancode will be - generated and sent to user space through the input device created by - the keyboard driver as a key type input event, with proper remap, the - following key code will appear to user space: - - EV_KEY, KEY_BRIGHTNESSUP - EV_KEY, KEY_BRIGHTNESSDOWN - etc. - -For this case, ACPI video driver does not need to do anything(actually, -it doesn't even know this happened). - -ii) For some laptops, the press of the hotkey will not generate the - scancode, instead, firmware will notify the video device ACPI node - about the event. The event value is defined in the ACPI spec. ACPI - video driver will generate an key type input event according to the - notify value it received and send the event to user space through the - input device it created: - - event keycode - 0x86 KEY_BRIGHTNESSUP - 0x87 KEY_BRIGHTNESSDOWN - etc. - -so this would lead to the same effect as case i) now. - -Once user space tool receives this event, it can modify the backlight -level through the sysfs interface. - -3 Change backlight level in the kernel - -This works for machines covered by case ii) in Section 2. Once the driver -received a notification, it will set the backlight level accordingly. This does -not affect the sending of event to user space, they are always sent to user -space regardless of whether or not the video module controls the backlight level -directly. This behaviour can be controlled through the brightness_switch_enabled -module parameter as documented in admin-guide/kernel-parameters.rst. It is recommended to -disable this behaviour once a GUI environment starts up and wants to have full -control of the backlight level. diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst index 0e60f4b7129a..ae609eec4679 100644 --- a/Documentation/firmware-guide/acpi/index.rst +++ b/Documentation/firmware-guide/acpi/index.rst @@ -23,3 +23,4 @@ ACPI Support i2c-muxes acpi-lid lpit + video_extension diff --git a/Documentation/firmware-guide/acpi/video_extension.rst b/Documentation/firmware-guide/acpi/video_extension.rst new file mode 100644 index 000000000000..099b8607e07b --- /dev/null +++ b/Documentation/firmware-guide/acpi/video_extension.rst @@ -0,0 +1,121 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================== +ACPI video extensions +===================== + +This driver implement the ACPI Extensions For Display Adapters for +integrated graphics devices on motherboard, as specified in ACPI 2.0 +Specification, Appendix B, allowing to perform some basic control like +defining the video POST device, retrieving EDID information or to +setup a video output, etc. Note that this is an ref. implementation +only. It may or may not work for your integrated video device. + +The ACPI video driver does 3 things regarding backlight control. + +Export a sysfs interface for user space to control backlight level +================================================================== + +If the ACPI table has a video device, and acpi_backlight=vendor kernel +command line is not present, the driver will register a backlight device +and set the required backlight operation structure for it for the sysfs +interface control. For every registered class device, there will be a +directory named acpi_videoX under /sys/class/backlight. + +The backlight sysfs interface has a standard definition here: +Documentation/ABI/stable/sysfs-class-backlight. + +And what ACPI video driver does is: + +actual_brightness: + on read, control method _BQC will be evaluated to + get the brightness level the firmware thinks it is at; +bl_power: + not implemented, will set the current brightness instead; +brightness: + on write, control method _BCM will run to set the requested brightness level; +max_brightness: + Derived from the _BCL package(see below); +type: + firmware + +Note that ACPI video backlight driver will always use index for +brightness, actual_brightness and max_brightness. So if we have +the following _BCL package:: + + Method (_BCL, 0, NotSerialized) + { + Return (Package (0x0C) + { + 0x64, + 0x32, + 0x0A, + 0x14, + 0x1E, + 0x28, + 0x32, + 0x3C, + 0x46, + 0x50, + 0x5A, + 0x64 + }) + } + +The first two levels are for when laptop are on AC or on battery and are +not used by Linux currently. The remaining 10 levels are supported levels +that we can choose from. The applicable index values are from 0 (that +corresponds to the 0x0A brightness value) to 9 (that corresponds to the +0x64 brightness value) inclusive. Each of those index values is regarded +as a "brightness level" indicator. Thus from the user space perspective +the range of available brightness levels is from 0 to 9 (max_brightness) +inclusive. + +Notify user space about hotkey event +==================================== + +There are generally two cases for hotkey event reporting: + +i) For some laptops, when user presses the hotkey, a scancode will be + generated and sent to user space through the input device created by + the keyboard driver as a key type input event, with proper remap, the + following key code will appear to user space:: + + EV_KEY, KEY_BRIGHTNESSUP + EV_KEY, KEY_BRIGHTNESSDOWN + etc. + +For this case, ACPI video driver does not need to do anything(actually, +it doesn't even know this happened). + +ii) For some laptops, the press of the hotkey will not generate the + scancode, instead, firmware will notify the video device ACPI node + about the event. The event value is defined in the ACPI spec. ACPI + video driver will generate an key type input event according to the + notify value it received and send the event to user space through the + input device it created: + + ===== ================== + event keycode + ===== ================== + 0x86 KEY_BRIGHTNESSUP + 0x87 KEY_BRIGHTNESSDOWN + etc. + ===== ================== + +so this would lead to the same effect as case i) now. + +Once user space tool receives this event, it can modify the backlight +level through the sysfs interface. + +Change backlight level in the kernel +==================================== + +This works for machines covered by case ii) in Section 2. Once the driver +received a notification, it will set the backlight level accordingly. This does +not affect the sending of event to user space, they are always sent to user +space regardless of whether or not the video module controls the backlight level +directly. This behaviour can be controlled through the brightness_switch_enabled +module parameter as documented in admin-guide/kernel-parameters.rst. It is +recommended to disable this behaviour once a GUI environment starts up and +wants to have full control of the backlight level. -- cgit v1.2.3-59-g8ed1b