linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v7-1 1/5] ACPI: Add acpi_handle_<level>() interfaces
@ 2012-11-21  1:36 Toshi Kani
  2012-11-22  0:13 ` Rafael J. Wysocki
  0 siblings, 1 reply; 3+ messages in thread
From: Toshi Kani @ 2012-11-21  1:36 UTC (permalink / raw)
  To: linux-acpi, rjw, lenb
  Cc: linux-kernel, joe, bhelgaas, isimatu.yasuaki,
	vijaymohan.pandarathil, Toshi Kani

This patch introduces acpi_handle_<level>(), where <level> is
a kernel message level such as err/warn/info, to support improved
logging messages for ACPI, esp. hot-plug operations.
acpi_handle_<level>() 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 to obtain an object path.  In interrupt context, it shows
the object path as <n/a>.

acpi_handle_<level>() 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_<level>() when they need
to identify a target ACPI object path in their messages, such as
error cases.  The usage model is similar to dev_<level>().
acpi_handle_<level>() 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_<level>() 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_<level>() 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 <toshi.kani@hp.com>
Tested-by: Vijay Mohan Pandarathil <vijaymohan.pandarathil@hp.com>
---

Hi Rafael,
This patch replaces the [PATCH v7 1/5] below in the v7 series.
https://lkml.org/lkml/2012/11/20/719

---
 drivers/acpi/utils.c | 38 ++++++++++++++++++++++++++++++++++++++
 include/linux/acpi.h | 43 +++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 81 insertions(+)

diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
index 462f7e3..74437130 100644
--- a/drivers/acpi/utils.c
+++ b/drivers/acpi/utils.c
@@ -28,6 +28,8 @@
 #include <linux/slab.h>
 #include <linux/init.h>
 #include <linux/types.h>
+#include <linux/hardirq.h>
+#include <linux/acpi.h>
 #include <acpi/acpi_bus.h>
 #include <acpi/acpi_drivers.h>
 
@@ -457,3 +459,39 @@ 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_<level> macros and prints
+ * a message with ACPI prefix and object path.  This function acquires
+ * the global namespace mutex to obtain an object path.  In interrupt
+ * context, it shows the object path as <n/a>.
+ */
+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 = "<n/a>";
+	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..417c96c 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_<level>: Print message with ACPI prefix and object path
+ * 
+ * These interfaces acquire the global namespace mutex to obtain an object
+ * path.  In interrupt context, it shows the object path as <n/a>.
+ */
+#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


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH v7-1 1/5] ACPI: Add acpi_handle_<level>() interfaces
  2012-11-21  1:36 [PATCH v7-1 1/5] ACPI: Add acpi_handle_<level>() interfaces Toshi Kani
@ 2012-11-22  0:13 ` Rafael J. Wysocki
  2012-11-22 16:52   ` Toshi Kani
  0 siblings, 1 reply; 3+ messages in thread
From: Rafael J. Wysocki @ 2012-11-22  0:13 UTC (permalink / raw)
  To: Toshi Kani
  Cc: linux-acpi, lenb, linux-kernel, joe, bhelgaas, isimatu.yasuaki,
	vijaymohan.pandarathil

On Tuesday, November 20, 2012 06:36:28 PM Toshi Kani wrote:
> This patch introduces acpi_handle_<level>(), where <level> is
> a kernel message level such as err/warn/info, to support improved
> logging messages for ACPI, esp. hot-plug operations.
> acpi_handle_<level>() 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 to obtain an object path.  In interrupt context, it shows
> the object path as <n/a>.
> 
> acpi_handle_<level>() 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_<level>() when they need
> to identify a target ACPI object path in their messages, such as
> error cases.  The usage model is similar to dev_<level>().
> acpi_handle_<level>() 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_<level>() 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_<level>() 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 <toshi.kani@hp.com>
> Tested-by: Vijay Mohan Pandarathil <vijaymohan.pandarathil@hp.com>
> ---
> 
> Hi Rafael,
> This patch replaces the [PATCH v7 1/5] below in the v7 series.
> https://lkml.org/lkml/2012/11/20/719

I've applied the entire v7 series to linux-pm.git/linux-next as v3.8 material.

As far as the .sys_notify series is concerned, I don't really like it.
I'll send you my comments in the next few days.

Thanks,
Rafael


> ---
>  drivers/acpi/utils.c | 38 ++++++++++++++++++++++++++++++++++++++
>  include/linux/acpi.h | 43 +++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 81 insertions(+)
> 
> diff --git a/drivers/acpi/utils.c b/drivers/acpi/utils.c
> index 462f7e3..74437130 100644
> --- a/drivers/acpi/utils.c
> +++ b/drivers/acpi/utils.c
> @@ -28,6 +28,8 @@
>  #include <linux/slab.h>
>  #include <linux/init.h>
>  #include <linux/types.h>
> +#include <linux/hardirq.h>
> +#include <linux/acpi.h>
>  #include <acpi/acpi_bus.h>
>  #include <acpi/acpi_drivers.h>
>  
> @@ -457,3 +459,39 @@ 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_<level> macros and prints
> + * a message with ACPI prefix and object path.  This function acquires
> + * the global namespace mutex to obtain an object path.  In interrupt
> + * context, it shows the object path as <n/a>.
> + */
> +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 = "<n/a>";
> +	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..417c96c 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_<level>: Print message with ACPI prefix and object path
> + * 
> + * These interfaces acquire the global namespace mutex to obtain an object
> + * path.  In interrupt context, it shows the object path as <n/a>.
> + */
> +#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*/
> 
-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH v7-1 1/5] ACPI: Add acpi_handle_<level>() interfaces
  2012-11-22  0:13 ` Rafael J. Wysocki
@ 2012-11-22 16:52   ` Toshi Kani
  0 siblings, 0 replies; 3+ messages in thread
From: Toshi Kani @ 2012-11-22 16:52 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: linux-acpi, lenb, linux-kernel, joe, bhelgaas, isimatu.yasuaki,
	vijaymohan.pandarathil

> > Signed-off-by: Toshi Kani <toshi.kani@hp.com>
> > Tested-by: Vijay Mohan Pandarathil <vijaymohan.pandarathil@hp.com>
> > ---
> > 
> > Hi Rafael,
> > This patch replaces the [PATCH v7 1/5] below in the v7 series.
> > https://lkml.org/lkml/2012/11/20/719
> 
> I've applied the entire v7 series to linux-pm.git/linux-next as v3.8 material.

Great!

> As far as the .sys_notify series is concerned, I don't really like it.
> I'll send you my comments in the next few days.

Thanks for reviewing!  Yes, let me know your comments.

-Toshi



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2012-11-22 18:56 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-21  1:36 [PATCH v7-1 1/5] ACPI: Add acpi_handle_<level>() interfaces Toshi Kani
2012-11-22  0:13 ` Rafael J. Wysocki
2012-11-22 16:52   ` Toshi Kani

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).