- 30 Jan, 2015 8 commits
-
-
Dan Williams authored
commit 72dd299d upstream. Ronny reports: https://bugzilla.kernel.org/show_bug.cgi?id=87101 "Since commit 8a4aeec8 "libata/ahci: accommodate tag ordered controllers" the access to the harddisk on the first SATA-port is failing on its first access. The access to the harddisk on the second port is working normal. When reverting the above commit, access to both harddisks is working fine again." Maintain tag ordered submission as the default, but allow sata_sil24 to continue with the old behavior. Cc: Tejun Heo <tj@kernel.org> Reported-by:
Ronny Hegewald <Ronny.Hegewald@online.de> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Roger Tseng authored
commit b166010f upstream. sd_set_power_mode() in derived module drivers/mmc/host/rtsx_usb_sdmmc.c acquires dev_mutex and then calls pm_runtime_get_sync() to make sure the device is awake while initializing a newly inserted card. Once it is called during suspending state and explicitly before rtsx_usb_suspend() acquires the same dev_mutex, both routine deadlock and further hang the driver because pm_runtime_get_sync() waits the pending PM operations. Fix this by using an empty suspend method. mmc_core always turns the LED off after a request is done and thus it is ok to remove the only rtsx_usb_turn_off_led() here. Fixes: 730876be ("mfd: Add realtek USB card reader driver") Signed-off-by:
Roger Tseng <rogerable@realtek.com> [Lee: Removed newly unused variable] Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Felipe Balbi authored
commit f29ae369 upstream. If we don't tell regmap-irq that our first status register is at offset 1, it will try to read offset zero, which is the chipid register. Fixes: 44b4dc61 mfd: tps65218: Add driver for the TPS65218 PMIC Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Felipe Balbi authored
commit 773328da upstream. STATUS register can be modified by the HW, so we should bypass cache because of that. In the case of INT[12] registers, they are the ones that actually clear the IRQ source at the time they are read. If we rely on the cache for them, we will never be able to clear the interrupt, which will cause our IRQ line to be disabled due to IRQ throttling. Fixes: 44b4dc61 mfd: tps65218: Add driver for the TPS65218 PMIC Signed-off-by:
-
Jim Lin authored
commit db93facf upstream. This patch is to fix two deadlock cases. Deadlock 1: CPU #1 pinctrl_register-> pinctrl_get -> create_pinctrl (Holding lock pinctrl_maps_mutex) -> get_pinctrl_dev_from_devname (Trying to acquire lock pinctrldev_list_mutex) CPU #0 pinctrl_unregister (Holding lock pinctrldev_list_mutex) -> pinctrl_put ->> pinctrl_free -> pinctrl_dt_free_maps -> pinctrl_unregister_map (Trying to acquire lock pinctrl_maps_mutex) Simply to say CPU#1 is holding lock A and trying to acquire lock B, CPU#0 is holding lock B and trying to acquire lock A. Deadlock 2: CPU #3 pinctrl_register-> pinctrl_get -> create_pinctrl (Holding lock pinctrl_maps_mutex) -> get_pinctrl_dev_from_devname (Trying to acquire lock pinctrldev_list_mutex) CPU #2 pinctrl_unregister (Holding lock pctldev->mutex) -> pinctrl_put ->> pinctrl_free -> pinctrl_dt_free_maps -> pinctrl_unregister_map (Trying to acquire lock pinctrl_maps_mutex) CPU #0 tegra_gpio_request (Holding lock pinctrldev_list_mutex) -> pinctrl_get_device_gpio_range (Trying to acquire lock pctldev->mutex) Simply to say CPU#3 is holding lock A and trying to acquire lock D, CPU#2 is holding lock B and trying to acquire lock A, CPU#0 is holding lock D and trying to acquire lock B. Signed-off-by:
Jim Lin <jilin@nvidia.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Stephen Boyd authored
commit bcd53f85 upstream. Timur reports that this code crashes if nfunctions is 0. Fix the loop iteration to only consider valid elements of the functions array. Reported-by:
Timur Tabi <timur@codeaurora.org> Cc: Pramod Gurav <pramod.gurav@smartplayin.com> Cc: Bjorn Andersson <bjorn.andersson@sonymobile.com> Cc: Ivan T. Ivanov <iivanov@mm-sol.com> Cc: Andy Gross <agross@codeaurora.org> Fixes: 32745581 "pinctrl: qcom: Add support for reset for apq8064" Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Oliver Hartkopp authored
commit 6cfda7fb upstream. During the CAN FD standardization process within the ISO it turned out that the failure detection capability has to be improved. The CAN in Automation organization (CiA) defined the already implemented CAN FD controllers as 'non-ISO' and the upcoming improved CAN FD controllers as 'ISO' compliant. See at http://www.can-cia.com/index.php?id=1937 Finally there will be three types of CAN FD controllers in the future: 1. ISO compliant (fixed) 2. non-ISO compliant (fixed, like the M_CAN IP v3.0.1 in m_can.c) 3. ISO/non-ISO CAN FD controllers (switchable, like the PEAK USB FD) So the current M_CAN driver for the M_CAN IP v3.0.1 has to expose its non-ISO implementation by setting the CAN_CTRLMODE_FD_NON_ISO ctrlmode at startup. As this bit cannot be switched at configuration time CAN_CTRLMODE_FD_NON_ISO must not be set in ctrlmode_supported of the current M_CAN driver. Signed-off-by:
Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Oliver Hartkopp authored
commit 9b1087aa upstream. When changing flags in the CAN drivers ctrlmode the provided new content has to be checked whether the bits are allowed to be changed. The bits that are to be changed are given as a bitfield in cm->mask. Therefore checking against cm->flags is wrong as the content can hold any kind of values. The iproute2 tool sets the bits in cm->mask and cm->flags depending on the detected command line options. To be robust against bogus user space applications additionally sanitize the provided flags with the provided mask. Cc: Wolfgang Grandegger <wg@grandegger.com> Signed-off-by:
-
- 27 Jan, 2015 32 commits
-
-
Greg Kroah-Hartman authored
-
Bandan Das authored
commit 78051e3b upstream. If L0 has disabled EPT, don't advertise unrestricted mode at all since it depends on EPT to run real mode code. Fixes: 92fbc7b1Reviewed-by:
Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by:
Bandan Das <bsd@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Ville Syrjälä authored
commit 7f1241ed upstream. pps_{lock,unlock}() call intel_display_power_{get,put}() outside pps_mutes to avoid deadlocks with the power_domain mutex. In theory during aux transfers we should usually have the relevant power domain references already held by some higher level code, so this should not result in much overhead (exception being userspace i2c-dev access). However thanks to the check_power_well() calls in intel_display_power_{get/put}() we end up doing a few Punit reads for each aux transfer. Obviously doing this for each byte transferred via i2c-over-aux is not a good idea. I can't think of a good way to keep check_power_well() while eliminating the overhead, so let's just remove check_power_well() entirely. Fixes a driver init time regression introduced by: commit 773538e8 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Sep 4 14:54:56 2014 +0300 drm/i915: Reset power sequencer pipe tracking when disp2d is off Credit goes to Jani for figuring this out. v2: Add the regression note in the commit message. Cc: Egbert Eich <eich@suse.de> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86201Tested-by:
Wendy Wang <wendy.wang@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> [Jani: s/intel_runtime_pm.c/intel_pm.c/g and wiggle for 3.18] Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Nicholas Bellinger authored
commit 46243860 upstream. While looking at hch's recent conversion to drop the MSG_*_TAG definitions, I noticed a long standing bug in vhost-scsi where the VIRTIO_SCSI_S_* attribute definitions where incorrectly being passed directly into target_submit_cmd_map_sgls(). This patch adds the missing virtio-scsi to TCM/SAM task attribute conversion. Cc: Christoph Hellwig <hch@lst.de> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Nicholas Bellinger authored
commit 046ba642 upstream. This patch drops the arbitrary maximum I/O size limit in sbc_parse_cdb(), which currently for fabric_max_sectors is hardcoded to 8192 (4 MB for 512 byte sector devices), and for hw_max_sectors is a backend driver dependent value. This limit is problematic because Linux initiators have only recently started to honor block limits MAXIMUM TRANSFER LENGTH, and other non-Linux based initiators (eg: MSFT Fibre Channel) can also generate I/Os larger than 4 MB in size. Currently when this happens, the following message will appear on the target resulting in I/Os being returned with non recoverable status: SCSI OP 28h with too big sectors 16384 exceeds fabric_max_sectors: 8192 Instead, drop both [fabric,hw]_max_sector checks in sbc_parse_cdb(), and convert the existing hw_max_sectors into a purely informational attribute used to represent the granuality that backend driver and/or subsystem code is splitting I/Os upon. Also, update FILEIO with an explicit FD_MAX_BYTES check in fd_execute_rw() to deal with the one special iovec limitiation case. v2 changes: - Drop hw_max_sectors check in sbc_parse_cdb() Reported-by:
Lance Gropper <lance.gropper@qosserver.com> Reported-by:
Stefan Priebe <s.priebe@profihost.ag> Cc: Christoph Hellwig <hch@lst.de> Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Trond Myklebust authored
commit 06bed7d1 upstream. This commit fixes a race whereby nlmclnt_init() first starts the lockd daemon, and then calls nlm_bind_host() with the expectation that nlmsvc_timeout has already been initialised. Unfortunately, there is no no synchronisation between lockd() and lockd_up() to guarantee that this is the case. Fix is to move the initialisation of nlmsvc_timeout into lockd_create_svc Fixes: 9a1b6bf8 ("LOCKD: Don't call utsname()->nodename...") Cc: Bruce Fields <bfields@fieldses.org> Cc: stable@vger.kernel.org # 3.10.x Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Michal Marek authored
commit a16c5f99 upstream. scripts/Makefile.clean treats absolute path specially, but $(objtree)/debian is no longer an absolute path since 7e1c0477 (kbuild: Use relative path for $(objtree). Work around this by checking if the path starts with $(objtree)/. Reported-and-tested-by:
Sedat Dilek <sedat.dilek@gmail.com> Fixes: 7e1c0477 (kbuild: Use relative path for $(objtree) Signed-off-by:
Michal Marek <mmarek@suse.cz> Signed-off-by:
-
Daniel Borkmann authored
commit b485342b upstream. Commit a074335a ("x86, um: Mark system call tables readonly") was supposed to mark the sys_call_table in UML as RO by adding the const, but it doesn't have the desired effect as it's nevertheless being placed into the data section since __cacheline_aligned enforces sys_call_table being placed into .data..cacheline_aligned instead. We need to use the ____cacheline_aligned version instead to fix this issue. Before: $ nm -v arch/x86/um/sys_call_table_64.o | grep -1 "sys_call_table" U sys_writev 0000000000000000 D sys_call_table 0000000000000000 D syscall_table_size After: $ nm -v arch/x86/um/sys_call_table_64.o | grep -1 "sys_call_table" U sys_writev 0000000000000000 R sys_call_table 0000000000000000 D syscall_table_size Fixes: a074335a ("x86, um: Mark system call tables readonly") Cc: H. Peter Anvin <hpa@zytor.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Daniel Borkmann <dborkman@redhat.com> Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Richard Weinberger authored
commit f911d731 upstream. futex_atomic_cmpxchg_inatomic() does not work on UML because it triggers a copy_from_user() in kernel context. On UML copy_from_user() can only be used if the kernel was called by a real user space process such that UML can use ptrace() to fetch the value. Reported-by:
Miklos Szeredi <miklos@szeredi.hu> Suggested-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Daniel Walter <d.walter@0x90.at> Signed-off-by:
-
Dan Carpenter authored
commit b5c8afe5 upstream. "origPtr" is used as an offset into the bd->dbuf[] array. That array is allocated in start_bunzip() and has "bd->dbufSize" number of elements so the test here should be >= instead of >. Later we check "origPtr" again before using it as an offset so I don't know if this bug can be triggered in real life. Fixes: bc22c17e ('bzip2/lzma: library support for gzip, bzip2 and lzma decompression') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Alain Knaff <alain@knaff.lu> Cc: Yinghai Lu <yinghai@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Lars-Peter Clausen authored
commit 2eacc608 upstream. The ad7991/ad7995/ad7999 does not have a configuration register like the other devices that can be written and read. The configuration is written as part of the conversion sequence. Fixes: 0f7ddcc1 ("iio:adc:ad799x: Write default config on probe and reset alert status on probe") Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Tested-by:
Mike Looijmans <mike.looijmans@topic.nl> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Mugunthan V N authored
commit 69d2626f upstream. 64KiB is allocated for qspi dtb partition which is not sufficient, so updating the partition table size to 512KiB for device tree partition. This also aligns the QSPI partition definitions between kernel and U-Boot. Fixes: dc2dd5b8 ("ARM: dts: dra7: Add qspi device") Signed-off-by:
Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Geert Uytterhoeven authored
commit b0ddb319 upstream. The sh73a0 INTC can't mask interrupts properly most likely due to a hardware bug. Set the .control_parent flag to delegate masking to the parent interrupt controller, like was already done for irqpin1. Without this, accessing the three-axis digital accelerometer ADXL345 on kzm9g through /dev/input/event1 causes an interrupt storm, which requires a power-cycle to recover from. This was inspired by a patch for arch/arm/boot/dts/sh73a0.dtsi from Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Fixes: 341eb546 ("ARM: shmobile: INTC External IRQ pin driver on sh73a0") Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
-
Jisheng Zhang authored
commit 5adba7c2 upstream. There's no card detection for the eMMC, so this patch adds the missing broken-cd property. This patch also sets bus width as 8 to add MMC_CAP_8_BIT_DATA in the Host capabilities. Fixes: 3047086d ("ARM: dts: berlin: enable SD card reader and eMMC for the BG2Q DMP") Signed-off-by:
Jisheng Zhang <jszhang@marvell.com> Signed-off-by:
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by:
-
Keerthy authored
commit c4cf0935 upstream. Correct returning IRQ_HANDLED unconditionally in the irq handler. Return IRQ_NONE for some interrupt which we do not expect to be handled in this handler. This prevents kernel stalling with back to back spurious interrupts. Fixes: 2722e56d ("OMAP4: l3: Introduce l3-interconnect error handling driver") Acked-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Keerthy <j-keerthy@ti.com> Signed-off-by:
-
Keerthy authored
commit 61b43d4e upstream. On certain SoCs such as AM437x SoC, L3_noc error registers are maintained in power domain such as per domain which looses context as part of low power state such as RTC+DDR mode. On these platforms when we mask interrupts which we cannot handle, the source of these interrupts still remain on resume, however, the flag mux registers now contain their reset value (unmasked) - this breaks the system with infinite interrupts since we do not these interrupts to take place ever again. To handle this: restore the masking of interrupts which we have already recorded in the system as ones we cannot handle. Fixes: 2100b595 ("bus: omap_l3_noc: ignore masked out unclearable targets") Acked-by:
-
Lennart Sorensen authored
commit 999f934d upstream. If the boot loader enables HYP mode on the boot CPU, the secondary CPU also needs to call into the ROM to switch to HYP mode before booting. The firmwares on the omap5 and dra7xx unfortunately do not take care of this, so it has to be handled by the kernel. This patch is based on "[PATCH 2/2] ARM: OMAP5: Add HYP mode entry support for secondary CPUs" by Santosh Shilimkar <santosh.shilimkar@ti.com>, except this version does not require a compile time CONFIG to control if it should enable HYP mode or not, it simply does it based on the mode of the boot CPU, so it works whether the CPU boots in SVC or HYP mode, and should even work as a guest kernel inside kvm if qemu decides to support emulating the omap5 or dra7xx. Signed-off-by:
Len Sorensen <lsorense@csclub.uwaterloo.ca> Signed-off-by:
-
Lennart Sorensen authored
commit 572b24e6 upstream. The switch statement of the possible list of SYSCLK1 frequencies is missing a 0 in 4 out of the 7 frequencies. Fixes: fa6d79d2 ("ARM: OMAP: Add initialisation for the real-time counter") Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Acked-by:
-
Gary Bisson authored
commit 81ef4479 upstream. The post dividers do not work on i.MX6Q rev T0 1.0 so they must be fixed to 1. As the table index was wrong, a divider a of 4 could still be requested which implied the clock not to be set properly. This is the root cause of the HDMI not working at high resolution on rev T0 1.0 of the SoC. Signed-off-by:
Gary Bisson <bisson.gary@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
-
Dmitry Voytik authored
commit d2a10a17 upstream. Drop unnecessary semicolon after closing curly bracket. Signed-off-by:
Dmitry Voytik <voytikd@gmail.com> Signed-off-by:
-
Fabio Estevam authored
commit 7a9f0604 upstream. GPIO2_5 is the reset GPIO for the USB3317 ULPI PHY. Instead of modelling it as a regulator, the correct approach is to use the 'reset_gpios' property of the "usb-nop-xceiv" node. GPIO1_7 is the reset GPIO for the USB2517 USB hub. As we currently don't have dt bindings to describe a HUB reset, let's keep using the regulator approach. Rename the regulator to 'reg_hub_reset' to better describe its function and bind it with the USB host1 port instead. USB host support has been introduced by commit 9bf206a9 ("ARM: dts: imx51-babbage: Add USB Host1 support"), which landed in 3.16 and it seems that USB has only been functional due to previous bootloader initialization. With this patch applied we can get USB host to work without relying on the bootloader. Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by:
-
Fabio Estevam authored
commit 7a87e9cb upstream. From Documentation/devicetree/bindings/clock/imx25-clock.txt: cspi1_ipg 78 cspi2_ipg 79 cspi3_ipg 80 , so fix the SPI1 clocks accordingly to avoid a kernel hang when trying to access SPI1. Signed-off-by:
-
Fabio Estevam authored
commit 7c168ed8 upstream. The default qspi2_clk_sel field of register CCM_CS2CDR contains '110' which is marked as 'reserved', so we can't rely on the default value. Provide a proper parent for QSPI clocks to avoid a kernel oops: [ 1.037920] Division by zero in kernel. [ 1.041807] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc7-next-20141204-00002-g5aa23e1 #2143 [ 1.050967] Hardware name: Freescale i.MX6 SoloX (Device Tree) [ 1.056853] Backtrace: [ 1.059360] [<80011ea0>] (dump_backtrace) from [<8001203c>] (show_stack+0x18/0x1c) [ 1.066982] r6:00000000 r5:00000000 r4:00000000 r3:00000000 [ 1.072754] [<80012024>] (show_stack) from [<806b7100>] (dump_stack+0x88/0xa4) [ 1.080038] [<806b7078>] (dump_stack) from [<80011d20>] (__div0+0x18/0x20) [ 1.086958] r5:be018500 r4:be017c00 [ 1.090600] [<80011d08>] (__div0) from [<802aa418>] (Ldiv0+0x8/0x10) [ 1.097012] [<80504fbc>] (clk_divider_set_rate) from [<80503ddc>] (clk_change_rate+0x14c/0x17c) [ 1.105759] r7:00000000 r6:00000000 r5:be018500 r4:00000000 [ 1.111516] [<80503c90>] (clk_change_rate) from [<80503ea0>] (clk_set_rate+0x94/0x98) [ 1.119391] r8:be7e0368 r7:00000000 r6:be11a000 r5:be018500 r4:00000000 r3:00000000 [ 1.127290] [<80503e0c>] (clk_set_rate) from [<80410558>] (fsl_qspi_probe+0x23c/0x75c) [ 1.135260] r5:be11a010 r4:be350010 [ 1.138900] [<8041031c>] (fsl_qspi_probe) from [<80385a18>] (platform_drv_probe+0x50/0xac) Signed-off-by:
-
Nishanth Menon authored
commit 40d1746d upstream. CONFIG_GENERIC_CPUFREQ_CPU0 disappeared with commit bbcf0719 ("cpufreq: cpu0: rename driver and internals to 'cpufreq_dt'") Use the renamed CONFIG_CPUFREQ_DT generic driver. It looks like with v3.18-rc1, commit bbcf0719 and fdc509b1 came in via different trees causing the resultant v3.18-rc1 to be non-functional for cpufreq as default supported with omap2plus_defconfig. Fixes: fdc509b1 ("ARM: omap2plus_defconfig: Add cpufreq to defconfig") Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Dmitry Torokhov authored
commit 9333caea upstream. When KBC is in active multiplexing mode the touchpad on this laptop does not work. Reported-by:
Bilal Koc <koc.bilo@googlemail.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Srihari Vijayaraghavan authored
commit 148e9a71 upstream. On some laptops, keyboard needs to be reset in order to successfully detect touchpad (e.g., some Gigabyte laptop models with Elantech touchpads). Without resettin keyboard touchpad pretends to be completely dead. Based on the original patch by Mateusz Jończyk this version has been expanded to include DMI based detection & application of the fix automatically on the affected models of laptops. This has been confirmed to fix problem by three users already on three different models of laptops. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81331Signed-off-by:
Srihari Vijayaraghavan <linux.bug.reporting@gmail.com> Acked-by:
Mateusz Jończyk <mat.jonczyk@o2.pl> Tested-by:
Guillaum Bouchard <guillaum.bouchard@gmail.com> Signed-off-by:
-
Sam hung authored
commit 810aa091 upstream. This change allows the driver to recognize newer Elantech touchpads. Signed-off-by:
Yi ju Hong <sam.hung@emc.com.tw> Signed-off-by:
-
Ahmed S. Darwish authored
commit 5e7e6e0c upstream. Recent Leaf firmware versions (>= 3.1.557) do not allow to send commands for non-existing channels. If a command is sent for a non-existing channel, the firmware crashes. Reported-by:
Christopher Storah <Christopher.Storah@invetech.com.au> Signed-off-by:
Olivier Sobrie <olivier@sobrie.be> Signed-off-by:
Ahmed S. Darwish <ahmed.darwish@valeo.com> Signed-off-by:
-
Ahmed S. Darwish authored
commit 889b77f7 upstream. Flooding the Kvaser CAN to USB dongle with multiple reads and writes in very high frequency (*), closing the CAN channel while all the transmissions are on (#), opening the device again (@), then sending a small number of packets would make the driver enter an almost infinite loop of: [....] [15959.853988] kvaser_usb 4-3:1.0 can0: cannot find free context [15959.853990] kvaser_usb 4-3:1.0 can0: cannot find free context [15959.853991] kvaser_usb 4-3:1.0 can0: cannot find free context [15959.853993] kvaser_usb 4-3:1.0 can0: cannot find free context [15959.853994] kvaser_usb 4-3:1.0 can0: cannot find free context [15959.853995] kvaser_usb 4-3:1.0 can0: cannot find free context [....] _dragging the whole system down_ in the process due to the excessive logging output. Initially, this has caused random panics in the kernel due to a buggy error recovery path. That got fixed in an earlier commit.(%) This patch aims at solving the root cause. --> 16 tx URBs and contexts are allocated per CAN channel per USB device. Such URBs are protected by: a) A simple atomic counter, up to a value of MAX_TX_URBS (16) b) A flag in each URB context, stating if it's free c) The fact that ndo_start_xmit calls are themselves protected by the networking layers higher above After grabbing one of the tx URBs, if the driver noticed that all of them are now taken, it stops the netif transmission queue. Such queue is worken up again only if an acknowedgment was received from the firmware on one of our earlier-sent frames. Meanwhile, upon channel close (#), the driver sends a CMD_STOP_CHIP to the firmware, effectively closing all further communication. In the high traffic case, the atomic counter remains at MAX_TX_URBS, and all the URB contexts remain marked as active. While opening the channel again (@), it cannot send any further frames since no more free tx URB contexts are available. Reset all tx URB contexts upon CAN channel close. (*) 50 parallel instances of `cangen0 -g 0 -ix` (#) `ifconfig can0 down` (@) `ifconfig can0 up` (%) "can: kvaser_usb: Don't free packets when tight on URBs" Signed-off-by:
-
Ahmed S. Darwish authored
commit b442723f upstream. Flooding the Kvaser CAN to USB dongle with multiple reads and writes in high frequency caused seemingly-random panics in the kernel. On further inspection, it seems the driver erroneously freed the to-be-transmitted packet upon getting tight on URBs and returning NETDEV_TX_BUSY, leading to invalid memory writes and double frees at a later point in time. Note: Finding no more URBs/transmit-contexts and returning NETDEV_TX_BUSY is a driver bug in and out of itself: it means that our start/stop queue flow control is broken. This patch only fixes the (buggy) error handling code; the root cause shall be fixed in a later commit. Acked-by:
-
Sebastian Andrzej Siewior authored
commit 68693b8e upstream. since the split of host+gadget mode in commit 74c2e936 ("usb: musb: factor out hcd initalization") we leak the usb_hcd struct. We call now musb_host_cleanup() which does basically usb_remove_hcd() and also sets the hcd variable to NULL. Doing so makes the finall call to musb_host_free() basically a nop and the usb_hcd remains around for ever without anowner. This patch drops that NULL assignment for that reason. Fixes: 74c2e936 ("usb: musb: factor out hcd initalization") Cc: Daniel Mack <zonque@gmail.com> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Alan Stern authored
commit 6d89252a upstream. Commit c3ee9b76 (EHCI: improved logic for isochronous scheduling) introduced the idea of using ehci->last_iso_frame as the origin (or base) for the circular calculations involved in modifying the isochronous schedule. However, the new code it added used ehci->last_iso_frame before the value was properly initialized. This patch rectifies the mistake by moving the initialization lines earlier in iso_stream_schedule(). This fixes Bugzilla #72891. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Fixes: c3ee9b76Reported-by:
Joe Bryant <tenminjoe@yahoo.com> Tested-by:
Martin Long <martin@longhome.co.uk> Signed-off-by:
-
