17 May, 2013

1 commit

  • The driver core clears the driver data to NULL after device_release
    or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
    (device-core: Ensure drvdata = NULL when no driver is bound).
    Thus, it is not needed to manually clear the device driver data to NULL.

    Signed-off-by: Jingoo Han
    Signed-off-by: Greg Kroah-Hartman

    Jingoo Han
     

29 Mar, 2013

2 commits


16 Mar, 2013

1 commit

  • Even if bus is not hot-pluggable, the devices can be unbound from the
    driver via sysfs, so we should not be using __exit annotations on
    remove() methods. The only exception is drivers registered with
    platform_driver_probe() which specifically disables sysfs bind/unbind
    attributes.

    Signed-off-by: Dmitry Torokhov
    Acked-by: Alan Stern
    Signed-off-by: Greg Kroah-Hartman

    Dmitry Torokhov
     

23 Jan, 2013

1 commit

  • Convert all uses of devm_request_and_ioremap() to the newly introduced
    devm_ioremap_resource() which provides more consistent error handling.

    devm_ioremap_resource() provides its own error messages so all explicit
    error messages can be removed from the failure code paths.

    Signed-off-by: Thierry Reding
    Acked-by: Alan Stern
    Acked-by: Felipe Balbi
    Signed-off-by: Greg Kroah-Hartman

    Thierry Reding
     

01 Nov, 2012

1 commit

  • This patch (as1623) removes the ehci_port_power() routine and all the
    places that call it. There's no reason for ehci-hcd to change the
    port power settings; the hub driver takes care of all that stuff.

    There is one exception: When the controller is resumed from
    hibernation or following a loss of power, the ports that are supposed
    to be handed over to a companion controller must be powered on first.
    Otherwise the handover won't work. This process is not visible to the
    hub driver, so it has to be handled in ehci-hcd.

    Signed-off-by: Alan Stern
    Signed-off-by: Greg Kroah-Hartman

    Alan Stern
     

11 Aug, 2012

1 commit

  • The various devm_ functions allocate memory that is released when a driver
    detaches. This patch uses these functions for data that is allocated in
    the probe function of a platform device and is only freed in the remove
    function.

    Signed-off-by: Julia Lawall
    Signed-off-by: Greg Kroah-Hartman

    Julia Lawall
     

10 Jul, 2012

1 commit

  • This patch (as1564c) converts the EHCI platform drivers to use the
    central ehci_setup() routine for generic controller initialization
    rather than each having its own idiosyncratic approach.

    The major point of difficulty lies in ehci-pci's many vendor- and
    device-specific workarounds. Some of them have to be applied before
    calling ehci_setup() and some after, which necessitates a fair amount
    of code motion. The other platform drivers require much smaller
    changes.

    One point not addressed by the patch is whether ports should be
    powered on or off following initialization. The different drivers
    appear to handle this pretty much at random. In fact it shouldn't
    matter, because the hub driver turns on power to all ports when it
    binds to the root hub. Straightening that out will be left for
    another day.

    Signed-off-by: Alan Stern
    Signed-off-by: Greg Kroah-Hartman

    Alan Stern
     

15 Jun, 2012

1 commit

  • If the platform_data is not set, pdata will be uninitialized value.
    Since the driver has the following code, if the condition is true when
    the pdata is uninitialized value, the driver may jump to the illegal
    phy_init().

    if (pdata && pdata->phy_init)
    pdata->phy_init();

    This patch also fixes the following warning:

    CC drivers/usb/host/ehci-hcd.o
    drivers/usb/host/ehci-sh.c: In function ‘ehci_hcd_sh_probe’:
    drivers/usb/host/ehci-sh.c:104: warning: ‘pdata’ may be used uninitialized in this function

    Signed-off-by: Yoshihiro Shimoda
    Acked-by: Alan Stern
    Signed-off-by: Greg Kroah-Hartman

    Shimoda, Yoshihiro
     

19 Apr, 2012

1 commit


18 Sep, 2011

1 commit


04 May, 2011

1 commit

  • The two first HC capability registers (CAPLENGTH and HCIVERSION)
    are defined as one 8-bit and one 16-bit register. Most HC
    implementations have selected to treat these registers as part
    of a 32-bit register, giving the same layout for both big and
    small endian systems.

    This patch adds a new quirk, big_endian_capbase, to support
    controllers with big endian register interfaces that treat
    HCIVERSION and CAPLENGTH as individual registers.

    Signed-off-by: Jan Andersson
    Acked-by: Alan Stern
    Signed-off-by: Greg Kroah-Hartman

    Jan Andersson
     

26 Nov, 2010

2 commits


02 Nov, 2010

1 commit