IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The pci_dev_put() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The usb_put_dev() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The usb_put_dev() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Acked-by: Valentina Manea <valentina.manea.m@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Return a negative error code on failure.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
@@
identifier ret; expression e1,e2;
@@
(
if (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret = 0
)
... when != ret = e1
when != &ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch does two things for SCM eUSCSI USB-SCSI converters:
1. SCM eUSCSI bridge devices are hard-wired to use SCSI ID 7. On connecting
the converter, access to that ID is attempted during the bus scan. Asking
the converter to issue INQUIRY commands to itself isn't very polite and
wastes time. Set this_id to 7 so __scsi_scan_target() skips it in the scan.
2. Enable multi-LUN support. eUSCSI devices don't support Get Max LUN
requests, returning an error (-32). [Different targets could have different
numbers of LUNs, so it wouldn't make sense to return a particular value in
response to Get Max LUN.]
usb_stor_scan_dwork() does this:
/* For bulk-only devices, determine the max LUN value */
if (us->protocol == USB_PR_BULK && !(us->fflags & US_FL_SINGLE_LUN)) {
mutex_lock(&us->dev_mutex);
us->max_lun = usb_stor_Bulk_max_lun(us);
mutex_unlock(&us->dev_mutex);
It avoids calling usb_stor_Bulk_max_lun() if US_FL_SINGLE_LUN, but not for
US_FL_SCM_MULT_TARG. Since usb_stor_Bulk_max_lun() returns 0 in the error
case, us->max_lun was always set to 0.
[If the user doesn't want multi-LUN support (perhaps there are SCSI devices
which respond to commands on all LUNs?), the US_FL_SINGLE_LUN quirk can be
specified on the kernel command line.]
Signed-off-by: Mark Knibbs <markk@clara.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb_stor_euscsi_init() enables multi-target mode for SCM eUSB SCSI bridge
devices. The control message it sends has wLength = 1 and the byte sent is
0x01. While that works, the SCM Windows driver does it with wLength = 0. We
may as well match what the SCM driver does.
Signed-off-by: Mark Knibbs <markk@clara.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit fixes ehci-orion operation in big-endian mode by enabling byteswap
when accessing registers using 'rdl' and 'wrl' macros.
Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
We need to check that we have both a valid data and control inteface for both
types of headers (union and not union.)
References: https://bugzilla.kernel.org/show_bug.cgi?id=83551
Reported-by: Simon Schubert <2+kernel@0x2c.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If probe() fails not only the attributes need to be removed
but also the memory freed.
Reported-by: Ahmed Tamrawi <ahmedtamrawi@gmail.com>
Signed-off-by: Oliver Neukum <oneukum@suse.de>
CC: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <chris@rorvick.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that ehci-dbgp has its own header, use it rather than duplicating
the declarations, etc.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The fotg210_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 fotg210 driver and will conflict those in the new
<linux/usb/ehci-dbgp.h> header.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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>
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 <chris@rorvick.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now that ehci-dbgp has its own header, use it rather than duplicating
the declarations, etc.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <chris@rorvick.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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>
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: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add new quirk for devices that cannot handle control-line state
requests.
Note that we currently send these requests to all devices, regardless of
whether they claim to support it, but that errors are only logged if
support is claimed.
Since commit 0943d8ead30e ("USB: cdc-acm: use tty-port dtr_rts"), which
only changed the timings for these requests slightly, this has been
reported to cause occasional firmware crashes on Simtec Electronics
Entropy Key devices after re-enumeration. Enable the quirk for this
device.
Reported-by: Nix <nix@esperi.org.uk>
Tested-by: Nix <nix@esperi.org.uk>
Cc: stable <stable@vger.kernel.org> # v3.16
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A single fix this for dwc2 this time. Because of
excessive debugging messages, dwc2 would sometimes
fail enumeration. The fix is simple, just converting
a dev_info() into dev_dbg().
Signed-off-by: Felipe Balbi <balbi@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJUW7HpAAoJEIaOsuA1yqREZKkP/j7o3Cyvkr7bW7I5N2mNNo3R
58hC+u8LcGMn3Q8YGoDGkVxGtM2OmXkorqAvWoEaM21LVHjl06zwAngoKNL/1Qm+
UPg4zvXGsKGqj+4cDb+SOKnIfNeMWHdwd0BmlSxrb+CnIQOxB7629R1XbhsWvZhS
Sf0h5p6zCUSC9A3poYeYtq7e/0yDBG345It9NzQgsXs1AqzTrcAgt1D9yyRSmRuZ
ADVgJrKto4gBBGK3jRhFzBBfdoUYHeL9mwXVogKUoOR+VLqfC0VmrwfKYqBx5kXW
2l2vIAv0mHWi/zBN1hfAcc53i1tOo0inxJnUep1Jfl8c/A8eb64lUPUCwoR22j3X
a3IC7LDHn+qO+Bx+DLvnKkapYtWjre9t+vglY16HH0QpE8ldqr/HOE5CAQP6EXRJ
nYLpVI0NDDwQGo16cs74jdRa/bUzT2OE2yh+Q78Nx8BrE87DsRh8jsniFnQ9coMP
Dxn0RKIRg6KpWHOl2qi77uSRf9XO4oG+tcgqvoU3UzD+fREGHHLD9Q46+caDhDkp
uX0kw5tIifUvdhFBJK/ev/R7yljOcd+91zfgeZjyBG0ZgcHRW3iod6NhJ/mmDcmo
n8c3TUMO9tTQvozp5KTx5/aPlkGVvva41Rkpg/6UBDuoiMhZithvYwvG1Wj0YSj9
SV1i9kNe+F1fybwfx+k9
=egWd
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-v3.18-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
Felipe writes:
usb: fixes for v3.18-rc4
A single fix this for dwc2 this time. Because of
excessive debugging messages, dwc2 would sometimes
fail enumeration. The fix is simple, just converting
a dev_info() into dev_dbg().
Signed-off-by: Felipe Balbi <balbi@ti.com>
