1) Anyone who has read access to loopdev has permission to call set_status
and may change important parameters such as lo_offset, lo_sizelimit and
so on, which contradicts to read access pattern and definitely equals
to write access pattern.
2) Add lo_offset over i_size check to prevent blkdev_size overflow.
##Testcase_bagin
#dd if=/dev/zero of=./file bs=1k count=1
#losetup /dev/loop0 ./file
/* userspace_application */
struct loop_info64 loinf;
fd = open("/dev/loop0", O_RDONLY);
ioctl(fd, LOOP_GET_STATUS64, &loinf);
/* Set offset to any value which is bigger than i_size, and sizelimit
* to nonzero value*/
loinf.lo_offset = 4096*1024;
loinf.lo_sizelimit = 1024;
ioctl(fd, LOOP_SET_STATUS64, &loinf);
/* After this loop device will have size similar to 0x7fffffffffxxxx */
#blockdev --getsz /dev/loop0
##OUTPUT: 36028797018955968
##Testcase_end
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
If read was not fully successful we have to fail whole bio to prevent
information leak of old pages
##Testcase_begin
dd if=/dev/zero of=./file bs=1M count=1
losetup /dev/loop0 ./file -o 4096
truncate -s 0 ./file
# OOps loop offset is now beyond i_size, so read will silently fail.
# So bio's pages would not be cleared, may which result in information leak.
hexdump -C /dev/loop0
##testcase_end
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
MIPS: lantiq: use export.h in favour of module.h
MAINTAINERS: The MIPS git tree has moved.
MIPS: Fix build error due to missing inclusion of <linux/export.h>.
MIPS: ASID conflict after CPU hotplug
MIPS: Octeon: Fix compile error in arch/mips/cavium-octeon/flash_setup.c
MIPS: errloongson2_clock: Fix build error by including linux/module.h
STAGING: octeon-ethernet: Fix compile error caused by skb_frag_struct change
MIPS: Hook up process_vm_readv and process_vm_writev system calls.
MIPS: Kernel hangs occasionally during boot.
MIPS: Octeon: Mark SMP-IPI interrupt as IRQF_NO_THREAD
MIPS: BCM47xx: fix build with GENERIC_GPIO configuration
MIPS: NXP: Remove unused source files.
MIPS: Yosemite, Emma: Fix off-by-two in arcs_cmdline buffer size check
The current implementation of dmi_name_in_vendors() is an invitation to
lazy coding and false positives [1]. Searching for a string in 8 know
what you're looking for, so you should know where to look. strstr isn't
fast, especially when it fails, so we should avoid calling it when it
just can't succeed.
Looking at the current users of the function, it seems clear to me that
they are looking for a system or board vendor name, so let's limit
dmi_name_in_vendors to these two DMI fields. This much better matches
the function name, BTW.
[1] We currently have code looking for short names in DMI data, such as
"IBM", "ASUS" or "Acer". I let you guess what will happen the day other
vendors ship products named, for example, "SCHREIBMEISTER", "PEGASUS" or
"Acerola".
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The driver for the DigsyMTC display configuration EEPROMs device got
added by commit 469dded183 ("misc/eeprom: add eeprom access driver for
digsy_mtc board"). Its Kconfig symbol depends on PPC_MPC5200_GPIO. But
at the time that driver got added PPC_MPC5200_GPIO was already renamed
to GPIO_MPC5200, by commit 6eae1ace68 ("gpio: Move mpc5200 gpio driver
to drivers/gpio").
So make this driver depend on GPIO_MPC5200. And since GPIO_MPC5200
itself implies that GPIOLIB is set, that dependency can be dropped.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Acked-by: Anatolij Gustschin <agust@denx.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Revert commit 6123b0e274.
The problem this patch intends to solve has alreadqy been fixed by
commit 7a5caabd09 ("drivers/leds/ledtrig-timer.c: fix broken sysfs
delay handling").
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Cc: Antonio Ospite <ospite@studenti.unina.it>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit 9636b755da.
It wasn't supposed to be applied, thanks to Doug for letting me know.
Cc: Doug Anderson <dianders@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Only update VERSION to reflect previous changes.
Signed-off-by: Grant Grundler <grundler@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Now works on Samsung Series 5 (chromebook)
Two fixes here:
o use 0x7F mask for phymode
o read phyid *AFTER* phy is powered up (via GPIOs)
Signed-off-by: Allan Chou <allan@asix.com.tw>
Signed-off-by: Grant Grundler <grundler@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
ax88772_reset takes about 2 seconds and is called twice.
Once from ax88772_bind() directly and again indirectly from usbnet_open().
Reset the USB FW/Phy enough to blink the LEDs when inserted.
Signed-off-by: Allan Chou <allan@asix.com.tw>
Signed-off-by: Grant Grundler <grundler@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Sometimes the phy isn't ready after reset...poll and pray it will be soon.
Signed-off-by: Freddy Xin <freddy@asix.com.tw>
Signed-off-by: Grant Grundler <grundler@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Use correct value for rtl phy support.
(rtl phy are in AX88178 devices like NWU220G and USB2-ET1000).
Signed-off-by: Allan Chou <allan@asix.com.tw>
Tested-by: Grant Grundler <grundler@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
There may be an issue when the user issue "reboot/shutdown" command, then
the device has shut down its hardware, after that, this runtime-pm featured
device's driver will probably be scheduled to do its suspend routine,
and at its suspend routine, it may access hardware, but the device has
already shutdown physically, then the system hang may be occurred.
I ran out this issue using an auto-suspend supported USB devices, like
3G modem, keyboard. The usb runtime suspend routine may be scheduled
after the usb controller has been shut down, and the usb runtime suspend
routine will try to suspend its roothub(controller), it will access
register, then the system hang occurs as the controller is shutdown.
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Acked-by: Ming Lei <tom.leiming@gmail.com>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Cc: stable@kernel.org
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
The crisv10.c and the atmel_serial.c serial drivers intepret the fields of the
serial_rs485 structure in a different way.
In particular, crisv10.c uses SER_RS485_RTS_AFTER_SEND and
SER_RS485_RTS_ON_SEND for the voltage of the RTS pin; atmel_serial.c,
instead, uses these values to know if a delay must be set before and
after sending. This patch makes the usage of these variables consistent
across all drivers and fixes the Documentation as well.
From now on, SER_RS485_RTS_AFTER_SEND and SER_RS485_RTS_ON_SEND will be
used to set the voltage of the RTS pin (as in the crisv10.c driver); the
delay will be understood by looking only at the value of
delay_rts_before_send and delay_rts_after_send.
Signed-off-by: Claudio Scordino <claudio@evidence.eu.com>
Signed-off-by: Darron Black <darron@griffin.net>
Acked-by: Jesper Nilsson <jesper.nilsson@axis.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Changing UART mode PIO->DMA->PIO->DMA like below, pch_uart driver can't get
DMA channel resource.
setserial /dev/ttyPCH0 ^low_latency
setserial /dev/ttyPCH0 low_latency
CAUSE:
Changing mode using setserial command, ".startup" function which gets DMA
channel is called before ".verify_port" function which sets
dma-flag(use_dma/use_dma_flag) as 1.
PIO->DMA
.startup: Since dma-flag is 0, DMA channel is not requested.
.verify_port: dma-flag is set as 1.
.shutdown: N/A
DMA->PIO
.startup: Since dma-flag is 1, DMA channel is requested.
.verify_port: dma-flag is set as 0.
.shutdown: Since dma-flag is 0, DMA channel is not released.
This means DMA channel resource leak occurs.
Next time, this driver can't get DMA channel resource forever.
MODIFICATION:
Currently, when release DMA channel resource, this driver checks dma-flag.
However, this specification occurs the above issue.
This driver must check whether dma_request_channel is executed or not.
The values are saved in private data variable "chan_tx/chan_tx".
These variables mean if the value is NULL, DMA channel is not requested,
if not NULL, DMA channel is requested.
This patch fixes the issue.
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This is referenced the wrong way. Mika Westerberg added some checks to the
tty to support multiple console, but the real problem is simply referencing the
termios object via the wrong path.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
On Tegra UARTs (except UART1), the DTR / DCD / DSR lines are not
externally accessible. Instead, the DTR line internally appears to be
looped back to be the input to the DCD and DSR lines. The net effect
of this is that when we drop DTR (like when we suspend), we'll see DCD
drop too. ...and when we see DCD drop, we treat that as a hangup.
In order to prevent this hangup from occurring at every sleep, we need
to force DTR to remain high on Tegra UARTs.
This patch uses the mcr_mask / mcr_force fields, which were originally
added for the kludge ALPHA_KLUDGE_MCR. Using these fields does not
prevent us from removing ALPHA_KLUDGE_MCR--we can just remove the "if"
tests I have added and always init mcr_mask / mcr_force from the
serial8250_config.
NOTE: If we have people that are using UARTA on a Tegra and need to
control DTR, we'll need to either add a separate port type for UARTA
or we'll need to add some tegra-specific code to detect whether the
DTR needs to be left high.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
On October 1 in 2011,
OKI SEMICONDUCTOR Co., Ltd. changed the company name in to LAPIS Semiconductor Co., Ltd.
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Using hardware flow control,
currently, register of the control-bit(AFE) is not set.
This patch fixes the issue.
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Reading from the DCC grabs a character from the buffer and
clears the status bit. Since this is a context-changing
operation, instructions following the character read that rely on
the status bit being accurate need to be synchronized with an
ISB.
In this case, the status bit check needs to execute after the
character read otherwise we run the risk of reading the character
and checking the status bit before the read can clear the status
bit in the first place. When this happens, the user will see the
same character they typed twice, instead of once.
Add an ISB after the read and the write, so that the status check
is synchronized with the read/write operations.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fixes i2c test failures when i2c_algo_bit.bit_test=1.
The hw doesn't actually require a mask, so just set it
to the default mask bits for r1xx-r4xx radeon ddc.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
ISSUE:
Using ML7831, MAC address writing doesn't work well.
CAUSE:
ML7831 and EG20T have the same register map for MAC address access.
However, this driver processes the writing the same as ML7223.
This is not true.
This driver must process the writing the same as EG20T.
This patch fixes the issue.
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Cc: Masayuki Ohtak <masa-korg@dsn.okisemi.com>
Cc: Alexander Stein <alexander.stein@systec-electronic.com>
Cc: Denis Turischev <denis@compulab.co.il>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Currently, external ROM access is enabled/disabled in probe()/remove().
So, when a buggy software access unanticipated memory area,
in case of enabling this ADE bit,
external ROM memory area can be broken.
This patch enables the ADE bit only accessing external ROM area.
Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com>
Cc: Masayuki Ohtak <masa-korg@dsn.okisemi.com>
Cc: Alexander Stein <alexander.stein@systec-electronic.com>
Cc: Denis Turischev <denis@compulab.co.il>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
On October 1 in 2011,
OKI SEMICONDUCTOR Co., Ltd. changed the company name in to LAPIS Semiconductor Co., Ltd.
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fix the following compile warning:
| drivers/usb/storage/ene_ub6250.c: In function ‘ms_scsi_write’:
| drivers/usb/storage/ene_ub6250.c:1728:6: warning: ‘result’ may \
| be used uninitialized in this function [-Wuninitialized]
| drivers/usb/storage/ene_ub6250.c:1795:77: warning: ‘offset’ may \
| be used uninitialized in this function [-Wuninitialized]
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add VendorID/ProductID for USB 3G dongle Model VT1000 of Viettel.
Signed-off-by: VU Tuan Duc <ducvt@viettel.com.vn>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
I get report from customer that his usb-serial
converter doesn't work well,it sometimes work,
but sometimes it doesn't.
The usb-serial converter's id:
vendor_id product_id
0x4348 0x5523
Then I search the usb-serial codes, and there are
two drivers announce support this device, pl2303
and ch341, commit 026dfaf1 cause it. Through many
times to test, ch341 works well with this device,
and pl2303 doesn't work quite often(it just work quite little).
ch341 works well with this device, so we doesn't
need pl2303 to support.I try to revert 026dfaf1 first,
but it failed. So I prepare this patch by hand to revert it.
Signed-off-by: Wang YanQing <Udknight@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
On October 1 in 2011,
OKI SEMICONDUCTOR Co., Ltd. changed the company name in to LAPIS Semiconductor Co., Ltd.
Signed-off-by: Tomoya MORINAGA <tomoya-linux@dsn.lapis-semi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* 'fixes' of git://git.linaro.org/people/triad/linux-pinctrl:
pinctrl: hide subsystem from the populace
pinctrl: fix "warning: 'struct pinctrl_dev' declared inside parameter list"
* 'gpio/merge' of git://git.secretlab.ca/git/linux-2.6:
gpio: pca953x: propagate the errno from the chip_init functions
gpio: pca953x: remove unneeded check for chip type
gpio/omap: check return value from irq_alloc_generic_chip
gpio/omap: replace MOD_REG_BIT macro with static inline
If we hit the default case in the switch in if_spi_host_to_card() we'll leak
the memory we allocated for 'packet'. This patch resolves the leak by freeing
the allocated memory in that case.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Dan Williams <dcbw@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The generic powersaving code that determines after reception of a frame
whether the device should go back to sleep or whether is could stay
awake was calling rt2x00lib_config directly from RX tasklet context.
On a number of the devices this call can actually sleep, due to having
to confirm that the sleeping commands have been executed successfully.
Fix this by moving the call to rt2x00lib_config to a workqueue call.
This fixes bug https://bugzilla.redhat.com/show_bug.cgi?id=731672
Tested-by: Tomas Trnka <tomastrnka@gmx.com>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Cc: <stable@vger.kernel.org>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is reported to be an RT3070 based device.
Reported-by: Teika Kazura <teika@lavabit.com>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Remove the driver (that was added in v2.6.32) since the architecture
has never been merged into mainline.
Reported-by: Paul Bolle <pebolle@tiscali.nl>
Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
In case that vblank_disable_allowed is 1, the problem that manager->pipe
could be -1 at vsync interrupt handler could be induced so this patch fixes
that.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
the purpose of this patch is to consider IOMMU support in the future.
EXYNOS4 SoC supports IOMMU also so the address for DMA could be
physical address with IOMMU or device address with IOMMU.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
this patch addes exynos_drm_gem_init() creating and initialzing a gem.
allocation functions could use this function to create new gem and
it changes size type of exynos_drm_gem_create structure to 64bit
and also corrects comments to exynos_drm_gem_create structure.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
crtc dpms is called as destroying attached fb so dpms off sould be processed.
crtc dpms also can be called after crtc is detached from encoder so pipe value
of manager is used to find display controller for this case
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
drm_framebuffer already has width and height so they are meaningless as
parameters when updating fb_info.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
during recreating exynos_drm_fbdev as a new display device probes,
fb_helper is reinitialized but kernel fb is not changed
so kernel_fb_list should be restored after fb_helper is reinitialized.
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
exynos_drm_display has function pointes so exynos_drm_display_ops is better
to describe.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
connector contains some contents for display controller so the connector also
should be able to access controller through manager.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
missing members are added into converting function between timing and display
mode and refresh rate of display mode is calculated by drm mode function.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
The 8020i protocol (also 8070i and QIC-157) uses 12-byte commands;
shorter commands must be padded. Simon Detheridge reports that his
3-TB USB disk drive claims to use the 8020i protocol (which is
normally meant for ATAPI devices like CD drives), and because of its
large size, the disk drive requires the use of 16-byte commands.
However the usb_stor_pad12_command() routine in usb-storage always
sets the command length to 12, making the drive impossible to use.
Since the SFF-8020i specification allows for 16-byte commands in
future extensions, we may as well accept them. This patch (as1490)
changes usb_stor_pad12_command() to leave commands larger than 12
bytes alone rather than truncating them.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Simon Detheridge <simon@widgit.com>
CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The following patch contains additional affected webcam models, on top of the
patches commited to linux-next 2394d67e44
and 5b253d88cc
Signed-off-by: sordna <sordna@gmail.com>
Cc: Oliver Neukum <oliver@neukum.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Since 43cc71eed1 (platform: prefix MODALIAS
with "platform:"), the platform modalias is prefixed with "platform:".
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Pratyush Anand <pratyush.anand@st.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Below are codes for accessing usb sysif_regs in driver:
usb_sys_regs = (struct usb_sys_interface *)
((u32)dr_regs + USB_DR_SYS_OFFSET);
these codes work in 32-bit, but in 64-bit, use u32 to type cast the address
of ioremap is not right, and accessing members of 'usb_sys_regs' will cause
call trace, so use (void *) for both 32-bit and 64-bit.
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
in commit aa6e52a35 we introduce the support of overcurrent notification
but the set and get of the power without checking if the gpio is valid or not
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Devfreq does not depend on OPP. The dependency is removed.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
In devfreq_remove_device, calling _remove_devfreq will also free devfreq.
Don't dereference devfreq->governor->no_central_polling after _remove_devfreq.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
There's a race between the USB disconnect handler and the TTY close
handler which may cause the acm object to be freed while it's still
being used. This may lead to things like
http://article.gmane.org/gmane.linux.usb.general/54250
and
https://lkml.org/lkml/2011/5/29/64
This is the simplest fix I could come up with. Holding on to open_mutex
while closing the TTY device prevents acm_disconnect() from freeing the
acm object between acm->port.count drops to 0 and the TTY side of the
cleanups are finalized.
Signed-off-by: Havard Skinnemoen <hskinnemoen@google.com>
Cc: Oliver Neukum <oliver@neukum.name>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We've had another report of the "chipmunk" sound on a Logitech C600 webcam.
This patch resolves the issue.
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The current TT scheduling doesn't allow to play and then record on a
full-speed device connected to a high speed hub.
The IN iso stream can only start on the first uframe (0-2 for a 165 us)
because of CSPLIT transactions.
For the OUT iso stream there no such restriction. uframe 0-5 are possible.
The idea of this patch is that the first uframe are precious (for IN TT iso
stream) and we should allocate the last uframes first if possible.
For that we reverse the order of uframe allocation (last uframe first).
Here an example :
hid interrupt stream
----------------------------------------------------------------------
uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
----------------------------------------------------------------------
max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 |
----------------------------------------------------------------------
used usecs on a frame | 13 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
----------------------------------------------------------------------
iso OUT stream
----------------------------------------------------------------------
uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
----------------------------------------------------------------------
max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 |
----------------------------------------------------------------------
used usecs on a frame | 13 | 125 | 39 | 0 | 0 | 0 | 0 | 0 |
----------------------------------------------------------------------
There no place for iso IN stream (uframe 0-2 are used) and we got "cannot
submit datapipe for urb 0, error -28: not enough bandwidth" error.
With the patch this become.
iso OUT stream
----------------------------------------------------------------------
uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
----------------------------------------------------------------------
max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 |
----------------------------------------------------------------------
used usecs on a frame | 13 | 0 | 0 | 0 | 125 | 39 | 0 | 0 |
----------------------------------------------------------------------
iso IN stream
----------------------------------------------------------------------
uframe | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
----------------------------------------------------------------------
max_tt_usecs | 125 | 125 | 125 | 125 | 125 | 125 | 30 | 0 |
----------------------------------------------------------------------
used usecs on a frame | 13 | 0 | 125 | 40 | 125 | 39 | 0 | 0 |
----------------------------------------------------------------------
Signed-off-by: Matthieu Castet <matthieu.castet@parrot.com>
Signed-off-by: Thomas Poussevin <thomas.poussevin@parrot.com>
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1494) fixes a problem in xhci-hcd's resume routine.
When the controller is runtime-resumed, this can only mean that one of
the two root hubs has made a wakeup request and therefore needs to be
resumed as well. Rather than try to determine which root hub requires
attention (which might be difficult in the case where a new
non-SuperSpeed device has been plugged in), the patch simply resumes
both root hubs.
Without this change, there is a race: The controller might be put back
to sleep before it can activate its IRQ line, and the wakeup condition
might never get handled.
The patch also simplifies the logic in xhci_resume a little, combining
some repeated flag settings into a single pair of statements.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Tested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1491) works around a bug in GCC-3.4.6, which is still
supposed to be supported. The number of microseconds in the udelay()
call in quirk_usb_disable_ehci() is fixed at 100, but the compiler
doesn't understand this and generates a link-time error. So we
replace the otherwise unused variable "delta" with a simple constant
100. This same pattern is already used in other delay loops in that
source file.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Konrad Rzepecki <krzepecki@dentonet.pl>
Tested-by: Konrad Rzepecki <krzepecki@dentonet.pl>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch for the usb serial ark3116 driver fixes an initialisation
ordering bug that gets triggered on hotplug when using at least recent
debian/ubuntu userspace. Without it, ark3116 serial cables don't work.
Signed-off-by: Bart Hartgers <bart.hartgers@gmail.com>
Tested-by: law_ence.dev@ntlworld.com
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit de47725 (include: replace linux/module.h
with "struct module" wherever possible) introduced
a compilation breaked when it removed <linux/module.h>
from <linux/device.h> which musb glue layers were
(mistakenly) relying on.
Include that header to fix the compile error.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Without this the gadget will never be able to allocate a stream capable
endpoint. The manual says that the stream id is a 16bit id. It does not
talk about an upper limit in any other way. So I think 15 is a
reasonable limit :)
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
new endpoint should start from DATA0,
but mod_host didn't care it.
This patch fix it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
renesas_usbhs is caring pipe type and its direction.
but current usbhs_endpoint_alloc() didn't check direction.
this patch modify it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Since commit "193ab2a usb: gadget: allow multiple gadgets to be built"
the udc controllers can be compiled as a module. The ci13xxx_msm driver
is missing the MODULE_LICENSE statement, so loading fails with:
ci13xxx_msm: module license 'unspecified' taints kernel.
ci13xxx_msm: Unknown symbol dev_set_name (err 0)
ci13xxx_msm: Unknown symbol platform_get_irq (err 0)
ci13xxx_msm: Unknown symbol device_unregister (err 0)
ci13xxx_msm: Unknown symbol usb_add_gadget_udc (err 0)
ci13xxx_msm: Unknown symbol put_device (err 0)
ci13xxx_msm: Unknown symbol platform_driver_register (err 0)
ci13xxx_msm: Unknown symbol platform_get_resource (err 0)
ci13xxx_msm: Unknown symbol device_register (err 0)
ci13xxx_msm: Unknown symbol usb_del_gadget_udc (err 0)
This patch adds the missing MODULE_LICENSE statement with GPL v2 according
to the header of the driver.
Tested-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes the following compile errors that show up if switching
on the debug trace code:
drivers/usb/gadget/ci13xxx_udc.c: In function 'ci13xxx_wakeup':
drivers/usb/gadget/ci13xxx_udc.c:2517:3: error: 'dev' undeclared (first use in this function)
drivers/usb/gadget/ci13xxx_udc.c:2517:3: note: each undeclared identifier is reported only once for each function it appears in
drivers/usb/gadget/ci13xxx_udc.c: In function 'udc_probe':
drivers/usb/gadget/ci13xxx_udc.c:2867:2: error: 'name' undeclared (first use in this function)
Tested-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The inline documentation of _gadget_stop_activity() states that the
function should be called holding the udc->lock. This however will
result in a deadlock, because _gadget_stop_activity() takes the udc->lock.
During normal operation _gadget_stop_activity() is always called unlocked,
but in ci13xxx_stop() it's called locked, this results in the following
deadlock during rmmod of a gadget driver.
This patch fixes the deadlock by calling _gadget_stop_activity() always
unlocked, the inline documentation is adjusted accordingly.
=============================================
[ INFO: possible recursive locking detected ]
3.1.0-rc6+ #159
---------------------------------------------
rmmod/121 is trying to acquire lock:
(udc_lock){-.-...}, at: [<c0229048>] _gadget_stop_activity+0x18/0x154
but task is already holding lock:
(udc_lock){-.-...}, at: [<c02291e0>] ci13xxx_stop+0x5c/0x164
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(udc_lock);
lock(udc_lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by rmmod/121:
#0: (udc_lock#2){+.+.+.}, at: [<c02286c0>] usb_gadget_unregister_driver+0x34/0x88
#1: (udc_lock){-.-...}, at: [<c02291e0>] ci13xxx_stop+0x5c/0x164
stack backtrace:
[<c000d41c>] (unwind_backtrace+0x0/0xf0) from [<c0056f94>] (check_deadlock.clone.24+0x284/0x2c4)
[<c0056f94>] (check_deadlock.clone.24+0x284/0x2c4) from [<c00589ac>] (validate_chain.clone.25+0x430/0x6fc)
[<c00589ac>] (validate_chain.clone.25+0x430/0x6fc) from [<c0059bac>] (__lock_acquire+0x494/0x8f0)
[<c0059bac>] (__lock_acquire+0x494/0x8f0) from [<c005a698>] (lock_acquire+0x98/0x1a8)
[<c005a698>] (lock_acquire+0x98/0x1a8) from [<c02f12a4>] (_raw_spin_lock_irqsave+0x64/0xa0)
[<c02f12a4>] (_raw_spin_lock_irqsave+0x64/0xa0) from [<c0229048>] (_gadget_stop_activity+0x18/0x154)
[<c0229048>] (_gadget_stop_activity+0x18/0x154) from [<c0229234>] (ci13xxx_stop+0xb0/0x164)
[<c0229234>] (ci13xxx_stop+0xb0/0x164) from [<c022867c>] (usb_gadget_remove_driver+0x88/0x98)
[<c022867c>] (usb_gadget_remove_driver+0x88/0x98) from [<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88)
[<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88) from [<c0065f2c>] (sys_delete_module+0x1fc/0x26c)
[<c0065f2c>] (sys_delete_module+0x1fc/0x26c) from [<c00092a0>] (ret_fast_syscall+0x0/0x38)
BUG: spinlock lockup on CPU#0, rmmod/121, c05b1644
[<c000d41c>] (unwind_backtrace+0x0/0xf0) from [<c01da000>] (do_raw_spin_lock+0x128/0x144)
[<c01da000>] (do_raw_spin_lock+0x128/0x144) from [<c02f12c8>] (_raw_spin_lock_irqsave+0x88/0xa0)
[<c02f12c8>] (_raw_spin_lock_irqsave+0x88/0xa0) from [<c0229048>] (_gadget_stop_activity+0x18/0x154)
[<c0229048>] (_gadget_stop_activity+0x18/0x154) from [<c0229234>] (ci13xxx_stop+0xb0/0x164)
[<c0229234>] (ci13xxx_stop+0xb0/0x164) from [<c022867c>] (usb_gadget_remove_driver+0x88/0x98)
[<c022867c>] (usb_gadget_remove_driver+0x88/0x98) from [<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88)
[<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88) from [<c0065f2c>] (sys_delete_module+0x1fc/0x26c)
[<c0065f2c>] (sys_delete_module+0x1fc/0x26c) from [<c00092a0>] (ret_fast_syscall+0x0/0x38)
Tested-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The current driver sets the request's dma addr (mReq->req.dma) to 0 to
mark the DMA address as not valid. However some gadget drivers
(e.g. gadgetfs) set the request's dma addr to DMA_ADDR_INVALID to mark
the address as invalid. This leads to bogus data send because the
ci13xxx_udc driver assumes the request has already been mapped.
This patch fixes the problem, by using DMA_ADDR_INVALID instead of 0
to mark the request's DMA address as invalid.
Tested-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Under certain circumstances lockdep finds an inconsistent lock state in
gadgetfs. The problem can be reproduced with a hardware using the
ci13xxx_udc driver and the gadgetfs test program (needs a patch to support
the ci13xxx_udc, though):
http://www.linux-usb.org/gadget/usb.c
Start the test program, wait to initialize, then press Ctrl+c.
This patch fixes the following problem by using spin_lock_irqsave()
instead of spin_lock().
=================================
[ INFO: inconsistent lock state ]
3.1.0-rc6+ #158
---------------------------------
inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
usb/113 [HC0[0]:SC0[0]:HE1:SE1] takes:
(&(&dev->lock)->rlock){?.....}, at: [<bf000340>] gadgetfs_disconnect+0x14/0x80 [gadgetfs]
{IN-HARDIRQ-W} state was registered at:
[<c00596b8>] mark_irqflags+0x14c/0x1ac
[<c0059bf8>] __lock_acquire+0x4e0/0x8f0
[<c005a698>] lock_acquire+0x98/0x1a8
[<c02f10e0>] _raw_spin_lock+0x54/0x8c
[<bf000340>] gadgetfs_disconnect+0x14/0x80 [gadgetfs]
[<c0229104>] _gadget_stop_activity+0xd4/0x154
[<c022b130>] isr_reset_handler+0x34/0x1c0
[<c022c320>] udc_irq+0x204/0x228
[<c0069018>] handle_irq_event_percpu+0x64/0x3a0
[<c0069390>] handle_irq_event+0x3c/0x5c
[<c006ae5c>] handle_level_irq+0x8c/0x10c
[<c0068a34>] generic_handle_irq+0x30/0x44
[<c0009b2c>] handle_IRQ+0x30/0x84
[<c0008ef8>] __irq_svc+0x38/0x60
[<c0009c58>] default_idle+0x30/0x34
[<c0009e30>] cpu_idle+0x9c/0xd8
[<c04056f4>] start_kernel+0x278/0x2bc
irq event stamp: 6412
hardirqs last enabled at (6412): [<c02f1cd0>] _raw_spin_unlock_irqrestore+0x30/0x5c
hardirqs last disabled at (6411): [<c02f1278>] _raw_spin_lock_irqsave+0x20/0xa0
softirqs last enabled at (6381): [<c002833c>] irq_exit+0xa0/0xa8
softirqs last disabled at (6372): [<c002833c>] irq_exit+0xa0/0xa8
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(&dev->lock)->rlock);
<Interrupt>
lock(&(&dev->lock)->rlock);
*** DEADLOCK ***
1 lock held by usb/113:
#0: (udc_lock#2){+.+.+.}, at: [<c02286c0>] usb_gadget_unregister_driver+0x34/0x88
stack backtrace:
[<c000d41c>] (unwind_backtrace+0x0/0xf0) from [<c0058e98>] (print_usage_bug+0x144/0x1c4)
[<c0058e98>] (print_usage_bug+0x144/0x1c4) from [<c0059144>] (mark_lock_irq+0x22c/0x274)
[<c0059144>] (mark_lock_irq+0x22c/0x274) from [<c00592d4>] (mark_lock+0x148/0x3e0)
[<c00592d4>] (mark_lock+0x148/0x3e0) from [<c0059668>] (mark_irqflags+0xfc/0x1ac)
[<c0059668>] (mark_irqflags+0xfc/0x1ac) from [<c0059bf8>] (__lock_acquire+0x4e0/0x8f0)
[<c0059bf8>] (__lock_acquire+0x4e0/0x8f0) from [<c005a698>] (lock_acquire+0x98/0x1a8)
[<c005a698>] (lock_acquire+0x98/0x1a8) from [<c02f10e0>] (_raw_spin_lock+0x54/0x8c)
[<c02f10e0>] (_raw_spin_lock+0x54/0x8c) from [<bf000340>] (gadgetfs_disconnect+0x14/0x80 [gadgetfs])
[<bf000340>] (gadgetfs_disconnect+0x14/0x80 [gadgetfs]) from [<c0229104>] (_gadget_stop_activity+0xd4/0x154)
[<c0229104>] (_gadget_stop_activity+0xd4/0x154) from [<c0229240>] (ci13xxx_stop+0xbc/0x17c)
[<c0229240>] (ci13xxx_stop+0xbc/0x17c) from [<c022867c>] (usb_gadget_remove_driver+0x88/0x98)
[<c022867c>] (usb_gadget_remove_driver+0x88/0x98) from [<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88)
[<c02286f4>] (usb_gadget_unregister_driver+0x68/0x88) from [<bf0003e8>] (dev_release+0x14/0x48 [gadgetfs])
[<bf0003e8>] (dev_release+0x14/0x48 [gadgetfs]) from [<c00cc158>] (__fput+0xa4/0x1f0)
[<c00cc158>] (__fput+0xa4/0x1f0) from [<c00c7f28>] (filp_close+0x5c/0x74)
[<c00c7f28>] (filp_close+0x5c/0x74) from [<c00c7fe8>] (sys_close+0xa8/0x150)
[<c00c7fe8>] (sys_close+0xa8/0x150) from [<c00092a0>] (ret_fast_syscall+0x0/0x38)
Tested-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The dynamic jack allocation of the MIDI gadget currently links all
external jacks to one single instance of an embedded jack. According to
the spec, this is only valid if these streams always carry the same data
stream, as described in the USB MIDI 1.0 spec, chapter 3.3.1.
Also, genius Windows 7(tm) terminates it's life cycle instantly with a
blue screen of death once a device with more than one input and output
port with the current implementation is connected.
While at it, and because it grew again by this change, allocate the
temporary function pointer list on the heap, not on the stack.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The USB-IF CV compliance tester is getting stricter, and it would
be valid for it to fail a mass-storage device that accepts an
invalid USB_BULK_RESET_REQUEST request. Although it doesn't do
that yet, let's be proactive and fix that now.
Suggested by Alan Stern.
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The latest USB-IF CV tester checks for a valid length for this
request.
Signed-off-by: Paul Zimmerman <paulz@synopsys.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fix up the following section mismatch warnings:
WARNING: drivers/usb/renesas_usbhs/renesas_usbhs.o(.text+0xf5d): Section
mismatch in reference from the function usbhs_mod_probe() to the function
.devinit.text:usbhs_mod_host_probe() The function usbhs_mod_probe() references
the function __devinit usbhs_mod_host_probe(). This is often because
usbhs_mod_probe lacks a __devinit annotation or the annotation of
usbhs_mod_host_probe is wrong.
WARNING: drivers/usb/renesas_usbhs/renesas_usbhs.o(.text+0xfd7): Section
mismatch in reference from the function usbhs_mod_probe() to the function
.devexit.text:usbhs_mod_host_remove() The function usbhs_mod_probe() references
a function in an exit section. Often the function usbhs_mod_host_remove() has
valid usage outside the exit section and the fix is to remove the __devexit
annotation of usbhs_mod_host_remove.
WARNING: drivers/usb/renesas_usbhs/renesas_usbhs.o(.text+0x1005): Section
mismatch in reference from the function usbhs_mod_remove() to the function
.devexit.text:usbhs_mod_host_remove() The function usbhs_mod_remove()
references a function in an exit section. Often the function
usbhs_mod_host_remove() has valid usage outside the exit section and the fix is
to remove the __devexit annotation of usbhs_mod_host_remove.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Since renesas_usbhs mod_host didn't use
struct completion as static object, the warning of lockdep came out.
This patch fixup this issue.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Fix compile error in file drivers/usb/gadget/fsl_udc_core.c.
drivers/usb/gadget/fsl_udc_core.c: In function 'portscx_device_speed':
drivers/usb/gadget/fsl_udc_core.c:1720: error: 'speed' undeclared (first
use in this function)
Introduced in commit e538dfdae8
(usb: Provide usb_speed_string() function)
Signed-off-by: Alexander Aring <a.aring@phytec.de>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The "BCLR" in CFIFOCTR/DnFIFOCTR can flush the fifo of "CPU side" only.
To flush the fifo of "SIE side", we have to use the "ACLRM" in PIPEnCTR.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The udc-newstyle needs device_register in probe() of platform_device.
If it doesn't call, kernel panic happens in the sysfs_create_dir() when
we run modprobe a gadget driver.
[ balbi@ti.com : fix compile warning introduced by this patch ]
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Those are simply giving information about the current
state of the UDC, nothing really fancy. We can let
everybody read those.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
usb_gadget_disconnect() is responsible of removing
data pullups. Before doing that we must, first, tell
gadget driver we're disconnecting (by calling disconnect
method on gadget driver structure), unbind the gadget
driver and stop the controller.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
that has already being done by udc-core.c. It's
unnecessary and might cause issues with some gadget
drivers.
Tested: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
We should not be using dev_get_drvdata() because we
never call dev_set_drvdata(). Let's use container_of()
as all other sysfs attributes.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The Lantiq ETOP ethernet driver fails to build in 3.2-rc1 due to 2 missing
header files.
Signed-off-by: John Crispin <blogic@openwrt.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
* 'for-usb-linus' of ra.kernel.org:/pub/scm/linux/kernel/git/sarah/xhci:
usb, xhci: Clear warm reset change event during init
xhci: Set slot and ep0 flags for address command.
usb, xhci: fix lockdep warning on endpoint timeout
When HW doesn't remove FCS bytes they are reported in the completion
byte count, we don't need to take them to skb.
Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
Previously we claimed device ID 0x7450, regardless of the vendor, which is
clearly wrong. Now we'll claim that device ID only for AMD.
I suspect this was just a typo in the original code, but it's possible this
change will break shpchp on non-7450 AMD bridges. If so, we'll have to fix
them as we find them.
Reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638863
Reported-by: Ralf Jung <ralfjung-e@gmx.de>
Cc: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
The Windows driver .inf disables ASPM on hpsa devices. Do the same because the
selection of a non default ASPM policy can cause the device to hang.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: stable@kernel.org
Acked-by: Mike Miller <mike.miller@hp.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
When the kernel is started in kdump mode, zfcpdump should not be
initialized because both dump methods can't be used at the same time.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Setup timer for processing messages in request queue, if sending an AP
message returns with reason code AP_RESPONSE_RESET_IN_PROGRESS.
Signed-off-by: Holger Dengler <hd@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
I assumed all PCI buses had a bridge, but playing with qemu recently, I
discovered vgaarb bug where it wasn't detecting both devices shared a bridge
at the root level.
Don't check for NULL, if two buses have a NULL bridge, assume they share the
root bus.
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
commit 27641c3f (drm/vblank: Add support for precise vblank
timestamping) adds preempt_disable()/enable() around a spin locked
section with the comments:
* Disable preemption, so vblank_time_lock is held as short as
* possible, even under a kernel with PREEMPT_RT patches.
/* Disable preemption while holding vblank_time_lock. Do
* it explicitely to guard against PREEMPT_RT kernel.
Just that this has never been tested on a RT kernel which would have
granted that nonsense with a might_sleep() warning because
dev->vblank_time_lock is converted to a "sleeping" spinlock on RT.
So this is activly wrong on RT and superflous on mainline. Remove it.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add checking for valid magic values (needed for stability in the event
corrupted packets are received) and remove some other unneeded checks.
Also, fix flagging device as WWAN (Bugzilla bug #39952).
Signed-off-by: Mark Kamichoff <prox@prolixium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Wait for the chip to be ready before any access to it. On the
Snowball platform we need to enable an external regulator before
the chip comes online, and then it happens that the device is
not yet ready at probe time, so let's wait for it.
Signed-off-by: Robert Marklund <robert.marklund@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This change makes sure that tx_packets/rx_bytes ifconfig counters are
updated even on NICs that don't provide hardware support for these
stats: they are now updated in software. For the sake of consistency,
we also now have tx_bytes updated in software (hardware counters
include ethernet CRC, and software doesn't account for it).
This reverts parts of:
- "forcedeth: statistics optimization" (21828163b2)
- "forcedeth: Improve stats counters" (0bdfea8ba8)
- "forcedeth: remove unneeded stats updates" (4687f3f364)
Tested:
pktgen + loopback (http://patchwork.ozlabs.org/patch/124698/)
reports identical tx_packets/rx_packets and tx_bytes/rx_bytes.
Signed-off-by: David Decotigny <david.decotigny@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 31a3ddda16 introduced
a use after free in virtio-pci. The main issue is
that the release method signals removal of the virtio device,
while remove signals removal of the pci device.
For example, on driver removal or hot-unplug,
virtio_pci_release_dev is called before virtio_pci_remove.
We then might get a crash as virtio_pci_remove tries to use the
device freed by virtio_pci_release_dev.
We allocate/free all resources together with the
pci device, so we can leave the release method empty.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: stable@kernel.org
After commit e978aa7d7d ("cpuidle: Move dev->last_residency update to
driver enter routine; remove dev->last_state") setting acpi_idle_suspend
to 1 by acpi_processor_suspend() causes the ACPI cpuidle routines to
return error codes continuously, which in turn causes cpuidle to lock up
(hard).
However, acpi_idle_suspend doesn't appear to be useful for any
particular purpose (it's racy and doesn't really provide any real
protection), so it can be removed, which makes the problem go away.
Reported-and-tested-by: Tomas M. <tmezzadra@gmail.com>
Reported-and-tested-by: Ferenc Wagner <wferi@niif.hu>
Tested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I missed the combios path when I updated the atombios pm code.
Reported by amarsh04 on IRC.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The variable i is removed by commit ded8433
"[CPUFREQ] db8500: remove unneeded for loop iteration over freq_table",
but current code to print available frequencies still uses the i variable.
Thus add the i variable back to fix below buld error:
CC drivers/cpufreq/db8500-cpufreq.o
drivers/cpufreq/db8500-cpufreq.c: In function 'db8500_cpufreq_init':
drivers/cpufreq/db8500-cpufreq.c:123: error: 'i' undeclared (first use in this function)
drivers/cpufreq/db8500-cpufreq.c:123: error: (Each undeclared identifier is reported only once
drivers/cpufreq/db8500-cpufreq.c:123: error: for each function it appears in.)
make[2]: *** [drivers/cpufreq/db8500-cpufreq.o] Error 1
make[1]: *** [drivers/cpufreq] Error 2
make: *** [drivers] Error 2
This patch also fixes using uninitialized i variable as array index.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Dave Jones <davej@redhat.com>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k: (29 commits)
m68k/mac: Remove mac_irq_{en,dis}able() wrappers
m68k/irq: Remove obsolete support for user vector interrupt fixups
m68k/irq: Remove obsolete m68k irq framework
m68k/q40: Convert Q40/Q60 to genirq
m68k/sun3: Convert Sun3/3x to genirq
m68k/sun3: Use the kstat_irqs_cpu() wrapper
m68k/apollo: Convert Apollo to genirq
m68k/vme: Convert VME to genirq
m68k/hp300: Convert HP9000/300 and HP9000/400 to genirq
m68k/mac: Optimize interrupts using chain handlers
m68k/mac: Convert Mac to genirq
m68k/amiga: Optimize interrupts using chain handlers
m68k/amiga: Convert Amiga to genirq
m68k/amiga: Refactor amiints.c
m68k/atari: Remove code and comments about different irq types
m68k/atari: Convert Atari to genirq
m68k/irq: Add genirq support
m68k/irq: Remove obsolete IRQ_FLG_* users
m68k/irq: Rename {,__}m68k_handle_int()
m68k/irq: Add m68k_setup_irq_controller()
...
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
[media] v4l2-ctrl: Send change events to all fh for auto cluster slave controls
[media] v4l2-event: Don't set sev->fh to NULL on unsubscribe
[media] v4l2-event: Remove pending events from fh event queue when unsubscribing
[media] v4l2-event: Deny subscribing with a type of V4L2_EVENT_ALL
[media] MAINTAINERS: add a maintainer for s5p-mfc driver
[media] v4l: s5p-mfc: fix reported capabilities
[media] media: vb2: reset queued list on REQBUFS(0) call
[media] media: vb2: set buffer length correctly for all buffer types
[media] media: vb2: add a check for uninitialized buffer
[media] mxl111sf: fix build warning
[media] mxl111sf: remove pointless if condition in mxl111sf_config_spi
[media] mxl111sf: check for errors after mxl111sf_write_reg in mxl111sf_idac_config
[media] mxl111sf: fix return value of mxl111sf_idac_config
[media] uvcvideo: GET_RES should only be checked for BITMAP type menu controls
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
powerpc/kvm: Fix build failure with HV KVM and CBE
powerpc/ps3: Fix lv1_gpu_attribute hcall
powerpc/ps3: Fix PS3 repository build warnings
powerpc/ps3: irq: Remove IRQF_DISABLED
powerpc/irq: Remove IRQF_DISABLED
powerpc/numa: NUMA topology support for PowerNV
powerpc: Add System RAM to /proc/iomem
powerpc: Add KVM as module to defconfigs
powerpc/kvm: Fix build with older toolchains
powerpc, tqm5200: update tqm5200_defconfig to fit for charon board.
powerpc/5200: add support for charon board
Real world year equals the value in vrtc YEAR register plus an offset.
We used 1960 as the offset to make leap year consistent, but for a
device's first use, its YEAR register is 0 and the system year will
be parsed as 1960 which is not a valid UNIX time and will cause many
applications to fail mysteriously. So we use 1972 instead to fix this
issue.
Updated patch which adds a sanity check suggested by Mathias
This isn't a change in behaviour for systems, because 1972 is the one we
actually use. It's the old version in upstream which is out of sync with
all devices.
Signed-off-by: Feng Tang <feng.tang@intel.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (42 commits)
drm/radeon/kms/pm: switch to dynamically allocating clock mode array
drm/radeon/kms: optimize r600_pm_profile_init
drm/radeon/kms/pm: add a proper pm profile init function for fusion
drm/radeon/kms: remove extraneous calls to radeon_pm_compute_clocks()
drm/exynos: added padding to be 64-bit align.
drm: fix kconfig unmet dependency warning
drm: add some comments to drm_wait_vblank and drm_queue_vblank_event
drm/radeon/benchmark: signedness bug in radeon_benchmark_move()
drm: do not sleep on vblank while holding a mutex
MAINTAINERS: exynos: Add EXYNOS DRM maintainer entry
drm: try to restore previous CRTC config if mode set fails
drm/radeon/kms: make an aux failure debug only
drm: drop select of SLOW_WORK
drm: serialize access to list of debugfs files
drm/radeon/kms: fix use of vram scratch page on evergreen/ni
drm/radeon: Make sure CS mutex is held across GPU reset.
drm: Ensure string is null terminated.
vmwgfx: Only allow 64x64 cursors
vmwgfx: Initialize clip rect loop correctly in surface dirty
vmwgfx: Close screen object system
...
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: iss_storagedev@hp.com
Acked-by: Mike Miller <mike.miller@hp.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
If the port supports Link speeds greater than 5.0 GT/s, we must wait
for 100 ms after Link training completes before sending configuration
request.
Acked-by: Yinghai Lu <yinghai@kernel.org>
Tested-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
We need to wait for 1000 ms after Data Link Layer Link Active (DLLLA)
bit reads 1b before sending configuration request. Currently pciehp
does this wait after checking Link Training (LT) bit. But we need it
before checking LT bit because LT is still set even after DLLLA bit is
set on some platforms.
Acked-by: Yinghai Lu <yinghai@kernel.org>
Tested-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Firmware expects 'max_ssid_length' field in
'struct mwifiex_ie_types_wildcard_ssid_params' to be '0' for
performing SSID specific scan. Currently driver updates it with
an actual SSID length. Hence UUT is not able to find the AP
configured in hidden SSID mode in scan results and association
fails.
max_ssid_length is filled with '0' to fix the issue.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The following error is seen in some case when mounting rootfs from
SD/MMC cards.
Waiting for root device /dev/mmcblk0p1...
mmc1: host does not support reading read-only switch. assuming write-enable.
mmc1: new high speed SDHC card at address b368
mmcblk0: mmc1:b368 SDC 3.74 GiB
mmcblk0: p1
mmc1: Timeout waiting for hardware interrupt.
mmcblk0: error -110 transferring data, sector 3678224, nr 40, cmd response 0x900, card status 0xc00
end_request: I/O error, dev mmcblk0, sector 3678225
Buffer I/O error on device mmcblk0p1, logical block 458754
lost page write due to I/O error on mmcblk0p1
This patch fixes the problem by lowering the usdhc clock and correcting
watermark configuration.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Cc: Chris Ball <cjb@laptop.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Aacraid controller can hang on some nodes if kernel uses non-default
(powersave) ASPM policy. Controller hangs shortly after successful load and
hardware detection. Scsi error handler detects this hang and tries to restart
hardware but it does not help.
Initially it was noticed on RHEL6-based openVZ kernel after backporting
aacraid driver from mainline (RHEL6 kernel with original driver works well)
http://bugzilla.openvz.org/show_bug.cgi?id=2043
This issue happens because default ASPM policy was changed in Red Hat
kernels. Therefore guys from Red Hat have noticed this problem long time ago:
on Fedora 12
https://bugzilla.redhat.com/show_bug.cgi?id=540478
on Fedora 14
https://bugzilla.redhat.com/show_bug.cgi?id=679385
In RHEL6 kernel this issue was fixed, ASPM was disabled in aacraid driver. In
kernel changelog I've found that seems it was done by Matthew Garrett: -
[scsi] aacraid: Disable ASPM by default (Matthew Garrett) [599735]
However seems this patch was not submitted to mainline. I've reproduced this
issue on vanilla 3.1.0 kernel booted with "pcie_aspm.policy=powersave" option,
So I believe it makes sense to do it now.
Signed-off-by: Vasily Averin <vvs@sw.ru>
[mjg: Checking the Windows drivers indicates that they disable ASPM under all
circumstances, so:]
Acked-by: Matthew Garrett <mjg@redhat.com>
Acked-by: Achim Leubner <Achim_Leubner@pmc-sierra.com>
Cc: stable@kernel.org
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
On newer chips the number of clock modes per power state varies.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Avoid a lot of extra loops through the pm state array.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The new power tables need to be handled differently when setting
up the profiles.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-nouveau-fixes' of git://git.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau: Fix bandwidth calculation for DisplayPort
drm/nouveau: by default use low bpp framebuffer on low memory cards
drm/nv10: Change the BO size threshold determining the memory placement range.
drm/nvc0: enable acceleration for nvc1 by default
drm/nvc0/gr: fixup the mmio list register writes for 0xc1
drm/nvc1: hacky workaround to fix accel issues
drm/nvc0/gr: fix some bugs in grctx generation
drm/nvc0: enable acceleration on 0xc8 by default
drm/nvc0/vram: skip disabled PBFB subunits
drm/nv40/pm: fix issues on igp chipsets, which don't have memory
drm/nouveau: testing the wrong variable
drm/nvc0/vram: storage type 0xc3 is not compressed
drm/nv50: fix stability issue on NV86.
drm/nouveau: initialize chan->fence.lock before use
drm/nv50/vram: fix incorrect detection of bank count on newer chipsets
drm/nv50/gr: typo fix, how about we not reset fifo during graph init?
drm/nv50/bios: fixup mpll programming from the init table parser
drm/nouveau: fix oops if i2c bus not found in nouveau_i2c_identify()
drm: make sure drm_vblank_init() has been called before touching vbl_lock
during the review of the fix for locks problems in drm_wait_vblank,
a couple of false concerns were raised about how the drm_vblank_get
and drm_vblank_put are used in this function; it turned out that the
code is correct and that it cannot be simplified
add a few comments to explain non-obvious flows in the code,
to prevent "false alarms" in the future
v2: incorporate comments received from Daniel Vetter
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
radeon_benchmark_do_move() returns an int so "time" should be int
too. Making it unsigned breaks the error handling.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm_wait_vblank must be DRM_UNLOCKED because otherwise it
will grab the drm_global_mutex and then go to sleep until the vblank
event it is waiting for. That can wreck havoc in the windowing system
because if one process issues this ioctl, it will block all other
processes for the duration of all vblanks between the current and the
one it is waiting for. In some cases it can block the entire windowing
system.
v2: incorporate comments received from Daniel Vetter and
Michel Daenzer.
v3/v4: after a lengty discussion with Daniel Vetter, it was concluded
that the only thing not yet protected with locks and atomic
ops is the write to dev->last_vblank_wait. It's only used in a
debug file in proc, and the current code already employs no
correct locking: the proc file only takes dev->struct_mutex,
whereas drm_wait_vblank implicitly took the drm_global_mutex.
Given all this, it's not worth bothering to try to fix
the locks at this time.
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We restore the CRTC, encoder, and connector configurations, but if the
mode set failed, the attached display may have been turned off, so we
need to try set_config again to restore things to the way they were.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Can happen when there is no DP panel attached, confusing
users. Make it debug only.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
slow-work got killed in commit 181a51f6e0. This means that since v2.6.36
there is no Kconfig symbol SLOW_WORK. Apparently selecting that symbol
is a nop. Drop that select.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Nouveau, when configured with debugfs, creates debugfs files for every
channel, so structure holding list of files needs to be protected from
simultaneous changes by multiple threads.
Without this patch it's possible to hit kernel oops in
drm_debugfs_remove_files just by running a couple of xterms with
looped glxinfo.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This hunk seems to have gotten lost when I rebased the patch.
Reported-by: Sylvain Bertrand <sylvain.bertrand@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This was only the case if the GPU reset was triggered from the CS ioctl,
otherwise other processes could happily enter the CS ioctl and wreak havoc
during the GPU reset.
This is a little complicated because the GPU reset can be triggered from the
CS ioctl, in which case we're already holding the mutex, or from other call
paths, in which case we need to lock the mutex. AFAICT the mutex API doesn't
allow recursive locking or finding out the mutex owner, so we need to handle
this with helper functions which allow recursive locking from the same
process.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Snooping code expects this to be the case.
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Now that all of the named string association with clocks has been
migrated to clkdev lookups there's no meaningful named topology that can
be constructed for a debugfs tree view. Get rid of the left over bits,
and shrink struct clk a bit in the process.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
The runtime PM platform support stub in use by ARM-based SH/R-Mobile
platforms contains nothing that's specifically ARM-related and instead of
wholly generic to anything using the clock framework.
The recent runtime PM changes interact rather badly with the lazy
disabling of clocks late in the boot process through the clock framework,
leading to situations where the runtime suspend/resume paths are entered
without a clock being actively driven due to having been lazily gated
off.
In order to correct this we can trivially tie in the aforementioned stub
as a general fallback for all SH platforms that don't presently have
their own runtime PM implementations (the corner case being SH-based
SH-Mobile platforms, which have their own stub through the hwblk API --
which in turn has bitrotted and will be subsequently adapted to use the
same stub as everyone else), regardless of whether the platforms choose
to define power domains of their own or not.
This fixes up regressions for clock framework users who also build in
runtime PM support without any specific power domains of their own, which
was previously causing the serial console to be lost when warring with
lazy clock disabling.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Drivers should not use NO_IRQ; moreover, some architectures don't
have it nowadays. '0' is the 'no irq' case.
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Testing i915_panel_use_ssc for the default value was broken, so the
driver would never autodetect the correct value.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Alexandre Salim <salimma@fedoraproject.org>
Tested-by: Michel Alexandre Salim <salimma@fedoraproject.org>
Cc: stable@kernel.org
There was supposed to be a kzalloc() here and the compiler complained
about it.
mpt2sas_scsih.c: In function ‘mpt2sas_scsih_reset_handler’:
mpt2sas_scsih.c:2807:21: warning: ‘fw_event’ may be used uninitialized in this function [-Wuninitialized]
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: "Nandigama, Nagalakshmi" <Nagalakshmi.Nandigama@lsi.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Added <linux/module.h> and <linux/stat.h> to avoid a compiler error
because linux/irq.h no longer includes linux/module.h after Linux 3.2.
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Machines that have embedded pin controllers need to select them
explicitly, so why broadcast their config options to menuconfig.
We provide a helpful submenu for those machines that do select
it, making it possible to enable debugging for example.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Fix the following compilation failure with v3.2-rc1 by including module.h:
CC drivers/input/serio/ams_delta_serio.o
drivers/input/serio/ams_delta_serio.c:33:15: error: expected declaration specifiers or '...' before string constant
drivers/input/serio/ams_delta_serio.c:34:20: error: expected declaration specifiers or '...' before string constant
drivers/input/serio/ams_delta_serio.c:35:16: error: expected declaration specifiers or '...' before string constant
drivers/input/serio/ams_delta_serio.c: In function 'ams_delta_serio_init':
drivers/input/serio/ams_delta_serio.c:155:2: error: 'THIS_MODULE' undeclared (first use in this function)
drivers/input/serio/ams_delta_serio.c:155:2: note: each undeclared identifier is reported only once for each function it appears in
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
This patch fixes some v3 hardware (fw_version: 0x150500) wrongly detected
as v2 hardware.
Reported-by: Marc Dietrich <marvin24@gmx.de>
Signed-off-by: JJ Ding <jj_ding@emc.com.tw>
Tested-By: Marc Dietrich <marvin24@gmx.de>
Acked-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Change them over to plain "ETHERNET"
Reported-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Make dev_pm_qos_add_request() use WARN() in a better way and do not hardcode
the function's name into the message (use __func__ instead).
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Refrain from running clk_disable() on clocks that
have not been enabled. A typical case when this can
happen is during Suspend-to-RAM for devices that have
no driver associated with them. In such case the clock
may be in default ACQUIRED state.
Without this patch the sh7372 Mackerel board crashes
in __clk_disable() during Suspend-to-RAM with:
"Trying to disable clock 0xdeadbeef with 0 usecount"
This happens for the CEU device which is added during
boot. The test case has no CEU driver included in the
kernel configuration. Needed for v3.2-rc1.
Signed-off-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Framebuffer's BPP is not that important but can waste significant part
of memory on low-VRAM cards. Lower it to 8bpp on < 32MB cards and to
16bpp on 64MB cards. It can still be overridden by video= option.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Fixes the framebuffer memory allocation failure seen on some
low-memory cards, followed by X refusing to start.
https://bugs.freedesktop.org/show_bug.cgi?id=42384
Reported-by: Chris Paulson-Ellis <chris@edesix.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Most serious is for chips with only 1 TPC, we'd get stuck in an infinite
loop. The fix here will slightly change the setup for all other chipsets
too, but, it shouldn't matter too much, and this all needs figuring out
and likely redone anyway.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
memtimings is a valid pointer here, the intent was to test for
kcalloc() failure.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Confirmed to fix random hangs while running all Unegine demos on NV86.
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Fence lock needs to be initialized before any call to nouveau_channel_put
because it calls nouveau_channel_idle->nouveau_fence_update which uses
fence lock.
BUG: spinlock bad magic on CPU#0, test/24134
lock: ffff88019f90dba8, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
Pid: 24134, comm: test Not tainted 3.0.0-nv+ #800
Call Trace:
spin_bug+0x9c/0xa3
do_raw_spin_lock+0x29/0x13c
_raw_spin_lock+0x1e/0x22
nouveau_fence_update+0x2d/0xf1
nouveau_channel_idle+0x22/0xa0
nouveau_channel_put_unlocked+0x84/0x1bd
nouveau_channel_put+0x20/0x24
nouveau_channel_alloc+0x4ec/0x585
nouveau_ioctl_fifo_alloc+0x50/0x130
drm_ioctl+0x289/0x361
do_vfs_ioctl+0x4dd/0x52c
sys_ioctl+0x42/0x65
system_call_fastpath+0x16/0x1b
It's easily triggerable from userspace.
Additionally remove double initialization of chan->fence.pending.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reportedly this has been causing stability and corruption issues after
resuming from suspend for a few people.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Commit ff5a3b509e ("hippi: Move the HIPPI driver") moved the HIPPI
driver into drivers/net/hippi. It didn't source
drivers/net/hippi/Kconfig though, so it didn't make all necessary
Kconfig changes. So let drivers/net/kconfig source HIPPI's Kconfig file.
[ Fix syntax error at the end of HIPP's Kconfig file. -DaveM ]
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
While tracing down a connectivity problem on the temac I connected a
probe to the Cross bar irq, and it was triggered when doing
ifdown->ifup.
This is fixed once waiting for the indirect write to end. Since it is
not on the hot path there is no performance loss.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Do not enable the irq until the scatter gather registers are ready to
handle the data. Otherwise an irq from a packet send/received before
last close can lead to an access to an invalid memory region on the irq
handler.
Also, stop the dma engine on close.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
use get_unaligned_le64() to get timestamp
Signed-off-by: Steven Miao <realmz6@gmail.com>
Acked-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When we tear down a device we try to flush all outstanding
commands in scsi_free_queue(). However the check in
scsi_request_fn() is imperfect as it only signals that
we _might start_ aborting commands, not that we've actually
aborted some.
So move the printk inside the scsi_kill_request function,
this will also give us a hint about which commands are aborted.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Commit 940ab889 "drivercore: Add helper macro for platform_driver boilerplate"
converted this driver to use module_platform_driver, but due to the use
of platform_driver_probe(), this resulted in the call to atmel_spi_probe being
lost. Place the call to this function into the driver structure.
fix section missmatch
atmel_spi_probe is marked __init where it's supposed to be __devinit
atmel_spi_remove is marked __exit where it's supposed to be __devexit
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Reenable sending SRST to devices connected behind a Sil3726 PMP.
This allow staggered spinups and handles drives that spins up slowly.
While the drives spin up, the PMP will not accept SRST.
Most controller reissues the reset until the drive is ready, while
some [Sil3124] returns an error.
In ata_eh_error, wait 10s before reset the ATA port and try again.
Signed-off-by: Gwendal Grignou <gwendal@google.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Use dev_get_platdata() to retrieve the struct ahci_platform_data data
from the platform.
Signed-off-by: JiSheng Zhang <jszhang3@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Add the documentation of parameters of ata_change_queue_depth to silence the warning of make xmldocs
Signed-off-by: Marcos paulo de Souza <marcos.mage@gmail.com>
Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
drivers/media: video/a5k6aa is a module and so needs module.h
mfd: fix build failures in recently added ab5500 code
hwspinlock/u8500: include linux/module.h
MTD: MAPS: bcm963xx-flash.c: explicitly include module.h
* 'for-linus' of git://neil.brown.name/md:
md/raid5: STRIPE_ACTIVE has lock semantics, add barriers
md/raid5: abort any pending parity operations when array fails.
