- 07 Nov, 2014 36 commits
-
-
Chris Rorvick authored
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 fotg210 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 fotg210 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 fotg210 drivers under the relevant configurations: EARLY_PRINTK_DBGP? XEN_DOM0? ehci-dbgp fotg210 ------------------ --------- ------------- ------------- 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 fotg210 is, at best, indifferent to whether Xen is notified of these events. Make fotg210 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>
-
Chris Rorvick authored
The FUSBH200 debug port has a EHCI-compatible register layout so there is no need to define a custom struct. Signed-off-by:
-
Chris Rorvick authored
Now that ehci-dbgp has its own header, use it rather than duplicating the declarations, etc. Signed-off-by:
-
Chris Rorvick authored
The fusbh200_dbg_port struct is a copy of the ehci_dbg_port definition in the <linux/usb/ehci_def.h> header. Embedded in this definition are a number of macros which came along for the ride. These macros are not used in the fusbh200 driver and will conflict those in the new <linux/usb/ehci-dbgp.h> header. Signed-off-by:
-
Chris Rorvick authored
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 authored
The FUSBH200 and FOTG210 controllers implement sufficiently EHCI- compatible debug ports to leverage ehci-dbgp from their respective drivers. Rather than including <linux/usb/ehci_def.h> header, though, they replicate the necessary declarations in their own headers. Move the ehci-dbgp stuff into its own header as a first step towards removing this redundancy. Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
Varka Bhadram <varkab@cdac.in> Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
Felipe Balbi <balbi@ti.com> Reviewed-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Sanity check on resource happening with devm_ioremap_resource(). Signed-off-by:
-
Varka Bhadram authored
Fix on accessing NULL pointer dereference on get resource failed. Signed-off-by:
-
Varka Bhadram authored
Fix in accessing NULL if resource didn't get. Signed-off-by:
-
Mark Knibbs authored
Some mass storage devices return a bogus value in response to a Get Max LUN request. The Iomega Jaz USB Adapter responds with 0x10, hence my recent patch to use the US_FL_SINGLE_LUN quirk for it. The USB MSC Bulk Only Transport document says "The device shall return one byte of data that contains the maximum LUN supported by the device." Since the LUN field in the command block wrapper is only 4 bits wide, it might be helpful to report too-large LUN values in the kernel log, and assume max LUN is actually 0. That could get some devices which currently need the US_FL_SINGLE_LUN quirk to work. Signed-off-by:
Mark Knibbs <markk@clara.co.uk> Acked-by:
-
- 03 Nov, 2014 4 commits
-
-
Geert Uytterhoeven authored
Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Peter Chen authored
The memory subsystem has already had similar message for it. Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
-
Peter Chen authored
The memory subsystem has already had similar message for it. Signed-off-by:
-
Peter Chen authored
The memory subsystem has already had similar message for it. Signed-off-by:
-
