All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lan Tianyu <tianyu.lan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: "Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>
Cc: lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org,
	wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org,
	robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	lv.zheng-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
	linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC PATCH] ACPI: Add _DEP(Operation Region Dependencies) support to fix battery issue on the Asus T100TA
Date: Thu, 25 Sep 2014 17:44:43 +0800	[thread overview]
Message-ID: <5423E40B.8010302@intel.com> (raw)
In-Reply-To: <5595235.8OhLbSk3cf-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>

On 2014年09月25日 06:27, Rafael J. Wysocki wrote:
> On Tuesday, September 23, 2014 03:06:43 PM Lan Tianyu wrote:
>> ACPI 5.0 introduces _DEP to designate device objects that OSPM should
>> assign a higher priority in start ordering due to future operation region
>> accesses.
>>
>> On Asus T100TA, ACPI battery info are read from a I2C slave device via
>> I2C operation region. Before I2C operation region handler is installed,
>> battery _STA always returns 0. There is a _DEP method of designating
>> start order under battery device node.
>>
>> This patch is to implement _DEP feature to fix battery issue on the Asus T100TA.
>> Introducing acpi_bus_dep_device_list and adding dep_present flags in the struct
>> acpi_device. During ACPI namespace scan, all devices with _DEP support will be put
>> into the new list and those devices' dep_present flag will be set. Driver's probe()
>> should return EPROBE_DEFER when find dep_present is set. When I2C operation
>> region handler is installed, check all devices on the new list. Remove the one from
>> list if _DEP condition is met and clear its dep_present flag and do acpi_bus_attch()
>> for the device in order to resolve battery _STA issue on the Asus T100TA.
>>
>> Signed-off-by: Lan Tianyu <tianyu.lan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> 
> This is going in the right direction in my view, but isn't there just yet.
> 
> Details below.

Thanks for review.

> 
>> ---
>>  drivers/acpi/battery.c  |  4 +++
>>  drivers/acpi/scan.c     | 84 +++++++++++++++++++++++++++++++++++++++++++++++++
>>  drivers/i2c/i2c-acpi.c  |  1 +
>>  include/acpi/acpi_bus.h |  2 ++
>>  include/linux/acpi.h    |  3 ++
>>  5 files changed, 94 insertions(+)
>>
>> diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
>> index 1c162e7..c0a68ce 100644
>> --- a/drivers/acpi/battery.c
>> +++ b/drivers/acpi/battery.c
>> @@ -1194,6 +1194,10 @@ static int acpi_battery_add(struct acpi_device *device)
>>  
>>  	if (!device)
>>  		return -EINVAL;
>> +
>> +	if (device->dep_present)
> 
> device->flags.dep_present would be better.  Or even call the flag dep_unmet.

Ok. Will update.

> 
>> +		return -EPROBE_DEFER;
>> +
>>  	battery = kzalloc(sizeof(struct acpi_battery), GFP_KERNEL);
>>  	if (!battery)
>>  		return -ENOMEM;
>> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
>> index 3bf7764..a26dbb3 100644
>> --- a/drivers/acpi/scan.c
>> +++ b/drivers/acpi/scan.c
>> @@ -36,6 +36,7 @@ bool acpi_force_hot_remove;
>>  
>>  static const char *dummy_hid = "device";
>>  
>> +static LIST_HEAD(acpi_bus_dep_device_list);
>>  static LIST_HEAD(acpi_bus_id_list);
>>  static DEFINE_MUTEX(acpi_scan_lock);
>>  static LIST_HEAD(acpi_scan_handlers_list);
>> @@ -43,6 +44,11 @@ DEFINE_MUTEX(acpi_device_lock);
>>  LIST_HEAD(acpi_wakeup_device_list);
>>  static DEFINE_MUTEX(acpi_hp_context_lock);
>>  
>> +struct acpi_dep_data {
>> +	struct list_head node;
>> +	struct acpi_device *adev;
>> +};
>> +
>>  struct acpi_device_bus_id{
>>  	char bus_id[15];
>>  	unsigned int instance_no;
>> @@ -2048,6 +2054,32 @@ static void acpi_scan_init_hotplug(struct acpi_device *adev)
>>  	}
>>  }
>>  
>> +static void acpi_device_dep_initialize(struct acpi_device * adev)
>> +{
>> +	struct acpi_dep_data *dep;
>> +	acpi_status status;
>> +
>> +	if (!acpi_has_method(adev->handle, "_DEP"))
>> +		return;
>> +
>> +	status = acpi_evaluate_reference(adev->handle, "_DEP", NULL,
>> +					&adev->dep_devices);
>> +	if (ACPI_FAILURE(status)) {
>> +		dev_err(&adev->dev, "Fail to evaluate _DEP.\n");
> 
> "Failed"
> 
>> +		return;
>> +	}
>> +
>> +	dep = kzalloc(sizeof(struct acpi_dep_data), GFP_KERNEL);
>> +	if (!dep) {
>> +		dev_err(&adev->dev, "Memory allocation error.\n");
> 
> "Not enough memory for _DEP list entry\n"
> 
>> +		return;
>> +	}
>> +
>> +	dep->adev = adev;
>> +	adev->dep_present = true;
>> +	list_add_tail(&dep->node , &acpi_bus_dep_device_list);
>> +}
>> +
>>  static acpi_status acpi_bus_check_add(acpi_handle handle, u32 lvl_not_used,
>>  				      void *not_used, void **return_value)
>>  {
>> @@ -2074,6 +2106,7 @@ static acpi_status acpi_bus_check_add(acpi_handle handle, u32 lvl_not_used,
>>  		return AE_CTRL_DEPTH;
>>  
>>  	acpi_scan_init_hotplug(device);
>> +	acpi_device_dep_initialize(device);
>>  
>>   out:
>>  	if (!*return_value)
>> @@ -2191,6 +2224,57 @@ static void acpi_bus_attach(struct acpi_device *device)
>>  		acpi_bus_attach(child);
>>  }
>>  
>> +static int acpi_device_dep_check(struct acpi_device *adev)
>> +{
>> +	struct acpi_device *dep_adev;
>> +	struct acpi_device_physical_node *pn;
>> +	int i;
>> +
>> +	for (i = 0; i < adev->dep_devices.count; i++) {
>> +		dep_adev = acpi_bus_get_acpi_device(
>> +				adev->dep_devices.handles[i]);
>> +
>> +		if (!dep_adev)
>> +			return -ENODEV;
>> +
>> +		/* Check acpi device driver probing */
>> +		if (dep_adev->dev.driver)
>> +			continue;
> 
> This check isn't sufficient, because _DEP is supposed to be about operation
> regions being present, not about drivers being present.  Same for the driver
> check below.
> 
> I wouldn't bother to check drivers in this stub implementation. ->

Sounds like we need to check whether the dependent device node has been
attached with operation region handler and this needs ACPICA to expose
such function, right?

> 
>> +
>> +		if (!dep_adev->physical_node_count)
>> +			return -ENODEV;
>> +
>> +		/* Check physcial device node driver probing */
>> +		mutex_lock(&dep_adev->physical_node_lock);
>> +		list_for_each_entry(pn, &dep_adev->physical_node_list, node) {
>> +			if (pn->dev->driver) {
>> +				mutex_unlock(&dep_adev->physical_node_lock);
>> +				continue;
>> +			}
>> +		}
>> +		mutex_unlock(&dep_adev->physical_node_lock);
>> +		return -EFAULT;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +int acpi_walk_dep_device_list(void)
> 
> -> I'd pass the operation region device to that (and I'd call the function
> differently, but that's a detail).  Then, I'd just clear flags.dep_unmet
> for all devices having that operation region device in their dep_devices
> (and drop their entries from the list).  It wouldn't cover the case when
> one device depends on two operation regions at the same time (in a meaningful
> way), but should be sufficient to address the battery problem at hand. 
> 

This requires the dependent devices have a list to record devices which
depends on them, right? Create such lists during ACPI namespace scan.


>> +{
>> +	struct acpi_dep_data *dep, *tmp;
>> +
>> +	list_for_each_entry_safe(dep, tmp, &acpi_bus_dep_device_list, node) {
>> +		if (!acpi_device_dep_check(dep->adev)) {
>> +			dep->adev->dep_present = false;
>> +			acpi_bus_attach(dep->adev);
>> +			list_del(&dep->node);
>> +			kfree(dep);
>> +		}
>> +	}
>> +	return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(acpi_walk_dep_device_list);
>> +
>>  /**
>>   * acpi_bus_scan - Add ACPI device node objects in a given namespace scope.
>>   * @handle: Root of the namespace scope to scan.
>> diff --git a/drivers/i2c/i2c-acpi.c b/drivers/i2c/i2c-acpi.c
>> index 0dbc18c..fdc8dc8 100644
>> --- a/drivers/i2c/i2c-acpi.c
>> +++ b/drivers/i2c/i2c-acpi.c
>> @@ -339,6 +339,7 @@ int acpi_i2c_install_space_handler(struct i2c_adapter *adapter)
>>  		return -ENOMEM;
>>  	}
>>  
>> +	acpi_walk_dep_device_list();
>>  	return 0;
>>  }
>>  
>> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
>> index c1c9de1..c1e7055 100644
>> --- a/include/acpi/acpi_bus.h
>> +++ b/include/acpi/acpi_bus.h
>> @@ -357,7 +357,9 @@ struct acpi_device {
>>  	struct acpi_hotplug_context *hp;
>>  	struct acpi_driver *driver;
>>  	void *driver_data;
>> +	bool dep_present;
>>  	struct device dev;
>> +	struct acpi_handle_list dep_devices;
>>  	unsigned int physical_node_count;
>>  	struct list_head physical_node_list;
>>  	struct mutex physical_node_lock;
>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>> index 807cbc4..c9a504b 100644
>> --- a/include/linux/acpi.h
>> +++ b/include/linux/acpi.h
>> @@ -431,6 +431,7 @@ static inline bool acpi_driver_match_device(struct device *dev,
>>  
>>  int acpi_device_uevent_modalias(struct device *, struct kobj_uevent_env *);
>>  int acpi_device_modalias(struct device *, char *, int);
>> +int acpi_walk_dep_device_list(void);
>>  
>>  #define ACPI_PTR(_ptr)	(_ptr)
>>  
>> @@ -449,6 +450,8 @@ static inline const char *acpi_dev_name(struct acpi_device *adev)
>>  
>>  static inline void acpi_early_init(void) { }
>>  
>> +static inline int acpi_walk_dep_device_list(void) { }
>> +
>>  static inline int early_acpi_boot_init(void)
>>  {
>>  	return 0;
>>
> 


-- 
Best regards
Tianyu Lan

WARNING: multiple messages have this Message-ID (diff)
From: Lan Tianyu <tianyu.lan@intel.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: lenb@kernel.org, mika.westerberg@linux.intel.com,
	wsa@the-dreams.de, robert.moore@intel.com, lv.zheng@intel.com,
	linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-i2c@vger.kernel.org
Subject: Re: [RFC PATCH] ACPI: Add _DEP(Operation Region Dependencies) support to fix battery issue on the Asus T100TA
Date: Thu, 25 Sep 2014 17:44:43 +0800	[thread overview]
Message-ID: <5423E40B.8010302@intel.com> (raw)
In-Reply-To: <5595235.8OhLbSk3cf@vostro.rjw.lan>

On 2014年09月25日 06:27, Rafael J. Wysocki wrote:
> On Tuesday, September 23, 2014 03:06:43 PM Lan Tianyu wrote:
>> ACPI 5.0 introduces _DEP to designate device objects that OSPM should
>> assign a higher priority in start ordering due to future operation region
>> accesses.
>>
>> On Asus T100TA, ACPI battery info are read from a I2C slave device via
>> I2C operation region. Before I2C operation region handler is installed,
>> battery _STA always returns 0. There is a _DEP method of designating
>> start order under battery device node.
>>
>> This patch is to implement _DEP feature to fix battery issue on the Asus T100TA.
>> Introducing acpi_bus_dep_device_list and adding dep_present flags in the struct
>> acpi_device. During ACPI namespace scan, all devices with _DEP support will be put
>> into the new list and those devices' dep_present flag will be set. Driver's probe()
>> should return EPROBE_DEFER when find dep_present is set. When I2C operation
>> region handler is installed, check all devices on the new list. Remove the one from
>> list if _DEP condition is met and clear its dep_present flag and do acpi_bus_attch()
>> for the device in order to resolve battery _STA issue on the Asus T100TA.
>>
>> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
> 
> This is going in the right direction in my view, but isn't there just yet.
> 
> Details below.

Thanks for review.

> 
>> ---
>>  drivers/acpi/battery.c  |  4 +++
>>  drivers/acpi/scan.c     | 84 +++++++++++++++++++++++++++++++++++++++++++++++++
>>  drivers/i2c/i2c-acpi.c  |  1 +
>>  include/acpi/acpi_bus.h |  2 ++
>>  include/linux/acpi.h    |  3 ++
>>  5 files changed, 94 insertions(+)
>>
>> diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
>> index 1c162e7..c0a68ce 100644
>> --- a/drivers/acpi/battery.c
>> +++ b/drivers/acpi/battery.c
>> @@ -1194,6 +1194,10 @@ static int acpi_battery_add(struct acpi_device *device)
>>  
>>  	if (!device)
>>  		return -EINVAL;
>> +
>> +	if (device->dep_present)
> 
> device->flags.dep_present would be better.  Or even call the flag dep_unmet.

Ok. Will update.

> 
>> +		return -EPROBE_DEFER;
>> +
>>  	battery = kzalloc(sizeof(struct acpi_battery), GFP_KERNEL);
>>  	if (!battery)
>>  		return -ENOMEM;
>> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
>> index 3bf7764..a26dbb3 100644
>> --- a/drivers/acpi/scan.c
>> +++ b/drivers/acpi/scan.c
>> @@ -36,6 +36,7 @@ bool acpi_force_hot_remove;
>>  
>>  static const char *dummy_hid = "device";
>>  
>> +static LIST_HEAD(acpi_bus_dep_device_list);
>>  static LIST_HEAD(acpi_bus_id_list);
>>  static DEFINE_MUTEX(acpi_scan_lock);
>>  static LIST_HEAD(acpi_scan_handlers_list);
>> @@ -43,6 +44,11 @@ DEFINE_MUTEX(acpi_device_lock);
>>  LIST_HEAD(acpi_wakeup_device_list);
>>  static DEFINE_MUTEX(acpi_hp_context_lock);
>>  
>> +struct acpi_dep_data {
>> +	struct list_head node;
>> +	struct acpi_device *adev;
>> +};
>> +
>>  struct acpi_device_bus_id{
>>  	char bus_id[15];
>>  	unsigned int instance_no;
>> @@ -2048,6 +2054,32 @@ static void acpi_scan_init_hotplug(struct acpi_device *adev)
>>  	}
>>  }
>>  
>> +static void acpi_device_dep_initialize(struct acpi_device * adev)
>> +{
>> +	struct acpi_dep_data *dep;
>> +	acpi_status status;
>> +
>> +	if (!acpi_has_method(adev->handle, "_DEP"))
>> +		return;
>> +
>> +	status = acpi_evaluate_reference(adev->handle, "_DEP", NULL,
>> +					&adev->dep_devices);
>> +	if (ACPI_FAILURE(status)) {
>> +		dev_err(&adev->dev, "Fail to evaluate _DEP.\n");
> 
> "Failed"
> 
>> +		return;
>> +	}
>> +
>> +	dep = kzalloc(sizeof(struct acpi_dep_data), GFP_KERNEL);
>> +	if (!dep) {
>> +		dev_err(&adev->dev, "Memory allocation error.\n");
> 
> "Not enough memory for _DEP list entry\n"
> 
>> +		return;
>> +	}
>> +
>> +	dep->adev = adev;
>> +	adev->dep_present = true;
>> +	list_add_tail(&dep->node , &acpi_bus_dep_device_list);
>> +}
>> +
>>  static acpi_status acpi_bus_check_add(acpi_handle handle, u32 lvl_not_used,
>>  				      void *not_used, void **return_value)
>>  {
>> @@ -2074,6 +2106,7 @@ static acpi_status acpi_bus_check_add(acpi_handle handle, u32 lvl_not_used,
>>  		return AE_CTRL_DEPTH;
>>  
>>  	acpi_scan_init_hotplug(device);
>> +	acpi_device_dep_initialize(device);
>>  
>>   out:
>>  	if (!*return_value)
>> @@ -2191,6 +2224,57 @@ static void acpi_bus_attach(struct acpi_device *device)
>>  		acpi_bus_attach(child);
>>  }
>>  
>> +static int acpi_device_dep_check(struct acpi_device *adev)
>> +{
>> +	struct acpi_device *dep_adev;
>> +	struct acpi_device_physical_node *pn;
>> +	int i;
>> +
>> +	for (i = 0; i < adev->dep_devices.count; i++) {
>> +		dep_adev = acpi_bus_get_acpi_device(
>> +				adev->dep_devices.handles[i]);
>> +
>> +		if (!dep_adev)
>> +			return -ENODEV;
>> +
>> +		/* Check acpi device driver probing */
>> +		if (dep_adev->dev.driver)
>> +			continue;
> 
> This check isn't sufficient, because _DEP is supposed to be about operation
> regions being present, not about drivers being present.  Same for the driver
> check below.
> 
> I wouldn't bother to check drivers in this stub implementation. ->

Sounds like we need to check whether the dependent device node has been
attached with operation region handler and this needs ACPICA to expose
such function, right?

> 
>> +
>> +		if (!dep_adev->physical_node_count)
>> +			return -ENODEV;
>> +
>> +		/* Check physcial device node driver probing */
>> +		mutex_lock(&dep_adev->physical_node_lock);
>> +		list_for_each_entry(pn, &dep_adev->physical_node_list, node) {
>> +			if (pn->dev->driver) {
>> +				mutex_unlock(&dep_adev->physical_node_lock);
>> +				continue;
>> +			}
>> +		}
>> +		mutex_unlock(&dep_adev->physical_node_lock);
>> +		return -EFAULT;
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +int acpi_walk_dep_device_list(void)
> 
> -> I'd pass the operation region device to that (and I'd call the function
> differently, but that's a detail).  Then, I'd just clear flags.dep_unmet
> for all devices having that operation region device in their dep_devices
> (and drop their entries from the list).  It wouldn't cover the case when
> one device depends on two operation regions at the same time (in a meaningful
> way), but should be sufficient to address the battery problem at hand. 
> 

This requires the dependent devices have a list to record devices which
depends on them, right? Create such lists during ACPI namespace scan.


>> +{
>> +	struct acpi_dep_data *dep, *tmp;
>> +
>> +	list_for_each_entry_safe(dep, tmp, &acpi_bus_dep_device_list, node) {
>> +		if (!acpi_device_dep_check(dep->adev)) {
>> +			dep->adev->dep_present = false;
>> +			acpi_bus_attach(dep->adev);
>> +			list_del(&dep->node);
>> +			kfree(dep);
>> +		}
>> +	}
>> +	return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(acpi_walk_dep_device_list);
>> +
>>  /**
>>   * acpi_bus_scan - Add ACPI device node objects in a given namespace scope.
>>   * @handle: Root of the namespace scope to scan.
>> diff --git a/drivers/i2c/i2c-acpi.c b/drivers/i2c/i2c-acpi.c
>> index 0dbc18c..fdc8dc8 100644
>> --- a/drivers/i2c/i2c-acpi.c
>> +++ b/drivers/i2c/i2c-acpi.c
>> @@ -339,6 +339,7 @@ int acpi_i2c_install_space_handler(struct i2c_adapter *adapter)
>>  		return -ENOMEM;
>>  	}
>>  
>> +	acpi_walk_dep_device_list();
>>  	return 0;
>>  }
>>  
>> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
>> index c1c9de1..c1e7055 100644
>> --- a/include/acpi/acpi_bus.h
>> +++ b/include/acpi/acpi_bus.h
>> @@ -357,7 +357,9 @@ struct acpi_device {
>>  	struct acpi_hotplug_context *hp;
>>  	struct acpi_driver *driver;
>>  	void *driver_data;
>> +	bool dep_present;
>>  	struct device dev;
>> +	struct acpi_handle_list dep_devices;
>>  	unsigned int physical_node_count;
>>  	struct list_head physical_node_list;
>>  	struct mutex physical_node_lock;
>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>> index 807cbc4..c9a504b 100644
>> --- a/include/linux/acpi.h
>> +++ b/include/linux/acpi.h
>> @@ -431,6 +431,7 @@ static inline bool acpi_driver_match_device(struct device *dev,
>>  
>>  int acpi_device_uevent_modalias(struct device *, struct kobj_uevent_env *);
>>  int acpi_device_modalias(struct device *, char *, int);
>> +int acpi_walk_dep_device_list(void);
>>  
>>  #define ACPI_PTR(_ptr)	(_ptr)
>>  
>> @@ -449,6 +450,8 @@ static inline const char *acpi_dev_name(struct acpi_device *adev)
>>  
>>  static inline void acpi_early_init(void) { }
>>  
>> +static inline int acpi_walk_dep_device_list(void) { }
>> +
>>  static inline int early_acpi_boot_init(void)
>>  {
>>  	return 0;
>>
> 


-- 
Best regards
Tianyu Lan

  parent reply	other threads:[~2014-09-25  9:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-23  7:06 [RFC PATCH] ACPI: Add _DEP(Operation Region Dependencies) support to fix battery issue on the Asus T100TA Lan Tianyu
     [not found] ` <1411456003-29541-1-git-send-email-tianyu.lan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2014-09-24 22:27   ` Rafael J. Wysocki
2014-09-24 22:27     ` Rafael J. Wysocki
     [not found]     ` <5595235.8OhLbSk3cf-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>
2014-09-25  9:44       ` Lan Tianyu [this message]
2014-09-25  9:44         ` Lan Tianyu
     [not found]         ` <5423E40B.8010302-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2014-09-25 19:27           ` Rafael J. Wysocki
2014-09-25 19:27             ` Rafael J. Wysocki
     [not found]             ` <2232717.X50lT6IYgQ-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>
2014-09-25 20:15               ` Rafael J. Wysocki
2014-09-25 20:15                 ` Rafael J. Wysocki
2014-09-26  5:23             ` Lan Tianyu
2014-09-26  5:23               ` Lan Tianyu
2014-09-26 13:48               ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5423E40B.8010302@intel.com \
    --to=tianyu.lan-ral2jqcrhueavxtiumwx3w@public.gmane.org \
    --cc=lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=lv.zheng-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    --cc=rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org \
    --cc=robert.moore-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.