Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 14
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 11 8月, 2010 3 次提交
    • A
      USB: add check to detect host controller hardware removal · c548795a
      由 Alan Stern 提交于 
      This patch (as1391) fixes a problem that can occur when USB host
controller hardware is hot-unplugged.  If no interrupts are generated
by the unplug then the HCD may not realize that the controller is
gone, and the subsequent unbind may hang waiting for interrupts that
never arrive.

The solution (for PCI-based controllers) is to call the HCD's
interrupt handler at the start of usb_hcd_pci_remove().  If the
hardware is gone, the handler will realize this when it tries to read
the controller's status register.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c548795a
    • A
      USB: don't stop root-hub status polls too soon · 6d88e679
      由 Alan Stern 提交于 
      This patch (as1390) fixes a problem that crops up when a UHCI host
controller is unbound from uhci-hcd while there are still some active
URBs.  The URBs have to be unlinked when the root hub is unregistered,
and uhci-hcd relies upon root-hub status polls as part of its
unlinking procedure.  But usb_hcd_poll_rh_status() won't make those
status calls if hcd->rh_registered is clear, and the flag is cleared
_before_ the unregistration takes place.

Since hcd->rh_registered is used for other things and needs to be
cleared early, the solution is to add a new flag (rh_pollable) and use
it instead.  It gets cleared _after_ the root hub is unregistered.

Now that the status polls don't end too soon, we have to make sure
they also don't occur too late -- after the root hub's usb_device
structure or the HCD's private structures are deallocated.  Therefore
the patch adds usb_get_device() and usb_put_device() calls to protect
the root hub structure, and it adds an extra del_timer_sync() to
prevent the root-hub timer from causing an unexpected status poll.

This additional complexity would not be needed if the HCD framework
had provided separate stop() and release() callbacks instead of just
stop().  This lack could be fixed at some future time (although it
would require changes to every host controller driver); when that
happens this patch won't be needed any more.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6d88e679
    • A
      USB: fix failure path in usb_add_hcd() · 96e077ae
      由 Alan Stern 提交于 
      This patch (as1389) fixes some errors in the failure pathway of
usb_add_hcd().  The actions it takes ought to be exactly the same as
those taken by usb_remove_hcd(), but they aren't.

In one case (removal of the usb_bus_attr_group), the two routines are
brought into agreement by changing usb_remove_hcd().  All the other
discrepancies are fixed by changing usb_add_hcd().
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      96e077ae
  3. 27 7月, 2010 3 次提交
  5. 30 6月, 2010 2 次提交
    • A
      USB: obey the sysfs power/wakeup setting · 48826626
      由 Alan Stern 提交于 
      This patch (as1403) is a partial reversion of an earlier change
(commit 5f677f1d "USB: fix remote
wakeup settings during system sleep").  After hearing from a user, I
realized that remote wakeup should be enabled during system sleep
whenever userspace allows it, and not only if a driver requests it
too.

Indeed, there could be a device with no driver, that does nothing but
generate a wakeup request when the user presses a button.  Such a
device should be allowed to do its job.

The problem fixed by the earlier patch -- device generating a wakeup
request for no reason, causing system suspend to abort -- was also
addressed by a later patch ("USB: don't enable remote wakeup by
default", accepted but not yet merged into mainline).  The device
won't be able to generate the bogus wakeup requests because it will be
disabled for remote wakeup by default.  Hence this reversion will not
re-introduce any old problems.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org> [.34]
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      48826626
    • A
      USB: fix oops in usb_sg_init() · 64d65872
      由 Alan Stern 提交于 
      This patch (as1401) fixes a bug in usb_sg_init() that can cause an
invalid pointer dereference.  An inner loop reuses some local variables
in an unsafe manner, so new variables are introduced.
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NAjay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      64d65872
  7. 05 6月, 2010 1 次提交
  9. 22 5月, 2010 2 次提交
  11. 21 5月, 2010 25 次提交
  13. 15 5月, 2010 1 次提交
    • A
      Fix the regression created by "set S_DEAD on unlink()..." commit · d83c49f3
      由 Al Viro 提交于 
      1) i_flags simply doesn't work for mount/unlink race prevention;
we may have many links to file and rm on one of those obviously
shouldn't prevent bind on top of another later on.  To fix it
right way we need to mark _dentry_ as unsuitable for mounting
upon; new flag (DCACHE_CANT_MOUNT) is protected by d_flags and
i_mutex on the inode in question.  Set it (with dont_mount(dentry))
in unlink/rmdir/etc., check (with cant_mount(dentry)) in places
in namespace.c that used to check for S_DEAD.  Setting S_DEAD
is still needed in places where we used to set it (for directories
getting killed), since we rely on it for readdir/rmdir race
prevention.

2) rename()/mount() protection has another bogosity - we unhash
the target before we'd checked that it's not a mountpoint.  Fixed.

3) ancient bogosity in pivot_root() - we locked i_mutex on the
right directory, but checked S_DEAD on the different (and wrong)
one.  Noticed and fixed.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      d83c49f3
  15. 01 5月, 2010 3 次提交
    • D
      USB: rename usb_buffer_alloc() and usb_buffer_free() · 073900a2
      由 Daniel Mack 提交于 
      For more clearance what the functions actually do,

  usb_buffer_alloc() is renamed to usb_alloc_coherent()
  usb_buffer_free()  is renamed to usb_free_coherent()

They should only be used in code which really needs DMA coherency.

[added compatibility macros so we can convert things easier - gregkh]
Signed-off-by: NDaniel Mack <daniel@caiaq.de>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Pedro Ribeiro <pedrib@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      073900a2
    • A
      USB: fix build on OMAPs if CONFIG_PM_RUNTIME is not set · 6d602610
      由 Anand Gadiyar 提交于 
      With patch as1329 (USB: convert to the runtime PM framework),
we make USB_SUSPEND depend on PM_RUNTIME instead of CONFIG_PM.

Also, CONFIG_USB_OTG selects CONFIG_USB_SUSPEND.

If PM_RUNTIME is not enabled, and we try to enable USB_OTG,
we will end up with CONFIG_USB_SUSPEND selected. This is
due to a known bug with the select statement.

This makes the build break on various OMAP configs (which
have CONFIG_USB_OTG set by default, but do not yet have
CONFIG_PM_RUNTIME enabled).

Avoid this by changing the logic for CONFIG_USB_OTG from
"select USB_SUSPEND" to "depends on USB_SUSPEND"
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
CC: Michal Marek <mmarek@suse.cz>
CC: Tony Lindgren <tony@atomide.com>
CC: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      6d602610
    • A
      USB: don't choose configs with no interfaces · 62f9cfa3
      由 Alan Stern 提交于 
      This patch (as1372) fixes a bug in the routine that chooses the
default configuration to install when a new USB device is detected.
The algorithm is supposed to look for a config whose first interface
is for a non-vendor-specific class.  But the way it's currently
written, it will also accept a config with no interfaces at all, which
is not very useful.  (Believe it or not, such things do exist.)
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Tested-by: NAndrew Victor <avictor.za@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      62f9cfa3