- 28 Mar, 2017 11 commits
-
-
Johan Hovold authored
Use the calc_num_ports callback to ignore unused endpoints. The driver binds to any interface with at least one bulk-in and one bulk-out endpoint, but some devices can have three or more endpoints of which only either the first or second pair of endpoints is needed. This avoids allocating resources for unused endpoints, and specifically a port is no longer registered for the unused first endpoint pair when there are more than three endpoints. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Use the calc_num_ports rather than attach callback to determine which interface to bind to in order to avoid allocating port-resources for interfaces that won't be bound. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
We can now abort probe early after an error in calc_num_ports by returning an errno instead of attempting to continue probing but not register any ports. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Simplify the endpoint sanity check by letting core verify that the required endpoints are present and moving the max-packet check to calc_num_ports. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Use the calc_num_ports rather than probe callback to determine which interface to bind to. This allows us to remove some duplicate code. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Implement the "horrible endpoint hack" for some legacy devices as a quirk and clean up the code somewhat. Note that the bulk-endpoint check can be removed as core will already have verified this. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Some pl2303 devices require the use of the interrupt endpoint of an unrelated interface. This has so far been dealt with in usb-serial core, but can now be moved to a driver calc_num_ports callback. Note that we relax the endpoint requirements checked by core and instead verify that we have an interrupt-in endpoint in calc_num_ports for all devices so that the hack can first be applied. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Relax the generic driver bulk-endpoint requirement. The driver handles devices without bulk-out endpoints just fine these days. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Add a calc_num_ports callback to the generic driver and verify that the device has the required endpoints there instead of in core. Note that the generic driver num_ports field was never used. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Add a probe callback to the generic driver and print the only-for-testing message there. This is a first step in getting rid of the CONFIG_USB_SERIAL_GENERIC ifdef from usb-serial core. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Allow subdrivers to modify the port-endpoint mapping by passing the endpoint descriptors to calc_num_ports. The callback can now also be used to verify that the required endpoints exists and abort probing otherwise. This will allow us to get rid of a few hacks in subdrivers that are already modifying the port-endpoint mapping (or aborting probe due to missing endpoints), but only after the port structures have been setup. Signed-off-by: Johan Hovold <johan@kernel.org>
-
- 16 Mar, 2017 21 commits
-
-
Johan Hovold authored
Simplify the endpoint sanity check by letting core verify that the required endpoints are present. Note that the driver registers four ports but uses five bulk-endpoint pairs. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Simplify the endpoint sanity check by letting core verify that the required endpoints are present. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Simplify the endpoint sanity check by letting core verify that the required endpoints are present. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Simplify the endpoint sanity check by letting core verify that the required endpoints are present. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Simplify the endpoint sanity check by letting core verify that the required endpoints are present. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Simplify the endpoint sanity check by letting core verify that the required endpoints are present. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Simplify the endpoint sanity check by letting core verify that the required endpoints are present. Note that the driver uses the second bulk-out endpoint for writing. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Simplify the endpoint sanity check by letting core verify that the required endpoints are present. Note that the driver expects two bulk-endpoint pairs also for mcs7715 devices for which only one serial port is registered. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Simplify the endpoint sanity check by letting core verify that the required endpoints are present. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Simplify the endpoint sanity check by letting core verify that the required endpoints are present. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Simplify the endpoint sanity check by letting core verify that the required endpoints are present. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Simplify the endpoint sanity check by letting core verify that the required endpoints are present. Also require the presence of a bulk-out endpoint, something which prevents the driver from trying to send bulk messages over the control pipe should a bulk-out endpoint be missing. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Simplify the endpoint sanity check by letting core verify that the required endpoints are present. Note that this driver uses an additional bulk-endpoint pair as an out-of-band port. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Simplify the endpoint sanity check by letting core verify that the required endpoints are present. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Simplify the endpoint sanity check by letting core verify that the required endpoints are present. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Allow drivers to specify a minimum number of endpoints per type, which USB serial core will verify after subdriver probe has returned (where the current alternate setting may have been changed). Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Since commit 0a8fd134 ("USB: fix problems with duplicate endpoint addresses") USB core guarantees that there are no more than 15 endpoint descriptors per type (and altsetting) so the corresponding overflow checks can now be replaced with a compile-time check on the array sizes (and indirectly the maximum number of ports). Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Raise the arbitrary limit of how many ports a single device can claim from eight to 16. This specifically enables the upper eight ports of some mxuport devices. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Refactor and clean up endpoint handling. This specifically moves the endpoint-descriptor arrays of the stack. Note that an err_free_epds label is not yet added to avoid a compilation warning when neither CONFIG_USB_SERIAL_PL2303 or CONFIG_USB_SERIAL_GENERIC is selected. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Use unsigned-char type for the endpoint and port counters. Signed-off-by: Johan Hovold <johan@kernel.org>
-
Johan Hovold authored
Clean up the probe error paths by adding a couple of new error labels. Signed-off-by: Johan Hovold <johan@kernel.org>
-
- 13 Mar, 2017 5 commits
-
-
Ian Abbott authored
The 'store' function for the "event_char" device attribute currently expects a base 10 value. The value is composed of an enable bit in bit 8 and an 8-bit "event character" code in bits 7 to 0. It seems reasonable to allow hexadecimal and octal numbers to be written to the device attribute in addition to decimal. Make it so. Change the debug message to show the value in hexadecimal, rather than decimal. Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
-
Ian Abbott authored
The "event_char" device attribute value, when written, is interpreted as an enable bit in bit 8, and an "event character" in bits 7 to 0. Return an error -EINVAL for out-of-range values. Use kstrtouint() to parse the integer instead of the obsolete simple_strtoul(). Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
-
Ian Abbott authored
Valid latency timer values are between 1 ms and 255 ms in 1 ms steps. The store function for the "latency_timer" device attribute currently allows any value, although only the lower 16 bits will be sent to the device, and the device only stores the lower 8 bits. The hardware appears to accept the (invalid) value 0 and treats it the same as 1 (resulting in a latency of 1 ms). Change the latency_timer_store() function to accept only the values 0 to 255, returning an error -EINVAL for out-of-range values. Call kstrtou8() to parse the integer instead of the obsolete simple_strtoul(). Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
-
Ian Abbott authored
If a BM type chip has iSerialNumber set to 0 in its EEPROM, an incorrect value is read from the bcdDevice field of the USB descriptor, making it look like an AM type chip. Attempt to correct this in ftdi_determine_type() by attempting to read the latency timer for an AM type chip if it has iSerialNumber set to 0. If that succeeds, assume it is a BM type chip. Currently, read_latency_timer() bails out without reading the latency timer for an AM type chip, so factor out the guts of read_latency_timer() into a new function _read_latency_timer() that attempts to read the latency timer regardless of chip type, and returns either the latency timer value or a negative error number. Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
-
Ian Abbott authored
The latency timer was introduced with the FT232BM and FT245BM chips. Do not bother attempting to read or write it for older chip versions. Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Johan Hovold <johan@kernel.org>
-
- 12 Mar, 2017 3 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linuxLinus Torvalds authored
Pull s390 fixes from Martin Schwidefsky: - four patches to get the new cputime code in shape for s390 - add the new statx system call - a few bug fixes * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390: wire up statx system call KVM: s390: Fix guest migration for huge guests resulting in panic s390/ipl: always use load normal for CCW-type re-IPL s390/timex: micro optimization for tod_to_ns s390/cputime: provide archicture specific cputime_to_nsecs s390/cputime: reset all accounting fields on fork s390/cputime: remove last traces of cputime_t s390: fix in-kernel program checks s390/crypt: fix missing unlock in ctr_paes_crypt on error path
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Thomas Gleixner: - a fix for the kexec/purgatory regression which was introduced in the merge window via an innocent sparse fix. We could have reverted that commit, but on deeper inspection it turned out that the whole machinery is neither documented nor robust. So a proper cleanup was done instead - the fix for the TLB flush issue which was discovered recently - a simple typo fix for a reboot quirk * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/tlb: Fix tlb flushing when lguest clears PGE kexec, x86/purgatory: Unbreak it and clean it up x86/reboot/quirks: Fix typo in ASUS EeeBook X205TA reboot quirk
-