]> git.karo-electronics.de Git - karo-tx-linux.git/commit
fusbh200: Make Xen notificaiton consistent with EHCI
authorChris Rorvick <chris@rorvick.com>
Wed, 5 Nov 2014 01:18:46 +0000 (19:18 -0600)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 7 Nov 2014 17:02:37 +0000 (09:02 -0800)
commit895baf2404ebc2f875fad39d2d81f98a38a8f9cc
tree200509a35abdbe5da9a9e5c217e99b27135bfc7e
parentb9ec1c9da64f0c1d130beb125a916d0725363ec9
fusbh200: Make Xen notificaiton consistent with EHCI

If CONFIG_XEN_DOM0 is enabled, the ehci-dbgp driver notifies Xen of
controller reset events via xen_dbgp_reset_prep() and
xen_dbgp_external_startup() (via calls to xen_dbgp_op().)  Otherwise
<linux/usb/ehci_def.h> defines them as no-ops to disable this logic.

The fusbh200 driver copies much of the dbgp code from ehci_def.h, but it
unconditionally defines the Xen hooks as no-ops, effectively disabling
these notifications when CONFIG_EARLY_PRINTK_DBGP is disabled.  When
enabled, though, notifying Xen is dependent on CONFIG_XEN_DOM0 due to
fusbh200 leveraging the ehci-dbgp driver.

The following table compares the implementations of xen_dbgp_reset_prep()
and xen_dbgp_external_startup() in the ehci-dbgp and fusbh200 drivers
under the relevant configurations:

  EARLY_PRINTK_DBGP?  XEN_DOM0?  ehci-dbgp      fusbh200
  ------------------  ---------  -------------  -------------
  n                   n          no-op          no-op
  n                   y          xen_dbgp_op()  no-op
  y                   n          no-op          no-op
  y                   y          xen_dbgp_op()  xen_dbgp_op()

This suggests that fusbh200 is, at best, indifferent to whether Xen is
notified of these events.  Make fusbh200 consistent with ehci-dbgp as a
step towards consolidating this code duplication.

Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/usb/host/fusbh200.h