Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753864Ab2KTXvY (ORCPT ); Tue, 20 Nov 2012 18:51:24 -0500 Received: from g6t0184.atlanta.hp.com ([15.193.32.61]:23486 "EHLO g6t0184.atlanta.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753835Ab2KTXvW (ORCPT ); Tue, 20 Nov 2012 18:51:22 -0500 From: Toshi Kani To: linux-acpi@vger.kernel.org, rjw@sisk.pl, lenb@kernel.org Cc: linux-kernel@vger.kernel.org, joe@perches.com, bhelgaas@google.com, isimatu.yasuaki@jp.fujitsu.com, vijaymohan.pandarathil@hp.com, Toshi Kani Subject: [PATCH v7 1/5] ACPI: Add acpi_handle_() interfaces Date: Tue, 20 Nov 2012 16:42:26 -0700 Message-Id: <1353454950-17010-2-git-send-email-toshi.kani@hp.com> X-Mailer: git-send-email 1.7.11.7 In-Reply-To: <1353454950-17010-1-git-send-email-toshi.kani@hp.com> References: <1353454950-17010-1-git-send-email-toshi.kani@hp.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5636 Lines: 154 This patch introduces acpi_handle_(), where is a kernel message level such as err/warn/info, to support improved logging messages for ACPI, esp. hot-plug operations. acpi_handle_() appends "ACPI" prefix and ACPI object path to the messages. This improves diagnosis of hotplug operations since an error message in a log file identifies an object that caused an issue. This interface acquires the global namespace mutex and is not suitable for interrupt context. acpi_handle_() takes acpi_handle as an argument, which is passed to ACPI hotplug notify handlers from the ACPICA. Therefore, it is always available unlike other kernel objects, such as device. For example: acpi_handle_err(handle, "Device don't exist, dropping EJECT\n"); logs an error message like this at KERN_ERR. ACPI: \_SB_.SCK4.CPU4: Device don't exist, dropping EJECT ACPI hot-plug drivers can use acpi_handle_() when they need to identify a target ACPI object path in their messages, such as error cases. The usage model is similar to dev_(). acpi_handle_() can be used when a device is not created or is invalid during hot-plug operations. ACPI object path is also consistent on the platform, unlike device name that gets incremented over hotplug operations. ACPI drivers should use dev_() when a device object is valid. Device name provides more user friendly information, and avoids acquiring the global ACPI namespace mutex. ACPI drivers also continue to use pr_() when they do not need to specify device information, such as boot-up messages. Note: ACPI_[WARNING|INFO|ERROR]() are intended for the ACPICA and are not associated with the kernel message level. Signed-off-by: Toshi Kani Tested-by: Vijay Mohan Pandarathil --- drivers/acpi/utils.c | 37 +++++++++++++++++++++++++++++++++++++ include/linux/acpi.h | 43 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 80 insertions(+) diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c index 462f7e3..4652730 100644 --- a/drivers/acpi/utils.c +++ b/drivers/acpi/utils.c @@ -28,6 +28,8 @@ #include #include #include +#include +#include #include #include @@ -457,3 +459,38 @@ acpi_evaluate_hotplug_ost(acpi_handle handle, u32 source_event, #endif } EXPORT_SYMBOL(acpi_evaluate_hotplug_ost); + +/** + * acpi_handle_printk: Print message with ACPI prefix and object path + * + * This function is called through acpi_handle_ macros and prints + * a message with ACPI prefix and object path. This function acquires + * the global namespace mutex and is not suitable for interrupt context. + */ +void +acpi_handle_printk(const char *level, acpi_handle handle, const char *fmt, ...) +{ + struct va_format vaf; + va_list args; + struct acpi_buffer buffer = { + .length = ACPI_ALLOCATE_BUFFER, + .pointer = NULL + }; + const char *path; + + va_start(args, fmt); + vaf.fmt = fmt; + vaf.va = &args; + + if (in_interrupt() || + acpi_get_name(handle, ACPI_FULL_PATHNAME, &buffer) != AE_OK) + path = ""; + else + path = buffer.pointer; + + printk("%sACPI: %s: %pV", level, path, &vaf); + + va_end(args); + kfree(buffer.pointer); +} +EXPORT_SYMBOL(acpi_handle_printk); diff --git a/include/linux/acpi.h b/include/linux/acpi.h index 0bb2070..d15d90d 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -517,4 +517,47 @@ static inline int acpi_dev_pm_attach(struct device *dev) { return -ENODEV; } static inline void acpi_dev_pm_detach(struct device *dev) {} #endif +#ifdef CONFIG_ACPI +__printf(3, 4) +void acpi_handle_printk(const char *level, acpi_handle handle, + const char *fmt, ...); +#else /* !CONFIG_ACPI */ +static inline __printf(3, 4) void +acpi_handle_printk(const char *level, void *handle, const char *fmt, ...) {} +#endif /* !CONFIG_ACPI */ + +/* + * acpi_handle_: Print message with ACPI prefix and object path + * + * These interfaces acquire the global namespace mutex and are not + * suitable for interrupt context. + */ +#define acpi_handle_emerg(handle, fmt, ...) \ + acpi_handle_printk(KERN_EMERG, handle, fmt, ##__VA_ARGS__) +#define acpi_handle_alert(handle, fmt, ...) \ + acpi_handle_printk(KERN_ALERT, handle, fmt, ##__VA_ARGS__) +#define acpi_handle_crit(handle, fmt, ...) \ + acpi_handle_printk(KERN_CRIT, handle, fmt, ##__VA_ARGS__) +#define acpi_handle_err(handle, fmt, ...) \ + acpi_handle_printk(KERN_ERR, handle, fmt, ##__VA_ARGS__) +#define acpi_handle_warn(handle, fmt, ...) \ + acpi_handle_printk(KERN_WARNING, handle, fmt, ##__VA_ARGS__) +#define acpi_handle_notice(handle, fmt, ...) \ + acpi_handle_printk(KERN_NOTICE, handle, fmt, ##__VA_ARGS__) +#define acpi_handle_info(handle, fmt, ...) \ + acpi_handle_printk(KERN_INFO, handle, fmt, ##__VA_ARGS__) + +/* REVISIT: Support CONFIG_DYNAMIC_DEBUG when necessary */ +#if defined(DEBUG) || defined(CONFIG_DYNAMIC_DEBUG) +#define acpi_handle_debug(handle, fmt, ...) \ + acpi_handle_printk(KERN_DEBUG, handle, fmt, ##__VA_ARGS__) +#else +#define acpi_handle_debug(handle, fmt, ...) \ +({ \ + if (0) \ + acpi_handle_printk(KERN_DEBUG, handle, fmt, ##__VA_ARGS__); \ + 0; \ +}) +#endif + #endif /*_LINUX_ACPI_H*/ -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/