- 05 Sep, 2014 40 commits
-
-
Theodore Ts'o authored
commit 86f0afd4 upstream. If there is a failure while allocating the preallocation structure, a number of blocks can end up getting marked in the in-memory buddy bitmap, and then not getting released. This can result in the following corruption getting reported by the kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:758: group 1126, 12793 clusters in bitmap, 12729 in gd In that case, we need to release the blocks using mb_free_blocks(). Tested: fs smoke test; also demonstrated that with injected errors, the file system is no longer getting corrupted Google-Bug-Id: 16657874 Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Lukas Czerner authored
commit 4f579ae7 upstream. Currently punch hole code on files with direct/indirect mapping has some problems which may lead to a data loss. For example (from Jan Kara): fallocate -n -p 10240000 4096 will punch the range 10240000 - 12632064 instead of the range 1024000 - 10244096. Also the code is a bit weird and it's not using infrastructure provided by indirect.c, but rather creating it's own way. This patch fixes the issues as well as making the operation to run 4 times faster from my testing (punching out 60GB file). It uses similar approach used in ext4_ind_truncate() which takes advantage of ext4_free_branches() function. Also rename the ext4_free_hole_blocks() to something more sensible, like the equivalent we have for extent mapped files. Call it ext4_ind_remove_space(). This has been tested mostly with fsx and some xfstests which are testing punch hole but does not require unwritten extents which are not supported with direct/indirect mapping. Not problems showed up even with 1024k block size. Signed-off-by:
Lukas Czerner <lczerner@redhat.com> Signed-off-by:
-
addy ke authored
commit 9c5f7cad upstream. If slave holds scl, I2C_IPD[7] will be set 1 by controller for debugging. Driver must ignore it. [ 5.752391] rk3x-i2c ff160000.i2c: unexpected irq in WRITE: 0x80 [ 5.939027] rk3x-i2c ff160000.i2c: timeout, ipd: 0x80, state: 4 Signed-off-by:
Addy Ke <addy.ke@rock-chips.com> Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Wolfram Sang authored
commit 28772ac8 upstream. dma_{un}map_* uses 'enum dma_data_direction' not 'enum dma_transfer_direction'. Signed-off-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by:
-
Jason Gunthorpe authored
commit f07a5e9a upstream. Most device drivers do call 'tpm_do_selftest' which executes a TPM_ContinueSelfTest. tpm_i2c_stm_st33 is just pointlessly different, I think it is bug. These days we have the general assumption that the TPM is usable by the kernel immediately after the driver is finished, so we can no longer defer the mandatory self test to userspace. Reported-by:
Richard Marciel <rmaciel@linux.vnet.ibm.com> Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by:
Peter Huewe <peterhuewe@gmx.de> Signed-off-by:
-
Axel Lin authored
commit 5b963089 upstream. On platforms with sizeof(int) < sizeof(long), writing a temperature limit larger than MAXINT will result in unpredictable limit values written to the chip. Avoid auto-conversion from long to int to fix the problem. The hysteresis temperature range depends on the value of data->temp[attr->index], since val is subtracted from it. Use a wider clamp, [-120000, 220000] should do to cover the possible range. Also add missing TEMP_TO_REG() on writes into cached hysteresis value. Also uses clamp_val to simplify the code a bit. Signed-off-by:
Axel Lin <axel.lin@ingics.com> [Guenter Roeck: Fixed double TEMP_TO_REG on hysteresis updates] Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Axel Lin authored
commit d58e47d7 upstream. On platforms with sizeof(int) < sizeof(long), writing a temperature limit larger than MAXINT will result in unpredictable limit values written to the chip. Avoid auto-conversion from long to int to fix the problem. Voltage limits, fan minimum speed, pwm frequency, pwm ramp rate, and other attributes have the same problem, fix them as well. Zone temperature limits are signed, but were cached as u8, causing unepected values to be reported for negative temperatures. Cache as s8 to fix the problem. vrm is an u8, so the written value needs to be limited to [0, 255]. Signed-off-by:
-
Axel Lin authored
commit e9814295 upstream. Current code uses data_rate as array index in ads1015_read_adc() and uses pga as array index in ads1015_reg_to_mv, so we must make sure both data_rate and pga settings are in valid value range. Return -EINVAL if the setting is out-of-range. Signed-off-by:
-
Guenter Roeck authored
commit 3248c3b7 upstream. Temperature limit register writes did not account for negative numbers. As a result, writing -127000 resulted in -126000 written into the temperature limit register. This problem affected temp[1-3]_min, temp[1-3]_max, temp[1-3]_auto_temp_crit, and temp[1-3]_auto_temp_min. When writing pwm[1-3]_freq, a long variable was auto-converted into an int without range check. Wiring values larger than MAXINT resulted in unexpected register values. When writing temp[1-3]_auto_temp_max, an unsigned long variable was auto-converted into an int without range check. Writing values larger than MAXINT resulted in unexpected register values. vrm is an u8, so the written value needs to be limited to [0, 255]. Cc: Axel Lin <axel.lin@ingics.com> Reviewed-by:
-
Axel Lin authored
commit 56de1377 upstream. Current code uses channel as array index, so the valid channel value is 0 .. ADS1015_CHANNELS - 1. Signed-off-by:
-
Axel Lin authored
commit 2565fb05 upstream. On platforms with sizeof(int) < sizeof(unsigned long), writing a rpm value larger than MAXINT will result in unpredictable limit values written to the chip. Avoid auto-conversion from unsigned long to int to fix the problem. Signed-off-by:
-
Guenter Roeck authored
commit 1074d683 upstream. On platforms with sizeof(int) < sizeof(long), writing a temperature limit larger than MAXINT will result in unpredictable limit values written to the chip. Avoid auto-conversion from long to int to fix the problem. Cc: Axel Lin <axel.lin@ingics.com> Reviewed-by:
-
Axel Lin authored
commit cf44819c upstream. Ensure mutex lock protects the read-modify-write period to prevent possible race condition bug. In additional, update data->valid should also be protected by the mutex lock. Signed-off-by:
-
Axel Lin authored
commit cc336546 upstream. On platforms with sizeof(int) < sizeof(long), writing a temperature limit larger than MAXINT will result in unpredictable limit values written to the chip. Avoid auto-conversion from long to int to fix the problem. Signed-off-by:
-
Ulf Hansson authored
commit ad82bfea upstream. This patch won't change the behavior of how mmci deals with CMD irqs. By moving code from mmci_irq() to mmci_cmd_irq(), we getter a better overview of what going on. Cc: Peter Maydell <peter.maydell@linaro.org> Cc: John Stultz <john.stultz@linaro.org> Cc: Russell King <linux@arm.linux.org.uk> Tested-by:
Kees Cook <keescook@chromium.org> Tested-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Ulf Hansson authored
commit 1cb9da50 upstream. We don't need to verify the content of the status register twice, while we are about to handle a DATA irq. Instead let's leave all verification to be handled by mmci_data_irq(). Cc: Peter Maydell <peter.maydell@linaro.org> Cc: John Stultz <john.stultz@linaro.org> Cc: Russell King <linux@arm.linux.org.uk> Tested-by:
-
Russell King authored
commit 2d31ca3a upstream. Regular randconfig nightly testing has detected problems with omapdrm. omapdrm fails to build when the kernel is built to support 64-bit DMA addresses and/or 64-bit physical addresses due to an assumption about the width of these types. Use %pad to print DMA addresses, rather than %x or %Zx (which is even more wrong than %x). Avoid passing a uint32_t pointer into a function which expects dma_addr_t pointer. drivers/gpu/drm/omapdrm/omap_plane.c: In function 'omap_plane_pre_apply': drivers/gpu/drm/omapdrm/omap_plane.c:145:2: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Werror=format] drivers/gpu/drm/omapdrm/omap_plane.c:145:2: error: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Werror=format] make[5]: *** [drivers/gpu/drm/omapdrm/omap_plane.o] Error 1 drivers/gpu/drm/omapdrm/omap_gem.c: In function 'omap_gem_get_paddr': drivers/gpu/drm/omapdrm/omap_gem.c:794:4: error: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t' [-Werror=format] drivers/gpu/drm/omapdrm/omap_gem.c: In function 'omap_gem_describe': drivers/gpu/drm/omapdrm/omap_gem.c:991:4: error: format '%Zx' expects argument of type 'size_t', but argument 7 has type 'dma_addr_t' [-Werror=format] drivers/gpu/drm/omapdrm/omap_gem.c: In function 'omap_gem_init': drivers/gpu/drm/omapdrm/omap_gem.c:1470:4: error: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Werror=format] make[5]: *** [drivers/gpu/drm/omapdrm/omap_gem.o] Error 1 drivers/gpu/drm/omapdrm/omap_dmm_tiler.c: In function 'dmm_txn_append': drivers/gpu/drm/omapdrm/omap_dmm_tiler.c:226:2: error: passing argument 3 of 'alloc_dma' from incompatible pointer type [-Werror] make[5]: *** [drivers/gpu/drm/omapdrm/omap_dmm_tiler.o] Error 1 make[5]: Target `__build' not remade because of errors. make[4]: *** [drivers/gpu/drm/omapdrm] Error 2 Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Jeremy Vial authored
commit 9b5f7428 upstream. According to the comment “restore_es3: applies to 34xx >= ES3.0" in "arch/arm/mach-omap2/sleep34xx.S”, omap3_restore_es3 should be used if the revision of an OMAP34xx is ES3.1.2. Signed-off-by:
Jeremy Vial <jvial@adeneo-embedded.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Baruch Siach authored
commit bc994c77 upstream. Commit cb8db5d4 (UAPI: (Scripted) Disintegrate arch/arm/include/asm) moved these syscall comments out of their context into the UAPI headers. Fix this. Fixes: cb8db5d4 ("UAPI: (Scripted) Disintegrate arch/arm/include/asm") Signed-off-by:
Baruch Siach <baruch@tkos.co.il> Signed-off-by:
-
Suman Anna authored
commit 44e6ab1b upstream. The mailbox DT node for AM4372 is enabled and is corrected to remove some properties that have crept in by mistake. Fixes: 9e3269b8 (ARM: dts: AM4372: Add L2, EDMA, mailbox, MMC and SHAM nodes) Signed-off-by:
Suman Anna <s-anna@ti.com> Signed-off-by:
-
Semen Protsenko authored
commit 6a7519e8 upstream. "efi" global data structure contains "runtime_version" field which must be assigned in order to use it later in Runtime Services virtual calls (virt_efi_* functions). Before this patch "runtime_version" was unassigned (0), so each Runtime Service virtual call that checks revision would fail. Signed-off-by:
Semen Protsenko <semen.protsenko@linaro.org> Acked-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Matt Fleming <matt.fleming@intel.com> Signed-off-by:
-
Will Deacon authored
commit c878e0cf upstream. Our break hooks are used to handle brk exceptions from kgdb (and potentially kprobes if that code ever resurfaces), so don't bother calling them if the BRK exception comes from userspace. This prevents userspace from trapping to a kdb shell on systems where kgdb is enabled and active. Reported-by:
Omar Sandoval <osandov@osandov.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Catalin Marinas authored
commit 7f0b1bf0 upstream. The architecture specification states that both DSB and ISB are required between page table modifications and subsequent memory accesses using the corresponding virtual address. When TLB invalidation takes place, the tlb_flush_* functions already have the necessary barriers. However, there are other functions like create_mapping() for which this is not the case. The patch adds the DSB+ISB instructions in the set_pte() function for valid kernel mappings. The invalid pte case is handled by tlb_flush_* and the user mappings in general have a corresponding update_mmu_cache() call containing a DSB. Even when update_mmu_cache() isn't called, the kernel can still cope with an unlikely spurious page fault by re-executing the instruction. In addition, the set_pmd, set_pud() functions gain an ISB for architecture compliance when block mappings are created. Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Reported-by:
Leif Lindholm <leif.lindholm@linaro.org> Acked-by:
Steve Capper <steve.capper@linaro.org> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Daniel Bristot de Oliveira authored
commit d8d28c8f upstream. The scheduler uses policy == -1 to preserve the current policy state to implement sched_setparam(). But, as (int) -1 is equals to 0xffffffff, it's matching the if (policy & SCHED_RESET_ON_FORK) on _sched_setscheduler(). This match changes the policy value to an invalid value, breaking the sched_setparam() syscall. This patch checks policy == -1 before check the SCHED_RESET_ON_FORK flag. The following program shows the bug: int main(void) { struct sched_param param = { .sched_priority = 5, }; sched_setscheduler(0, SCHED_FIFO, ¶m); param.sched_priority = 1; sched_setparam(0, ¶m); param.sched_priority = 0; sched_getparam(0, ¶m); if (param.sched_priority != 1) printf("failed priority setting (found %d instead of 1)\n", param.sched_priority); else printf("priority setting fine\n"); } Signed-off-by:
Daniel Bristot de Oliveira <bristot@redhat.com> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Reviewed-by:
Steven Rostedt <rostedt@goodmis.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: linux-kernel@vger.kernel.org Fixes: 7479f3c9 "sched: Move SCHED_RESET_ON_FORK into attr::sched_flags" Link: http://lkml.kernel.org/r/9ebe0566a08dbbb3999759d3f20d6004bb2dbcfa.1406079891.git.bristot@redhat.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Hans de Goede authored
commit 8f873c1f upstream. Streams on the EJ168 do not work as they should. I've spend 2 days trying to get them to work, but without success. The first problem is that when ever you ring the stream-ring doorbell, the controller starts executing trbs at the beginning of the first ring segment, event if it ended somewhere else previously. This can be worked around by allowing enqueing only one td (not a problem with how streams are typically used) and then resetting our copies of the enqueueing en dequeueing pointers on a td completion to match what the controller seems to be doing. This way things seem to start working with uas and instead of being able to complete only the very first scsi command, the scsi core can probe the disk. But then things break later on when td-s get enqueued with more then one trb. The controller does seem to increase its dequeue pointer while executing a stream-ring (data transfer events I inserted for debugging do trigger). However execution seems to stop at the final normal trb of a multi trb td, even if there is a data transfer event inserted after the final trb. The first problem alone is a serious deviation from the spec, and esp. dealing with cancellation would have been very tricky if not outright impossible, but the second problem simply is a deal breaker altogether, so this patch simply disables streams. Note this will cause the usb-storage + uas driver pair to automatically switch to using usb-storage instead of uas on these devices, essentially reverting to the 3.14 and earlier behavior when uas was marked CONFIG_BROKEN. https://bugzilla.redhat.com/show_bug.cgi?id=1121288 https://bugzilla.kernel.org/show_bug.cgi?id=80101Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Alexander Usyskin authored
commit fe2f17eb upstream. wait_event_timeout can return 0 or the remaining jiffies so return -ETIME if disconnected state not reached. Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Alexander Usyskin authored
commit d5d83f8a upstream. Calling pm_schedule_suspend from the runtime pm idle callback may reschedule existing timer, thus in case of frequent runtime rpm idle call the suspend maybe starved. Instead we call pm_runtime_autosuspend which is checking if the timer is already charged. An example is monitoring device pci config space. Pci config sysfs handlers calls pci_config_pm_runtime_put/get helpers which in turns calls to device idle callback Signed-off-by:
-
Alexander Usyskin authored
commit 22b987a3 upstream. Link must be reset in case the fw doesn't respond to client disconnect request. We did charge the timer only in irq path from mei_cl_irq_close and not in mei_cl_disconnect Signed-off-by:
-
Alexander Usyskin authored
commit 3e37ebb7 upstream. On connection timeout we leave the connecting client in connecting state. Since a new connection is stalled till previous connection is completed in this case no new connection is possible till the user space does release the file handle. Therefore on timeout we move the client to disconnected state. Signed-off-by:
-
Takashi Iwai authored
commit f3ee07d8 upstream. ALC269 & co have many vendor-specific setups with COEF verbs. However, some verbs seem specific to some codec versions and they result in the codec stalling. Typically, such a case can be avoided by checking the return value from reading a COEF. If the return value is -1, it implies that the COEF is invalid, thus it shouldn't be written. This patch adds the invalid COEF checks in appropriate places accessing ALC269 and its variants. The patch actually fixes the resume problem on Acer AO725 laptop. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52181Tested-by:
Francesco Muzio <muziofg@gmail.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Hui Wang authored
commit f475371a upstream. On some HP laptops, the mute led is controlled by codec gpio. When some machine resume from s3/s4, the codec gpio data will be cleared to 0 by BIOS: Before suspend: IO[3]: enable=1, dir=1, wake=0, sticky=0, data=1, unsol=0 After resume: IO[3]: enable=1, dir=1, wake=0, sticky=0, data=0, unsol=0 To skip the AFG node to enter D3 can't fix this problem. A workaround is to restore the gpio data when the system resume back from s3/s4. It is safe even on the machines without this problem. BugLink: https://bugs.launchpad.net/bugs/1358116Tested-by:
Franz Hsieh <franz.hsieh@canonical.com> Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
-
David Henningsson authored
commit 42304474 upstream. This makes the mute LED work on a HP 15 touchsmart machine. BugLink: https://bugs.launchpad.net/bugs/1334950Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
Clemens Ladisch authored
commit 53da5ebf upstream. The BOSS ME-25 turns out not to have any useful descriptors in its MIDI interface, so its needs a quirk entry after all. Reported-and-tested-by:
Kees van Veen <kees.vanveen@gmail.com> Fixes: 8e5ced83 ("ALSA: usb-audio: remove superfluous Roland quirks") Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Takashi Iwai authored
commit e24aa0a4 upstream. CA0132 driver tries to reload the firmware at resume. Usually this works since the firmware loader core caches the firmware contents by itself. However, if the driver failed to load the firmwares (e.g. missing files), reloading the firmware at resume goes through the actual file loading code path, and triggers a kernel WARNING like: WARNING: CPU: 10 PID:11371 at drivers/base/firmware_class.c:1105 _request_firmware+0x9ab/0x9d0() For avoiding this situation, this patch makes CA0132 skipping the f/w loading at resume when it failed at probe time. Reported-and-tested-by:
Janek Kozicki <cosurgi@gmail.com> Signed-off-by:
-
Clemens Ladisch authored
commit f42bb222 upstream. Just add the PCI ID for the STX II. It appears to work the same as the STX, except for the addition of the not-yet-supported daughterboard. Tested-by:
Mario <fugazzi99@gmail.com> Tested-by:
corubba <corubba@gmx.de> Signed-off-by:
-
Paul S McSpadden authored
commit 542baf94 upstream. Original patch fixed the original problem, but the sound was far too low for most users. This patch references a compare matrix to allow the volume levels to act normally. I personally tested this patch myself, and volume levels returned to normal. Please see this discussion for more details: https://bugzilla.kernel.org/show_bug.cgi?id=65251Signed-off-by:
Paul S McSpadden <fisch602@gmail.com> Signed-off-by:
-
Hui Wang authored
commit 7440850c upstream. ON the machine, two pin complex (0xb and 0xe) are both routed to the same external right-side mic jack, this makes the jack can't work. To fix this problem, set the 0xe to "not connected". BugLink: https://bugs.launchpad.net/bugs/1350148Tested-by:
-
Pratyush Anand authored
commit a40178b2 upstream. Problem Summary: Problem has been observed generally with PM states where VBUS goes off during suspend. There are some SS USB devices which take longer time for link training compared to many others. Such devices fail to reconnect with same old address which was associated with it before suspend. When system resumes, at some point of time (dpm_run_callback-> usb_dev_resume->usb_resume->usb_resume_both->usb_resume_device-> usb_port_resume) SW reads hub status. If device is present, then it finishes port resume and re-enumerates device with same address. If device is not present then, SW thinks that device was removed during suspend and therefore does logical disconnection and removes all the resource allocated for this device. Now, if I put sufficient delay just before root hub status read in usb_resume_device then, SW sees always that device is present. In normal course(without any delay) SW sees that no device is present and then SW removes all resource associated with the device at this port. In the latter case, after sometime, device says that hey I am here, now host enumerates it, but with new address. Problem had been reproduced when I connect verbatim USB3.0 hard disc with my STiH407 XHCI host running with 3.10 kernel. I see that similar problem has been reported here. https://bugzilla.kernel.org/show_bug.cgi?id=53211 Reading above it seems that bug was not in 3.6.6 and was present in 3.8 and again it was not present for some in 3.12.6, while it was present for few others. I tested with 3.13-FC19 running at i686 desktop, problem was still there. However, I was failed to reproduce it with 3.16-RC4 running at same i686 machine. I would say it is just a random observation. Problem for few devices is always there, as I am unable to find a proper fix for the issue. So, now question is what should be the amount of delay so that host is always able to recognize suspended device after resume. XHCI specs 4.19.4 says that when Link training is successful, port sets CSC bit to 1. So if SW reads port status before successful link training, then it will not find device to be present. USB Analyzer log with such buggy devices show that in some cases device switch on the RX termination after long delay of host enabling the VBUS. In few other cases it has been seen that device fails to negotiate link training in first attempt. It has been reported till now that few devices take as long as 2000 ms to train the link after host enabling its VBUS and RX termination. This patch implements a 2000 ms timeout for CSC bit to set ie for link training. If in a case link trains before timeout, loop will exit earlier. This patch implements above delay, but only for SS device and when persist is enabled. So, for the good device overhead is almost none. While for the bad devices penalty could be the time which it take for link training. But, If a device was connected before suspend, and was removed while system was asleep, then the penalty would be the timeout ie 2000 ms. Results: Verbatim USB SS hard disk connected with STiH407 USB host running 3.10 Kernel resumes in 461 msecs without this patch, but hard disk is assigned a new device address. Same system resumes in 790 msecs with this patch, but with old device address. Signed-off-by:
Pratyush Anand <pratyush.anand@st.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
Bryan O'Donoghue authored
commit 6e693739 upstream. The EHCI packet buffer in/out threshold is programmable for Intel Quark X1000 USB host controller, and the default value is 0x20 dwords. The in/out threshold can be programmed to 0x80 dwords (512 Bytes) to maximize the perfomrance, but only when isochronous/interrupt transactions are not initiated by the USB host controller. This patch is to reconfigure the packet buffer in/out threshold as maximal as possible to maximize the performance, and 0x7F dwords (508 Bytes) should be used because the USB host controller initiates isochronous/interrupt transactions. Signed-off-by:
Bryan O'Donoghue <bryan.odonoghue@intel.com> Signed-off-by:
Alvin (Weike) Chen <alvin.chen@intel.com> Acked-by:
Jingoo Han <jg1.han@samsung.com> Signed-off-by:
-
Patrick Riphagen authored
commit 4bdcde35 upstream. This adds support for new Xsens devices, using Xsens' own Vendor ID. Signed-off-by:
Patrick Riphagen <patrick.riphagen@xsens.com> Signed-off-by:
Frans Klaver <frans.klaver@xsens.com> Cc: Johan Hovold <johan@kernel.org> Signed-off-by:
-
