On Tue, Feb 03, 2015 at 05:55:25PM +0800, Ken Xue wrote:
> On Tue, 2015-02-03 at 11:53 +0200, mika.westerb...@linux.intel.com
> wrote:
> > On Tue, Feb 03, 2015 at 09:04:55AM +0800, Ken Xue wrote:
> > > as you said, platform_drv_probe calls dev_pm_domain_attach(). but
> > > platform_drv_probe just
On Tue, 2015-02-03 at 11:53 +0200, mika.westerb...@linux.intel.com
wrote:
> On Tue, Feb 03, 2015 at 09:04:55AM +0800, Ken Xue wrote:
> > as you said, platform_drv_probe calls dev_pm_domain_attach(). but
> > platform_drv_probe just is a default probe routine. Not all platform
> > device drivers use
On Tue, Feb 03, 2015 at 09:04:55AM +0800, Ken Xue wrote:
> as you said, platform_drv_probe calls dev_pm_domain_attach(). but
> platform_drv_probe just is a default probe routine. Not all platform
> device drivers use this probe routine. so, codes here may be still
> necessary.
Are you saying that
On Tue, Feb 03, 2015 at 05:55:25PM +0800, Ken Xue wrote:
On Tue, 2015-02-03 at 11:53 +0200, mika.westerb...@linux.intel.com
wrote:
On Tue, Feb 03, 2015 at 09:04:55AM +0800, Ken Xue wrote:
as you said, platform_drv_probe calls dev_pm_domain_attach(). but
platform_drv_probe just is a
On Tue, Feb 03, 2015 at 09:04:55AM +0800, Ken Xue wrote:
as you said, platform_drv_probe calls dev_pm_domain_attach(). but
platform_drv_probe just is a default probe routine. Not all platform
device drivers use this probe routine. so, codes here may be still
necessary.
Are you saying that for
On Tue, 2015-02-03 at 11:53 +0200, mika.westerb...@linux.intel.com
wrote:
On Tue, Feb 03, 2015 at 09:04:55AM +0800, Ken Xue wrote:
as you said, platform_drv_probe calls dev_pm_domain_attach(). but
platform_drv_probe just is a default probe routine. Not all platform
device drivers use this
On Mon, 2015-02-02 at 15:03 +0200, mika.westerb...@linux.intel.com
wrote:
> On Mon, Feb 02, 2015 at 05:50:52PM +0800, Ken Xue wrote:
> > >From b9654ecbfaebde00aee746a024eec9fe8de24b97 Mon Sep 17 00:00:00 2001
> > From: Ken Xue
> > Date: Mon, 2 Feb 2015 17:32:24 +0800
> > Subject: [PATCH] This new
On Mon, Feb 02, 2015 at 05:50:52PM +0800, Ken Xue wrote:
> >From b9654ecbfaebde00aee746a024eec9fe8de24b97 Mon Sep 17 00:00:00 2001
> From: Ken Xue
> Date: Mon, 2 Feb 2015 17:32:24 +0800
> Subject: [PATCH] This new feature is to interpret AMD specific ACPI device to
> platform device such as I2C,
>From b9654ecbfaebde00aee746a024eec9fe8de24b97 Mon Sep 17 00:00:00 2001
From: Ken Xue
Date: Mon, 2 Feb 2015 17:32:24 +0800
Subject: [PATCH] This new feature is to interpret AMD specific ACPI device to
platform device such as I2C, UART found on AMD CZ and later chipsets. It
based on example
On Mon, 2015-02-02 at 15:03 +0200, mika.westerb...@linux.intel.com
wrote:
On Mon, Feb 02, 2015 at 05:50:52PM +0800, Ken Xue wrote:
From b9654ecbfaebde00aee746a024eec9fe8de24b97 Mon Sep 17 00:00:00 2001
From: Ken Xue ken@amd.com
Date: Mon, 2 Feb 2015 17:32:24 +0800
Subject: [PATCH]
From b9654ecbfaebde00aee746a024eec9fe8de24b97 Mon Sep 17 00:00:00 2001
From: Ken Xue ken@amd.com
Date: Mon, 2 Feb 2015 17:32:24 +0800
Subject: [PATCH] This new feature is to interpret AMD specific ACPI device to
platform device such as I2C, UART found on AMD CZ and later chipsets. It
based
On Mon, Feb 02, 2015 at 05:50:52PM +0800, Ken Xue wrote:
From b9654ecbfaebde00aee746a024eec9fe8de24b97 Mon Sep 17 00:00:00 2001
From: Ken Xue ken@amd.com
Date: Mon, 2 Feb 2015 17:32:24 +0800
Subject: [PATCH] This new feature is to interpret AMD specific ACPI device to
platform device
12 matches
Mail list logo
