- 04 Dec, 2013 31 commits
-
-
Tony Lindgren authored
commit 0b2aa8be upstream. Commit c111feab (gpio: twl4030: Cache the direction and output states in private data) improved things in general, but caused a regression for setting the GPIO output direction. The change reorganized twl_direction_out() and twl_set() and swapped the function names around in the process. While doing that, a bug got introduced that's not obvious while reading the patch as it appears as no change to the code. The bug is we now call function twl4030_set_gpio_dataout() twice in both twl_direction_out() and twl_set(). Instead, we should first call twl_direction_out() in twl_direction_out() followed by twl4030_set_gpio_dataout() in twl_set(). This regression probably has gone unnoticed for a long time as the bootloader may have set the GPIO direction properly in many cases. This fixes at least the LCD panel not turning on omap3 LDP for example. Cc: linux-gpio@vger.kernel.org Reviewed-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Stephen Warren authored
commit a31ab44e upstream. The I2C controller node needs #address-cells and #size-cells properties, but these are currently missing. Add them. This allows child nodes to be parsed correctly. Signed-off-by:
Stephen Warren <swarren@wwwdotorg.org> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Doug Anderson authored
commit c61248af upstream. Without the interrupt you'll get problems if you enable CONFIG_RTC_DRV_MAX77686. Setup the interrupt properly in the device tree. Signed-off-by:
Doug Anderson <dianders@chromium.org> Tested-by:
Marc Zyngier <marc.zyngier@arm.com> Signed-off-by:
-
Ionut Nicu authored
commit 250ad590 upstream. Some gpio chips may have get/set operations that can sleep. gpio_set_value() only works for chips which do not sleep, for the others we will get a kernel warning. Using gpio_set_value_cansleep() will work for both chips that do sleep and those who don't. Signed-off-by:
Ionut Nicu <ioan.nicu.ext@nsn.com> Acked-by:
Peter Korsgaard <peter.korsgaard@barco.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Ionut Nicu authored
commit 8c0ec250 upstream. The i2c-mux driver requires that the chan_id parameter passed to the i2c_add_mux_adapter() function is equal to the reg value for that adapter: for_each_child_of_node(mux_dev->of_node, child) { ret = of_property_read_u32(child, "reg", ®); if (ret) continue; if (chan_id == reg) { priv->adap.dev.of_node = child; break; } } The i2c-mux-gpio driver uses an internal logical index for chan_id when calling i2c_add_mux_adapter() instead of using the reg value. Because of this, there will problems in selecting the right adapter when the i2c-mux-gpio's index into mux->data.values doesn't match the reg value. An example of such a case: mux->data.values = { 1, 0 } For chan_id = 0, i2c-mux will bind the adapter to the of_node with reg = <0>, but when it will call the select() callback with chan_id set to 0, the i2c-mux-gpio will use it as an index into mux->data.values and it will actually select the bus with reg = <1>. Signed-off-by:
Alexander Sverdlin <alexander.sverdlin@nsn.com> Signed-off-by:
-
Marc Kleine-Budde authored
commit 0d1862ea upstream. In the flexcan_chip_start() function first the flexcan core is going through the soft reset sequence, then the RX FIFO is enabled. With the hardware is put into FIFO mode, message buffers 1...7 are reserved by the FIFO engine. The remaining message buffers are in reset default values. This patch removes the bogus initialization of the message buffers, as it causes an imprecise external abort on imx6. Reported-by:
Lothar Waßmann <LW@KARO-electronics.de> Tested-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Helge Deller authored
commit 38c79373 upstream. Break SOCK_NONBLOCK out to its own asm-file as other arches do. This fixes build errors with auditd and probably other packages. Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Ilija Hadzic authored
commit 66da0e1f upstream. When devpts is unmounted, there may be a no-longer-used IDR tree hanging off the superblock we are about to kill. This needs to be cleaned up before destroying the SB. The leak is usually not a big deal because unmounting devpts is typically done when shutting down the whole machine. However, shutting down an LXC container instead of a physical machine exposes the problem (the garbage is detectable with kmemleak). Signed-off-by:
Ilija Hadzic <ihadzic@research.bell-labs.com> Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Roel Kluin authored
commit 6d0a4ed2 upstream. This fixes a typo which left twsi config3 option enabled. Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Acked-by:
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by:
-
KOSAKI Motohiro authored
commit 98d6f4dd upstream. Fedora Ruby maintainer reported latest Ruby doesn't work on Fedora Rawhide on ARM. (http://bugs.ruby-lang.org/issues/9008) Because of, commit 1c6b39ad (alarmtimers: Return -ENOTSUPP if no RTC device is present) intruduced to return ENOTSUPP when clock_get{time,res} can't find a RTC device. However this is incorrect. First, ENOTSUPP isn't exported to userland (ENOTSUP or EOPNOTSUP are the closest userland equivlents). Second, Posix and Linux man pages agree that clock_gettime and clock_getres should return EINVAL if clk_id argument is invalid. While the arugment that the clockid is valid, but just not supported on this hardware could be made, this is just a technicality that doesn't help userspace applicaitons, and only complicates error handling. Thus, this patch changes the code to use EINVAL. Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Frederic Weisbecker <fweisbec@gmail.com> Reported-by:
Vit Ondruch <v.ondruch@tiscali.cz> Signed-off-by:
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> [jstultz: Tweaks to commit message to include full rational] Signed-off-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
-
Michael Hudson-Doyle authored
commit 53805eca upstream. The 4fb71074 (perf ui/hist: Consolidate hpp helpers) cset introduced a cast of percent_color_snprintf to a function pointer type with varargs. Change percent_color_snprintf to be variadic and remove the cast. The symptom of this was all percentages being reported as 0.00% in perf report --stdio output on the armhf arch. Signed-off-by:
Michael Hudson-Doyle <michael.hudson@linaro.org> Acked-by:
Namhyung Kim <namhyung@kernel.org> Acked-by:
Will Deacon <will.deacon@arm.com> Cc: Jean Pihet <jean.pihet@linaro.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Will Deacon <will.deacon@arm.com> Link: http://lkml.kernel.org/r/87zjppvw7y.fsf@canonical.comSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Charles Keepax authored
commit f69f86b1 upstream. Certain registers require patching after the SYSCLK has been brought up add support for this into the CODEC driver. Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
-
Richard Fitzgerald authored
commit 3e68ce1b upstream. The FLL must be placed into free-run mode before disabling to allow it to entirely shut down. Signed-off-by:
Richard Fitzgerald <rf@opensource.wolfsonmicro.com> Signed-off-by:
-
Oskar Schirmer authored
commit fc7dc61d upstream. Unbalanced calls to snd_imx_pcm_trigger() may result in endless FIQ activity and thus provoke eternal sound. While on the first glance, the switch statement looks pretty symmetric, the SUSPEND/RESUME pair is not: the suspend case comes along snd_pcm_suspend_all(), which for fsl/imx-pcm-fiq is called only at snd_soc_suspend(), but the resume case originates straight from the SNDRV_PCM_IOCTL_RESUME. This way userland may provoke an unbalanced resume, which might cause the fiq_enable counter to increase and never return to zero again, so eventually imx_pcm_fiq is never disabled. Simply removing the fiq_enable will solve the problem, as long as one never goes play and capture game simultaneously, but beware trying both at once, the early TRIGGER_STOP will cut off the other activity prematurely. So now playing and capturing is scrutinized separately, instead of by counting. Signed-off-by:
Oskar Schirmer <oskar@scara.com> Signed-off-by:
-
Takashi Iwai authored
commit afed4dbe upstream. Fixes: 4b2ffc20 ('ASoC: Blackfin I2S: add 8-bit sample support') Reported-by: David Binderman Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Nicolin Chen authored
commit 50bfcf2d upstream. It's safer to turn on regcache_cache_only before disabling regulator since the driver will turn off the regcache_cache_only after enabling regulator. If we remain cache_only false, some command like 'amixer cset' would get failure if being run before wm8962_resume(). Signed-off-by:
Nicolin Chen <b42378@freescale.com> Signed-off-by:
-
Brian Austin authored
commit 3d800c6d upstream. The mask for CS42L52_MIC_CTL_TYPE_MASK was wrong keeping the mic config from being set correctly. Signed-off-by:
Brian Austin <brian.austin@cirrus.com> Signed-off-by:
-
Phil Edworthy authored
commit 7b5bfb82 upstream. If you record the sound during playback, the playback sound becomes silent. Modify so that the codec driver does not clear SG_SL1::DACL bit which is controlled under widget Signed-off-by:
Phil Edworthy <phil.edworthy@renesas.com> Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
-
Johan Hovold authored
commit 185d9144 upstream. The driver supports 16-bit brightness values, but the value returned from get_brightness was truncated to eight bits. Signed-off-by:
Johan Hovold <jhovold@gmail.com> Cc: Jingoo Han <jg1.han@samsung.com> Signed-off-by:
-
Johan Hovold authored
commit ad5066d4 upstream. Make sure to honour gpio polarity also at remove so that the backlight is actually disabled on boards with active-low enable pin. Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Signed-off-by:
-
Malcolm Priestley authored
commit 9df68292 upstream. This fixes resets on heavy TX data traffic. Vendor driver VT6656_Linux_src_v1.21.03_x86_11.04.zip http://www.viaembedded.com/servlet/downloadSvl?id=1890&download_file_id=14704 This is GPL-licensed code. original code BBbVT3184Init ... //2007-0725, RobertChang add, Enable Squelch detect reset option(SQ_RST_Opt), USB (register4, bit1) CONTROLnsRequestIn(pDevice, MESSAGE_TYPE_READ, (WORD)0x600+4, // USB's Reg4's bit1 MESSAGE_REQUEST_MEM, 1, (PBYTE) &byData); byData = byData|2 ; CONTROLnsRequestOut(pDevice, MESSAGE_TYPE_WRITE, (WORD)0x600+4, // USB's Reg4's bit1 MESSAGE_REQUEST_MEM, 1, (PBYTE) &byData); return TRUE;//ntStatus; .... A back port patch is needed for kernels less than 3.10. Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by:
-
Olav Haugan authored
commit 67296874 upstream. zsmalloc encodes a handle using the pfn and an object index. On hardware platforms with physical memory starting at 0x0 the pfn can be 0. This causes the encoded handle to be 0 and is incorrectly interpreted as an allocation failure. This issue affects all current and future SoCs with physical memory starting at 0x0. All MSM8974 SoCs which includes Google Nexus 5 devices are affected. To prevent this false error we ensure that the encoded handle will not be 0 when allocation succeeds. Signed-off-by:
Olav Haugan <ohaugan@codeaurora.org> Signed-off-by:
-
Greg Kroah-Hartman authored
commit 930ba4a3 upstream. There seems to be no active maintainer for the driver, and there is an unfixed security bug, so disable the driver for now. Hopefully someone steps up to be the maintainer, and works to get this out of staging, otherwise it will be deleted soon. Reported-by:
Nico Golde <nico@ngolde.de> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Omar Ramirez Luna <omar.ramirez@copitl.com> Cc: Omar Ramirez Luna <omar.ramirez@ti.com> Cc: Kanigeri, Hari <h-kanigeri2@ti.com> Cc: Ameya Palande <ameya.palande@nokia.com> Cc: Guzman Lugo, Fernando <fernando.lugo@ti.com> Cc: Hebbar, Shivananda <x0hebbar@ti.com> Cc: Ramos Falcon, Ernesto <ernesto@ti.com> Cc: Felipe Contreras <felipe.contreras@gmail.com> Cc: Anna, Suman <s-anna@ti.com> Cc: Gupta, Ramesh <grgupta@ti.com> Cc: Gomez Castellanos, Ivan <ivan.gomez@ti.com> Cc: Andy Shevchenko <ext-andriy.shevchenko@nokia.com> Cc: Armando Uribe De Leon <x0095078@ti.com> Cc: Deepak Chitriki <deepak.chitriki@ti.com> Cc: Menon, Nishanth <nm@ti.com> Cc: Phil Carmody <ext-phil.2.carmody@nokia.com> Cc: Ohad Ben-Cohen <ohad@wizery.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Jiada Wang authored
commit 9b3d4237 upstream. instead of pll3_usb_otg the parent of can_root clock should be pll3_60m. Signed-off-by:
Jiada Wang <jiada_wang@mentor.com> Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Cc: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Johan Hovold authored
commit 94c4c79f upstream. Make sure the RTT-interrupts are masked at boot by adding a new helper function to be used at SOC-init. This fixes hanged boot on all AT91 SOCs with an RTT, for example, if an RTT-alarm goes off after a non-clean shutdown (e.g. when using RTC wakeup). The RTC and RTT-peripherals are powered by backup power (VDDBU) (on all AT91 SOCs but RM9200) and are not reset on wake-up, user, watchdog or software reset. This means that their interrupts may be enabled during early boot if, for example, they where not disabled during a previous shutdown (e.g. due to a buggy driver or a non-clean shutdown such as a user reset). Furthermore, an RTC or RTT-alarm may also be active. The RTC and RTT-interrupts use the shared system-interrupt line, which is also used by the PIT, and if an interrupt occurs before a handler (e.g. RTC-driver) has been installed this leads to the system interrupt being disabled and prevents the system from booting. Note that when boot hangs due to an early RTC or RTT-interrupt, the only way to get the system to start again is to remove the backup power (e.g. battery) or to disable the interrupt manually from the bootloader. In particular, a user reset is not sufficient. Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Johan Hovold authored
commit 6de714c2 upstream. Make sure the RTC-interrupts are masked at boot by adding a new helper function to be used at SOC-init. This fixes hanged boot on all AT91 SOCs with an RTC (but RM9200), for example, after a reset during an RTC-update or if an RTC-alarm goes off after shutdown (e.g. when using RTC wakeup). The RTC and RTT-peripherals are powered by backup power (VDDBU) (on all AT91 SOCs but RM9200) and are not reset on wake-up, user, watchdog or software reset. This means that their interrupts may be enabled during early boot if, for example, they where not disabled during a previous shutdown (e.g. due to a buggy driver or a non-clean shutdown such as a user reset). Furthermore, an RTC or RTT-alarm may also be active. The RTC and RTT-interrupts use the shared system-interrupt line, which is also used by the PIT, and if an interrupt occurs before a handler (e.g. RTC-driver) has been installed this leads to the system interrupt being disabled and prevents the system from booting. Note that when boot hangs due to an early RTC or RTT-interrupt, the only way to get the system to start again is to remove the backup power (e.g. battery) or to disable the interrupt manually from the bootloader. In particular, a user reset is not sufficient. Signed-off-by:
-
Jonathan Austin authored
commit 30aeadd4 upstream. This turns on the internal integrator LCD display(s). It seems that the code to do this got lost in refactoring of the CLCD driver. Signed-off-by:
Jonathan Austin <jonathan.austin@arm.com> Acked-by:
-
Marc Zyngier authored
commit e16b31bf upstream. The exception handling code fails to clear the IT state, potentially leading to incorrect execution of the fixup if the size of the IT block is more than one. Let fixup_exception do the IT sanitizing if a fixup has been found, and restore CPSR from the stack when returning from a data abort. Cc: Will Deacon <will.deacon@arm.com> Reviewed-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Russell King authored
commit f3964fe1 upstream. The CS2 region contains the Assabet board configuration and status registers, which are 32-bit. Unfortunately, some boot loaders do not configure this region correctly, leaving it setup as a 16-bit region. Fix this. Signed-off-by:
-
Markus Pargmann authored
commit 0bebda68 upstream. am33xx has a INTC_PENDING_IRQ3 register that is not checked for pending interrupts. This patch adds AM33XX to the ifdef of SOCs that have to check this register. Signed-off-by:
Markus Pargmann <mpa@pengutronix.de> Signed-off-by:
-
Helge Deller authored
commit 0219132f upstream. STI text console (sticon) was broken on 64bit machines with more than 4GB RAM and this lead in some cases to a kernel crash. Since sticon uses the 32bit STI API it needs to keep pointers to memory below 4GB. But on a 64bit kernel some memory regions (e.g. the kernel stack) might be above 4GB which then may crash the kernel in the STI functions. Additionally sticon didn't selected the built-in framebuffer fonts by default. This is now fixed. On a side-note: Theoretically we could enhance the sticon driver to use the 64bit STI API. But - beside the fact that some machines don't provide a 64bit STI ROM - this would just add complexity. Signed-off-by:
-
- 29 Nov, 2013 9 commits
-
-
Greg Kroah-Hartman authored
-
Rob Pearce authored
commit 645378d8 upstream. The Intel D410PT(LW) and D425KT Mini-ITX desktop boards both show up as having LVDS but the hardware is not populated. This patch adds them to the list of such systems. Patch is against 3.11.4 v2: Patch revised to match the D425KT exactly as the D425KTW does have LVDS. According to Intel's documentation, the D410PTL and D410PLTW don't. Signed-off-by:
Rob Pearce <rob@flitspace.org.uk> [danvet: Pimp commit message to my liking and add cc: stable.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Chris Wilson authored
commit e5614f0c upstream. This replaceable mainboard only has a VGA-out, yet it claims to also have a connected LVDS header. Addresses https://bugs.freedesktop.org/show_bug.cgi?id=63860 [jani.nikula@intel.com: use DMI_EXACT_MATCH for board name.] Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reported-by: <annndddrr@gmail.com> Cc: Cornel Panceac <cpanceac@gmail.com> Acked-by:
-
Jani Nikula authored
commit 5017b285 upstream. dmi_match() considers a substring match to be a successful match. This is not always sufficient to distinguish between DMI data for different systems. Add support for exact string matching using strcmp() in addition to the substring matching using strstr(). The specific use case in the i915 driver is to allow us to use an exact match for D510MO, without also incorrectly matching D510MOV: { .ident = "Intel D510MO", .matches = { DMI_MATCH(DMI_BOARD_VENDOR, "Intel"), DMI_EXACT_MATCH(DMI_BOARD_NAME, "D510MO"), }, } Signed-off-by:
-
Mauro Carvalho Chehab authored
commit 72a0c557 upstream. On cris arch, the functions below aren't defined: drivers/media/platform/sh_veu.c: In function 'sh_veu_reg_read': drivers/media/platform/sh_veu.c:228:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] drivers/media/platform/sh_veu.c: In function 'sh_veu_reg_write': drivers/media/platform/sh_veu.c:234:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration] drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_read': drivers/media/platform/vsp1/vsp1.h:66:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_write': drivers/media/platform/vsp1/vsp1.h:71:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration] drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_read': drivers/media/platform/vsp1/vsp1.h:66:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] drivers/media/platform/vsp1/vsp1.h: In function 'vsp1_write': drivers/media/platform/vsp1/vsp1.h:71:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration] drivers/media/platform/soc_camera/rcar_vin.c: In function 'rcar_vin_setup': drivers/media/platform/soc_camera/rcar_vin.c:284:3: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration] drivers/media/platform/soc_camera/rcar_vin.c: In function 'rcar_vin_request_capture_stop': drivers/media/platform/soc_camera/rcar_vin.c:353:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] Yet, they're available, as CONFIG_GENERIC_IOMAP is defined. What happens is that asm/io.h was not including asm-generic/iomap.h. Suggested-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Mauro Carvalho Chehab <m.chehab@samsung.com> Cc: Mikael Starvik <starvik@axis.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-by:
-
Junxiao Bi authored
commit 76ae281f upstream. A race window in configfs, it starts from one dentry is UNHASHED and end before configfs_d_iput is called. In this window, if a lookup happen, since the original dentry was UNHASHED, so a new dentry will be allocated, and then in configfs_attach_attr(), sd->s_dentry will be updated to the new dentry. Then in configfs_d_iput(), BUG_ON(sd->s_dentry != dentry) will be triggered and system panic. sys_open: sys_close: ... fput dput dentry_kill __d_drop <--- dentry unhashed here, but sd->dentry still point to this dentry. lookup_real configfs_lookup configfs_attach_attr---> update sd->s_dentry to new allocated dentry here. d_kill configfs_d_iput <--- BUG_ON(sd->s_dentry != dentry) triggered here. To fix it, change configfs_d_iput to not update sd->s_dentry if sd->s_count > 2, that means there are another dentry is using the sd beside the one that is going to be put. Use configfs_dirent_lock in configfs_attach_attr to sync with configfs_d_iput. With the following steps, you can reproduce the bug. 1. enable ocfs2, this will mount configfs at /sys/kernel/config and fill configure in it. 2. run the following script. while [ 1 ]; do cat /sys/kernel/config/cluster/$your_cluster_name/idle_timeout_ms > /dev/null; done & while [ 1 ]; do cat /sys/kernel/config/cluster/$your_cluster_name/idle_timeout_ms > /dev/null; done & Signed-off-by:
Junxiao Bi <junxiao.bi@oracle.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Martin Schwidefsky authored
commit 4560e7c3 upstream. Use the ACCESS_ONCE macro for both accesses to idle->sequence in the loops to calculate the idle time. If only one access uses the macro, the compiler is free to cache the value for the second access which can cause endless loops. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Stanislaw Gruszka authored
commit 36165fd5 upstream. Polling TX statuses too frequently has two negative effects. First is randomly peek CPU usage, causing overall system functioning delays. Second bad effect is that device is not able to fill TX statuses in H/W register on some workloads and we get lot of timeouts like below: ieee80211 phy4: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2 ieee80211 phy4: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2 ieee80211 phy4: rt2800usb_txdone: Warning - Got TX status for an empty queue 2, dropping This not only cause flood of messages in dmesg, but also bad throughput, since rate scaling algorithm can not work optimally. In the future, we should probably make polling interval be adjusted automatically, but for now just increase values, this make mentioned problems gone. Resolve: https://bugzilla.kernel.org/show_bug.cgi?id=62781Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Julius Werner authored
commit e92aee33 upstream. This patch adds the Port Reset Change flag to the set of bits that are preemptively cleared on init/resume of a hub. In theory this bit should never be set unexpectedly... in practice it can still happen if BIOS, SMM or ACPI code plays around with USB devices without cleaning up correctly. This is especially dangerous for XHCI root hubs, which don't generate any more Port Status Change Events until all change bits are cleared, so this is a good precaution to have (similar to how it's already done for the Warm Port Reset Change flag). Signed-off-by:
Julius Werner <jwerner@chromium.org> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
