Skip to contentSkip to conversation

x86/platform/intel-mid: Retrofit pci_platform_pm_ops

PATCH Superseded Lukas Wunner 2 participants 11 messages Oct 6, 2016 – Oct 10, 2016

Subsystems (3)

v1 of 3 Superseded Latest is v3 →

lore
Share & tools
lore
#0 lore raw

cover x86/platform/intel-mid: Retrofit pci_platform_pm_ops

Somehow it went completely under my radar that v4.8 added another struct pci_platform_pm_ops for Intel Mobile Internet Devices.

There's a commit queued for v4.9 on Bjorn's pci/pm branch which adds a mandatory ->get_power hook to pci_platform_pm_ops and implements it for acpi_pci_platform_pm, but not mid_pci_platform_pm.

The following patch fixes that. It's not a build issue, the missing hook in mid_pci_platform_pm only becomes a problem at runtime.

@Andy: Could you look over this and provide an ack? I do not have an Intel MID so I was only able to compile-test the patch.

The ->get_power hook is currently only called to update a device's current_state after resume (both at runtime and after system sleep) and after changing its power state using the platform in pci_platform_power_transition(). The result of the ->get_power hook is ignored unless it's D3cold. Since intel-mid PCI devices can only be suspended to D3hot, the return value is irrelevant on this platform, the hook just needs to be present to make pci_set_platform_pm() happy.

If you want to test the patch, you need to apply it either on Bjorn's pci/pm branch or linux-next:
http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/pm

Thanks,

Lukas

Lukas Wunner (1):
x86/platform/intel-mid: Retrofit pci_platform_pm_ops ->get_power hook

 arch/x86/include/asm/intel-mid.h  |  1 +
 arch/x86/platform/intel-mid/pwr.c | 19 +++++++++++++++++++
 drivers/pci/pci-mid.c             |  6 ++++++
 3 files changed, 26 insertions(+)
Signature · 1 line
2.9.3
#1 lore raw

PATCH 1/1 x86/platform/intel-mid: Retrofit pci_platform_pm_ops ->get_power hook

Commit cc7cc02bada8 ("PCI: Query platform firmware for device power state") augmented struct pci_platform_pm_ops with a ->get_power hook and implemented it for acpi_pci_platform_pm, the only pci_platform_pm_ops existing till v4.7.

However v4.8 introduced another pci_platform_pm_ops for Intel Mobile Internet Devices with commit 5823d0893ec2 ("x86/platform/intel-mid: Add Power Management Unit driver"). It is missing the ->get_power hook, which is fatal since pci_set_platform_pm() enforces its presence.

Retrofit mid_pci_platform_pm with the missing callback to fix the breakage.

---
 arch/x86/include/asm/intel-mid.h  |  1 +
 arch/x86/platform/intel-mid/pwr.c | 19 +++++++++++++++++++
 drivers/pci/pci-mid.c             |  6 ++++++
 3 files changed, 26 insertions(+)
arch/x86/include/asm/intel-mid.h +1 -0
index 9d6b097..4511c10 100644
@@ -17,6 +17,7 @@
 
 extern int intel_mid_pci_init(void);
 extern int intel_mid_pci_set_power_state(struct pci_dev *pdev, pci_power_t state);
+extern pci_power_t intel_mid_pci_get_power_state(struct pci_dev *pdev);
 
 #define INTEL_MID_PWR_LSS_OFFSET	4
 #define INTEL_MID_PWR_LSS_TYPE		(1 << 7)
arch/x86/platform/intel-mid/pwr.c +19 -0
index c901a34..214bc99 100644
@@ -260,6 +260,25 @@ int intel_mid_pci_set_power_state(struct pci_dev *pdev, pci_power_t state)
 }
 EXPORT_SYMBOL_GPL(intel_mid_pci_set_power_state);
 
+pci_power_t intel_mid_pci_get_power_state(struct pci_dev *pdev)
+{
+	struct mid_pwr *pwr = midpwr;
+	int id, reg, bit;
+	u32 power;
+
+	if (!pwr || !pwr->available)
+		return PCI_UNKNOWN;
+
+	id = intel_mid_pwr_get_lss_id(pdev);
+	if (id < 0)
+		return PCI_UNKNOWN;
+
+	reg = (id * LSS_PWS_BITS) / 32;
+	bit = (id * LSS_PWS_BITS) % 32;
+	power = mid_pwr_get_state(pwr, reg);
+	return (power >> bit) & 3;
+}
+
 int intel_mid_pwr_get_lss_id(struct pci_dev *pdev)
 {
 	int vndr;
drivers/pci/pci-mid.c +6 -0
index c878aa7..a8b52dc 100644
@@ -29,6 +29,11 @@ static int mid_pci_set_power_state(struct pci_dev *pdev, pci_power_t state)
 	return intel_mid_pci_set_power_state(pdev, state);
 }
 
+static pci_power_t mid_pci_get_power_state(struct pci_dev *pdev)
+{
+	return intel_mid_pci_get_power_state(pdev);
+}
+
 static pci_power_t mid_pci_choose_state(struct pci_dev *pdev)
 {
 	return PCI_D3hot;
@@ -52,6 +57,7 @@ static bool mid_pci_need_resume(struct pci_dev *dev)
 static struct pci_platform_pm_ops mid_pci_platform_pm = {
 	.is_manageable	= mid_pci_power_manageable,
 	.set_state	= mid_pci_set_power_state,
+	.get_state	= mid_pci_get_power_state,
 	.choose_state	= mid_pci_choose_state,
 	.sleep_wake	= mid_pci_sleep_wake,
 	.run_wake	= mid_pci_run_wake,
Signature · 1 line
2.9.3
#2 lore raw

Re: [PATCH 1/1] x86/platform/intel-mid: Retrofit pci_platform_pm_ops ->get_power hook

Quoted 6 lines · Lukas Wunner

Commit cc7cc02bada8 ("PCI: Query platform firmware for device power state") augmented struct pci_platform_pm_ops with a ->get_power hook and
implemented it for acpi_pci_platform_pm, the only pci_platform_pm_ops existing till v4.7.

Quoted 8 lines

However v4.8 introduced another pci_platform_pm_ops for Intel Mobile Internet Devices with commit 5823d0893ec2 ("x86/platform/intel-mid:
Add
Power Management Unit driver").  It is missing the ->get_power hook, which is fatal since pci_set_platform_pm() enforces its presence.

Retrofit mid_pci_platform_pm with the missing callback to fix the breakage.

Check comments below.

Quoted 7 lines
arch/x86/platform/intel-mid/pwr.c +0 -0
@@ -260,6 +260,25 @@ int intel_mid_pci_set_power_state(struct pci_dev
 *pdev, pci_power_t state)
  }
  EXPORT_SYMBOL_GPL(intel_mid_pci_set_power_state);

arch/x86/platform/intel-mid/pwr.c int intel_mid_pci_set_power_state(struct pci_dev *pdev, pci_power_t state) · line 270

Quoted 8 lines
arch/x86/platform/intel-mid/pwr.c +8 -0
+pci_power_t intel_mid_pci_get_power_state(struct pci_dev *pdev)
+{
+	struct mid_pwr *pwr = midpwr;
+	int id, reg, bit;
+	u32 power;
+
+	if (!pwr || !pwr->available)
+		return PCI_UNKNOWN;

I'm not sure it's a right value. In arch/x86/pci/intel_mid_pci.c we assign D3hot to PMCSR for all devices. I dunno how to proceed here, though your case works for me.

arch/x86/platform/intel-mid/pwr.c int intel_mid_pci_set_power_state(struct pci_dev *pdev, pci_power_t state) · line 274

Quoted 4 lines
arch/x86/platform/intel-mid/pwr.c +4 -0
+
+	id = intel_mid_pwr_get_lss_id(pdev);
+	if (id < 0)
+		return PCI_UNKNOWN;

Similar here, not all PCI devices are using PWRMU (or P-Unit, which support is absent) and might be AON, or be controllable via PMCSR only.

arch/x86/platform/intel-mid/pwr.c int intel_mid_pci_set_power_state(struct pci_dev *pdev, pci_power_t state) · line 279

Quoted 5 lines
arch/x86/platform/intel-mid/pwr.c +5 -0
+
+	reg = (id * LSS_PWS_BITS) / 32;
+	bit = (id * LSS_PWS_BITS) % 32;
+	power = mid_pwr_get_state(pwr, reg);
+	return (power >> bit) & 3;

Don't add sparse warnings:

        return (__force pci_power_t)((power >> bit) & 3);

Quoted 1 line

+}

Signature · 2 lines
Andy Shevchenko <[email protected]>
Intel Finland Oy
#3 lore raw

Re: [PATCH 1/1] x86/platform/intel-mid: Retrofit pci_platform_pm_ops ->get_power hook

Hi Andy,

thanks a lot for testing the patch!

Quoted 13 lines · Andy Shevchenko

arch/x86/platform/intel-mid/pwr.c int intel_mid_pci_set_power_state(struct pci_dev *pdev, pci_power_t state) · line 270

Quoted 8 lines · Lukas Wunner
arch/x86/platform/intel-mid/pwr.c +8 -0
+pci_power_t intel_mid_pci_get_power_state(struct pci_dev *pdev)
+{
+	struct mid_pwr *pwr = midpwr;
+	int id, reg, bit;
+	u32 power;
+
+	if (!pwr || !pwr->available)
+		return PCI_UNKNOWN;

I'm not sure it's a right value. In arch/x86/pci/intel_mid_pci.c we assign D3hot to PMCSR for all devices. I dunno how to proceed here, though your case works for me.

Generally returning PCI_UNKNOWN from the ->get_state hook is fine if the platform fails to determine the state. The ACPI equivalent acpi_pci_get_power_state() does this as well.

Quoted 8 lines

arch/x86/platform/intel-mid/pwr.c int intel_mid_pci_set_power_state(struct pci_dev *pdev, pci_power_t state) · line 274

Quoted 5 lines
arch/x86/platform/intel-mid/pwr.c +4 -0
+
+	id = intel_mid_pwr_get_lss_id(pdev);
+	if (id < 0)
+		return PCI_UNKNOWN;

Similar here, not all PCI devices are using PWRMU (or P-Unit, which support is absent) and might be AON, or be controllable via PMCSR only.

Hm, then mid_pci_power_manageable() is broken, you let it return true unconditionally. I'm not familiar at all with Intel MID devices, do you have a way to clearly identify if a PCI device is power managed by the PWRMU versus PMCSR? My guess is that at the very least, intel_mid_pwr_get_lss_id() needs to be called and false needs to be returned by mid_pci_power_manageable() if the return value is negative.

As said it's not a problem for the single existing caller of mid_pci_get_power_state(), which is pci_target_state(), since it only honors the return value if it's PCI_D3cold. Otherwise it defers to the PMCSR. The rationale is that reading the PMCSR is usually the most reliable way to determine the power state, but D3cold cannot be determined by reading the PMCSR.

What you say sounds to me like you need to amend the callbacks in mid_pci_platform_pm to differentiate between PWRMU-manageable versus non-PWRMU-manageable devices, but that's not specific to the single ->get_state callback added by this commit and can thus go into a separate commit.

Quoted 10 lines

arch/x86/platform/intel-mid/pwr.c int intel_mid_pci_set_power_state(struct pci_dev *pdev, pci_power_t state) · line 279

Quoted 6 lines
arch/x86/platform/intel-mid/pwr.c +5 -0
+
+	reg = (id * LSS_PWS_BITS) / 32;
+	bit = (id * LSS_PWS_BITS) % 32;
+	power = mid_pwr_get_state(pwr, reg);
+	return (power >> bit) & 3;

Don't add sparse warnings:

        return (__force pci_power_t)((power >> bit) & 3);

Okay, I'll fix this in v2.

Thanks again,

Lukas

#4 lore raw

Re: [PATCH 1/1] x86/platform/intel-mid: Retrofit pci_platform_pm_ops ->get_power hook

Quoted 37 lines · Lukas Wunner

Hi Andy,

thanks a lot for testing the patch!

Quoted 15 lines · Andy Shevchenko

arch/x86/platform/intel-mid/pwr.c int intel_mid_pci_set_power_state(struct pci_dev *pdev, pci_power_t state) · line 270

Quoted 9 lines · Lukas Wunner
arch/x86/platform/intel-mid/pwr.c +8 -0
+pci_power_t intel_mid_pci_get_power_state(struct pci_dev *pdev)
+{
+	struct mid_pwr *pwr = midpwr;
+	int id, reg, bit;
+	u32 power;
+
+	if (!pwr || !pwr->available)
+		return PCI_UNKNOWN;

I'm not sure it's a right value. In arch/x86/pci/intel_mid_pci.c we assign D3hot to PMCSR for all devices. I dunno how to proceed here, though your case works for me.

Generally returning PCI_UNKNOWN from the ->get_state hook is fine if the platform fails to determine the state.  The ACPI equivalent acpi_pci_get_power_state() does this as well.

Quoted 11 lines

arch/x86/platform/intel-mid/pwr.c int intel_mid_pci_set_power_state(struct pci_dev *pdev, pci_power_t state) · line 274

Quoted 7 lines
arch/x86/platform/intel-mid/pwr.c +4 -0
+
+	id = intel_mid_pwr_get_lss_id(pdev);
+	if (id < 0)
+		return PCI_UNKNOWN;

Similar here, not all PCI devices are using PWRMU (or P-Unit, which support is absent) and might be AON, or be controllable via PMCSR only.

Quoted 2 lines

Hm, then mid_pci_power_manageable() is broken, you let it return true unconditionally.

Till now it works for me and others who tested my code / patches, I would say "might be broken". I don't have [access to] all possible documentation that shed a light on this, so, let's stick on your version for now until some bug appears.

Quoted 6 lines

  I'm not familiar at all with Intel MID devices, do
you have a way to clearly identify if a PCI device is power managed by the PWRMU versus PMCSR?  My guess is that at the very least, intel_mid_pwr_get_lss_id() needs to be called and false needs to be returned by mid_pci_power_manageable() if the return value is negative.

PCI bus is kinda fake on those platforms (which implement SFI) and don't always follow [PCI] specification. The vendor register represents so called Logical Subsystem ID of the device in question. Some of them are related to PWRMU, some to P-Unit, some just has no such register.

In PWRMU/P-Unit cases PMCSR is present and writing to it is needed. For the rest I don't remember what is actual state, perhaps writing is just ignored and OS reads D0 all the time from it.

And I don't remember if P-Unit manageable devices require anything else than plain update of PMCSR.

Quoted 6 lines

As said it's not a problem for the single existing caller of mid_pci_get_power_state(), which is pci_target_state(), since it only honors the return value if it's PCI_D3cold. Otherwise it defers to the PMCSR.  The rationale is that reading the PMCSR is usually the most reliable way to determine the power state, but D3cold cannot be determined by reading the PMCSR.

Yep.

Quoted 6 lines

What you say sounds to me like you need to amend the callbacks in mid_pci_platform_pm to differentiate between PWRMU-manageable versus non-PWRMU-manageable devices, but that's not specific to the single ->get_state callback added by this commit and can thus go into a separate commit.

See above.

So, from PWRMU code the function behaves correctly for now. Whenever P- Unit support will be added the code will have to be modified accordingly.

P.S. Btw, Asus Zenfone 2 and Lenovo K80m phones are based on Intel Moorefield which is, AFAIK, latest [widely distributed] successor of Intel MID devices. I dunno if anyone inside or outside Intel ever tried [fresh] upstream kernels there.

Quoted 19 lines
Quoted 12 lines

arch/x86/platform/intel-mid/pwr.c int intel_mid_pci_set_power_state(struct pci_dev *pdev, pci_power_t state) · line 279

Quoted 9 lines
arch/x86/platform/intel-mid/pwr.c +5 -0
+
+	reg = (id * LSS_PWS_BITS) / 32;
+	bit = (id * LSS_PWS_BITS) % 32;
+	power = mid_pwr_get_state(pwr, reg);
+	return (power >> bit) & 3;

Don't add sparse warnings:

Quoted 1 line

        return (__force pci_power_t)((power >> bit) & 3);

Okay, I'll fix this in v2.

Thanks again,

Lukas

Signature · 2 lines
Andy Shevchenko <[email protected]>
Intel Finland Oy
#5 lore raw

Re: [PATCH 1/1] x86/platform/intel-mid: Retrofit pci_platform_pm_ops ->get_power hook

Quoted 8 lines · Andy Shevchenko
Quoted 6 lines · Lukas Wunner

  I'm not familiar at all with Intel MID devices, do
you have a way to clearly identify if a PCI device is power managed by the PWRMU versus PMCSR?  My guess is that at the very least, intel_mid_pwr_get_lss_id() needs to be called and false needs to be returned by mid_pci_power_manageable() if the return value is negative.

Quoted 8 lines

PCI bus is kinda fake on those platforms (which implement SFI) and don't always follow [PCI] specification. The vendor register represents so called Logical Subsystem ID of the device in question. Some of them are related to PWRMU, some to P-Unit, some just has no such register.

In PWRMU/P-Unit cases PMCSR is present and writing to it is needed. For the rest I don't remember what is actual state, perhaps writing is just ignored and OS reads D0 all the time from it.

For devices with PM mechanisms not covered by the standard PCI code (or ACPI platform code), a common pattern is to assign them a struct dev_pm_domain using dev_pm_domain_set(). Then on suspend you'd invoke the PCI bus suspend hook and afterwards ask the PWRMU to power down. On resume you'd first power up using the PWRMU, then call the PCI bus resume hook. See drivers/gpu/vga/vga_switcheroo.c:
vga_switcheroo_init_domain_pm_ops() for an example. This would have been an alternative approach to introducing a new PCI platform for these devices. I'm not sure which approach is more suitable, it's just something that crossed my mind when looking at this.

Best regards,

Lukas

#6 lore raw

Re: [PATCH 1/1] x86/platform/intel-mid: Retrofit pci_platform_pm_ops ->get_power hook

Quoted 24 lines · Lukas Wunner
Quoted 18 lines · Andy Shevchenko
Quoted 8 lines · Lukas Wunner

  I'm not familiar at all with Intel MID devices, do you have a way to clearly identify if a PCI device is power managed
by the PWRMU versus PMCSR?  My guess is that at the very least, intel_mid_pwr_get_lss_id() needs to be called and false needs to be returned by mid_pci_power_manageable() if the return value is negative.

PCI bus is kinda fake on those platforms (which implement SFI) and don't
always follow [PCI] specification. The vendor register represents so called Logical Subsystem ID of the device in question. Some of them are
related to PWRMU, some to P-Unit, some just has no such register.

Quoted 4 lines

In PWRMU/P-Unit cases PMCSR is present and writing to it is needed. For the rest I don't remember what is actual state, perhaps writing is
just ignored and OS reads D0 all the time from it.

Quoted 10 lines

For devices with PM mechanisms not covered by the standard PCI code (or ACPI platform code), a common pattern is to assign them a struct dev_pm_domain using dev_pm_domain_set().  Then on suspend you'd invoke the PCI bus suspend hook and afterwards ask the PWRMU to power down.  On resume you'd first power up using the PWRMU, then call the PCI bus resume hook.  See drivers/gpu/vga/vga_switcheroo.c:
vga_switcheroo_init_domain_pm_ops() for an example.  This would have been an alternative approach to introducing a new PCI platform for these devices.  I'm not sure which approach is more suitable, it's just something that crossed my mind when looking at this.

Looks like individual drivers shall decide how to behave, right? We would actually like to avoid to touch any of the device driver in question.

Signature · 2 lines
Andy Shevchenko <[email protected]>
Intel Finland Oy
#7 lore raw

Re: [PATCH 1/1] x86/platform/intel-mid: Retrofit pci_platform_pm_ops ->get_power hook

In reply to Andy Shevchenko
Quoted 10 lines · Andy Shevchenko

arch/x86/platform/intel-mid/pwr.c int intel_mid_pci_set_power_state(struct pci_dev *pdev, pci_power_t state) · line 279

Quoted 5 lines · Lukas Wunner
arch/x86/platform/intel-mid/pwr.c +5 -0
+
+	reg = (id * LSS_PWS_BITS) / 32;
+	bit = (id * LSS_PWS_BITS) % 32;
+	power = mid_pwr_get_state(pwr, reg);
+	return (power >> bit) & 3;

Don't add sparse warnings:

        return (__force pci_power_t)((power >> bit) & 3);

I do not get any different sparse warnings with or without the cast despite using -Wsparse-all. This is with sparse 0.5.0 as included in Debian stretch.

With which options and sparse version did you manage to get new warnings?

Thanks,

Lukas

#8 lore raw

Re: [PATCH 1/1] x86/platform/intel-mid: Retrofit pci_platform_pm_ops ->get_power hook

Quoted 12 lines · Lukas Wunner
Quoted 11 lines · Andy Shevchenko

arch/x86/platform/intel-mid/pwr.c int intel_mid_pci_set_power_state(struct pci_dev *pdev, pci_power_t state) · line 279

Quoted 6 lines · Lukas Wunner
arch/x86/platform/intel-mid/pwr.c +5 -0
+
+	reg = (id * LSS_PWS_BITS) / 32;
+	bit = (id * LSS_PWS_BITS) % 32;
+	power = mid_pwr_get_state(pwr, reg);
+	return (power >> bit) & 3;

Don't add sparse warnings:

Quoted 8 lines
Quoted 1 line

        return (__force pci_power_t)((power >> bit) & 3);

I do not get any different sparse warnings with or without the cast despite using -Wsparse-all.  This is with sparse 0.5.0 as included in Debian stretch.

With which options and sparse version did you manage to get new warnings?

$ sparse --version
v0.5.0
$ make C=1 CF=-D__CHECK_ENDIAN__ W=1 -j64 

Warning itself:

arch/x86/platform/intel-mid/pwr.c:305:31: warning: incorrect type in return expression (different base types) arch/x86/platform/intel-mid/pwr.c:305:31:    expected restricted pci_power_t
arch/x86/platform/intel-mid/pwr.c:305:31:    got unsigned int

Signature · 2 lines
Andy Shevchenko <[email protected]>
Intel Finland Oy
#9 lore raw

Re: [PATCH 1/1] x86/platform/intel-mid: Retrofit pci_platform_pm_ops ->get_power hook

Quoted 27 lines · Andy Shevchenko
Quoted 12 lines · Lukas Wunner
Quoted 11 lines · Andy Shevchenko

arch/x86/platform/intel-mid/pwr.c int intel_mid_pci_set_power_state(struct pci_dev *pdev, pci_power_t state) · line 279

Quoted 6 lines · Lukas Wunner
arch/x86/platform/intel-mid/pwr.c +5 -0
+
+	reg = (id * LSS_PWS_BITS) / 32;
+	bit = (id * LSS_PWS_BITS) % 32;
+	power = mid_pwr_get_state(pwr, reg);
+	return (power >> bit) & 3;

Don't add sparse warnings:

Quoted 8 lines
Quoted 1 line

        return (__force pci_power_t)((power >> bit) & 3);

I do not get any different sparse warnings with or without the cast despite using -Wsparse-all.  This is with sparse 0.5.0 as included in Debian stretch.

With which options and sparse version did you manage to get new warnings?

$ sparse --version
v0.5.0
$ make C=1 CF=-D__CHECK_ENDIAN__ W=1 -j64 
Quoted 7 lines

Warning itself:

arch/x86/platform/intel-mid/pwr.c:305:31: warning: incorrect type in return expression (different base types) arch/x86/platform/intel-mid/pwr.c:305:31:    expected restricted pci_power_t
arch/x86/platform/intel-mid/pwr.c:305:31:    got unsigned int

Okay, -D__CHECK_ENDIAN__ was necessary to reproduce the warning. Thanks for replying so quickly, much appreciated.

Lukas

#10 lore raw
In reply to Lukas Wunner
Quoted 7 lines · Lukas Wunner

Somehow it went completely under my radar that v4.8 added another struct pci_platform_pm_ops for Intel Mobile Internet Devices.

There's a commit queued for v4.9 on Bjorn's pci/pm branch which adds a mandatory ->get_power hook to pci_platform_pm_ops and implements it for acpi_pci_platform_pm, but not mid_pci_platform_pm.

Quoted 5 lines

The following patch fixes that.  It's not a build issue, the missing hook in mid_pci_platform_pm only becomes a problem at runtime.

@Andy: Could you look over this and provide an ack?  I do not have an Intel MID so I was only able to compile-test the patch.

Without this I got nothing but constant reboot.

Nevertheless please address my comments.

Quoted 6 lines

The ->get_power hook is currently only called to update a device's current_state after resume (both at runtime and after system sleep) and after changing its power state using the platform in pci_platform_power_transition().  The result of the ->get_power hook is ignored unless it's D3cold.  Since intel-mid PCI devices can only be suspended to D3hot,

Strictly speaking platform supports it, but we don't use these feature.

Quoted 7 lines

the return value is irrelevant on this platform,
the hook just needs to be present to make pci_set_platform_pm() happy.

If you want to test the patch, you need to apply it either on Bjorn's pci/pm branch or linux-next:
http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci
/pm

I'm using linux-next.

Quoted 14 lines

Thanks,

Lukas

Lukas Wunner (1):
  x86/platform/intel-mid: Retrofit pci_platform_pm_ops ->get_power hook

 arch/x86/include/asm/intel-mid.h  |  1 + arch/x86/platform/intel-mid/pwr.c | 19 +++++++++++++++++++ drivers/pci/pci-mid.c             |  6 ++++++

 3 files changed, 26 insertions(+)
Signature · 2 lines
Andy Shevchenko <[email protected]>
Intel Finland Oy