>
>> >> +#elif defined(CONFIG_X86_MRST)
>> >> +static void hcd_pci_set_platform_config(struct pci_dev *pci_dev, int enable)
>> >> +{
>> >> + /* Check if it is Intel Medfield platform */
>> >> + if (pci_dev->vendor == PCI_VENDOR_ID_INTEL &&
>> >> + pci_dev->device == 0x0829) {
>> >> + if (enable) {
>> >> + pci_restore_state(pci_dev);
>> >> + pci_set_power_state(pci_dev, PCI_D0);
>> >> + } else {
>> >> + pci_save_state(pci_dev);
>> >> + pci_set_power_state(pci_dev, PCI_D3hot);
>> >> + }
>> >> + }
>> >> +}
>> >
>> >Why do you need this routine? Doesn't the PCI core already do this for
>> >you?
>>
>> Hello
>>
>> Thanks a lot for your help on code review.
>>
>> we manually invoke pci_set_power_state to notify that the hardware can be powered
>on/off in this function mainly for runtime pm case.
>> Actually it depends on Intel MID platform related pm implementation, it will not enter
>D3hot in runtime suspend by PCI core but required driver to call pci_set_power_state
>itself.
>
>Then there's a bug in the Intel MID platform-related PM implementation.
>You should fix that bug instead of introducing extra unnecessary code
>somewhere else. After all, that same bug will affect other PCI drivers
>on the MID platform.
Agree, if the platform-related PM implementation can handle correct state transition (platform_pci_choose_state function).
We did not need this patch any longer. But actually I am not sure if the details of the PM implementation.
So I will remove this patch from the second submission list directly and check the pm implementation first.
Thanks a lot for the comment. : )
Hao
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
