[Qemu-commits] [qemu/qemu] 84d04e: ohci: split reset method in 3 parts

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 84d04e216279b5388c66c00fb00ed591da894357
      
https://github.com/qemu/qemu/commit/84d04e216279b5388c66c00fb00ed591da894357
  Author: Hervé Poussineau <address@hidden>
  Date:   2016-01-08 (Fri, 08 Jan 2016)

  Changed paths:
    M hw/usb/hcd-ohci.c

  Log Message:
  -----------
  ohci: split reset method in 3 parts

The three parts are:
- root hub reset (ohci_roothub_reset)
- host controller soft reset (ohci_soft_reset)
- host controller hard reset (ohci_hard_reset)

Signed-off-by: Hervé Poussineau <address@hidden>
Tested-by: Mark Cave-Ayland <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>


  Commit: 7d938fd14b87e1d8db2de5ea1359d6d11e366a56
      
https://github.com/qemu/qemu/commit/7d938fd14b87e1d8db2de5ea1359d6d11e366a56
  Author: Hervé Poussineau <address@hidden>
  Date:   2016-01-08 (Fri, 08 Jan 2016)

  Changed paths:
    M hw/usb/hcd-ohci.c

  Log Message:
  -----------
  ohci: fix Host Controller USBRESET

Specification says that, when entering this state, "the contents of the 
registers
(except Root Hub registers) are preserved by the HC. [...] The Root Hub is 
being reset,
which causes the Root Hub's downstream ports to be reset and possibly powered 
off."

Signed-off-by: Hervé Poussineau <address@hidden>
Tested-by: Mark Cave-Ayland <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>


  Commit: 0922c3f6064ebe4c65fd1190b014a742083b5906
      
https://github.com/qemu/qemu/commit/0922c3f6064ebe4c65fd1190b014a742083b5906
  Author: Hervé Poussineau <address@hidden>
  Date:   2016-01-08 (Fri, 08 Jan 2016)

  Changed paths:
    M hw/usb/hcd-ohci.c

  Log Message:
  -----------
  ohci: fix command HostControllerReset

Specification says that: "This bit is set by HCD to initiate a software reset 
of HC."

Signed-off-by: Hervé Poussineau <address@hidden>
Tested-by: Mark Cave-Ayland <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>


  Commit: c22d5dcd7a8ee8316dfbad66d13abb6d661c86b9
      
https://github.com/qemu/qemu/commit/c22d5dcd7a8ee8316dfbad66d13abb6d661c86b9
  Author: Bandan Das <address@hidden>
  Date:   2016-01-08 (Fri, 08 Jan 2016)

  Changed paths:
    M hw/usb/dev-mtp.c

  Log Message:
  -----------
  usb-mtp: use safe variant when cleaning events list

usb_mtp_inotify_cleanup uses QLIST_FOREACH to pick events
from a list and free them which is incorrect. Use QLIST_FOREACH_SAFE
instead.

Signed-off-by: Bandan Das <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>


  Commit: ec93e158b1930d6c6db22e3c0a655337ae221034
      
https://github.com/qemu/qemu/commit/ec93e158b1930d6c6db22e3c0a655337ae221034
  Author: Bandan Das <address@hidden>
  Date:   2016-01-08 (Fri, 08 Jan 2016)

  Changed paths:
    M hw/usb/dev-mtp.c

  Log Message:
  -----------
  usb-mtp: fix call to trace function

trace_usb_mtp_inotify_event() was being called after the object was
being freed.

Signed-off-by: Bandan Das <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>


  Commit: fd0a10cd20a1c5ae829be32f3364dae88f435c4e
      
https://github.com/qemu/qemu/commit/fd0a10cd20a1c5ae829be32f3364dae88f435c4e
  Author: Laurent Vivier <address@hidden>
  Date:   2016-01-08 (Fri, 08 Jan 2016)

  Changed paths:
    M hw/usb/hcd-ohci.c

  Log Message:
  -----------
  ohci: delay first SOF interrupt

On overcommitted CPU, kernel can be so slow that an interrupt can
be triggered by the device whereas the driver is not ready to receive
it. This drives us into an infinite loop.

This does not happen on real hardware because real hardware never send
interrupt immediately after the controller has been moved to OPERATION state.

This patch tries to delay the first SOF interrupt to let driver exits from
the critical section (which is not protected against interrupts...)

Some details:

- ohci_irq(): the OHCI interrupt handler, acknowledges the SOF IRQ
  only if the state of the driver (rh_state) is OHCI_STATE_RUNNING.
  So if this interrupt happens and the driver is not in this state,
  the function is called again and again, moving the system to a
  CPU starvation.

- ohci_rh_resume(): the driver re-enables operation with OHCI_USB_OPER.
  In QEMU this start the SOF timer and QEMU starts to send IRQs. As
  the driver is not in OHCI_STATE_RUNNING and not protected against IRQ,
  the ohci_irq() can be called and the driver never moved to
  OHCI_STATE_RUNNING.

Suggested-by: Gerd Hoffmann <address@hidden>
Signed-off-by: Laurent Vivier <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>


  Commit: 087462c7739869e9b888c06c06c8f1bbfd99779c
      
https://github.com/qemu/qemu/commit/087462c7739869e9b888c06c06c8f1bbfd99779c
  Author: Laurent Vivier <address@hidden>
  Date:   2016-01-08 (Fri, 08 Jan 2016)

  Changed paths:
    M hw/usb/hcd-ohci.c

  Log Message:
  -----------
  ohci: clear pending SOF on suspend

On overcommitted CPU, kernel can be so slow that an interrupt can
be triggered by the device whereas the driver is not ready to receive
it. This drives us into an infinite loop.

On suspend, if a SOF interrupt is raised between the stop of the
device processing and the change of the device internal state to
OHCI_USB_SUSPEND (QEMU stops SOF timer on this state change), this
interrupt is never acknowledged.

This patch clears pending SOF interrupt on OHCI_USB_SUSPEND setting.

Some details:

- ohci_irq(): the OHCI interrupt handler, acknowledges the SOF IRQ
  only if the state of the driver (rh_state) is OHCI_STATE_RUNNING.
  So if this interrupt happens and the driver is not in this state,
  the function is called again and again, moving the system to a
  CPU starvation.

- ohci_rh_suspend(): the function stop the operation and acknowledge
  pending interrupts (but doesn't disable it). Later in the function,
  the device is moved to OHCI_SUSPEND_STATE, and the driver to
  OHCI_RH_SUSPENDED. If between the moment when the interrupt is
  acknowledged and the moment when the device is suspended a new
  interrupt is raised, it will be never acknowledged because the
  driver is now not in OHCI_RH_RUNNING state.

Signed-off-by: Laurent Vivier <address@hidden>
Reviewed-by: Thomas Huth <address@hidden>
Message-id: address@hidden
Signed-off-by: Gerd Hoffmann <address@hidden>


  Commit: 9df2513730c5902813f575a74ac9303388fd029d
      
https://github.com/qemu/qemu/commit/9df2513730c5902813f575a74ac9303388fd029d
  Author: Peter Maydell <address@hidden>
  Date:   2016-01-08 (Fri, 08 Jan 2016)

  Changed paths:
    M hw/usb/dev-mtp.c
    M hw/usb/hcd-ohci.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/kraxel/tags/pull-usb-20160108-1' into 
staging

usb: mtp and ohci fixes.

# gpg: Signature made Fri 08 Jan 2016 10:14:59 GMT using RSA key ID D3E87138
# gpg: Good signature from "Gerd Hoffmann (work) <address@hidden>"
# gpg:                 aka "Gerd Hoffmann <address@hidden>"
# gpg:                 aka "Gerd Hoffmann (private) <address@hidden>"

* remotes/kraxel/tags/pull-usb-20160108-1:
  ohci: clear pending SOF on suspend
  ohci: delay first SOF interrupt
  usb-mtp: fix call to trace function
  usb-mtp: use safe variant when cleaning events list
  ohci: fix command HostControllerReset
  ohci: fix Host Controller USBRESET
  ohci: split reset method in 3 parts

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/d9767f1bfa1f...9df2513730c5