[GIT PATCH] USB patches for 3.9-rc1

[GIT PATCH] USB patches for 3.9-rc1

[Greg KH]

The following changes since commit 200e0d994d9d1919b28c87f1a5fb99a8e13b8a0f:

  USB: storage: optimize to match the Huawei USB storage devices and support new switch command (2013-02-04 10:41:40 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.9-rc1

for you to fetch changes up to 6166805c3de539a41cfcae39026c5bc273d7c6aa:

  Revert "USB: EHCI: make ehci-vt8500 a separate driver" (2013-02-20 10:26:31 -0800)

----------------------------------------------------------------
USB patches for 3.9-rc1

Here's the big USB merge for 3.9-rc1

Nothing major, lots of gadget fixes, and of course, xhci stuff.

All of this has been in linux-next for a while, with the exception of
the last 3 patches, which were reverts of patches in the tree that
caused problems, they went in yesterday.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

----------------------------------------------------------------
Aaro Koskinen (1):
      usb: musb: omap2430: fix the readiness check in omap_musb_mailbox

Alan Stern (3):
      USB: fix sign-extension bug in the hub driver
      USB: altsetting overrides for usbtest
      USB: GADGET: optionally force full-speed for net2280 UDC

Andrzej Pietrasiewicz (1):
      usb: gadget: f_mass_storage: remove unused operations

Armando Visconti (1):
      usb: gadget zero: avoid unnecessary reinit of data in f_sourcesink

Arnd Bergmann (1):
      USB: update host controller Kconfig entries

Arvid Brodin (1):
      usb/isp1760: declare schedule_ptds() and errata2_function() static

Bjørn Mork (3):
      USB: option: add and update Alcatel modems
      USB: option: add Yota / Megafon M100-1 4g modem
      USB: option: add Huawei "ACM" devices using protocol = vendor

Cesar Eduardo Barros (1):
      usb: phy: mv-otg: use to_delayed_work instead of cast

Chao Xie (6):
      usb: gadget: mv_udc: use udc_start and udc_stop functions
      usb: gadget: mv_udc: use devm_xxx for probe
      usb: gadget: mv_udc: fix the warning of mv_udc_remove
      usb: otg: mv_otg: use devm_xxx for probe
      usb: host: ehci-mv: remove unused variable
      usb: gadget: mv_udc: fix the value of tranceiver

Chen Gang (5):
      USB: ohci: set urb->hcpriv = NULL immediately, after free it
      USB: uhci: check buffer length to avoid memory overflow
      USB: uhci: beautify source code
      drivers/usb/core: using strlcpy instead of strncpy
      drivers/usb/gadget: using strlcpy instead of strncpy

Dan Carpenter (2):
      USB: c67x00-ll-hpi.c: signedness bug in ll_recv_msg()
      USB: wusbcore/wa-xfer: error handling fixes in setup_segs()

Dongjin Kim (4):
      USB: misc: Add USB3503 High-Speed Hub Controller
      USB: misc: fixup smatch WARNING
      USB: misc: usb3503: add dt support
      USB: misc: usb3503: Fix compiler warning

Fabio Baltieri (1):
      usb: musb: ux500: use clk_prepare_enable and clk_disable_unprepare

Fabio Estevam (1):
      USB: chipidea: ci13xxx_imx: Remove sparse warning

Felipe Balbi (21):
      usb: dwc3: decrease event buffer size
      usb: dwc3: gadget: don't redefine 'ret'
      usb: dwc3: debugfs: convert our regdump to use regsets
      usb: gadget: f_uac2: fix compile warning
      usb: gadget: fix two sparse warnings
      usb: dwc3: gadget: change HIRD threshold to 12
      usb: gadget: amd5536udc: convert to udc_start/udc_stop
      usb: gadget: fusb300_udc: convert to udc_start/udc_stop
      usb: gadget: goku_udc: convert to udc_start/udc_stop
      usb: gadget: fsl_udc_core: convert to udc_start/udc_stop
      usb: gadget: m66592-udc: convert to udc_start/udc_stop
      usb: gadget: omap_udc: convert to udc_start/udc_stop
      usb: gadget: pch_udc: convert to udc_start/udc_stop
      usb: gadget: pxa25x_udc: convert to udc_start/udc_stop
      usb: gadget: pxa27x_udc: convert to udc_start/udc_stop
      usb: gadget: s3c2410: convert to udc_start/udc_stop
      usb: gadget: completely remove ->start/->stop
      usb: gadget: constify all struct usb_gadget_ops
      usb: phy: fix Kconfig warning
      usb: omap_control_usb: fix compile warning
      usb: gadget: imx_udc: make it depend on BROKEN

Fengguang Wu (1):
      usb: misc: usb3503_probe() can be static

Frans Klaver (1):
      usb: add driver for xsens motion trackers

Gerd Hoffmann (8):
      uas: new function to cancel data urbs
      uas: add UNLINK_DATA_URBS flag
      uas: add IS_IN_WORK_LIST flag
      uas: improve abort handler
      uas: improve device reset
      uas: fail any request submitted while resetting the device.
      usb-uas: set max_lun and max_channel
      usb-uas: update MAINTAINERS entry

Greg Kroah-Hartman (11):
      Merge tag 'for-usb-next-2013-01-03' of git://git.kernel.org/.../sarah/xhci into usb-next
      Merge 3.8-rc4 into usb-next
      Merge tag 'musb-for-v3.9' of git://git.kernel.org/.../balbi/usb into usb-next
      Merge tag 'dwc3-for-v3.9' of git://git.kernel.org/.../balbi/usb into usb-next
      Merge tag 'gadget-for-v3.9' of git://git.kernel.org/.../balbi/usb into usb-next
      Merge tag 'xceiv-for-v3.9' of git://git.kernel.org/.../balbi/usb into usb-next
      Merge 3.8-rc5 into usb-next
      Merge usb-linus branch into usb-next
      Revert "USB: update host controller Kconfig entries"
      Revert "USB: EHCI: make ehci-orion a separate driver"
      Revert "USB: EHCI: make ehci-vt8500 a separate driver"

Heiko Carstens (1):
      drivers/usb: add missing GENERIC_HARDIRQS dependencies

Javier Martinez Canillas (1):
      usb: host: xhci: remove unused trb var in xhci_irq()

Jean-Christophe PLAGNIOL-VILLARD (1):
      USB: gadget: at91_adc: fix pullup pin validity check

Jingoo Han (1):
      usb: dwc3: exynos: use devm_ functions

Johan Hovold (6):
      USB: io_ti: move write-fifo flushing to close
      USB: io_ti: use tty-port drain delay
      USB: serial: grab disconnect mutex in chars_in_buffer
      USB: io_ti: query hardware-buffer status in chars_in_buffer
      USB: io_ti: kill custom closing_wait implementation
      USB: serial: fix null-pointer dereferences on disconnect

Josh Boyer (1):
      USB: usb-storage: unusual_devs update for Super TOP SATA bridge

Julia Lawall (1):
      drivers/usb/chipidea/core.c: adjust duplicate test

Kishon Vijay Abraham I (21):
      usb: dwc3: omap: use device_for_each_child to handle child removal
      usb: dwc3: omap: use of_platform API to create dwc3 core pdev
      usb: dwc3: omap: use runtime API's to enable clocks
      usb: dwc3: omap: Remove explicit writes to SYSCONFIG register
      usb: dwc3: omap: Add an API to write to dwc mailbox
      usb: dwc3: core: enable the USB2 and USB3 phy in probe
      usb: dwc3: core: stray statements are removed
      usb: otg: add an api to bind the usb controller and phy
      usb: otg: utils: add facilities in phy lib to support multiple PHYs of same type
      usb: otg: add device tree support to otg library
      usb: phy: add a new driver for usb part of control module
      usb: start using the control module driver
      usb: phy: add a new driver for usb3 phy
      usb: musb: omap: make use of the new PHY lib APIs
      usb: musb: omap: get phy by phandle for dt boot
      usb: phy: omap-usb2: enable 960Mhz clock for omap5
      usb: dwc3: core: add dt support for dwc3 core
      ARM: OMAP4: remove control module address space from PHY and OTG
      ARM: OMAP: devices: create device for usb part of control module
      ARM: OMAP2: MUSB: Specify omap4 has mailbox
      ARM: OMAP: USB: Add phy binding information

Lan Tianyu (12):
      usb: Add driver/usb/core/(port.c,hub.h) files
      usb: fix compilation error and warning of driver/usb/core/port.c on arm and blackfin
      usb: Add "portX/connect_type" attribute to expose usb port's connect type
      usb: Create link files between child device and usb port device.
      USB: Set usb port's DeviceRemovable according acpi information
      usb: Register usb port's acpi power resources
      PM/Qos: Expose dev_pm_qos_flags symbol
      usb: add runtime pm support for usb port device
      usb: add usb port auto power off mechanism
      usb: expose usb port's pm qos flags to user space
      usb: enable usb port device's async suspend.
      Revert "usb: Register usb port's acpi power resources"

Manjunath Goudar (2):
      USB: EHCI: make ehci-vt8500 a separate driver
      USB: EHCI: make ehci-orion a separate driver

Matt Sealey (1):
      USB: ehci-mxc: remove Efika MX-specific CHRGVBUS hack

Michal Nazarewicz (1):
      usb: gadget: FunctionFS: Use kstrtoul()

Ming Lei (3):
      usb: musb: core: fix failure path
      usb: musb: fix dependency on transceiver driver
      USB: storage: avoid scanning other targets for single target device

Peter Chen (1):
      usb: phy: mxs-phy: add set_suspend API

Pratyush Anand (8):
      usb: dwc3: Enable usb2 LPM only when connected as usb2.0
      usb: dwc3: gadget: fix missed isoc
      usb: dwc3: gadget: correct return from ep_queue
      usb: dwc3: gadget: fix isoc END TRANSFER Condition
      usb: dwc3: gadget: fix skip LINK_TRB on ISOC
      usb: dwc3: gadget: no need to pass params in case of UPDATE_TRANSFER
      usb: dwc3: gadget: fix scatter gather implementation
      usb: dwc3: gadget: req->queued must be forced to false in cleanup

Praveen Paneri (2):
      usb: phy: samsung: Introducing usb phy driver for hsotg
      usb: phy: s3c-hsotg: adding phy driver support

Roger Quadros (2):
      USB: ehci-omap: Don't free gpios that we didn't request
      USB: ehci-omap: Fix autoloading of module

Sachin Kamat (3):
      usb: gadget: s3c-hsudc: Use devm_regulator_bulk_get
      usb: gadget: s3c-hsotg: Use devm_regulator_bulk_get API
      usb: musb: dsps: Remove duplicate inclusion of linux/of.h

Sarah Sharp (6):
      USB: Don't use EHCI port sempahore for USB 3.0 hubs.
      USB: Prepare for refactoring by adding extra udev checks.
      USB: Rip out recursive call on warm port reset.
      USB: Fix connected device switch to Inactive state.
      USB: Use helper function hub_set_port_link_state
      USB: Refactor hub_port_wait_reset.

Sasha Levin (1):
      tools/usb: remove unneeded 'continue' and simplify condition

Sebastian Andrzej Siewior (28):
      usb: gadget: file_storage: remove its last pieces
      usb: gadget: ncm: make global variable ndp*_opts read only
      usb: gadget: mass_storage: remove >= 0 check for unsigned type
      usb: gadget: consider link speed for bMaxPower
      usb/core: consider link speed while looking at bMaxPower
      usb/core: update power budget for SuperSpeed
      usb: gadget: composite: don't call driver's unbind() if bind() failed
      usb: gadget: remove u32 castings of address passed to readl()
      usb: gadget: provide a wrapper around SourceSink's setup function
      usb: gadget: move source sink's config descriptor out of f_sourcesink
      usb: gadget: move loopback's config descriptor out of f_loopback
      usb: gadget: add some infracture to register/unregister functions
      usb: gadget: convert source sink and loopback to new function interface
      usb: gadget: f_acm: remove empty function
      usb: gadget: g_serial: split the three possible functions into three bind functions
      usb: gadget: u_serial: convert into a module
      usb: gadget: composite: add usb_remove_function()
      usb: gadget: allocate & giveback serial ports instead hard code them
      usb: gadget: f_acm: convert to new function interface with backwards compatibility
      usb: gadget: acm_ms: use function framework for ACM
      usb: gadget: cdc2: use function framework for ACM
      usb: gadget: multi: use function framework for ACM
      usb: gadget: add a forward pointer from usb_function to its "instance"
      usb: gadget: udc-core: introduce UDC binding by name
      usb: gadget: factor out two helper functions from composite_bind()
      usb: gadget: export composite's setup & disconnect function
      usb: gadget: composite: introduce usb_gstrings_attach()
      usb: gadget: f_acm: use usb_gstrings_attach()

Sergei Shtylyov (3):
      usb: musb: omap2430: kill redundant assignments in omap2430_probe()
      usb: musb: omap2430: fix wrong devm_kzalloc() result check
      testusb: remove all mentions of 'usbfs'

Stefan Hubner (1):
      usb: serial: keyspan: fixed coding style issues

Tejun Heo (1):
      usb: gadget: at91_udc: don't use [delayed_]work_pending()

Vivek Gautam (11):
      usb: dwc3: remove dwc3 dependency on host AND gadget.
      usb: phy: samsung: Add support to set pmu isolation
      ARM: EXYNOS: Update & move usb-phy types to generic include layer
      usb: phy: samsung: Add host phy support to samsung-phy driver
      USB: ehci-s5p: Add phy driver support
      USB: ohci-exynos: Add phy driver support
      usb: phy: samsung: Remove __devinit, __devexit_p and __exit annotations
      usb: ehci-s5p/ohci-exynos: Fix compatible strings for the device
      usb: dwc3: exynos: fix compatible strings for the device
      usb: dwc3: exynos/omap: Change platform device IDs for no_op_xceive to AUTO
      usb: dwc3: host: Change platform device ID for xhci-hcd to AUTO

Wei Yongjun (1):
      usb: gadget: remove unused variable in uac2_pcm_trigger()

Woody Suwalski (1):
      USB: UHCI: remove unused definition

fangxiaozhi (1):
      USB: storage: properly handle the endian issues of idProduct

supriya karanth (3):
      usb: musb: set TXMAXP and AUTOSET for full speed bulk in device mode
      usb: musb: set AUTOSET for full speed bulk DMA transfer in host mode
      usb: musb: Double buffering issues in host mode TX

 Documentation/ABI/testing/sysfs-bus-usb            |   9 +
 Documentation/devicetree/bindings/usb/dwc3.txt     |  22 +
 Documentation/devicetree/bindings/usb/omap-usb.txt |  34 +-
 .../devicetree/bindings/usb/samsung-usbphy.txt     |  55 ++
 Documentation/devicetree/bindings/usb/usb-phy.txt  |  35 +-
 Documentation/devicetree/bindings/usb/usb3503.txt  |  20 +
 MAINTAINERS                                        |   3 +-
 arch/arm/mach-omap2/board-2430sdp.c                |   2 +
 arch/arm/mach-omap2/board-3430sdp.c                |   2 +
 arch/arm/mach-omap2/board-4430sdp.c                |   2 +
 arch/arm/mach-omap2/board-cm-t35.c                 |   2 +
 arch/arm/mach-omap2/board-devkit8000.c             |   2 +
 arch/arm/mach-omap2/board-igep0020.c               |   2 +
 arch/arm/mach-omap2/board-ldp.c                    |   2 +
 arch/arm/mach-omap2/board-omap3beagle.c            |   2 +
 arch/arm/mach-omap2/board-omap3evm.c               |   2 +
 arch/arm/mach-omap2/board-omap3logic.c             |   2 +
 arch/arm/mach-omap2/board-omap3pandora.c           |   2 +
 arch/arm/mach-omap2/board-omap3stalker.c           |   2 +
 arch/arm/mach-omap2/board-omap3touchbook.c         |   2 +
 arch/arm/mach-omap2/board-omap4panda.c             |   2 +
 arch/arm/mach-omap2/board-overo.c                  |   2 +
 arch/arm/mach-omap2/board-rm680.c                  |   2 +
 arch/arm/mach-omap2/board-zoom-peripherals.c       |   2 +
 arch/arm/mach-omap2/devices.c                      |  45 +
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |  13 -
 arch/arm/mach-omap2/usb-musb.c                     |   3 +
 drivers/base/power/qos.c                           |   1 +
 drivers/usb/c67x00/c67x00-ll-hpi.c                 |   2 +-
 drivers/usb/chipidea/ci13xxx_imx.h                 |   2 +-
 drivers/usb/chipidea/core.c                        |   2 +-
 drivers/usb/core/Makefile                          |   1 +
 drivers/usb/core/devices.c                         |  13 +-
 drivers/usb/core/devio.c                           |   3 +-
 drivers/usb/core/generic.c                         |   2 +-
 drivers/usb/core/hcd.c                             |   5 +-
 drivers/usb/core/hub.c                             | 616 ++++++++------
 drivers/usb/core/hub.h                             | 122 +++
 drivers/usb/core/message.c                         |   2 +-
 drivers/usb/core/port.c                            | 202 +++++
 drivers/usb/core/sysfs.c                           |  31 +-
 drivers/usb/core/usb.h                             |  12 +
 drivers/usb/dwc3/Kconfig                           |  31 +-
 drivers/usb/dwc3/Makefile                          |  10 +-
 drivers/usb/dwc3/core.c                            |  31 +-
 drivers/usb/dwc3/core.h                            |  24 +-
 drivers/usb/dwc3/debugfs.c                         |  38 +-
 drivers/usb/dwc3/dwc3-exynos.c                     |  57 +-
 drivers/usb/dwc3/dwc3-omap.c                       | 152 ++--
 drivers/usb/dwc3/gadget.c                          | 292 ++++---
 drivers/usb/dwc3/host.c                            |   2 +-
 drivers/usb/gadget/Kconfig                         |  24 +-
 drivers/usb/gadget/Makefile                        |   8 +-
 drivers/usb/gadget/acm_ms.c                        |  42 +-
 drivers/usb/gadget/amd5536udc.c                    |  59 +-
 drivers/usb/gadget/amd5536udc.h                    |   2 +
 drivers/usb/gadget/at91_udc.c                      |   5 +-
 drivers/usb/gadget/cdc2.c                          |  36 +-
 drivers/usb/gadget/composite.c                     | 326 ++++++--
 drivers/usb/gadget/dbgp.c                          |  14 +-
 drivers/usb/gadget/f_acm.c                         | 153 ++--
 drivers/usb/gadget/f_fs.c                          |   5 +-
 drivers/usb/gadget/f_loopback.c                    | 103 +--
 drivers/usb/gadget/f_mass_storage.c                |  37 +-
 drivers/usb/gadget/f_ncm.c                         |  18 +-
 drivers/usb/gadget/f_obex.c                        |   4 -
 drivers/usb/gadget/f_serial.c                      |   4 -
 drivers/usb/gadget/f_sourcesink.c                  | 200 +++--
 drivers/usb/gadget/f_uac2.c                        |   9 +-
 drivers/usb/gadget/f_uvc.c                         |   3 +-
 drivers/usb/gadget/fsl_qe_udc.c                    |   2 +-
 drivers/usb/gadget/fsl_udc_core.c                  |  60 +-
 drivers/usb/gadget/functions.c                     | 116 +++
 drivers/usb/gadget/fusb300_udc.c                   |  67 +-
 drivers/usb/gadget/fusb300_udc.h                   |   2 +
 drivers/usb/gadget/g_zero.h                        |  35 +-
 drivers/usb/gadget/gmidi.c                         |   2 +-
 drivers/usb/gadget/goku_udc.c                      |  70 +-
 drivers/usb/gadget/goku_udc.h                      |   1 +
 drivers/usb/gadget/m66592-udc.c                    |  72 +-
 drivers/usb/gadget/m66592-udc.h                    |   1 +
 drivers/usb/gadget/multi.c                         |  71 +-
 drivers/usb/gadget/mv_udc_core.c                   | 246 +++---
 drivers/usb/gadget/net2280.c                       |  15 +
 drivers/usb/gadget/nokia.c                         |  43 +-
 drivers/usb/gadget/omap_udc.c                      |  51 +-
 drivers/usb/gadget/pch_udc.c                       |  67 +-
 drivers/usb/gadget/pxa25x_udc.c                    |  62 +-
 drivers/usb/gadget/pxa25x_udc.h                    |   1 +
 drivers/usb/gadget/pxa27x_udc.c                    |  61 +-
 drivers/usb/gadget/pxa27x_udc.h                    |   1 +
 drivers/usb/gadget/r8a66597-udc.c                  |   2 +-
 drivers/usb/gadget/s3c-hsotg.c                     |  44 +-
 drivers/usb/gadget/s3c-hsudc.c                     |  13 +-
 drivers/usb/gadget/s3c2410_udc.c                   |  65 +-
 drivers/usb/gadget/s3c2410_udc.h                   |   1 +
 drivers/usb/gadget/serial.c                        | 118 ++-
 drivers/usb/gadget/storage_common.c                |  61 --
 drivers/usb/gadget/u_serial.c                      | 313 +++----
 drivers/usb/gadget/u_serial.h                      |  13 +-
 drivers/usb/gadget/udc-core.c                      | 157 ++--
 drivers/usb/gadget/webcam.c                        |   2 +-
 drivers/usb/gadget/zero.c                          | 233 ++++--
 drivers/usb/host/Kconfig                           |   2 +-
 drivers/usb/host/ehci-mv.c                         |   1 -
 drivers/usb/host/ehci-mxc.c                        |  20 -
 drivers/usb/host/ehci-omap.c                       |  10 +-
 drivers/usb/host/ehci-s5p.c                        |  83 +-
 drivers/usb/host/isp1760-hcd.c                     |   4 +-
 drivers/usb/host/ohci-exynos.c                     |  87 +-
 drivers/usb/host/ohci-q.c                          |   1 +
 drivers/usb/host/uhci-debug.c                      | 178 ++--
 drivers/usb/host/uhci-hcd.c                        |  31 +-
 drivers/usb/host/uhci-hcd.h                        |   4 -
 drivers/usb/host/uhci-hub.c                        |   4 +-
 drivers/usb/host/uhci-q.c                          |   2 +-
 drivers/usb/host/xhci-ring.c                       |   2 -
 drivers/usb/misc/Kconfig                           |   6 +
 drivers/usb/misc/Makefile                          |   1 +
 drivers/usb/misc/usb3503.c                         | 325 +++++++
 drivers/usb/misc/usbtest.c                         |  13 +-
 drivers/usb/musb/Kconfig                           |   2 +
 drivers/usb/musb/am35x.c                           |   2 +-
 drivers/usb/musb/blackfin.c                        |   2 +-
 drivers/usb/musb/da8xx.c                           |   7 +-
 drivers/usb/musb/davinci.c                         |   7 +-
 drivers/usb/musb/musb_core.c                       |   1 +
 drivers/usb/musb/musb_dsps.c                       |   3 +-
 drivers/usb/musb/musb_gadget.c                     |  22 +-
 drivers/usb/musb/musb_host.c                       |  44 +-
 drivers/usb/musb/omap2430.c                        |  91 +-
 drivers/usb/musb/omap2430.h                        |   9 -
 drivers/usb/musb/tusb6010.c                        |   2 +-
 drivers/usb/musb/ux500.c                           |  12 +-
 drivers/usb/otg/mv_otg.c                           |  84 +-
 drivers/usb/otg/mxs-phy.c                          |  20 +
 drivers/usb/otg/otg.c                              | 235 +++++-
 drivers/usb/otg/twl4030-usb.c                      |   3 +-
 drivers/usb/phy/Kconfig                            |  28 +
 drivers/usb/phy/Makefile                           |   3 +
 drivers/usb/phy/omap-control-usb.c                 | 295 +++++++
 drivers/usb/phy/omap-usb2.c                        |  72 +-
 drivers/usb/phy/omap-usb3.c                        | 355 ++++++++
 drivers/usb/phy/samsung-usbphy.c                   | 930 +++++++++++++++++++++
 drivers/usb/renesas_usbhs/Kconfig                  |   2 +-
 drivers/usb/renesas_usbhs/mod_gadget.c             |   2 +-
 drivers/usb/serial/Kconfig                         |  12 +
 drivers/usb/serial/Makefile                        |   1 +
 drivers/usb/serial/ftdi_sio.c                      |  20 +-
 drivers/usb/serial/io_ti.c                         |  89 +-
 drivers/usb/serial/keyspan.c                       |   4 +-
 drivers/usb/serial/mct_u232.c                      |  22 +-
 drivers/usb/serial/option.c                        |  16 +-
 drivers/usb/serial/quatech2.c                      |  18 +-
 drivers/usb/serial/sierra.c                        |   8 +-
 drivers/usb/serial/ssu100.c                        |  19 +-
 drivers/usb/serial/usb-serial.c                    |  28 +-
 drivers/usb/serial/usb_wwan.c                      |   8 +-
 drivers/usb/serial/xsens_mt.c                      |  86 ++
 drivers/usb/storage/initializers.c                 |   4 +-
 drivers/usb/storage/uas.c                          | 124 ++-
 drivers/usb/storage/unusual_cypress.h              |   2 +-
 drivers/usb/storage/usb.c                          |   3 +
 drivers/usb/wusbcore/wa-xfer.c                     |   6 +-
 include/linux/platform_data/samsung-usbphy.h       |  27 +
 include/linux/platform_data/usb3503.h              |  19 +
 include/linux/usb/composite.h                      |  75 +-
 include/linux/usb/dwc3-omap.h                      |  30 +
 include/linux/usb/gadget.h                         |  13 +-
 include/linux/usb/musb.h                           |   2 +
 include/linux/usb/omap_control_usb.h               |  92 ++
 include/linux/usb/omap_usb.h                       |  27 +-
 include/linux/usb/phy.h                            |  43 +
 include/linux/usb/samsung_usb_phy.h                |  16 +
 tools/usb/testusb.c                                |  31 +-
 175 files changed, 6383 insertions(+), 2515 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt
 create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt
 create mode 100644 Documentation/devicetree/bindings/usb/usb3503.txt
 create mode 100644 drivers/usb/core/hub.h
 create mode 100644 drivers/usb/core/port.c
 create mode 100644 drivers/usb/gadget/functions.c
 create mode 100644 drivers/usb/misc/usb3503.c
 create mode 100644 drivers/usb/phy/omap-control-usb.c
 create mode 100644 drivers/usb/phy/omap-usb3.c
 create mode 100644 drivers/usb/phy/samsung-usbphy.c
 create mode 100644 drivers/usb/serial/xsens_mt.c
 create mode 100644 include/linux/platform_data/samsung-usbphy.h
 create mode 100644 include/linux/platform_data/usb3503.h
 create mode 100644 include/linux/usb/dwc3-omap.h
 create mode 100644 include/linux/usb/omap_control_usb.h
 create mode 100644 include/linux/usb/samsung_usb_phy.h

Re: [GIT PATCH] USB patches for 3.9-rc1

[Linus Torvalds]

On Thu, Feb 21, 2013 at 10:40 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> USB patches for 3.9-rc1
>
> Here's the big USB merge for 3.9-rc1
>
> Nothing major, lots of gadget fixes, and of course, xhci stuff.

Ok, so there were a couple of conflicts with Thierry Reding's series
to convert devm_request_and_ioremap() users into
devm_ioremap_resource(), where some of the old users had been
converted to use other helper functions (eg omap_get_control_dev()).

I left the omap_get_control_dev() users alone, but I do want to note
that omap_control_usb_probe() itself now uses that
devm_request_and_ioremap() function. And I did *not* extend the merge
to do that kind of conversion in the helper function, so I'm assuming
Thierry might want to extend his work. Assuming people care enough..

                Linus

Re: [GIT PATCH] USB patches for 3.9-rc1

[Greg KH]

On Thu, Feb 21, 2013 at 12:25:24PM -0800, Linus Torvalds wrote:
> On Thu, Feb 21, 2013 at 10:40 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > USB patches for 3.9-rc1
> >
> > Here's the big USB merge for 3.9-rc1
> >
> > Nothing major, lots of gadget fixes, and of course, xhci stuff.
> 
> Ok, so there were a couple of conflicts with Thierry Reding's series
> to convert devm_request_and_ioremap() users into
> devm_ioremap_resource(), where some of the old users had been
> converted to use other helper functions (eg omap_get_control_dev()).

That's fine.

> I left the omap_get_control_dev() users alone, but I do want to note
> that omap_control_usb_probe() itself now uses that
> devm_request_and_ioremap() function. And I did *not* extend the merge
> to do that kind of conversion in the helper function, so I'm assuming
> Thierry might want to extend his work. Assuming people care enough..

Yes, his plan was to do another sweep of the calls and hopefully remove
the old api in 3.10 or so once that is all cleaned up.

thanks,

greg k-h

Re: [GIT PATCH] USB patches for 3.9-rc1

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1507 bytes --]

On Thu, Feb 21, 2013 at 01:58:39PM -0800, Greg KH wrote:
> On Thu, Feb 21, 2013 at 12:25:24PM -0800, Linus Torvalds wrote:
> > On Thu, Feb 21, 2013 at 10:40 AM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > USB patches for 3.9-rc1
> > >
> > > Here's the big USB merge for 3.9-rc1
> > >
> > > Nothing major, lots of gadget fixes, and of course, xhci stuff.
> > 
> > Ok, so there were a couple of conflicts with Thierry Reding's series
> > to convert devm_request_and_ioremap() users into
> > devm_ioremap_resource(), where some of the old users had been
> > converted to use other helper functions (eg omap_get_control_dev()).
> 
> That's fine.
> 
> > I left the omap_get_control_dev() users alone, but I do want to note
> > that omap_control_usb_probe() itself now uses that
> > devm_request_and_ioremap() function. And I did *not* extend the merge
> > to do that kind of conversion in the helper function, so I'm assuming
> > Thierry might want to extend his work. Assuming people care enough..
> 
> Yes, his plan was to do another sweep of the calls and hopefully remove
> the old api in 3.10 or so once that is all cleaned up.

Given that even devm_request_and_ioremap() is rather new and people have
been busy sending patches to use it I had expected that the initial
series wouldn't catch all uses once it had been merged. grepping is easy
and I even have a semantic patch to help with the conversion so I'll
keep an eye out for any new occurrences.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: [GIT PATCH] USB patches for 3.9-rc1

[Dave Jones]

On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote:

 > USB patches for 3.9-rc1
 > 
 > Here's the big USB merge for 3.9-rc1
 > 
 > Nothing major, lots of gadget fixes, and of course, xhci stuff.

I get no USB devices recognised when I insert them any more, which
I think is pretty major.  I suspect it has something to do with this ?

 > Lan Tianyu (12):
 >       usb: add runtime pm support for usb port device
 >       usb: add usb port auto power off mechanism

It looks like every port on my laptop is powered down, as I can't
even charge devices with it.

I tried running powertop, which noted autosuspend for the usb controllers
was 'good'. I flipped them to 'bad', but it made no difference.

What can I do to debug this ?

$ lspci | grep USB
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)

$ lsusb
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad]
Bus 001 Device 004: ID 5986:02d5 Acer, Inc 

(inserted USB devices don't show up in this list)

$ dmesg | grep -i usb
[    0.996096] ACPI: bus type usb registered
[    0.996428] usbcore: registered new interface driver usbfs
[    0.996638] usbcore: registered new interface driver hub
[    0.996875] usbcore: registered new device driver usb
[    1.874896] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    1.876103] ehci-pci 0000:00:1a.0: new USB bus registered, assigned bus number 1
[    1.886220] ehci-pci 0000:00:1a.0: USB 2.0 started, EHCI 1.00
[    1.886781] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    1.886878] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.887017] usb usb1: Product: EHCI Host Controller
[    1.887111] usb usb1: Manufacturer: Linux 3.8.0+ ehci_hcd
[    1.887220] usb usb1: SerialNumber: 0000:00:1a.0
[    1.888942] hub 1-0:1.0: USB hub found
[    1.892347] ehci-pci 0000:00:1d.0: new USB bus registered, assigned bus number 2
[    1.902216] ehci-pci 0000:00:1d.0: USB 2.0 started, EHCI 1.00
[    1.902674] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[    1.902770] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.902910] usb usb2: Product: EHCI Host Controller
[    1.903004] usb usb2: Manufacturer: Linux 3.8.0+ ehci_hcd
[    1.903098] usb usb2: SerialNumber: 0000:00:1d.0
[    1.904444] hub 2-0:1.0: USB hub found
[    1.906795] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    1.906970] uhci_hcd: USB Universal Host Controller Interface driver
[    1.908243] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 3
[    1.909823] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
[    1.909920] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.910060] usb usb3: Product: xHCI Host Controller
[    1.910153] usb usb3: Manufacturer: Linux 3.8.0+ xhci_hcd
[    1.910260] usb usb3: SerialNumber: 0000:00:14.0
[    1.911644] hub 3-0:1.0: USB hub found
[    1.930176] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 4
[    1.930802] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003
[    1.930899] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.931039] usb usb4: Product: xHCI Host Controller
[    1.931131] usb usb4: Manufacturer: Linux 3.8.0+ xhci_hcd
[    1.931239] usb usb4: SerialNumber: 0000:00:14.0
[    1.932568] hub 4-0:1.0: USB hub found
[    1.950215] usbcore: registered new interface driver usbserial
[    1.950388] usbcore: registered new interface driver usbserial_generic
[    1.950612] usbserial: USB Serial support registered for generic
[    1.950781] usbcore: registered new interface driver usb_debug
[    1.950959] usbserial: USB Serial support registered for debug
[    1.972227] usbcore: registered new interface driver usbhid
[    1.972322] usbhid: USB HID core driver
[    2.193584] usb 1-1: new high-speed USB device number 2 using ehci-pci
[    2.309836] usb 1-1: New USB device found, idVendor=8087, idProduct=0024
[    2.309965] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    2.313198] hub 1-1:1.0: USB hub found
[    2.436596] usb 2-1: new high-speed USB device number 2 using ehci-pci
[    2.551777] usb 2-1: New USB device found, idVendor=8087, idProduct=0024
[    2.551906] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    2.555603] hub 2-1:1.0: USB hub found
[    2.673812] usb 1-1.4: new full-speed USB device number 3 using ehci-pci
[    2.754662] usb 1-1.4: New USB device found, idVendor=0a5c, idProduct=21e6
[    2.754791] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    2.754968] usb 1-1.4: Product: BCM20702A0
[    2.755081] usb 1-1.4: Manufacturer: Broadcom Corp
[    2.755194] usb 1-1.4: SerialNumber: 689423EB48E2
[    2.827871] usb 1-1.6: new high-speed USB device number 4 using ehci-pci
[    2.921573] usb 1-1.6: New USB device found, idVendor=5986, idProduct=02d5
[    2.921671] usb 1-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    2.921820] usb 1-1.6: Product: Integrated Camera
[    2.921932] usb 1-1.6: Manufacturer: Ricoh Company Ltd.

*after this point, inserting devices made no printk's at all*


	Dave

Re: [GIT PATCH] USB patches for 3.9-rc1

[Lan Tianyu]

On 2013/2/22 16:59, Dave Jones wrote:
> On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote:
>
>   > USB patches for 3.9-rc1
>   >
>   > Here's the big USB merge for 3.9-rc1
>   >
>   > Nothing major, lots of gadget fixes, and of course, xhci stuff.
>
> I get no USB devices recognised when I insert them any more, which
> I think is pretty major.  I suspect it has something to do with this ?
>
>   > Lan Tianyu (12):
>   >       usb: add runtime pm support for usb port device
>   >       usb: add usb port auto power off mechanism
>
> It looks like every port on my laptop is powered down, as I can't
> even charge devices with it.
>
Hi Dave:
	Do you disable usb port's pm_qos_no_power_off?
	cat /sys/bus/usb/devices/(dev)/port/power/pm_qos_no_power_off

> I tried running powertop, which noted autosuspend for the usb controllers
> was 'good'. I flipped them to 'bad', but it made no difference.
>
> What can I do to debug this ?
Can you attach the output of dmesg with CONFIG_USB_DEBUG?
>
> $ lspci | grep USB
> 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)
> 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
> 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
>
> $ lsusb
> Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
> Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 001 Device 003: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad]
> Bus 001 Device 004: ID 5986:02d5 Acer, Inc
>
> (inserted USB devices don't show up in this list)
>
> $ dmesg | grep -i usb
> [    0.996096] ACPI: bus type usb registered
> [    0.996428] usbcore: registered new interface driver usbfs
> [    0.996638] usbcore: registered new interface driver hub
> [    0.996875] usbcore: registered new device driver usb
> [    1.874896] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [    1.876103] ehci-pci 0000:00:1a.0: new USB bus registered, assigned bus number 1
> [    1.886220] ehci-pci 0000:00:1a.0: USB 2.0 started, EHCI 1.00
> [    1.886781] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> [    1.886878] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    1.887017] usb usb1: Product: EHCI Host Controller
> [    1.887111] usb usb1: Manufacturer: Linux 3.8.0+ ehci_hcd
> [    1.887220] usb usb1: SerialNumber: 0000:00:1a.0
> [    1.888942] hub 1-0:1.0: USB hub found
> [    1.892347] ehci-pci 0000:00:1d.0: new USB bus registered, assigned bus number 2
> [    1.902216] ehci-pci 0000:00:1d.0: USB 2.0 started, EHCI 1.00
> [    1.902674] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
> [    1.902770] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    1.902910] usb usb2: Product: EHCI Host Controller
> [    1.903004] usb usb2: Manufacturer: Linux 3.8.0+ ehci_hcd
> [    1.903098] usb usb2: SerialNumber: 0000:00:1d.0
> [    1.904444] hub 2-0:1.0: USB hub found
> [    1.906795] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> [    1.906970] uhci_hcd: USB Universal Host Controller Interface driver
> [    1.908243] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 3
> [    1.909823] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
> [    1.909920] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    1.910060] usb usb3: Product: xHCI Host Controller
> [    1.910153] usb usb3: Manufacturer: Linux 3.8.0+ xhci_hcd
> [    1.910260] usb usb3: SerialNumber: 0000:00:14.0
> [    1.911644] hub 3-0:1.0: USB hub found
> [    1.930176] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 4
> [    1.930802] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003
> [    1.930899] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    1.931039] usb usb4: Product: xHCI Host Controller
> [    1.931131] usb usb4: Manufacturer: Linux 3.8.0+ xhci_hcd
> [    1.931239] usb usb4: SerialNumber: 0000:00:14.0
> [    1.932568] hub 4-0:1.0: USB hub found
> [    1.950215] usbcore: registered new interface driver usbserial
> [    1.950388] usbcore: registered new interface driver usbserial_generic
> [    1.950612] usbserial: USB Serial support registered for generic
> [    1.950781] usbcore: registered new interface driver usb_debug
> [    1.950959] usbserial: USB Serial support registered for debug
> [    1.972227] usbcore: registered new interface driver usbhid
> [    1.972322] usbhid: USB HID core driver
> [    2.193584] usb 1-1: new high-speed USB device number 2 using ehci-pci
> [    2.309836] usb 1-1: New USB device found, idVendor=8087, idProduct=0024
> [    2.309965] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> [    2.313198] hub 1-1:1.0: USB hub found
> [    2.436596] usb 2-1: new high-speed USB device number 2 using ehci-pci
> [    2.551777] usb 2-1: New USB device found, idVendor=8087, idProduct=0024
> [    2.551906] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> [    2.555603] hub 2-1:1.0: USB hub found
> [    2.673812] usb 1-1.4: new full-speed USB device number 3 using ehci-pci
> [    2.754662] usb 1-1.4: New USB device found, idVendor=0a5c, idProduct=21e6
> [    2.754791] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [    2.754968] usb 1-1.4: Product: BCM20702A0
> [    2.755081] usb 1-1.4: Manufacturer: Broadcom Corp
> [    2.755194] usb 1-1.4: SerialNumber: 689423EB48E2
> [    2.827871] usb 1-1.6: new high-speed USB device number 4 using ehci-pci
> [    2.921573] usb 1-1.6: New USB device found, idVendor=5986, idProduct=02d5
> [    2.921671] usb 1-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> [    2.921820] usb 1-1.6: Product: Integrated Camera
> [    2.921932] usb 1-1.6: Manufacturer: Ricoh Company Ltd.
>
> *after this point, inserting devices made no printk's at all*
>
>
> 	Dave
>

-- 
Best Regards
Tianyu Lan
linux kernel enabling team

Re: [GIT PATCH] USB patches for 3.9-rc1

[Lan Tianyu]

On 2013/2/22 16:59, Dave Jones wrote:
> On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote:
>
>   > USB patches for 3.9-rc1
>   >
>   > Here's the big USB merge for 3.9-rc1
>   >
>   > Nothing major, lots of gadget fixes, and of course, xhci stuff.
>
> I get no USB devices recognised when I insert them any more, which
> I think is pretty major.  I suspect it has something to do with this ?
>
>   > Lan Tianyu (12):
>   >       usb: add runtime pm support for usb port device
>   >       usb: add usb port auto power off mechanism
>
> It looks like every port on my laptop is powered down, as I can't
> even charge devices with it.
Hi Dave:
	Do you enable the port/power/pm_qos_no_power_off?
	cat /sys/bus/usb/devices/(dev)/port/power/pm_qos_no_power_off to show.
>
> I tried running powertop, which noted autosuspend for the usb controllers
> was 'good'. I flipped them to 'bad', but it made no difference.
>
> What can I do to debug this ?
	Can you attach the output of dmesg with CONFIG_USB_DEBUG?
>
> $ lspci | grep USB
> 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)
> 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
> 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
>
> $ lsusb
> Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
> Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 001 Device 003: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad]
> Bus 001 Device 004: ID 5986:02d5 Acer, Inc
Can you show the "lusb -s 1:1 -v"?
>
> (inserted USB devices don't show up in this list)
>
> $ dmesg | grep -i usb
> [    0.996096] ACPI: bus type usb registered
> [    0.996428] usbcore: registered new interface driver usbfs
> [    0.996638] usbcore: registered new interface driver hub
> [    0.996875] usbcore: registered new device driver usb
> [    1.874896] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> [    1.876103] ehci-pci 0000:00:1a.0: new USB bus registered, assigned bus number 1
> [    1.886220] ehci-pci 0000:00:1a.0: USB 2.0 started, EHCI 1.00
> [    1.886781] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> [    1.886878] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    1.887017] usb usb1: Product: EHCI Host Controller
> [    1.887111] usb usb1: Manufacturer: Linux 3.8.0+ ehci_hcd
> [    1.887220] usb usb1: SerialNumber: 0000:00:1a.0
> [    1.888942] hub 1-0:1.0: USB hub found
> [    1.892347] ehci-pci 0000:00:1d.0: new USB bus registered, assigned bus number 2
> [    1.902216] ehci-pci 0000:00:1d.0: USB 2.0 started, EHCI 1.00
> [    1.902674] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
> [    1.902770] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    1.902910] usb usb2: Product: EHCI Host Controller
> [    1.903004] usb usb2: Manufacturer: Linux 3.8.0+ ehci_hcd
> [    1.903098] usb usb2: SerialNumber: 0000:00:1d.0
> [    1.904444] hub 2-0:1.0: USB hub found
> [    1.906795] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> [    1.906970] uhci_hcd: USB Universal Host Controller Interface driver
> [    1.908243] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 3
> [    1.909823] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002
> [    1.909920] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    1.910060] usb usb3: Product: xHCI Host Controller
> [    1.910153] usb usb3: Manufacturer: Linux 3.8.0+ xhci_hcd
> [    1.910260] usb usb3: SerialNumber: 0000:00:14.0
> [    1.911644] hub 3-0:1.0: USB hub found
> [    1.930176] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 4
> [    1.930802] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003
> [    1.930899] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
> [    1.931039] usb usb4: Product: xHCI Host Controller
> [    1.931131] usb usb4: Manufacturer: Linux 3.8.0+ xhci_hcd
> [    1.931239] usb usb4: SerialNumber: 0000:00:14.0
> [    1.932568] hub 4-0:1.0: USB hub found
> [    1.950215] usbcore: registered new interface driver usbserial
> [    1.950388] usbcore: registered new interface driver usbserial_generic
> [    1.950612] usbserial: USB Serial support registered for generic
> [    1.950781] usbcore: registered new interface driver usb_debug
> [    1.950959] usbserial: USB Serial support registered for debug
> [    1.972227] usbcore: registered new interface driver usbhid
> [    1.972322] usbhid: USB HID core driver
> [    2.193584] usb 1-1: new high-speed USB device number 2 using ehci-pci
> [    2.309836] usb 1-1: New USB device found, idVendor=8087, idProduct=0024
> [    2.309965] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> [    2.313198] hub 1-1:1.0: USB hub found
> [    2.436596] usb 2-1: new high-speed USB device number 2 using ehci-pci
> [    2.551777] usb 2-1: New USB device found, idVendor=8087, idProduct=0024
> [    2.551906] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> [    2.555603] hub 2-1:1.0: USB hub found
> [    2.673812] usb 1-1.4: new full-speed USB device number 3 using ehci-pci
> [    2.754662] usb 1-1.4: New USB device found, idVendor=0a5c, idProduct=21e6
> [    2.754791] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> [    2.754968] usb 1-1.4: Product: BCM20702A0
> [    2.755081] usb 1-1.4: Manufacturer: Broadcom Corp
> [    2.755194] usb 1-1.4: SerialNumber: 689423EB48E2
> [    2.827871] usb 1-1.6: new high-speed USB device number 4 using ehci-pci
> [    2.921573] usb 1-1.6: New USB device found, idVendor=5986, idProduct=02d5
> [    2.921671] usb 1-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> [    2.921820] usb 1-1.6: Product: Integrated Camera
> [    2.921932] usb 1-1.6: Manufacturer: Ricoh Company Ltd.
>
> *after this point, inserting devices made no printk's at all*
>
>
> 	Dave
>

-- 
Best Regards
Tianyu Lan
linux kernel enabling team

Re: [GIT PATCH] USB patches for 3.9-rc1

[Dave Jones]

On Fri, Feb 22, 2013 at 05:51:10PM +0800, Lan Tianyu wrote:

 > >   > Nothing major, lots of gadget fixes, and of course, xhci stuff.
 > >
 > > I get no USB devices recognised when I insert them any more, which
 > > I think is pretty major.  I suspect it has something to do with this ?
 > >
 > >   > Lan Tianyu (12):
 > >   >       usb: add runtime pm support for usb port device
 > >   >       usb: add usb port auto power off mechanism
 > >
 > > It looks like every port on my laptop is powered down, as I can't
 > > even charge devices with it.
 >
 > 	Do you enable the port/power/pm_qos_no_power_off?
 > 	cat /sys/bus/usb/devices/(dev)/port/power/pm_qos_no_power_off to show.

/sys/bus/usb/devices/1-1.4/port/power/pm_qos_no_power_off:1
/sys/bus/usb/devices/1-1.6/port/power/pm_qos_no_power_off:1
/sys/bus/usb/devices/1-1/port/power/pm_qos_no_power_off:1
/sys/bus/usb/devices/2-1/port/power/pm_qos_no_power_off:1

I changed them to 0, made no difference.

 > > What can I do to debug this ?
 > 	Can you attach the output of dmesg with CONFIG_USB_DEBUG?

http://paste.fedoraproject.org/3620

	Dave

Re: [GIT PATCH] USB patches for 3.9-rc1

[Lan Tianyu]

On 2013/2/23 0:43, Dave Jones wrote:
> On Fri, Feb 22, 2013 at 05:51:10PM +0800, Lan Tianyu wrote:
>
>   > >   > Nothing major, lots of gadget fixes, and of course, xhci stuff.
>   > >
>   > > I get no USB devices recognised when I insert them any more, which
>   > > I think is pretty major.  I suspect it has something to do with this ?
>   > >
>   > >   > Lan Tianyu (12):
>   > >   >       usb: add runtime pm support for usb port device
>   > >   >       usb: add usb port auto power off mechanism
>   > >
>   > > It looks like every port on my laptop is powered down, as I can't
>   > > even charge devices with it.
>   >
>   > 	Do you enable the port/power/pm_qos_no_power_off?
>   > 	cat /sys/bus/usb/devices/(dev)/port/power/pm_qos_no_power_off to show.
>
> /sys/bus/usb/devices/1-1.4/port/power/pm_qos_no_power_off:1
> /sys/bus/usb/devices/1-1.6/port/power/pm_qos_no_power_off:1
> /sys/bus/usb/devices/1-1/port/power/pm_qos_no_power_off:1
> /sys/bus/usb/devices/2-1/port/power/pm_qos_no_power_off:1
>
At last, this mean usb port power off mechanism should not work.

> I changed them to 0, made no difference.
>
>   > > What can I do to debug this ?
>   > 	Can you attach the output of dmesg with CONFIG_USB_DEBUG?
>
> http://paste.fedoraproject.org/3620
How about"sudo lsusb -s 1:1 -v" or "2:1"?
>
> 	Dave
>

-- 
Best Regards
Tianyu Lan
linux kernel enabling team

Re: [GIT PATCH] USB patches for 3.9-rc1

[Dave Jones]

On Sat, Feb 23, 2013 at 01:02:11AM +0800, Lan Tianyu wrote:

 > >   > > What can I do to debug this ?
 > >   > 	Can you attach the output of dmesg with CONFIG_USB_DEBUG?
 > >
 > > http://paste.fedoraproject.org/3620
 > How about"sudo lsusb -s 1:1 -v" or "2:1"?

(12:13:51:davej@t430s:~)$ sudo lsusb -s 1:1
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
(12:13:53:davej@t430s:~)$ sudo lsusb -s 2:1
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Re: [GIT PATCH] USB patches for 3.9-rc1

[Lan Tianyu]

On 2013/2/23 1:14, Dave Jones wrote:
> On Sat, Feb 23, 2013 at 01:02:11AM +0800, Lan Tianyu wrote:
>
>   > >   > > What can I do to debug this ?
>   > >   > 	Can you attach the output of dmesg with CONFIG_USB_DEBUG?
>   > >
>   > > http://paste.fedoraproject.org/3620
>   > How about"sudo lsusb -s 1:1 -v" or "2:1"?
>
> (12:13:51:davej@t430s:~)$ sudo lsusb -s 1:1
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> (12:13:53:davej@t430s:~)$ sudo lsusb -s 2:1
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>
Oh. Sorry, I didn't say clearly.
Please run
"sudo lsusb -s 1:1 -v"
"sudo lsusb -s 2:1 -v"

-- 
Best Regards
Tianyu Lan
linux kernel enabling team

Re: [GIT PATCH] USB patches for 3.9-rc1

[Dave Jones]

On Sat, Feb 23, 2013 at 01:17:42AM +0800, Lan Tianyu wrote:
 > On 2013/2/23 1:14, Dave Jones wrote:
 > > On Sat, Feb 23, 2013 at 01:02:11AM +0800, Lan Tianyu wrote:
 > >
 > >   > >   > > What can I do to debug this ?
 > >   > >   > 	Can you attach the output of dmesg with CONFIG_USB_DEBUG?
 > >   > >
 > >   > > http://paste.fedoraproject.org/3620
 > >   > How about"sudo lsusb -s 1:1 -v" or "2:1"?
 > >
 > > (12:13:51:davej@t430s:~)$ sudo lsusb -s 1:1
 > > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 > > (12:13:53:davej@t430s:~)$ sudo lsusb -s 2:1
 > > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 > >
 > Oh. Sorry, I didn't say clearly.
 > Please run
 > "sudo lsusb -s 1:1 -v"
 > "sudo lsusb -s 2:1 -v"

(12:20:00:davej@t430s:~)$ sudo lsusb -s 1:1 -v | fpaste
Uploading (2.3KiB)...
http://paste.fedoraproject.org/3623
(12:20:11:davej@t430s:~)$ sudo lsusb -s 2:1 -v | fpaste
Uploading (2.3KiB)...
http://paste.fedoraproject.org/3624

Re: [GIT PATCH] USB patches for 3.9-rc1

[Lan Tianyu]

On 2013/2/23 1:20, Dave Jones wrote:
> On Sat, Feb 23, 2013 at 01:17:42AM +0800, Lan Tianyu wrote:
>   > On 2013/2/23 1:14, Dave Jones wrote:
>   > > On Sat, Feb 23, 2013 at 01:02:11AM +0800, Lan Tianyu wrote:
>   > >
>   > >   > >   > > What can I do to debug this ?
>   > >   > >   > 	Can you attach the output of dmesg with CONFIG_USB_DEBUG?
>   > >   > >
>   > >   > > http://paste.fedoraproject.org/3620
>   > >   > How about"sudo lsusb -s 1:1 -v" or "2:1"?
>   > >
>   > > (12:13:51:davej@t430s:~)$ sudo lsusb -s 1:1
>   > > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>   > > (12:13:53:davej@t430s:~)$ sudo lsusb -s 2:1
>   > > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>   > >
>   > Oh. Sorry, I didn't say clearly.
>   > Please run
>   > "sudo lsusb -s 1:1 -v"
>   > "sudo lsusb -s 2:1 -v"
>
> (12:20:00:davej@t430s:~)$ sudo lsusb -s 1:1 -v | fpaste
> Uploading (2.3KiB)...
> http://paste.fedoraproject.org/3623
> (12:20:11:davej@t430s:~)$ sudo lsusb -s 2:1 -v | fpaste
> Uploading (2.3KiB)...
> http://paste.fedoraproject.org/3624
>
>
Please attach
"sudo lsusb -s 1:2 -v"
"sudo lsusb -s 2:2 -v"
"sudo lsusb -s 3:1 -v"
"sudo lsusb -s 4:1 -v"

How about disable runtime pm for root hub, intergrated hub and host controller?
echo on > (dev)/power/control
-- 
Best Regards
Tianyu Lan
linux kernel enabling team

Re: [GIT PATCH] USB patches for 3.9-rc1

[Fabio Baltieri]

On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote:
> On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote:
> 
>  > USB patches for 3.9-rc1
>  > 
>  > Here's the big USB merge for 3.9-rc1
>  > 
>  > Nothing major, lots of gadget fixes, and of course, xhci stuff.
> 
> I get no USB devices recognised when I insert them any more, which
> I think is pretty major.  I suspect it has something to do with this ?
> 
>  > Lan Tianyu (12):
>  >       usb: add runtime pm support for usb port device
>  >       usb: add usb port auto power off mechanism
> 
> It looks like every port on my laptop is powered down, as I can't
> even charge devices with it.

Hi Dave,

I have the same problem (and almost the same laptop, Thinkpad T430
here), all external USB ports without power - even the always-on one
:-).

The bug seems to be ACPI related, I bisected it down to this patch:

f95988d ACPI / scan: Treat power resources in a special way

In the dmesg I have some error like these:

ACPI: Power Resource [PUBS] (on)
...
pci 0000:00:14.0: System wakeup disabled by ACPI

for the USB controllers in the broken kernel, there are some in your
dmesg too.  I'll try to come up with a fix for current mainline, but all
the acpi stuff is quite obscure to me and the patch does not revert
cleanly, maybe Rafael (in CC) has some idea!

Fabio

-- 
Fabio Baltieri

Re: [GIT PATCH] USB patches for 3.9-rc1

[Dave Jones]

On Fri, Feb 22, 2013 at 10:51:58PM +0100, Fabio Baltieri wrote:
 > On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote:
 > > On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote:
 > > 
 > > It looks like every port on my laptop is powered down, as I can't
 > > even charge devices with it.
 > 
 > I have the same problem (and almost the same laptop, Thinkpad T430
 > here), all external USB ports without power - even the always-on one
 > :-).
 > 
 > The bug seems to be ACPI related, I bisected it down to this patch:
 > 
 > f95988d ACPI / scan: Treat power resources in a special way
 > 
 > In the dmesg I have some error like these:
 > 
 > ACPI: Power Resource [PUBS] (on)
 > ...
 > pci 0000:00:14.0: System wakeup disabled by ACPI
 > 
 > for the USB controllers in the broken kernel, there are some in your
 > dmesg too.  I'll try to come up with a fix for current mainline, but all
 > the acpi stuff is quite obscure to me and the patch does not revert
 > cleanly, maybe Rafael (in CC) has some idea!

Good find. I see the same thing.

[    0.930283] ACPI _OSC control for PCIe not granted, disabling ASPM
[    0.933527] pci 0000:00:14.0: System wakeup disabled by ACPI
[    0.935982] pci 0000:00:19.0: System wakeup disabled by ACPI
[    0.937898] pci 0000:00:1a.0: System wakeup disabled by ACPI
[    0.939835] pci 0000:00:1b.0: System wakeup disabled by ACPI
[    0.940700] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP1._PRT]
[    0.942195] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP2._PRT]
[    0.943737] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP3._PRT]
[    0.944564] pci 0000:00:1c.2: System wakeup disabled by ACPI
[    0.966491] pci 0000:00:1d.0: System wakeup disabled by ACPI

I must have pulled in the acpi bits the same time as the usb pull,
because I don't recall seeing this problem before last night.

	Dave

Re: [GIT PATCH] USB patches for 3.9-rc1

[Fabio Baltieri]

On Fri, Feb 22, 2013 at 05:23:04PM -0500, Dave Jones wrote:
> On Fri, Feb 22, 2013 at 10:51:58PM +0100, Fabio Baltieri wrote:
>  > On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote:
>  > > On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote:
>  > > 
>  > > It looks like every port on my laptop is powered down, as I can't
>  > > even charge devices with it.
>  > 
>  > I have the same problem (and almost the same laptop, Thinkpad T430
>  > here), all external USB ports without power - even the always-on one
>  > :-).
>  > 
>  > The bug seems to be ACPI related, I bisected it down to this patch:
>  > 
>  > f95988d ACPI / scan: Treat power resources in a special way
>  > 
>  > In the dmesg I have some error like these:
>  > 
>  > ACPI: Power Resource [PUBS] (on)
>  > ...
>  > pci 0000:00:14.0: System wakeup disabled by ACPI
>  > 
>  > for the USB controllers in the broken kernel, there are some in your
>  > dmesg too.  I'll try to come up with a fix for current mainline, but all
>  > the acpi stuff is quite obscure to me and the patch does not revert
>  > cleanly, maybe Rafael (in CC) has some idea!
> 
> Good find. I see the same thing.
> 
> [    0.930283] ACPI _OSC control for PCIe not granted, disabling ASPM
> [    0.933527] pci 0000:00:14.0: System wakeup disabled by ACPI
> [    0.935982] pci 0000:00:19.0: System wakeup disabled by ACPI
> [    0.937898] pci 0000:00:1a.0: System wakeup disabled by ACPI
> [    0.939835] pci 0000:00:1b.0: System wakeup disabled by ACPI
> [    0.940700] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP1._PRT]
> [    0.942195] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP2._PRT]
> [    0.943737] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP3._PRT]
> [    0.944564] pci 0000:00:1c.2: System wakeup disabled by ACPI
> [    0.966491] pci 0000:00:1d.0: System wakeup disabled by ACPI
> 
> I must have pulled in the acpi bits the same time as the usb pull,
> because I don't recall seeing this problem before last night.

Definitely.

Well, this did the trick in my case:

--- >8 ---
diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
index b820528..54175a0 100644
--- a/drivers/acpi/power.c
+++ b/drivers/acpi/power.c
@@ -795,7 +795,7 @@ int acpi_add_power_resource(acpi_handle handle)
        int state, result = -ENODEV;
 
        acpi_bus_get_device(handle, &device);
-       if (device)
+       if (!device)
                return 0;
 
        resource = kzalloc(sizeof(*resource), GFP_KERNEL);
--- >8 ---

But I guess it's working as a coincidence and something else is wrong -
I'll not even try to make a patch out of it and will leave the dirty
work to the ACPI guys instead.

Fabio

-- 
Fabio Baltieri

Re: [GIT PATCH] USB patches for 3.9-rc1

[Rafael J. Wysocki]

On Friday, February 22, 2013 10:51:58 PM Fabio Baltieri wrote:
> On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote:
> > On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote:
> > 
> >  > USB patches for 3.9-rc1
> >  > 
> >  > Here's the big USB merge for 3.9-rc1
> >  > 
> >  > Nothing major, lots of gadget fixes, and of course, xhci stuff.
> > 
> > I get no USB devices recognised when I insert them any more, which
> > I think is pretty major.  I suspect it has something to do with this ?
> > 
> >  > Lan Tianyu (12):
> >  >       usb: add runtime pm support for usb port device
> >  >       usb: add usb port auto power off mechanism
> > 
> > It looks like every port on my laptop is powered down, as I can't
> > even charge devices with it.
> 
> Hi Dave,
> 
> I have the same problem (and almost the same laptop, Thinkpad T430
> here), all external USB ports without power - even the always-on one
> :-).
> 
> The bug seems to be ACPI related, I bisected it down to this patch:
> 
> f95988d ACPI / scan: Treat power resources in a special way
> 
> In the dmesg I have some error like these:
> 
> ACPI: Power Resource [PUBS] (on)
> ...
> pci 0000:00:14.0: System wakeup disabled by ACPI

They aren't errors in fact, just info messages.

> for the USB controllers in the broken kernel, there are some in your
> dmesg too.  I'll try to come up with a fix for current mainline, but all
> the acpi stuff is quite obscure to me and the patch does not revert
> cleanly, maybe Rafael (in CC) has some idea!

It won't revert, there's more stuff on top of it.  And it is a fix, so
reverting it is not really a good idea anyway.

I suspect that the USB controllers are put into low-power states at one
point and they don't generate wakeup events.  I'm not sure, though, why this
is related to power resources.

Can you please send a dmesg boot log and the output of acpidump from the
affected machine?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [GIT PATCH] USB patches for 3.9-rc1

[Rafael J. Wysocki]

On Friday, February 22, 2013 05:23:04 PM Dave Jones wrote:
> On Fri, Feb 22, 2013 at 10:51:58PM +0100, Fabio Baltieri wrote:
>  > On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote:
>  > > On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote:
>  > > 
>  > > It looks like every port on my laptop is powered down, as I can't
>  > > even charge devices with it.
>  > 
>  > I have the same problem (and almost the same laptop, Thinkpad T430
>  > here), all external USB ports without power - even the always-on one
>  > :-).
>  > 
>  > The bug seems to be ACPI related, I bisected it down to this patch:
>  > 
>  > f95988d ACPI / scan: Treat power resources in a special way
>  > 
>  > In the dmesg I have some error like these:
>  > 
>  > ACPI: Power Resource [PUBS] (on)
>  > ...
>  > pci 0000:00:14.0: System wakeup disabled by ACPI
>  > 
>  > for the USB controllers in the broken kernel, there are some in your
>  > dmesg too.  I'll try to come up with a fix for current mainline, but all
>  > the acpi stuff is quite obscure to me and the patch does not revert
>  > cleanly, maybe Rafael (in CC) has some idea!
> 
> Good find. I see the same thing.
> 
> [    0.930283] ACPI _OSC control for PCIe not granted, disabling ASPM
> [    0.933527] pci 0000:00:14.0: System wakeup disabled by ACPI
> [    0.935982] pci 0000:00:19.0: System wakeup disabled by ACPI
> [    0.937898] pci 0000:00:1a.0: System wakeup disabled by ACPI
> [    0.939835] pci 0000:00:1b.0: System wakeup disabled by ACPI
> [    0.940700] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP1._PRT]
> [    0.942195] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP2._PRT]
> [    0.943737] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP3._PRT]
> [    0.944564] pci 0000:00:1c.2: System wakeup disabled by ACPI
> [    0.966491] pci 0000:00:1d.0: System wakeup disabled by ACPI
> 
> I must have pulled in the acpi bits the same time as the usb pull,
> because I don't recall seeing this problem before last night.

Can you please check if the problem is still there in the master branch of
the linux-pm.git tree alone?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [GIT PATCH] USB patches for 3.9-rc1

[Linus Torvalds]

On Fri, Feb 22, 2013 at 4:19 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
> It won't revert, there's more stuff on top of it.  And it is a fix, so
> reverting it is not really a good idea anyway.

Rafael, please don't *ever* write that crap again.

We revert stuff whether it "fixed" something else or not. The rule is
"NO REGRESSIONS". It doesn't matter one whit if something "fixes"
something else or not - if it breaks an old case, it gets reverted.

Seriously. Why do I even have to mention this? Why do I have to
explain this to somebody pretty much *every* f*cking merge window?

This is not a new rule.

And btw, the *reason* for that rule becoming such a hard rule was
pretty much exactly suspend/resume and ACPI. Exactly because we used
to have those infinite "let's fix one thing and break another" dances.
So you should be well acquainted with the rule, and I'm surprised to
hear that kind of utter garbage from you in particular.

There is no excuse for regressions, and "it is a fix" is actually the
_least_ valid of all reasons.

A commit that causes a regression is - by definition - not a "fix". So
please don't *ever* say something that stupid again.

Things that used to work are simply a million times more important
than things that historically didn't work.

So this had better get fixed asap, and I need to feel like people are
working on it. Otherwise we start reverting.

And no amount "but it's a fix" matters one whit. In fact, it just
makes me feel like I need to start reverting early, because the
maintainer doesn't seem to understand how serious a regression is.

                  Linus

Re: [GIT PATCH] USB patches for 3.9-rc1

[Rafael J. Wysocki]

On Saturday, February 23, 2013 01:10:55 AM Fabio Baltieri wrote:
> On Fri, Feb 22, 2013 at 05:23:04PM -0500, Dave Jones wrote:
> > On Fri, Feb 22, 2013 at 10:51:58PM +0100, Fabio Baltieri wrote:
> >  > On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote:
> >  > > On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote:
> >  > > 
> >  > > It looks like every port on my laptop is powered down, as I can't
> >  > > even charge devices with it.
> >  > 
> >  > I have the same problem (and almost the same laptop, Thinkpad T430
> >  > here), all external USB ports without power - even the always-on one
> >  > :-).
> >  > 
> >  > The bug seems to be ACPI related, I bisected it down to this patch:
> >  > 
> >  > f95988d ACPI / scan: Treat power resources in a special way
> >  > 
> >  > In the dmesg I have some error like these:
> >  > 
> >  > ACPI: Power Resource [PUBS] (on)
> >  > ...
> >  > pci 0000:00:14.0: System wakeup disabled by ACPI
> >  > 
> >  > for the USB controllers in the broken kernel, there are some in your
> >  > dmesg too.  I'll try to come up with a fix for current mainline, but all
> >  > the acpi stuff is quite obscure to me and the patch does not revert
> >  > cleanly, maybe Rafael (in CC) has some idea!
> > 
> > Good find. I see the same thing.
> > 
> > [    0.930283] ACPI _OSC control for PCIe not granted, disabling ASPM
> > [    0.933527] pci 0000:00:14.0: System wakeup disabled by ACPI
> > [    0.935982] pci 0000:00:19.0: System wakeup disabled by ACPI
> > [    0.937898] pci 0000:00:1a.0: System wakeup disabled by ACPI
> > [    0.939835] pci 0000:00:1b.0: System wakeup disabled by ACPI
> > [    0.940700] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP1._PRT]
> > [    0.942195] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP2._PRT]
> > [    0.943737] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP3._PRT]
> > [    0.944564] pci 0000:00:1c.2: System wakeup disabled by ACPI
> > [    0.966491] pci 0000:00:1d.0: System wakeup disabled by ACPI
> > 
> > I must have pulled in the acpi bits the same time as the usb pull,
> > because I don't recall seeing this problem before last night.
> 
> Definitely.
> 
> Well, this did the trick in my case:
> 
> --- >8 ---
> diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
> index b820528..54175a0 100644
> --- a/drivers/acpi/power.c
> +++ b/drivers/acpi/power.c
> @@ -795,7 +795,7 @@ int acpi_add_power_resource(acpi_handle handle)
>         int state, result = -ENODEV;
>  
>         acpi_bus_get_device(handle, &device);
> -       if (device)
> +       if (!device)
>                 return 0;
>  
>         resource = kzalloc(sizeof(*resource), GFP_KERNEL);
> --- >8 ---
> 
> But I guess it's working as a coincidence and something else is wrong -
> I'll not even try to make a patch out of it and will leave the dirty
> work to the ACPI guys instead.

Well, this patch effectively disables the handling of power resources on your
machine entirely.  The effect of which is probably that the power resources
can't be turned off for the USB controllers, so they don't go into D3cold.

And the bisection found a commit that restores the handling of power resources
for you, which is not entirely surprising, but the root cause is somewhere else
most likely.

The new sysfs interface for power resources control may be helpful here.  You
need to use the Linus' current for it to work, though.

Can you please do

$ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;

$ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {} \;

$ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls {} \;

$ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {} \;

and send the output?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [GIT PATCH] USB patches for 3.9-rc1

[Rafael J. Wysocki]

On Friday, February 22, 2013 04:30:25 PM Linus Torvalds wrote:
> On Fri, Feb 22, 2013 at 4:19 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >
> > It won't revert, there's more stuff on top of it.  And it is a fix, so
> > reverting it is not really a good idea anyway.
> 
> Rafael, please don't *ever* write that crap again.
> 
> We revert stuff whether it "fixed" something else or not. The rule is
> "NO REGRESSIONS". It doesn't matter one whit if something "fixes"
> something else or not - if it breaks an old case, it gets reverted.
> 
> Seriously. Why do I even have to mention this? Why do I have to
> explain this to somebody pretty much *every* f*cking merge window?

Well, sorry.  I shouldn't have said that.

The problem is, though, that even if bisection turns up something, it doesn't
automatically mean that this particular commit is the one that caused the
problem to happen in the first place.

And in this particular case bisection turns up a commit that enables something
that didn't work on that particular machine for some time.  It used to work,
then it stopped working and that commit made it work again.  And the fact that
it made it work again caused something different to trigger the result of which
is the observed breakage.

I'm obviously going to fix it, because it is a serious problem, but the commit
in question is not the root cause of it in my opinion (as I wrote to Fabio in
another message).

> This is not a new rule.
> 
> And btw, the *reason* for that rule becoming such a hard rule was
> pretty much exactly suspend/resume and ACPI. Exactly because we used
> to have those infinite "let's fix one thing and break another" dances.
> So you should be well acquainted with the rule, and I'm surprised to
> hear that kind of utter garbage from you in particular.
> 
> There is no excuse for regressions, and "it is a fix" is actually the
> _least_ valid of all reasons.
> 
> A commit that causes a regression is - by definition - not a "fix". So
> please don't *ever* say something that stupid again.
> 
> Things that used to work are simply a million times more important
> than things that historically didn't work.
> 
> So this had better get fixed asap, and I need to feel like people are
> working on it. Otherwise we start reverting.
> 
> And no amount "but it's a fix" matters one whit. In fact, it just
> makes me feel like I need to start reverting early, because the
> maintainer doesn't seem to understand how serious a regression is.

OK, OK.

Please let me understand what the problem is first.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [GIT PATCH] USB patches for 3.9-rc1

[Rafael J. Wysocki]

On Friday, February 22, 2013 10:51:58 PM Fabio Baltieri wrote:
> On Fri, Feb 22, 2013 at 03:59:54AM -0500, Dave Jones wrote:
> > On Thu, Feb 21, 2013 at 10:40:10AM -0800, Greg KH wrote:
> > 
> >  > USB patches for 3.9-rc1
> >  > 
> >  > Here's the big USB merge for 3.9-rc1
> >  > 
> >  > Nothing major, lots of gadget fixes, and of course, xhci stuff.
> > 
> > I get no USB devices recognised when I insert them any more, which
> > I think is pretty major.  I suspect it has something to do with this ?
> > 
> >  > Lan Tianyu (12):
> >  >       usb: add runtime pm support for usb port device
> >  >       usb: add usb port auto power off mechanism
> > 
> > It looks like every port on my laptop is powered down, as I can't
> > even charge devices with it.
> 
> Hi Dave,
> 
> I have the same problem (and almost the same laptop, Thinkpad T430
> here), all external USB ports without power - even the always-on one
> :-).
> 
> The bug seems to be ACPI related, I bisected it down to this patch:
> 
> f95988d ACPI / scan: Treat power resources in a special way
> 
> In the dmesg I have some error like these:
> 
> ACPI: Power Resource [PUBS] (on)
> ...
> pci 0000:00:14.0: System wakeup disabled by ACPI
> 
> for the USB controllers in the broken kernel, there are some in your
> dmesg too.  I'll try to come up with a fix for current mainline, but all
> the acpi stuff is quite obscure to me and the patch does not revert
> cleanly, maybe Rafael (in CC) has some idea!

May I see the bisection log, BTW?

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [GIT PATCH] USB patches for 3.9-rc1

[Linus Torvalds]

On Fri, Feb 22, 2013 at 4:48 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
> The problem is, though, that even if bisection turns up something, it doesn't
> automatically mean that this particular commit is the one that caused the
> problem to happen in the first place.

No, I agree. I just react *very* strongly when somebody starts arguing
against reverting.

The fact that the commit that was bisected fixes another bug in a
previous commit does in fact just imply that that *previous* commit
should perhaps be reverted. Of course, I see that that is the first in
the whole series, so I understand the pain, but even so..

And looking at that commit that makes power resources be treated
specially, that looks completely bogus. It's not what the old code did
either, and it seems to be a total hack for the breakage that just
happens to fix that one machine for purely random reasons, as far as I
can tell. The ACPI_BUS_TYPE_POWER case always had match=1 before, no?

The thing that looks to have been dropped somewhere is that

  .acpi_op_start = !!context,

which first became

  device->add_type = context ? ACPI_BUS_ADD_START : ACPI_BUS_ADD_MATCH;

and then somehow that wasn't needed any more, so it became just an unconditional

  device->add_type = ACPI_BUS_ADD_START;

for unexplained reasons (the commit message says that the argument
"context" wasn't used, and renames it not_used to reinforce the point,
but doesn't explain why it can remove the use that was there).

That unconditional "add_type = ACPI_BUS_ADD_START" then later becomes
"flags.match_driver = true", which is where the whole match_driver
thing comes in.

Anyway, I don't see how magically it became about ACPI_BUS_TYPE_POWER.
The code is not exactly obvious, though, so whatever. But that
"context is suddenly not used" commit (e3863094c6f9: "ACPI: Drop the
second argument of acpi_bus_scan()") looks odd.

Maybe "context" was effectively always non-NULL, but it *looks* like
that series of commits is intended to have no semantic changes, and
that's the one that looked very dubious to me.

                   Linus

Re: [GIT PATCH] USB patches for 3.9-rc1

[Fabio Baltieri]

On Sat, Feb 23, 2013 at 01:35:26AM +0100, Rafael J. Wysocki wrote:
> On Saturday, February 23, 2013 01:10:55 AM Fabio Baltieri wrote:
> > Well, this did the trick in my case:
> > 
> > --- >8 ---
> > diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
> > index b820528..54175a0 100644
> > --- a/drivers/acpi/power.c
> > +++ b/drivers/acpi/power.c
> > @@ -795,7 +795,7 @@ int acpi_add_power_resource(acpi_handle handle)
> >         int state, result = -ENODEV;
> >  
> >         acpi_bus_get_device(handle, &device);
> > -       if (device)
> > +       if (!device)
> >                 return 0;
> >  
> >         resource = kzalloc(sizeof(*resource), GFP_KERNEL);
> > --- >8 ---
> > 
> > But I guess it's working as a coincidence and something else is wrong -
> > I'll not even try to make a patch out of it and will leave the dirty
> > work to the ACPI guys instead.
> 
> Well, this patch effectively disables the handling of power resources on your
> machine entirely.  The effect of which is probably that the power resources
> can't be turned off for the USB controllers, so they don't go into D3cold.

Ok, as I wrote, I suspected this was just shutting off something and not
solving the real problem.

So, I'll try to recap all the threads here:

> And the bisection found a commit that restores the handling of power resources
> for you, which is not entirely surprising, but the root cause is somewhere else
> most likely.

Indeed.

> The new sysfs interface for power resources control may be helpful here.  You
> need to use the Linus' current for it to work, though.
> 
> Can you please do
> 
> $ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
> $ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {} \;
> $ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls {} \;
> $ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {} \;
> and send the output?

With the acpi_add_power_resource disabled all power_state read "D0",
other attributes are not generated.

With a plain kernel that's the output:

$ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:09/LNXVIDEO:01/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_state
D0
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/power_state
D0

$ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/real_power_state
D3cold
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/real_power_state
D3cold
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/real_power_state
D3cold

$ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls {} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D0
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D1
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D2
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D0
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D1
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D2
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D0
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D1
LNXPOWER:00
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D2
LNXPOWER:00

$ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {} \;
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/PNP0C09:00/LNXPOWER:00/resource_in_use
0

> Can you please check if the problem is still there in the master
> branch of the linux-pm.git tree alone?

Not sure if this was for me or Dave, anyway linux-pm.git master
currently points as:

10baf04 Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux

and the problem is still there.

> May I see the bisection log, BTW?

Sure, here it is:

git bisect start
# bad: [8793422fd9ac5037f5047f80473007301df3689f] Merge tag 'pm+acpi-3.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect bad 8793422fd9ac5037f5047f80473007301df3689f
# good: [19f949f52599ba7c3f67a5897ac6be14bfcb1200] Linux 3.8
git bisect good 19f949f52599ba7c3f67a5897ac6be14bfcb1200
# good: [8909ff652ddfc83ecdf450f96629c25489d88f77] Merge tag 'regulator-3.9' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
git bisect good 8909ff652ddfc83ecdf450f96629c25489d88f77
# good: [3aad3f03b2b6d2d977b985c49274cdb78a1593e5] Merge tag 'spi-for-linus' of git://git.secretlab.ca/git/linux
git bisect good 3aad3f03b2b6d2d977b985c49274cdb78a1593e5
# bad: [e8f71df723339b6d3861886f58c245812d1994f8] Merge branch 'acpi-cleanup'
git bisect bad e8f71df723339b6d3861886f58c245812d1994f8
# bad: [701190fd7419f6757c19cdc6473830c79debb3ae] clk: x86: add support for Lynxpoint LPSS clocks
git bisect bad 701190fd7419f6757c19cdc6473830c79debb3ae
# good: [3e5621a750e2cfb26748c34acbb67c691845494a] ACPICA: Update ACPICA initialization messages.
git bisect good 3e5621a750e2cfb26748c34acbb67c691845494a
# bad: [115c9ad854bd4c0f58ebcb967ec1b0a1c4e4b2d3] ACPI: remove unused acpi_op_bind and acpi_op_unbind
git bisect bad 115c9ad854bd4c0f58ebcb967ec1b0a1c4e4b2d3
# good: [e3863094c6f9b2f980d6e7a5cad6b4d03a4dd579] ACPI: Drop the second argument of acpi_bus_scan()
git bisect good e3863094c6f9b2f980d6e7a5cad6b4d03a4dd579
# good: [38a9a67a281eeebcd7cccf87f0e371f58ae625e3] ACPI / PCI: Move the _PRT setup and cleanup code to pci-acpi.c
git bisect good 38a9a67a281eeebcd7cccf87f0e371f58ae625e3
# good: [e0ebda2ee12c261fb2f2d7abf21489b93d9caa4e] ACPI: Remove unused struct acpi_pci_root.id member
git bisect good e0ebda2ee12c261fb2f2d7abf21489b93d9caa4e
# bad: [abe99210e0f624cea39f1dc375ba818b201c0d7f] ACPI / scan: Fix check of device_attach() return value.
git bisect bad abe99210e0f624cea39f1dc375ba818b201c0d7f
# bad: [f95988de06ea62ef5bd861f06e9ef56cea405ed1] ACPI / scan: Treat power resources in a special way
git bisect bad f95988de06ea62ef5bd861f06e9ef56cea405ed1

> Can you please send a dmesg boot log and the output of acpidump from the
> affected machine?

dmesg:
http://paste.ubuntu.com/5556864/

acpidump:
http://paste.ubuntu.com/5556867/

Thanks,
Fabio

-- 
Fabio Baltieri

Re: [GIT PATCH] USB patches for 3.9-rc1

[Rafael J. Wysocki]

On Friday, February 22, 2013 05:10:43 PM Linus Torvalds wrote:
> On Fri, Feb 22, 2013 at 4:48 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >
> > The problem is, though, that even if bisection turns up something, it doesn't
> > automatically mean that this particular commit is the one that caused the
> > problem to happen in the first place.
> 
> No, I agree. I just react *very* strongly when somebody starts arguing
> against reverting.
> 
> The fact that the commit that was bisected fixes another bug in a
> previous commit does in fact just imply that that *previous* commit
> should perhaps be reverted. Of course, I see that that is the first in
> the whole series, so I understand the pain, but even so..
> 
> And looking at that commit that makes power resources be treated
> specially, that looks completely bogus. It's not what the old code did
> either, and it seems to be a total hack for the breakage that just
> happens to fix that one machine for purely random reasons, as far as I
> can tell. The ACPI_BUS_TYPE_POWER case always had match=1 before, no?

It had, when it was called from acpi_bus_add_power_resource(), but that
was not the only way power resources could be added.  That function was only
called when we found a device using power resources and we needed to add them
before adding that device (if they were not present already).

The second way we could add power resources was during the normal namespace
walk and that case was broken.

> The thing that looks to have been dropped somewhere is that
> 
>   .acpi_op_start = !!context,
> 
> which first became
> 
>   device->add_type = context ? ACPI_BUS_ADD_START : ACPI_BUS_ADD_MATCH;
> 
> and then somehow that wasn't needed any more, so it became just an unconditional
> 
>   device->add_type = ACPI_BUS_ADD_START;
> 
> for unexplained reasons (the commit message says that the argument
> "context" wasn't used, and renames it not_used to reinforce the point,
> but doesn't explain why it can remove the use that was there).
> 
> That unconditional "add_type = ACPI_BUS_ADD_START" then later becomes
> "flags.match_driver = true", which is where the whole match_driver
> thing comes in.
> 
> Anyway, I don't see how magically it became about ACPI_BUS_TYPE_POWER.

If we added a power resource with acpi_add_single_object(..., false) from
acpi_bus_check_add(), later acpi_bus_add_power_resource() saw that it
was already present and didn't add it either.  The power resource was there at
that point, but it didn't have a driver (which only would be probed in the
second pass, after all ACPI devices had been registered).  The driver was
needed, though, for the initialization of the power management of devices
depending on that power resource.

The fact that it was missing caused power management of devices depending on
that power resource not to be initialized correctly and changing their power
states didn't really work going forward.

That's why the Fabio's bisection turned up that commit, BTW (the changing
of USB controllers' power states didn't really work before it on his machine).

I put ACPI_BUS_TYPE_POWER in there, because power resources always needed
'true' in the last arg of acpi_add_single_object() and they were the only type
needing it.

> The code is not exactly obvious, though, so whatever. But that
> "context is suddenly not used" commit (e3863094c6f9: "ACPI: Drop the
> second argument of acpi_bus_scan()") looks odd.
> 
> Maybe "context" was effectively always non-NULL, but it *looks* like
> that series of commits is intended to have no semantic changes, and
> that's the one that looked very dubious to me.

While I might make a mistake in it, I seriously doubt that it is the root
cause of the problem at hand.

It surely is related to PCI power management and to the fact that PCI devices
can go into D3cold at run time now.  This isn't an old change and there were
problems with it.  The known problems were fixed, but there might be more to
uncover and it looks like we've just run into a new one. :-(

So I really need to know what's going on before deciding how to fix that.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [GIT PATCH] USB patches for 3.9-rc1

[Rafael J. Wysocki]

On Saturday, February 23, 2013 02:44:27 AM Fabio Baltieri wrote:
> On Sat, Feb 23, 2013 at 01:35:26AM +0100, Rafael J. Wysocki wrote:
> > On Saturday, February 23, 2013 01:10:55 AM Fabio Baltieri wrote:
> > > Well, this did the trick in my case:
> > > 
> > > --- >8 ---
> > > diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
> > > index b820528..54175a0 100644
> > > --- a/drivers/acpi/power.c
> > > +++ b/drivers/acpi/power.c
> > > @@ -795,7 +795,7 @@ int acpi_add_power_resource(acpi_handle handle)
> > >         int state, result = -ENODEV;
> > >  
> > >         acpi_bus_get_device(handle, &device);
> > > -       if (device)
> > > +       if (!device)
> > >                 return 0;
> > >  
> > >         resource = kzalloc(sizeof(*resource), GFP_KERNEL);
> > > --- >8 ---
> > > 
> > > But I guess it's working as a coincidence and something else is wrong -
> > > I'll not even try to make a patch out of it and will leave the dirty
> > > work to the ACPI guys instead.
> > 
> > Well, this patch effectively disables the handling of power resources on your
> > machine entirely.  The effect of which is probably that the power resources
> > can't be turned off for the USB controllers, so they don't go into D3cold.
> 
> Ok, as I wrote, I suspected this was just shutting off something and not
> solving the real problem.
> 
> So, I'll try to recap all the threads here:
> 
> > And the bisection found a commit that restores the handling of power resources
> > for you, which is not entirely surprising, but the root cause is somewhere else
> > most likely.
> 
> Indeed.
> 
> > The new sysfs interface for power resources control may be helpful here.  You
> > need to use the Linus' current for it to work, though.
> > 
> > Can you please do
> > 
> > $ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
> > $ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {} \;
> > $ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls {} \;
> > $ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {} \;
> > and send the output?
> 
> With the acpi_add_power_resource disabled all power_state read "D0",
> other attributes are not generated.

Yup.  That's how it should be.

> With a plain kernel that's the output:
> 
> $ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:09/LNXVIDEO:01/power_state
> D0
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_state
> D0
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_state
> D0
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_state
> D0
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/power_state
> D0
> 
> $ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {} \;
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/real_power_state
> D3cold
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/real_power_state
> D3cold
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/real_power_state
> D3cold

This is obviously wrong.  We expect the devices to be in D0, while they really
are in D3cold.  Let's look deeper.

> $ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls {} \;
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D0
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D1
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D2
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D0
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D1
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D2
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D0
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D1
> LNXPOWER:00
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D2
> LNXPOWER:00

PNP0A08 is the PCI root bridge and device:29, device:34, device:1f are the USB
controllers.  All of them have ACPI power states D0, D1, D2 and D3cold, where
D0-D2 depend on the same power resource, so in fact they all are the same state
(what sense does this make?).

I suspect that the power resource being shared (and it being shared in such a
broken way) has to do something with the breakage.

> $ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {} \;
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/PNP0C09:00/LNXPOWER:00/resource_in_use
> 0

There's one power resource in the system and it's usage count is 0, so it is
"off" (which is consistent with the real power states of the USB controllers).

Now, the boot log shows that the power resource was "on" when it was found,
so the initial states of the USB controllers should have been D0.

However, the DSDT source shows that the very same power resource that the D0-D2
power states of the devices depend on is listed for them as a wakeup power
resource by _PRW.  [Is that even valid?  It doesn't seem to make sense anyway.]
Thus when pci_acpi_setup() does acpi_pci_sleep_wake(pci_dev, false), which
calls acpi_pm_device_sleep_wake(&dev->dev, false), eventually
acpi_disable_wakeup_device_power() will be called for the device.  This leads
to calling acpi_power_off_list() for wakeup resources and that list includes
our single power resource, so its refcount will be dropped and it will be
turned off silently without updating the current power state of the device.

So first, the commit that broke things for you was probably
d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device wakeup) which moved
the wakeup initialization, but didn't show up in the bisection, because the
power resources handling didn't work at that point.  And if I'm not mistaken,
it only broke things because we've never assumed that a wakeup power resource
may be the same as a power resource the device's power states depend on (which
we should).

Now, how to fix this is an interesting problem.

After some consideration I got the appended patch, but I'm really tired now
and couldn't really test it, so caveat emptor.  I'll look at it once again
tomorrow and see if it still makes sense to me then.

> > Can you please check if the problem is still there in the master
> > branch of the linux-pm.git tree alone?
> 
> Not sure if this was for me or Dave, anyway linux-pm.git master
> currently points as:
> 
> 10baf04 Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux
> 
> and the problem is still there.

OK, thanks for verifying this.

> > May I see the bisection log, BTW?
> 
> Sure, here it is:
> 
> git bisect start
> # bad: [8793422fd9ac5037f5047f80473007301df3689f] Merge tag 'pm+acpi-3.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
> git bisect bad 8793422fd9ac5037f5047f80473007301df3689f
> # good: [19f949f52599ba7c3f67a5897ac6be14bfcb1200] Linux 3.8
> git bisect good 19f949f52599ba7c3f67a5897ac6be14bfcb1200
> # good: [8909ff652ddfc83ecdf450f96629c25489d88f77] Merge tag 'regulator-3.9' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
> git bisect good 8909ff652ddfc83ecdf450f96629c25489d88f77
> # good: [3aad3f03b2b6d2d977b985c49274cdb78a1593e5] Merge tag 'spi-for-linus' of git://git.secretlab.ca/git/linux
> git bisect good 3aad3f03b2b6d2d977b985c49274cdb78a1593e5
> # bad: [e8f71df723339b6d3861886f58c245812d1994f8] Merge branch 'acpi-cleanup'
> git bisect bad e8f71df723339b6d3861886f58c245812d1994f8
> # bad: [701190fd7419f6757c19cdc6473830c79debb3ae] clk: x86: add support for Lynxpoint LPSS clocks
> git bisect bad 701190fd7419f6757c19cdc6473830c79debb3ae
> # good: [3e5621a750e2cfb26748c34acbb67c691845494a] ACPICA: Update ACPICA initialization messages.
> git bisect good 3e5621a750e2cfb26748c34acbb67c691845494a
> # bad: [115c9ad854bd4c0f58ebcb967ec1b0a1c4e4b2d3] ACPI: remove unused acpi_op_bind and acpi_op_unbind
> git bisect bad 115c9ad854bd4c0f58ebcb967ec1b0a1c4e4b2d3
> # good: [e3863094c6f9b2f980d6e7a5cad6b4d03a4dd579] ACPI: Drop the second argument of acpi_bus_scan()
> git bisect good e3863094c6f9b2f980d6e7a5cad6b4d03a4dd579
> # good: [38a9a67a281eeebcd7cccf87f0e371f58ae625e3] ACPI / PCI: Move the _PRT setup and cleanup code to pci-acpi.c
> git bisect good 38a9a67a281eeebcd7cccf87f0e371f58ae625e3
> # good: [e0ebda2ee12c261fb2f2d7abf21489b93d9caa4e] ACPI: Remove unused struct acpi_pci_root.id member
> git bisect good e0ebda2ee12c261fb2f2d7abf21489b93d9caa4e
> # bad: [abe99210e0f624cea39f1dc375ba818b201c0d7f] ACPI / scan: Fix check of device_attach() return value.
> git bisect bad abe99210e0f624cea39f1dc375ba818b201c0d7f
> # bad: [f95988de06ea62ef5bd861f06e9ef56cea405ed1] ACPI / scan: Treat power resources in a special way
> git bisect bad f95988de06ea62ef5bd861f06e9ef56cea405ed1

Thanks.  I had hoped it would give me a hint, but it didn't after all.

> > Can you please send a dmesg boot log and the output of acpidump from the
> > affected machine?
> 
> dmesg:
> http://paste.ubuntu.com/5556864/
> 
> acpidump:
> http://paste.ubuntu.com/5556867/

Thanks a lot for the great info, it all helped.

Thanks,
Rafael


---
 drivers/acpi/internal.h |    2 
 drivers/acpi/power.c    |  106 ++++++++++++++++++++++++++++++++++++------------
 drivers/acpi/scan.c     |    2 
 3 files changed, 82 insertions(+), 28 deletions(-)

Index: test/drivers/acpi/internal.h
===================================================================
--- test.orig/drivers/acpi/internal.h
+++ test/drivers/acpi/internal.h
@@ -84,7 +84,7 @@ int acpi_extract_power_resources(union a
 				 struct list_head *list);
 int acpi_add_power_resource(acpi_handle handle);
 void acpi_power_add_remove_device(struct acpi_device *adev, bool add);
-int acpi_power_min_system_level(struct list_head *list);
+int acpi_power_wakeup_list_init(struct list_head *list);
 int acpi_device_sleep_wake(struct acpi_device *dev,
                            int enable, int sleep_state, int dev_state);
 int acpi_power_get_inferred_state(struct acpi_device *device, int *state);
Index: test/drivers/acpi/power.c
===================================================================
--- test.orig/drivers/acpi/power.c
+++ test/drivers/acpi/power.c
@@ -73,6 +73,7 @@ struct acpi_power_resource {
 	u32 system_level;
 	u32 order;
 	unsigned int ref_count;
+	bool wakeup_enabled;
 	struct mutex resource_lock;
 };
 
@@ -272,11 +273,9 @@ static int __acpi_power_on(struct acpi_p
 	return 0;
 }
 
-static int acpi_power_on(struct acpi_power_resource *resource)
+static int acpi_power_on_unlocked(struct acpi_power_resource *resource)
 {
-	int result = 0;;
-
-	mutex_lock(&resource->resource_lock);
+	int result = 0;
 
 	if (resource->ref_count++) {
 		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
@@ -293,9 +292,16 @@ static int acpi_power_on(struct acpi_pow
 				schedule_work(&dep->work);
 		}
 	}
+	return result;
+}
 
-	mutex_unlock(&resource->resource_lock);
+static int acpi_power_on(struct acpi_power_resource *resource)
+{
+	int result;
 
+	mutex_lock(&resource->resource_lock);
+	result = acpi_power_on_unlocked(resource);
+	mutex_unlock(&resource->resource_lock);
 	return result;
 }
 
@@ -313,17 +319,15 @@ static int __acpi_power_off(struct acpi_
 	return 0;
 }
 
-static int acpi_power_off(struct acpi_power_resource *resource)
+static int acpi_power_off_unlocked(struct acpi_power_resource *resource)
 {
 	int result = 0;
 
-	mutex_lock(&resource->resource_lock);
-
 	if (!resource->ref_count) {
 		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
 				  "Power resource [%s] already off",
 				  resource->name));
-		goto unlock;
+		return 0;
 	}
 
 	if (--resource->ref_count) {
@@ -335,10 +339,16 @@ static int acpi_power_off(struct acpi_po
 		if (result)
 			resource->ref_count++;
 	}
+	return result;
+}
 
- unlock:
-	mutex_unlock(&resource->resource_lock);
+static int acpi_power_off(struct acpi_power_resource *resource)
+{
+	int result;
 
+	mutex_lock(&resource->resource_lock);
+	result = acpi_power_off_unlocked(resource);
+	mutex_unlock(&resource->resource_lock);
 	return result;
 }
 
@@ -521,16 +531,29 @@ void acpi_power_add_remove_device(struct
 	}
 }
 
-int acpi_power_min_system_level(struct list_head *list)
+int acpi_power_wakeup_list_init(struct list_head *list)
 {
 	struct acpi_power_resource_entry *entry;
 	int system_level = 5;
 
 	list_for_each_entry(entry, list, node) {
 		struct acpi_power_resource *resource = entry->resource;
+		acpi_handle handle = resource->device.handle;
+		int result;
+		int state;
+
+		mutex_lock(&resource->resource_lock);
+
+		result = acpi_power_get_state(handle, &state);
+		if (!result && state == ACPI_POWER_RESOURCE_STATE_ON) {
+			resource->ref_count++;
+			resource->wakeup_enabled = true;
+		}
 
 		if (system_level > resource->system_level)
 			system_level = resource->system_level;
+
+		mutex_unlock(&resource->resource_lock);
 	}
 	return system_level;
 }
@@ -610,6 +633,7 @@ int acpi_device_sleep_wake(struct acpi_d
  */
 int acpi_enable_wakeup_device_power(struct acpi_device *dev, int sleep_state)
 {
+	struct acpi_power_resource_entry *entry;
 	int err = 0;
 
 	if (!dev || !dev->wakeup.flags.valid)
@@ -620,17 +644,31 @@ int acpi_enable_wakeup_device_power(stru
 	if (dev->wakeup.prepare_count++)
 		goto out;
 
-	err = acpi_power_on_list(&dev->wakeup.resources);
-	if (err) {
-		dev_err(&dev->dev, "Cannot turn wakeup power resources on\n");
-		dev->wakeup.flags.valid = 0;
-	} else {
-		/*
-		 * Passing 3 as the third argument below means the device may be
-		 * put into arbitrary power state afterward.
-		 */
-		err = acpi_device_sleep_wake(dev, 1, sleep_state, 3);
+	list_for_each_entry(entry, &dev->wakeup.resources, node) {
+		struct acpi_power_resource *resource = entry->resource;
+
+		mutex_lock(&resource->resource_lock);
+
+		if (!resource->wakeup_enabled) {
+			err = acpi_power_on_unlocked(resource);
+			if (!err)
+				resource->wakeup_enabled = true;
+		}
+
+		mutex_unlock(&resource->resource_lock);
+
+		if (err) {
+			dev_err(&dev->dev,
+				"Cannot turn wakeup power resources on\n");
+			dev->wakeup.flags.valid = 0;
+			goto out;
+		}
 	}
+	/*
+	 * Passing 3 as the third argument below means the device may be
+	 * put into arbitrary power state afterward.
+	 */
+	err = acpi_device_sleep_wake(dev, 1, sleep_state, 3);
 	if (err)
 		dev->wakeup.prepare_count = 0;
 
@@ -647,6 +685,7 @@ int acpi_enable_wakeup_device_power(stru
  */
 int acpi_disable_wakeup_device_power(struct acpi_device *dev)
 {
+	struct acpi_power_resource_entry *entry;
 	int err = 0;
 
 	if (!dev || !dev->wakeup.flags.valid)
@@ -668,10 +707,25 @@ int acpi_disable_wakeup_device_power(str
 	if (err)
 		goto out;
 
-	err = acpi_power_off_list(&dev->wakeup.resources);
-	if (err) {
-		dev_err(&dev->dev, "Cannot turn wakeup power resources off\n");
-		dev->wakeup.flags.valid = 0;
+	list_for_each_entry(entry, &dev->wakeup.resources, node) {
+		struct acpi_power_resource *resource = entry->resource;
+
+		mutex_lock(&resource->resource_lock);
+
+		if (resource->wakeup_enabled) {
+			err = acpi_power_off_unlocked(resource);
+			if (!err)
+				resource->wakeup_enabled = false;
+		}
+
+		mutex_unlock(&resource->resource_lock);
+
+		if (err) {
+			dev_err(&dev->dev,
+				"Cannot turn wakeup power resources off\n");
+			dev->wakeup.flags.valid = 0;
+			break;
+		}
 	}
 
  out:
Index: test/drivers/acpi/scan.c
===================================================================
--- test.orig/drivers/acpi/scan.c
+++ test/drivers/acpi/scan.c
@@ -1153,7 +1153,7 @@ static int acpi_bus_extract_wakeup_devic
 	if (!list_empty(&wakeup->resources)) {
 		int sleep_state;
 
-		sleep_state = acpi_power_min_system_level(&wakeup->resources);
+		sleep_state = acpi_power_wakeup_list_init(&wakeup->resources);
 		if (sleep_state < wakeup->sleep_state) {
 			acpi_handle_warn(handle, "Overriding _PRW sleep state "
 					 "(S%d) by S%d from power resources\n",


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [GIT PATCH] USB patches for 3.9-rc1

[Fabio Baltieri]

Hello Rafael,

On Sat, Feb 23, 2013 at 05:33:39AM +0100, Rafael J. Wysocki wrote:
> On Saturday, February 23, 2013 02:44:27 AM Fabio Baltieri wrote:
> > On Sat, Feb 23, 2013 at 01:35:26AM +0100, Rafael J. Wysocki wrote:
> > > The new sysfs interface for power resources control may be helpful here.  You
> > > need to use the Linus' current for it to work, though.
> > > 
> > > Can you please do
> > > 
> > > $ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
> > > $ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {} \;
> > > $ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls {} \;
> > > $ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {} \;
> > > and send the output?
> > 
> > With the acpi_add_power_resource disabled all power_state read "D0",
> > other attributes are not generated.
> 
> Yup.  That's how it should be.
> 
> > With a plain kernel that's the output:
> > 
> > $ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:09/LNXVIDEO:01/power_state
> > D0
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_state
> > D0
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_state
> > D0
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_state
> > D0
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/power_state
> > D0
> > 
> > $ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {} \;
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/real_power_state
> > D3cold
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/real_power_state
> > D3cold
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/real_power_state
> > D3cold
> 
> This is obviously wrong.  We expect the devices to be in D0, while they really
> are in D3cold.  Let's look deeper.
> 
> > $ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls {} \;
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D0
> > LNXPOWER:00
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D1
> > LNXPOWER:00
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D2
> > LNXPOWER:00
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D0
> > LNXPOWER:00
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D1
> > LNXPOWER:00
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D2
> > LNXPOWER:00
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D0
> > LNXPOWER:00
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D1
> > LNXPOWER:00
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D2
> > LNXPOWER:00
> 
> PNP0A08 is the PCI root bridge and device:29, device:34, device:1f are the USB
> controllers.  All of them have ACPI power states D0, D1, D2 and D3cold, where
> D0-D2 depend on the same power resource, so in fact they all are the same state
> (what sense does this make?).
> 
> I suspect that the power resource being shared (and it being shared in such a
> broken way) has to do something with the breakage.
> 
> > $ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {} \;
> > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/PNP0C09:00/LNXPOWER:00/resource_in_use
> > 0
> 
> There's one power resource in the system and it's usage count is 0, so it is
> "off" (which is consistent with the real power states of the USB controllers).
> 
> Now, the boot log shows that the power resource was "on" when it was found,
> so the initial states of the USB controllers should have been D0.

Sounds reasonable, I see that the ports are active until the kernel
starts.

> However, the DSDT source shows that the very same power resource that the D0-D2
> power states of the devices depend on is listed for them as a wakeup power
> resource by _PRW.  [Is that even valid?  It doesn't seem to make sense anyway.]
> Thus when pci_acpi_setup() does acpi_pci_sleep_wake(pci_dev, false), which
> calls acpi_pm_device_sleep_wake(&dev->dev, false), eventually
> acpi_disable_wakeup_device_power() will be called for the device.  This leads
> to calling acpi_power_off_list() for wakeup resources and that list includes
> our single power resource, so its refcount will be dropped and it will be
> turned off silently without updating the current power state of the device.
> 
> So first, the commit that broke things for you was probably
> d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device wakeup) which moved
> the wakeup initialization, but didn't show up in the bisection, because the
> power resources handling didn't work at that point.  And if I'm not mistaken,
> it only broke things because we've never assumed that a wakeup power resource
> may be the same as a power resource the device's power states depend on (which
> we should).
> 
> Now, how to fix this is an interesting problem.
> 
> After some consideration I got the appended patch, but I'm really tired now
> and couldn't really test it, so caveat emptor.  I'll look at it once again
> tomorrow and see if it still makes sense to me then.
[snip]
> ---
>  drivers/acpi/internal.h |    2 
>  drivers/acpi/power.c    |  106 ++++++++++++++++++++++++++++++++++++------------
>  drivers/acpi/scan.c     |    2 
>  3 files changed, 82 insertions(+), 28 deletions(-)

Well, this works fine on my system.  The power is back and from sysfs I
got all three real_power_state to D0 and resource_in_use to 1.

Anything else I should check?

I'll re-test again when you submit the patch formally!

Thanks,
Fabio

-- 
Fabio Baltieri

[PATCH] ACPI / PM: Take unusual configurations of power resources into account (was: Re: [GIT PATCH] USB patches for 3.9-rc1)

[Rafael J. Wysocki]

On Saturday, February 23, 2013 12:49:14 PM Fabio Baltieri wrote:
> Hello Rafael,
> 
> On Sat, Feb 23, 2013 at 05:33:39AM +0100, Rafael J. Wysocki wrote:
> > On Saturday, February 23, 2013 02:44:27 AM Fabio Baltieri wrote:
> > > On Sat, Feb 23, 2013 at 01:35:26AM +0100, Rafael J. Wysocki wrote:
> > > > The new sysfs interface for power resources control may be helpful here.  You
> > > > need to use the Linus' current for it to work, though.
> > > > 
> > > > Can you please do
> > > > 
> > > > $ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
> > > > $ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {} \;
> > > > $ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls {} \;
> > > > $ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {} \;
> > > > and send the output?
> > > 
> > > With the acpi_add_power_resource disabled all power_state read "D0",
> > > other attributes are not generated.
> > 
> > Yup.  That's how it should be.
> > 
> > > With a plain kernel that's the output:
> > > 
> > > $ find /sys/devices/LNXSYSTM:00/ -name power_state -print -exec cat {} \;
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:09/LNXVIDEO:01/power_state
> > > D0
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_state
> > > D0
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_state
> > > D0
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_state
> > > D0
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/power_state
> > > D0
> > > 
> > > $ find /sys/devices/LNXSYSTM:00/ -name real_power_state -print -exec cat {} \;
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/real_power_state
> > > D3cold
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/real_power_state
> > > D3cold
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/real_power_state
> > > D3cold
> > 
> > This is obviously wrong.  We expect the devices to be in D0, while they really
> > are in D3cold.  Let's look deeper.
> > 
> > > $ find /sys/devices/LNXSYSTM:00/ -name power_resources_D\* -print -exec ls {} \;
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D0
> > > LNXPOWER:00
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D1
> > > LNXPOWER:00
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:29/power_resources_D2
> > > LNXPOWER:00
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D0
> > > LNXPOWER:00
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D1
> > > LNXPOWER:00
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:34/power_resources_D2
> > > LNXPOWER:00
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D0
> > > LNXPOWER:00
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D1
> > > LNXPOWER:00
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/power_resources_D2
> > > LNXPOWER:00
> > 
> > PNP0A08 is the PCI root bridge and device:29, device:34, device:1f are the USB
> > controllers.  All of them have ACPI power states D0, D1, D2 and D3cold, where
> > D0-D2 depend on the same power resource, so in fact they all are the same state
> > (what sense does this make?).
> > 
> > I suspect that the power resource being shared (and it being shared in such a
> > broken way) has to do something with the breakage.
> > 
> > > $ find /sys/devices/LNXSYSTM:00/ -name resource_in_use -print -exec cat {} \;
> > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/PNP0C09:00/LNXPOWER:00/resource_in_use
> > > 0
> > 
> > There's one power resource in the system and it's usage count is 0, so it is
> > "off" (which is consistent with the real power states of the USB controllers).
> > 
> > Now, the boot log shows that the power resource was "on" when it was found,
> > so the initial states of the USB controllers should have been D0.
> 
> Sounds reasonable, I see that the ports are active until the kernel
> starts.
> 
> > However, the DSDT source shows that the very same power resource that the D0-D2
> > power states of the devices depend on is listed for them as a wakeup power
> > resource by _PRW.  [Is that even valid?  It doesn't seem to make sense anyway.]
> > Thus when pci_acpi_setup() does acpi_pci_sleep_wake(pci_dev, false), which
> > calls acpi_pm_device_sleep_wake(&dev->dev, false), eventually
> > acpi_disable_wakeup_device_power() will be called for the device.  This leads
> > to calling acpi_power_off_list() for wakeup resources and that list includes
> > our single power resource, so its refcount will be dropped and it will be
> > turned off silently without updating the current power state of the device.
> > 
> > So first, the commit that broke things for you was probably
> > d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device wakeup) which moved
> > the wakeup initialization, but didn't show up in the bisection, because the
> > power resources handling didn't work at that point.  And if I'm not mistaken,
> > it only broke things because we've never assumed that a wakeup power resource
> > may be the same as a power resource the device's power states depend on (which
> > we should).
> > 
> > Now, how to fix this is an interesting problem.
> > 
> > After some consideration I got the appended patch, but I'm really tired now
> > and couldn't really test it, so caveat emptor.  I'll look at it once again
> > tomorrow and see if it still makes sense to me then.
> [snip]
> > ---
> >  drivers/acpi/internal.h |    2 
> >  drivers/acpi/power.c    |  106 ++++++++++++++++++++++++++++++++++++------------
> >  drivers/acpi/scan.c     |    2 
> >  3 files changed, 82 insertions(+), 28 deletions(-)
> 
> Well, this works fine on my system.  The power is back and from sysfs I
> got all three real_power_state to D0 and resource_in_use to 1.
> 
> Anything else I should check?

No need.

> I'll re-test again when you submit the patch formally!

Thanks, it is appended.

I've only changed acpi_power_wakeup_list_init() so that it returns an error if
it cannot get the current states of wakeup power resources, which is essential.
The rest of the patch is the same as before.

Besides, it looks like it will be useful to have wakeup power resources exposed
in sysfs too, so I think I'll cut a patch for that.

Thanks,
Rafael


---
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Subject: ACPI / PM: Take unusual configurations of power resources into account

Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
wakeup) moved the initial disabling of system wakeup for PCI devices
into a place where it can actually work and that exposed a hidden old
issue with crap^Wunusual system designs where the same power
resources are used for both wakeup power and device power control at
run time.

Namely, say there is one power resource such that the ACPI power
state D0 of a PCI device depends on that power resource (i.e. the
device is in D0 when that power resource is "on") and it is used
as a wakeup power resource for the same device.  Then, calling
acpi_pci_sleep_wake(pci_dev, false) for the device in question will
cause the reference counter of that power resource to drop to 0,
which in turn will cause it to be turned off.  As a result, the
device will go into D3cold at that point, although it should have
stayed in D0.

As it turns out, that happens to USB controllers on some laptops
and USB becomes unusable on those machines as a result, which is
a major regression from v3.8.

To fix this problem, (1) increment the reference counters of wakup
power resources during their initialization if they are "on"
initially, (2) prevent acpi_disable_wakeup_device_power() from
decrementing the reference counters of wakeup power resources that
were not enabled for wakeup power previously, and (3) prevent
acpi_enable_wakeup_device_power() from incrementing the reference
counters of wakeup power resources that already are enabled for
wakeup power.

In addition to that, if it is impossible to determine the initial
states of wakeup power resources, avoid enabling wakeup for devices
whose wakeup power depends on those power resources.

Reported-by: Dave Jones <davej@redhat.com>
Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/acpi/internal.h |    2 
 drivers/acpi/power.c    |  112 ++++++++++++++++++++++++++++++++++++------------
 drivers/acpi/scan.c     |    9 +++
 3 files changed, 94 insertions(+), 29 deletions(-)

Index: test/drivers/acpi/internal.h
===================================================================
--- test.orig/drivers/acpi/internal.h
+++ test/drivers/acpi/internal.h
@@ -84,7 +84,7 @@ int acpi_extract_power_resources(union a
 				 struct list_head *list);
 int acpi_add_power_resource(acpi_handle handle);
 void acpi_power_add_remove_device(struct acpi_device *adev, bool add);
-int acpi_power_min_system_level(struct list_head *list);
+int acpi_power_wakeup_list_init(struct list_head *list, int *system_level);
 int acpi_device_sleep_wake(struct acpi_device *dev,
                            int enable, int sleep_state, int dev_state);
 int acpi_power_get_inferred_state(struct acpi_device *device, int *state);
Index: test/drivers/acpi/power.c
===================================================================
--- test.orig/drivers/acpi/power.c
+++ test/drivers/acpi/power.c
@@ -73,6 +73,7 @@ struct acpi_power_resource {
 	u32 system_level;
 	u32 order;
 	unsigned int ref_count;
+	bool wakeup_enabled;
 	struct mutex resource_lock;
 };
 
@@ -272,11 +273,9 @@ static int __acpi_power_on(struct acpi_p
 	return 0;
 }
 
-static int acpi_power_on(struct acpi_power_resource *resource)
+static int acpi_power_on_unlocked(struct acpi_power_resource *resource)
 {
-	int result = 0;;
-
-	mutex_lock(&resource->resource_lock);
+	int result = 0;
 
 	if (resource->ref_count++) {
 		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
@@ -293,9 +292,16 @@ static int acpi_power_on(struct acpi_pow
 				schedule_work(&dep->work);
 		}
 	}
+	return result;
+}
 
-	mutex_unlock(&resource->resource_lock);
+static int acpi_power_on(struct acpi_power_resource *resource)
+{
+	int result;
 
+	mutex_lock(&resource->resource_lock);
+	result = acpi_power_on_unlocked(resource);
+	mutex_unlock(&resource->resource_lock);
 	return result;
 }
 
@@ -313,17 +319,15 @@ static int __acpi_power_off(struct acpi_
 	return 0;
 }
 
-static int acpi_power_off(struct acpi_power_resource *resource)
+static int acpi_power_off_unlocked(struct acpi_power_resource *resource)
 {
 	int result = 0;
 
-	mutex_lock(&resource->resource_lock);
-
 	if (!resource->ref_count) {
 		ACPI_DEBUG_PRINT((ACPI_DB_INFO,
 				  "Power resource [%s] already off",
 				  resource->name));
-		goto unlock;
+		return 0;
 	}
 
 	if (--resource->ref_count) {
@@ -335,10 +339,16 @@ static int acpi_power_off(struct acpi_po
 		if (result)
 			resource->ref_count++;
 	}
+	return result;
+}
 
- unlock:
-	mutex_unlock(&resource->resource_lock);
+static int acpi_power_off(struct acpi_power_resource *resource)
+{
+	int result;
 
+	mutex_lock(&resource->resource_lock);
+	result = acpi_power_off_unlocked(resource);
+	mutex_unlock(&resource->resource_lock);
 	return result;
 }
 
@@ -521,18 +531,35 @@ void acpi_power_add_remove_device(struct
 	}
 }
 
-int acpi_power_min_system_level(struct list_head *list)
+int acpi_power_wakeup_list_init(struct list_head *list, int *system_level_p)
 {
 	struct acpi_power_resource_entry *entry;
 	int system_level = 5;
 
 	list_for_each_entry(entry, list, node) {
 		struct acpi_power_resource *resource = entry->resource;
+		acpi_handle handle = resource->device.handle;
+		int result;
+		int state;
 
+		mutex_lock(&resource->resource_lock);
+
+		result = acpi_power_get_state(handle, &state);
+		if (result) {
+			mutex_unlock(&resource->resource_lock);
+			return result;
+		}
+		if (state == ACPI_POWER_RESOURCE_STATE_ON) {
+			resource->ref_count++;
+			resource->wakeup_enabled = true;
+		}
 		if (system_level > resource->system_level)
 			system_level = resource->system_level;
+
+		mutex_unlock(&resource->resource_lock);
 	}
-	return system_level;
+	*system_level_p = system_level;
+	return 0;
 }
 
 /* --------------------------------------------------------------------------
@@ -610,6 +637,7 @@ int acpi_device_sleep_wake(struct acpi_d
  */
 int acpi_enable_wakeup_device_power(struct acpi_device *dev, int sleep_state)
 {
+	struct acpi_power_resource_entry *entry;
 	int err = 0;
 
 	if (!dev || !dev->wakeup.flags.valid)
@@ -620,17 +648,31 @@ int acpi_enable_wakeup_device_power(stru
 	if (dev->wakeup.prepare_count++)
 		goto out;
 
-	err = acpi_power_on_list(&dev->wakeup.resources);
-	if (err) {
-		dev_err(&dev->dev, "Cannot turn wakeup power resources on\n");
-		dev->wakeup.flags.valid = 0;
-	} else {
-		/*
-		 * Passing 3 as the third argument below means the device may be
-		 * put into arbitrary power state afterward.
-		 */
-		err = acpi_device_sleep_wake(dev, 1, sleep_state, 3);
+	list_for_each_entry(entry, &dev->wakeup.resources, node) {
+		struct acpi_power_resource *resource = entry->resource;
+
+		mutex_lock(&resource->resource_lock);
+
+		if (!resource->wakeup_enabled) {
+			err = acpi_power_on_unlocked(resource);
+			if (!err)
+				resource->wakeup_enabled = true;
+		}
+
+		mutex_unlock(&resource->resource_lock);
+
+		if (err) {
+			dev_err(&dev->dev,
+				"Cannot turn wakeup power resources on\n");
+			dev->wakeup.flags.valid = 0;
+			goto out;
+		}
 	}
+	/*
+	 * Passing 3 as the third argument below means the device may be
+	 * put into arbitrary power state afterward.
+	 */
+	err = acpi_device_sleep_wake(dev, 1, sleep_state, 3);
 	if (err)
 		dev->wakeup.prepare_count = 0;
 
@@ -647,6 +689,7 @@ int acpi_enable_wakeup_device_power(stru
  */
 int acpi_disable_wakeup_device_power(struct acpi_device *dev)
 {
+	struct acpi_power_resource_entry *entry;
 	int err = 0;
 
 	if (!dev || !dev->wakeup.flags.valid)
@@ -668,10 +711,25 @@ int acpi_disable_wakeup_device_power(str
 	if (err)
 		goto out;
 
-	err = acpi_power_off_list(&dev->wakeup.resources);
-	if (err) {
-		dev_err(&dev->dev, "Cannot turn wakeup power resources off\n");
-		dev->wakeup.flags.valid = 0;
+	list_for_each_entry(entry, &dev->wakeup.resources, node) {
+		struct acpi_power_resource *resource = entry->resource;
+
+		mutex_lock(&resource->resource_lock);
+
+		if (resource->wakeup_enabled) {
+			err = acpi_power_off_unlocked(resource);
+			if (!err)
+				resource->wakeup_enabled = false;
+		}
+
+		mutex_unlock(&resource->resource_lock);
+
+		if (err) {
+			dev_err(&dev->dev,
+				"Cannot turn wakeup power resources off\n");
+			dev->wakeup.flags.valid = 0;
+			break;
+		}
 	}
 
  out:
Index: test/drivers/acpi/scan.c
===================================================================
--- test.orig/drivers/acpi/scan.c
+++ test/drivers/acpi/scan.c
@@ -1153,7 +1153,14 @@ static int acpi_bus_extract_wakeup_devic
 	if (!list_empty(&wakeup->resources)) {
 		int sleep_state;
 
-		sleep_state = acpi_power_min_system_level(&wakeup->resources);
+		err = acpi_power_wakeup_list_init(&wakeup->resources,
+						  &sleep_state);
+		if (err) {
+			acpi_handle_warn(handle, "Retrieving current states "
+					 "of wakeup power resources failed\n");
+			acpi_power_resources_list_free(&wakeup->resources);
+			goto out;
+		}
 		if (sleep_state < wakeup->sleep_state) {
 			acpi_handle_warn(handle, "Overriding _PRW sleep state "
 					 "(S%d) by S%d from power resources\n",


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [PATCH] ACPI / PM: Take unusual configurations of power resources into account (was: Re: [GIT PATCH] USB patches for 3.9-rc1)

[Fabio Baltieri]

> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Subject: ACPI / PM: Take unusual configurations of power resources into account
> 
> Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
> wakeup) moved the initial disabling of system wakeup for PCI devices
> into a place where it can actually work and that exposed a hidden old
> issue with crap^Wunusual system designs where the same power
> resources are used for both wakeup power and device power control at
> run time.
> 
> Namely, say there is one power resource such that the ACPI power
> state D0 of a PCI device depends on that power resource (i.e. the
> device is in D0 when that power resource is "on") and it is used
> as a wakeup power resource for the same device.  Then, calling
> acpi_pci_sleep_wake(pci_dev, false) for the device in question will
> cause the reference counter of that power resource to drop to 0,
> which in turn will cause it to be turned off.  As a result, the
> device will go into D3cold at that point, although it should have
> stayed in D0.
> 
> As it turns out, that happens to USB controllers on some laptops
> and USB becomes unusable on those machines as a result, which is
> a major regression from v3.8.
> 
> To fix this problem, (1) increment the reference counters of wakup
> power resources during their initialization if they are "on"
> initially, (2) prevent acpi_disable_wakeup_device_power() from
> decrementing the reference counters of wakeup power resources that
> were not enabled for wakeup power previously, and (3) prevent
> acpi_enable_wakeup_device_power() from incrementing the reference
> counters of wakeup power resources that already are enabled for
> wakeup power.
> 
> In addition to that, if it is impossible to determine the initial
> states of wakeup power resources, avoid enabling wakeup for devices
> whose wakeup power depends on those power resources.
> 
> Reported-by: Dave Jones <davej@redhat.com>
> Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Works just fine!

Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>

Thanks,
Fabio

-- 
Fabio Baltieri

Re: [PATCH] ACPI / PM: Take unusual configurations of power resources into account (was: Re: [GIT PATCH] USB patches for 3.9-rc1)

[Rafael J. Wysocki]

On Saturday, February 23, 2013 03:48:59 PM Fabio Baltieri wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > Subject: ACPI / PM: Take unusual configurations of power resources into account
> > 
> > Commit d2e5f0c (ACPI / PCI: Rework the setup and cleanup of device
> > wakeup) moved the initial disabling of system wakeup for PCI devices
> > into a place where it can actually work and that exposed a hidden old
> > issue with crap^Wunusual system designs where the same power
> > resources are used for both wakeup power and device power control at
> > run time.
> > 
> > Namely, say there is one power resource such that the ACPI power
> > state D0 of a PCI device depends on that power resource (i.e. the
> > device is in D0 when that power resource is "on") and it is used
> > as a wakeup power resource for the same device.  Then, calling
> > acpi_pci_sleep_wake(pci_dev, false) for the device in question will
> > cause the reference counter of that power resource to drop to 0,
> > which in turn will cause it to be turned off.  As a result, the
> > device will go into D3cold at that point, although it should have
> > stayed in D0.
> > 
> > As it turns out, that happens to USB controllers on some laptops
> > and USB becomes unusable on those machines as a result, which is
> > a major regression from v3.8.
> > 
> > To fix this problem, (1) increment the reference counters of wakup
> > power resources during their initialization if they are "on"
> > initially, (2) prevent acpi_disable_wakeup_device_power() from
> > decrementing the reference counters of wakeup power resources that
> > were not enabled for wakeup power previously, and (3) prevent
> > acpi_enable_wakeup_device_power() from incrementing the reference
> > counters of wakeup power resources that already are enabled for
> > wakeup power.
> > 
> > In addition to that, if it is impossible to determine the initial
> > states of wakeup power resources, avoid enabling wakeup for devices
> > whose wakeup power depends on those power resources.
> > 
> > Reported-by: Dave Jones <davej@redhat.com>
> > Reported-by: Fabio Baltieri <fabio.baltieri@linaro.org>
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> Works just fine!
> 
> Tested-by: Fabio Baltieri <fabio.baltieri@linaro.org>

Thanks for verifying!

Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.