All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Zheng, Lv" <lv.zheng-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
To: "Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>,
	"Lu, Aaron" <aaron.lu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Jacob Pan <jacob.jun.pan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	"Iyer,
	Yegnesh S"
	<yegnesh.s.iyer-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	"linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: RE: [PATCH v3 updated 3/3] ACPI / PMIC: AXP288: support virtual GPIO in ACPI table
Date: Tue, 25 Nov 2014 01:44:28 +0000	[thread overview]
Message-ID: <1AE640813FDE7649BE1B193DEA596E88026A4A7C@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <2204417.orosXAozvY-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>

Hi,

> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> Sent: Monday, November 24, 2014 11:20 PM
> Lv
> Subject: Re: [PATCH v3 updated 3/3] ACPI / PMIC: AXP288: support virtual GPIO in ACPI table
> 
> On Monday, November 24, 2014 05:32:33 PM Aaron Lu wrote:
> > On 11/24/2014 09:06 AM, Rafael J. Wysocki wrote:
> > > On Friday, November 21, 2014 03:11:51 PM Aaron Lu wrote:
> > >> +	if (!result) {
> > >> +		status = acpi_install_address_space_handler(
> > >> +				ACPI_HANDLE(parent), ACPI_ADR_SPACE_GPIO,
> > >> +				intel_xpower_pmic_gpio_handler, NULL, NULL);
> > >
> > > So here we have a problem, because we can't unregister the opregion handler
> > > registered above if this fails.  Not nice.
> >
> > I'm not correct in the cover letter, the actual problem with operation
> > region remove is with module unload, it happens like this:
> >
> > The acpi_remove_address_space_handler doesn't wait for the current
> > running handler to return, so if we call
> > acpi_remove_address_space_handler in a module's exit function, the
> > handler's memory will be freed and the running handler will access to
> > a no longer valid memory place.
> >
> > So as long as we can make sure the handler will not go away from the
> > memory, we are safe.
> 
> This only means that address space handlers cannot be removed from kernel
> modules.
> 
> Lv was trying to add a wrapper for that some time ago, maybe it's a good
> idea to revive that?

I may fix the issue in ACPICA, but it looks like that it will cost time to discuss.
So I also think it is better to take the wrapper now.
I'll hand the patch to Aaron to let him do a test on it before posting it again.

Thanks and best regards
-Lv

> > With this said, the updated patch is here:
> >
> > From: Aaron Lu <aaron.lu@intel.com>
> > Date: Mon, 20 Oct 2014 17:06:20 +0800
> > Subject: [PATCH 3/3] ACPI / PMIC: AXP288: support virtual GPIO in ACPI table
> >
> > The same virtual GPIO strategy is also used for the AXP288 PMIC in that
> > various control methods that are used to do power rail handling and
> > sensor reading/setting will touch GPIO fields defined under the PMIC
> > device. The GPIO fileds are only defined by the ACPI code while the
> > actual hardware doesn't really have a GPIO controller, but to make those
> > control method execution succeed, we have to install a GPIO handler for
> > the PMIC device handle. Since we do not need the virtual GPIO strategy,
> > we can simply do nothing in that handler.
> >
> > Signed-off-by: Aaron Lu <aaron.lu@intel.com>
> > ---
> >  drivers/acpi/pmic/intel_pmic_xpower.c | 30 ++++++++++++++++++++++++++----
> >  1 file changed, 26 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/acpi/pmic/intel_pmic_xpower.c b/drivers/acpi/pmic/intel_pmic_xpower.c
> > index 795ca073db08..9ec57ebd81c9 100644
> > --- a/drivers/acpi/pmic/intel_pmic_xpower.c
> > +++ b/drivers/acpi/pmic/intel_pmic_xpower.c
> > @@ -220,13 +220,35 @@ static struct intel_pmic_opregion_data intel_xpower_pmic_opregion_data = {
> >  	.thermal_table_count = ARRAY_SIZE(thermal_table),
> >  };
> >
> > +static acpi_status intel_xpower_pmic_gpio_handler(u32 function,
> > +		acpi_physical_address address, u32 bit_width, u64 *value,
> > +		void *handler_context, void *region_context)
> > +{
> > +	return AE_OK;
> > +}
> >
> >  static int intel_xpower_pmic_opregion_probe(struct platform_device *pdev)
> >  {
> > -	struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
> > -	return intel_pmic_install_opregion_handler(&pdev->dev,
> > -			ACPI_HANDLE(pdev->dev.parent), axp20x->regmap,
> > -			&intel_xpower_pmic_opregion_data);
> > +	struct device *parent = pdev->dev.parent;
> > +	struct axp20x_dev *axp20x = dev_get_drvdata(parent);
> > +	acpi_status status;
> > +	int result;
> > +
> > +	status = acpi_install_address_space_handler(ACPI_HANDLE(parent),
> > +			ACPI_ADR_SPACE_GPIO, intel_xpower_pmic_gpio_handler,
> > +			NULL, NULL);
> > +	if (ACPI_FAILURE(status))
> > +		return -ENODEV;
> > +
> > +	result = intel_pmic_install_opregion_handler(&pdev->dev,
> > +					ACPI_HANDLE(parent), axp20x->regmap,
> > +					&intel_xpower_pmic_opregion_data);
> > +	if (result)
> > +		acpi_remove_address_space_handler(ACPI_HANDLE(parent),
> > +						  ACPI_ADR_SPACE_GPIO,
> > +						  intel_xpower_pmic_gpio_handler);
> > +
> > +	return result;
> >  }
> >
> >  static struct platform_driver intel_xpower_pmic_opregion_driver = {
> >
> 
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.

WARNING: multiple messages have this Message-ID (diff)
From: "Zheng, Lv" <lv.zheng@intel.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	"Lu, Aaron" <aaron.lu@intel.com>
Cc: Lee Jones <lee.jones@linaro.org>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	"Iyer, Yegnesh S" <yegnesh.s.iyer@intel.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v3 updated 3/3] ACPI / PMIC: AXP288: support virtual GPIO in ACPI table
Date: Tue, 25 Nov 2014 01:44:28 +0000	[thread overview]
Message-ID: <1AE640813FDE7649BE1B193DEA596E88026A4A7C@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <2204417.orosXAozvY@vostro.rjw.lan>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 4671 bytes --]

Hi,

> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> Sent: Monday, November 24, 2014 11:20 PM
> Lv
> Subject: Re: [PATCH v3 updated 3/3] ACPI / PMIC: AXP288: support virtual GPIO in ACPI table
> 
> On Monday, November 24, 2014 05:32:33 PM Aaron Lu wrote:
> > On 11/24/2014 09:06 AM, Rafael J. Wysocki wrote:
> > > On Friday, November 21, 2014 03:11:51 PM Aaron Lu wrote:
> > >> +	if (!result) {
> > >> +		status = acpi_install_address_space_handler(
> > >> +				ACPI_HANDLE(parent), ACPI_ADR_SPACE_GPIO,
> > >> +				intel_xpower_pmic_gpio_handler, NULL, NULL);
> > >
> > > So here we have a problem, because we can't unregister the opregion handler
> > > registered above if this fails.  Not nice.
> >
> > I'm not correct in the cover letter, the actual problem with operation
> > region remove is with module unload, it happens like this:
> >
> > The acpi_remove_address_space_handler doesn't wait for the current
> > running handler to return, so if we call
> > acpi_remove_address_space_handler in a module's exit function, the
> > handler's memory will be freed and the running handler will access to
> > a no longer valid memory place.
> >
> > So as long as we can make sure the handler will not go away from the
> > memory, we are safe.
> 
> This only means that address space handlers cannot be removed from kernel
> modules.
> 
> Lv was trying to add a wrapper for that some time ago, maybe it's a good
> idea to revive that?

I may fix the issue in ACPICA, but it looks like that it will cost time to discuss.
So I also think it is better to take the wrapper now.
I'll hand the patch to Aaron to let him do a test on it before posting it again.

Thanks and best regards
-Lv

> > With this said, the updated patch is here:
> >
> > From: Aaron Lu <aaron.lu@intel.com>
> > Date: Mon, 20 Oct 2014 17:06:20 +0800
> > Subject: [PATCH 3/3] ACPI / PMIC: AXP288: support virtual GPIO in ACPI table
> >
> > The same virtual GPIO strategy is also used for the AXP288 PMIC in that
> > various control methods that are used to do power rail handling and
> > sensor reading/setting will touch GPIO fields defined under the PMIC
> > device. The GPIO fileds are only defined by the ACPI code while the
> > actual hardware doesn't really have a GPIO controller, but to make those
> > control method execution succeed, we have to install a GPIO handler for
> > the PMIC device handle. Since we do not need the virtual GPIO strategy,
> > we can simply do nothing in that handler.
> >
> > Signed-off-by: Aaron Lu <aaron.lu@intel.com>
> > ---
> >  drivers/acpi/pmic/intel_pmic_xpower.c | 30 ++++++++++++++++++++++++++----
> >  1 file changed, 26 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/acpi/pmic/intel_pmic_xpower.c b/drivers/acpi/pmic/intel_pmic_xpower.c
> > index 795ca073db08..9ec57ebd81c9 100644
> > --- a/drivers/acpi/pmic/intel_pmic_xpower.c
> > +++ b/drivers/acpi/pmic/intel_pmic_xpower.c
> > @@ -220,13 +220,35 @@ static struct intel_pmic_opregion_data intel_xpower_pmic_opregion_data = {
> >  	.thermal_table_count = ARRAY_SIZE(thermal_table),
> >  };
> >
> > +static acpi_status intel_xpower_pmic_gpio_handler(u32 function,
> > +		acpi_physical_address address, u32 bit_width, u64 *value,
> > +		void *handler_context, void *region_context)
> > +{
> > +	return AE_OK;
> > +}
> >
> >  static int intel_xpower_pmic_opregion_probe(struct platform_device *pdev)
> >  {
> > -	struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
> > -	return intel_pmic_install_opregion_handler(&pdev->dev,
> > -			ACPI_HANDLE(pdev->dev.parent), axp20x->regmap,
> > -			&intel_xpower_pmic_opregion_data);
> > +	struct device *parent = pdev->dev.parent;
> > +	struct axp20x_dev *axp20x = dev_get_drvdata(parent);
> > +	acpi_status status;
> > +	int result;
> > +
> > +	status = acpi_install_address_space_handler(ACPI_HANDLE(parent),
> > +			ACPI_ADR_SPACE_GPIO, intel_xpower_pmic_gpio_handler,
> > +			NULL, NULL);
> > +	if (ACPI_FAILURE(status))
> > +		return -ENODEV;
> > +
> > +	result = intel_pmic_install_opregion_handler(&pdev->dev,
> > +					ACPI_HANDLE(parent), axp20x->regmap,
> > +					&intel_xpower_pmic_opregion_data);
> > +	if (result)
> > +		acpi_remove_address_space_handler(ACPI_HANDLE(parent),
> > +						  ACPI_ADR_SPACE_GPIO,
> > +						  intel_xpower_pmic_gpio_handler);
> > +
> > +	return result;
> >  }
> >
> >  static struct platform_driver intel_xpower_pmic_opregion_driver = {
> >
> 
> --
> I speak only for myself.
> Rafael J. Wysocki, Intel Open Source Technology Center.
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

WARNING: multiple messages have this Message-ID (diff)
From: "Zheng, Lv" <lv.zheng@intel.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	"Lu, Aaron" <aaron.lu@intel.com>
Cc: Lee Jones <lee.jones@linaro.org>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	"Iyer, Yegnesh S" <yegnesh.s.iyer@intel.com>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v3 updated 3/3] ACPI / PMIC: AXP288: support virtual GPIO in ACPI table
Date: Tue, 25 Nov 2014 01:44:28 +0000	[thread overview]
Message-ID: <1AE640813FDE7649BE1B193DEA596E88026A4A7C@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <2204417.orosXAozvY@vostro.rjw.lan>

SGksDQoNCj4gRnJvbTogUmFmYWVsIEouIFd5c29ja2kgW21haWx0bzpyandAcmp3eXNvY2tpLm5l
dF0NCj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAyNCwgMjAxNCAxMToyMCBQTQ0KPiBMdg0KPiBT
dWJqZWN0OiBSZTogW1BBVENIIHYzIHVwZGF0ZWQgMy8zXSBBQ1BJIC8gUE1JQzogQVhQMjg4OiBz
dXBwb3J0IHZpcnR1YWwgR1BJTyBpbiBBQ1BJIHRhYmxlDQo+IA0KPiBPbiBNb25kYXksIE5vdmVt
YmVyIDI0LCAyMDE0IDA1OjMyOjMzIFBNIEFhcm9uIEx1IHdyb3RlOg0KPiA+IE9uIDExLzI0LzIw
MTQgMDk6MDYgQU0sIFJhZmFlbCBKLiBXeXNvY2tpIHdyb3RlOg0KPiA+ID4gT24gRnJpZGF5LCBO
b3ZlbWJlciAyMSwgMjAxNCAwMzoxMTo1MSBQTSBBYXJvbiBMdSB3cm90ZToNCj4gPiA+PiArCWlm
ICghcmVzdWx0KSB7DQo+ID4gPj4gKwkJc3RhdHVzID0gYWNwaV9pbnN0YWxsX2FkZHJlc3Nfc3Bh
Y2VfaGFuZGxlcigNCj4gPiA+PiArCQkJCUFDUElfSEFORExFKHBhcmVudCksIEFDUElfQURSX1NQ
QUNFX0dQSU8sDQo+ID4gPj4gKwkJCQlpbnRlbF94cG93ZXJfcG1pY19ncGlvX2hhbmRsZXIsIE5V
TEwsIE5VTEwpOw0KPiA+ID4NCj4gPiA+IFNvIGhlcmUgd2UgaGF2ZSBhIHByb2JsZW0sIGJlY2F1
c2Ugd2UgY2FuJ3QgdW5yZWdpc3RlciB0aGUgb3ByZWdpb24gaGFuZGxlcg0KPiA+ID4gcmVnaXN0
ZXJlZCBhYm92ZSBpZiB0aGlzIGZhaWxzLiAgTm90IG5pY2UuDQo+ID4NCj4gPiBJJ20gbm90IGNv
cnJlY3QgaW4gdGhlIGNvdmVyIGxldHRlciwgdGhlIGFjdHVhbCBwcm9ibGVtIHdpdGggb3BlcmF0
aW9uDQo+ID4gcmVnaW9uIHJlbW92ZSBpcyB3aXRoIG1vZHVsZSB1bmxvYWQsIGl0IGhhcHBlbnMg
bGlrZSB0aGlzOg0KPiA+DQo+ID4gVGhlIGFjcGlfcmVtb3ZlX2FkZHJlc3Nfc3BhY2VfaGFuZGxl
ciBkb2Vzbid0IHdhaXQgZm9yIHRoZSBjdXJyZW50DQo+ID4gcnVubmluZyBoYW5kbGVyIHRvIHJl
dHVybiwgc28gaWYgd2UgY2FsbA0KPiA+IGFjcGlfcmVtb3ZlX2FkZHJlc3Nfc3BhY2VfaGFuZGxl
ciBpbiBhIG1vZHVsZSdzIGV4aXQgZnVuY3Rpb24sIHRoZQ0KPiA+IGhhbmRsZXIncyBtZW1vcnkg
d2lsbCBiZSBmcmVlZCBhbmQgdGhlIHJ1bm5pbmcgaGFuZGxlciB3aWxsIGFjY2VzcyB0bw0KPiA+
IGEgbm8gbG9uZ2VyIHZhbGlkIG1lbW9yeSBwbGFjZS4NCj4gPg0KPiA+IFNvIGFzIGxvbmcgYXMg
d2UgY2FuIG1ha2Ugc3VyZSB0aGUgaGFuZGxlciB3aWxsIG5vdCBnbyBhd2F5IGZyb20gdGhlDQo+
ID4gbWVtb3J5LCB3ZSBhcmUgc2FmZS4NCj4gDQo+IFRoaXMgb25seSBtZWFucyB0aGF0IGFkZHJl
c3Mgc3BhY2UgaGFuZGxlcnMgY2Fubm90IGJlIHJlbW92ZWQgZnJvbSBrZXJuZWwNCj4gbW9kdWxl
cy4NCj4gDQo+IEx2IHdhcyB0cnlpbmcgdG8gYWRkIGEgd3JhcHBlciBmb3IgdGhhdCBzb21lIHRp
bWUgYWdvLCBtYXliZSBpdCdzIGEgZ29vZA0KPiBpZGVhIHRvIHJldml2ZSB0aGF0Pw0KDQpJIG1h
eSBmaXggdGhlIGlzc3VlIGluIEFDUElDQSwgYnV0IGl0IGxvb2tzIGxpa2UgdGhhdCBpdCB3aWxs
IGNvc3QgdGltZSB0byBkaXNjdXNzLg0KU28gSSBhbHNvIHRoaW5rIGl0IGlzIGJldHRlciB0byB0
YWtlIHRoZSB3cmFwcGVyIG5vdy4NCkknbGwgaGFuZCB0aGUgcGF0Y2ggdG8gQWFyb24gdG8gbGV0
IGhpbSBkbyBhIHRlc3Qgb24gaXQgYmVmb3JlIHBvc3RpbmcgaXQgYWdhaW4uDQoNClRoYW5rcyBh
bmQgYmVzdCByZWdhcmRzDQotTHYNCg0KPiA+IFdpdGggdGhpcyBzYWlkLCB0aGUgdXBkYXRlZCBw
YXRjaCBpcyBoZXJlOg0KPiA+DQo+ID4gRnJvbTogQWFyb24gTHUgPGFhcm9uLmx1QGludGVsLmNv
bT4NCj4gPiBEYXRlOiBNb24sIDIwIE9jdCAyMDE0IDE3OjA2OjIwICswODAwDQo+ID4gU3ViamVj
dDogW1BBVENIIDMvM10gQUNQSSAvIFBNSUM6IEFYUDI4ODogc3VwcG9ydCB2aXJ0dWFsIEdQSU8g
aW4gQUNQSSB0YWJsZQ0KPiA+DQo+ID4gVGhlIHNhbWUgdmlydHVhbCBHUElPIHN0cmF0ZWd5IGlz
IGFsc28gdXNlZCBmb3IgdGhlIEFYUDI4OCBQTUlDIGluIHRoYXQNCj4gPiB2YXJpb3VzIGNvbnRy
b2wgbWV0aG9kcyB0aGF0IGFyZSB1c2VkIHRvIGRvIHBvd2VyIHJhaWwgaGFuZGxpbmcgYW5kDQo+
ID4gc2Vuc29yIHJlYWRpbmcvc2V0dGluZyB3aWxsIHRvdWNoIEdQSU8gZmllbGRzIGRlZmluZWQg
dW5kZXIgdGhlIFBNSUMNCj4gPiBkZXZpY2UuIFRoZSBHUElPIGZpbGVkcyBhcmUgb25seSBkZWZp
bmVkIGJ5IHRoZSBBQ1BJIGNvZGUgd2hpbGUgdGhlDQo+ID4gYWN0dWFsIGhhcmR3YXJlIGRvZXNu
J3QgcmVhbGx5IGhhdmUgYSBHUElPIGNvbnRyb2xsZXIsIGJ1dCB0byBtYWtlIHRob3NlDQo+ID4g
Y29udHJvbCBtZXRob2QgZXhlY3V0aW9uIHN1Y2NlZWQsIHdlIGhhdmUgdG8gaW5zdGFsbCBhIEdQ
SU8gaGFuZGxlciBmb3INCj4gPiB0aGUgUE1JQyBkZXZpY2UgaGFuZGxlLiBTaW5jZSB3ZSBkbyBu
b3QgbmVlZCB0aGUgdmlydHVhbCBHUElPIHN0cmF0ZWd5LA0KPiA+IHdlIGNhbiBzaW1wbHkgZG8g
bm90aGluZyBpbiB0aGF0IGhhbmRsZXIuDQo+ID4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBBYXJvbiBM
dSA8YWFyb24ubHVAaW50ZWwuY29tPg0KPiA+IC0tLQ0KPiA+ICBkcml2ZXJzL2FjcGkvcG1pYy9p
bnRlbF9wbWljX3hwb3dlci5jIHwgMzAgKysrKysrKysrKysrKysrKysrKysrKysrKystLS0tDQo+
ID4gIDEgZmlsZSBjaGFuZ2VkLCAyNiBpbnNlcnRpb25zKCspLCA0IGRlbGV0aW9ucygtKQ0KPiA+
DQo+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvYWNwaS9wbWljL2ludGVsX3BtaWNfeHBvd2VyLmMg
Yi9kcml2ZXJzL2FjcGkvcG1pYy9pbnRlbF9wbWljX3hwb3dlci5jDQo+ID4gaW5kZXggNzk1Y2Ew
NzNkYjA4Li45ZWM1N2ViZDgxYzkgMTAwNjQ0DQo+ID4gLS0tIGEvZHJpdmVycy9hY3BpL3BtaWMv
aW50ZWxfcG1pY194cG93ZXIuYw0KPiA+ICsrKyBiL2RyaXZlcnMvYWNwaS9wbWljL2ludGVsX3Bt
aWNfeHBvd2VyLmMNCj4gPiBAQCAtMjIwLDEzICsyMjAsMzUgQEAgc3RhdGljIHN0cnVjdCBpbnRl
bF9wbWljX29wcmVnaW9uX2RhdGEgaW50ZWxfeHBvd2VyX3BtaWNfb3ByZWdpb25fZGF0YSA9IHsN
Cj4gPiAgCS50aGVybWFsX3RhYmxlX2NvdW50ID0gQVJSQVlfU0laRSh0aGVybWFsX3RhYmxlKSwN
Cj4gPiAgfTsNCj4gPg0KPiA+ICtzdGF0aWMgYWNwaV9zdGF0dXMgaW50ZWxfeHBvd2VyX3BtaWNf
Z3Bpb19oYW5kbGVyKHUzMiBmdW5jdGlvbiwNCj4gPiArCQlhY3BpX3BoeXNpY2FsX2FkZHJlc3Mg
YWRkcmVzcywgdTMyIGJpdF93aWR0aCwgdTY0ICp2YWx1ZSwNCj4gPiArCQl2b2lkICpoYW5kbGVy
X2NvbnRleHQsIHZvaWQgKnJlZ2lvbl9jb250ZXh0KQ0KPiA+ICt7DQo+ID4gKwlyZXR1cm4gQUVf
T0s7DQo+ID4gK30NCj4gPg0KPiA+ICBzdGF0aWMgaW50IGludGVsX3hwb3dlcl9wbWljX29wcmVn
aW9uX3Byb2JlKHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKnBkZXYpDQo+ID4gIHsNCj4gPiAtCXN0
cnVjdCBheHAyMHhfZGV2ICpheHAyMHggPSBkZXZfZ2V0X2RydmRhdGEocGRldi0+ZGV2LnBhcmVu
dCk7DQo+ID4gLQlyZXR1cm4gaW50ZWxfcG1pY19pbnN0YWxsX29wcmVnaW9uX2hhbmRsZXIoJnBk
ZXYtPmRldiwNCj4gPiAtCQkJQUNQSV9IQU5ETEUocGRldi0+ZGV2LnBhcmVudCksIGF4cDIweC0+
cmVnbWFwLA0KPiA+IC0JCQkmaW50ZWxfeHBvd2VyX3BtaWNfb3ByZWdpb25fZGF0YSk7DQo+ID4g
KwlzdHJ1Y3QgZGV2aWNlICpwYXJlbnQgPSBwZGV2LT5kZXYucGFyZW50Ow0KPiA+ICsJc3RydWN0
IGF4cDIweF9kZXYgKmF4cDIweCA9IGRldl9nZXRfZHJ2ZGF0YShwYXJlbnQpOw0KPiA+ICsJYWNw
aV9zdGF0dXMgc3RhdHVzOw0KPiA+ICsJaW50IHJlc3VsdDsNCj4gPiArDQo+ID4gKwlzdGF0dXMg
PSBhY3BpX2luc3RhbGxfYWRkcmVzc19zcGFjZV9oYW5kbGVyKEFDUElfSEFORExFKHBhcmVudCks
DQo+ID4gKwkJCUFDUElfQURSX1NQQUNFX0dQSU8sIGludGVsX3hwb3dlcl9wbWljX2dwaW9faGFu
ZGxlciwNCj4gPiArCQkJTlVMTCwgTlVMTCk7DQo+ID4gKwlpZiAoQUNQSV9GQUlMVVJFKHN0YXR1
cykpDQo+ID4gKwkJcmV0dXJuIC1FTk9ERVY7DQo+ID4gKw0KPiA+ICsJcmVzdWx0ID0gaW50ZWxf
cG1pY19pbnN0YWxsX29wcmVnaW9uX2hhbmRsZXIoJnBkZXYtPmRldiwNCj4gPiArCQkJCQlBQ1BJ
X0hBTkRMRShwYXJlbnQpLCBheHAyMHgtPnJlZ21hcCwNCj4gPiArCQkJCQkmaW50ZWxfeHBvd2Vy
X3BtaWNfb3ByZWdpb25fZGF0YSk7DQo+ID4gKwlpZiAocmVzdWx0KQ0KPiA+ICsJCWFjcGlfcmVt
b3ZlX2FkZHJlc3Nfc3BhY2VfaGFuZGxlcihBQ1BJX0hBTkRMRShwYXJlbnQpLA0KPiA+ICsJCQkJ
CQkgIEFDUElfQURSX1NQQUNFX0dQSU8sDQo+ID4gKwkJCQkJCSAgaW50ZWxfeHBvd2VyX3BtaWNf
Z3Bpb19oYW5kbGVyKTsNCj4gPiArDQo+ID4gKwlyZXR1cm4gcmVzdWx0Ow0KPiA+ICB9DQo+ID4N
Cj4gPiAgc3RhdGljIHN0cnVjdCBwbGF0Zm9ybV9kcml2ZXIgaW50ZWxfeHBvd2VyX3BtaWNfb3By
ZWdpb25fZHJpdmVyID0gew0KPiA+DQo+IA0KPiAtLQ0KPiBJIHNwZWFrIG9ubHkgZm9yIG15c2Vs
Zi4NCj4gUmFmYWVsIEouIFd5c29ja2ksIEludGVsIE9wZW4gU291cmNlIFRlY2hub2xvZ3kgQ2Vu
dGVyLg0K

  parent reply	other threads:[~2014-11-25  1:44 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-21  7:11 [PATCH v3 0/3] Support PMIC operation region for CrystalCove and XPower Aaron Lu
2014-11-21  7:11 ` Aaron Lu
2014-11-21  7:11 ` [PATCH v3 2/3] ACPI / PMIC: support PMIC operation region for XPower AXP288 Aaron Lu
2014-11-24  1:04   ` Rafael J. Wysocki
2014-11-24  9:24     ` [PATCH v3 updated " Aaron Lu
2014-11-21  7:11 ` [PATCH v3 3/3] ACPI / PMIC: AXP288: support virtual GPIO in ACPI table Aaron Lu
2014-11-24  1:06   ` Rafael J. Wysocki
2014-11-24  6:01     ` Aaron Lu
     [not found]     ` <1648486.coeVgHKNdn-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>
2014-11-24  9:32       ` [PATCH v3 updated " Aaron Lu
2014-11-24  9:32         ` Aaron Lu
     [not found]         ` <5472FB31.8000408-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2014-11-24 15:19           ` Rafael J. Wysocki
2014-11-24 15:19             ` Rafael J. Wysocki
     [not found]             ` <2204417.orosXAozvY-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>
2014-11-25  1:44               ` Zheng, Lv [this message]
2014-11-25  1:44                 ` Zheng, Lv
2014-11-25  1:44                 ` Zheng, Lv
2014-11-25 12:01             ` Aaron Lu
     [not found]               ` <54746FA2.9030408-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2014-11-25 20:34                 ` Rafael J. Wysocki
2014-11-25 20:34                   ` Rafael J. Wysocki
     [not found] ` <1416553911-22990-1-git-send-email-aaron.lu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2014-11-21  7:11   ` [PATCH v3 1/3] ACPI / PMIC: support PMIC operation region for CrystalCove Aaron Lu
2014-11-21  7:11     ` Aaron Lu
2014-11-24  0:59     ` Rafael J. Wysocki
2014-11-24  5:55       ` Aaron Lu
2014-11-24  9:21       ` [PATCH v3 1/3 updated] " Aaron Lu
2014-11-25  1:47   ` [PATCH v3 0/3] Support PMIC operation region for CrystalCove and XPower Rafael J. Wysocki
2014-11-25  1:47     ` Rafael J. Wysocki
     [not found]     ` <1987897.BgdIEqPdlH-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>
2014-11-25 11:52       ` Aaron Lu
2014-11-25 11:52         ` Aaron Lu
2014-11-25 20:41         ` Rafael J. Wysocki
     [not found]           ` <3232241.9QsNPyI1Av-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>
2014-11-26  2:35             ` Aaron Lu
2014-11-26  2:35               ` Aaron Lu
     [not found]               ` <54753C7E.8030503-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2014-11-26  2:44                 ` Aaron Lu
2014-11-26  2:44                   ` Aaron Lu
     [not found]                   ` <54753E92.2010609-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2014-11-26 23:02                     ` Rafael J. Wysocki
2014-11-26 23:02                       ` 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=1AE640813FDE7649BE1B193DEA596E88026A4A7C@SHSMSX101.ccr.corp.intel.com \
    --to=lv.zheng-ral2jqcrhueavxtiumwx3w@public.gmane.org \
    --cc=aaron.lu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=jacob.jun.pan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    --cc=lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org \
    --cc=yegnesh.s.iyer-ral2JQCrhuEAvxtiuMwx3w@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.