Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 17 12月, 2011 11 次提交
  3. 16 12月, 2011 2 次提交
  5. 15 12月, 2011 1 次提交
    • A
      PCI: Set device power state to PCI_D0 for device without native PM support · b51306c6
      由 Ajaykumar Hotchandani 提交于 
      During test of one IB card with guest VM, found that, msi is not
initialized properly.

It turns out __write_msi_msg will do nothing if device current_state is
not PCI_D0.  And, that pci device does not have pm_cap in guest VM.

There is an error in setting of power state to PCI_D0 in
pci_enable_device(), but error is not returned for this.  Following is
code flow:

pci_enable_device() -->   __pci_enable_device_flags() -->
do_pci_enable_device() -->   pci_set_power_state() -->
__pci_start_power_transition()

We have following condition inside __pci_start_power_transition():
         if (platform_pci_power_manageable(dev)) {
                 error = platform_pci_set_power_state(dev, state);
                 if (!error)
                         pci_update_current_state(dev, state);
         } else {
                 error = -ENODEV;
                 /* Fall back to PCI_D0 if native PM is not supported */
                 if (!dev->pm_cap)
                         dev->current_state = PCI_D0;
         }

Here, from platform_pci_set_power_state(), acpi_pci_set_power_state() is
getting called and that is failing with ENODEV because of following
condition:

         if (!handle || ACPI_SUCCESS(acpi_get_handle(handle, "_EJ0",&tmp)))
                 return -ENODEV;

Because of that, pci_update_current_state() is not getting called.

With this patch, if device power state can not be set via
platform_pci_set_power_state and that device does not have native pm
support, then PCI device power state will be set to PCI_D0.

-v2: This also reverts 47e9037a, as it's
     not needed after this change.
Acked-by: N"Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Ajaykumar Hotchandani<ajaykumar.hotchandani@oracle.com>
Signed-off-by: Yinghai Lu<yinghai.lu@oracle.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      b51306c6
  7. 14 12月, 2011 9 次提交
    • L
      staging: r8712u: Add new USB ID · c7caf4d4
      由 Larry Finger 提交于 
      Add USB ID for Sitecom WLA-2000 v1.001 WLAN.
Reported-and-tested-by: NRoland Gruber <post@rolandgruber.de>
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c7caf4d4
    • O
      staging: tidspbridge: request dmtimer clocks on init · ed625b91
      由 Omar Ramirez Luna 提交于 
      Given that dm timer framework doesn't support request of clocks
by soft | hard irqs because some recent changes, tidspbridge needs
to request its clocks on init and enable/disable them on demand.

This was first seen on 3.2-rc1.
Signed-off-by: NOmar Ramirez Luna <omar.ramirez@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      ed625b91
    • O
      staging: tidspbridge: include module.h by default · 0a7e22e6
      由 Omar Ramirez Luna 提交于 
      Fixes compilation break when compiled as part of the kernel:

drivers/staging/tidspbridge/rmgr/drv_interface.c:134: error: expected declaration specifiers or '...' before string constant
drivers/staging/tidspbridge/rmgr/drv_interface.c:134: warning: data definition has no type or storage class
drivers/staging/tidspbridge/rmgr/drv_interface.c:134: warning: type defaults to 'int' in declaration of 'MODULE_AUTHOR'
drivers/staging/tidspbridge/rmgr/drv_interface.c:134: warning: function declaration isn't a prototype
drivers/staging/tidspbridge/rmgr/drv_interface.c:135: error: expected declaration specifiers or '...' before string constant
drivers/staging/tidspbridge/rmgr/drv_interface.c:135: warning: data definition has no type or storage class
drivers/staging/tidspbridge/rmgr/drv_interface.c:135: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE'
drivers/staging/tidspbridge/rmgr/drv_interface.c:135: warning: function declaration isn't a prototype
drivers/staging/tidspbridge/rmgr/drv_interface.c:136: error: expected declaration specifiers or '...' before string constant
drivers/staging/tidspbridge/rmgr/drv_interface.c:136: warning: data definition has no type or storage class
drivers/staging/tidspbridge/rmgr/drv_interface.c:136: warning: type defaults to 'int' in declaration of 'MODULE_VERSION'
drivers/staging/tidspbridge/rmgr/drv_interface.c:136: warning: function declaration isn't a prototype
drivers/staging/tidspbridge/rmgr/drv_interface.c: In function 'omap34_xx_bridge_probe':
drivers/staging/tidspbridge/rmgr/drv_interface.c:359: error: 'THIS_MODULE' undeclared (first use in this function)
drivers/staging/tidspbridge/rmgr/drv_interface.c:359: error: (Each undeclared identifier is reported only once
drivers/staging/tidspbridge/rmgr/drv_interface.c:359: error: for each function it appears in.)
Signed-off-by: NOmar Ramirez Luna <omar.ramirez@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      0a7e22e6
    • R
      PCI hotplug: Always allow acpiphp to handle non-PCIe bridges · 619a5182
      由 Rafael J. Wysocki 提交于 
      Commit 0d52f54e (PCI / ACPI: Make
acpiphp ignore root bridges using PCIe native hotplug) added code
that made the acpiphp driver completely ignore PCIe root complexes
for which the kernel had been granted control of the native PCIe
hotplug feature by the BIOS through _OSC.  Unfortunately, however,
this was a mistake, because on some systems there were PCI bridges
supporting PCI (non-PCIe) hotplug under such root complexes and
those bridges should have been handled by acpiphp.

For this reason, revert the changes made by the commit mentioned
above and make register_slot() in drivers/pci/hotplug/acpiphp_glue.c
avoid registering hotplug slots for PCIe ports that belong to
root complexes with native PCIe hotplug enabled (which means that
the BIOS has granted the kernel control of this feature for the
given root complex).  This is reported to address the original
issue fixed by commit 0d52f54e and
to work on the system where that commit broke things.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      619a5182
    • W
      gpio: mpc8xxx: don't allow input-only pins to be output for MPC5121 · 28538df0
      由 Wolfram Sang 提交于 
      Add a 5121-custom reject if an input-only pin is requested to be output
(see 18.3.1.1 in the refman). Also, rewrite mach-specific quirk setup to
consume less lines which scales better.
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
[grant.likely: Fixed build error]
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      28538df0
    • F
      gpio-ml-ioh: Add the irq_disable/irq_enable hooks for ml-ioh irq chip · 4d052213
      由 Feng Tang 提交于 
      These hooks will be needed by the general disabl/enable_irq();
Signed-off-by: NFeng Tang <feng.tang@intel.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      4d052213
    • F
      gpio-ml-ioh: fix a bug in the interrupt handler · f9ea14ef
      由 Feng Tang 提交于 
      GPIO's irq action's dev_id is set to the first struct ioh_gpio chip,
so when loop checking the 8 chips, the "chip" should be changed
according.
Signed-off-by: NFeng Tang <feng.tang@intel.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      f9ea14ef
    • R
      gpio: pl061: drop extra check for NULL platform_data · b2888095
      由 Rob Herring 提交于 
      In adding DT binding support, the check for NULL platform_data got added
back in inadvertently, so remove it.
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      b2888095
    • B
      USB: option: Removing one bogus and adding some new Huawei combinations · 02a551c9
      由 Bjørn Mork 提交于 
      Huawei use the product code HUAWEI_PRODUCT_E353 (0x1506) for a
number of different devices, which each can appear with a number
of different descriptor sets.  Different types of interfaces
can be identified by looking at the subclass and protocol fields

Subclass 1 protocol 8 is actually the data interface of a CDC
ECM set, with subclass 1 protocol 9 as the control interface.
Neither support serial data communcation, and cannot therefore
be supported by this driver.

At the same time, add a few other sets which appear if the
device is configured in "Windows mode" using this modeswitch
message:
55534243000000000000000000000011060000000100000000000000000000
Signed-off-by: NBjørn Mork <bjorn@mork.no>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      02a551c9
  9. 13 12月, 2011 5 次提交
  11. 12 12月, 2011 4 次提交
  13. 11 12月, 2011 8 次提交