In commit a51435a313
Author: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Date: Wed Mar 12 16:39:40 2014 +0530
drm/i915: disable rings before HW status page setup
we reordered stopping the rings to do so before we set the HWS register.
However, there is an extra workaround for g45 to reset the rings twice,
and for consistency we should apply that workaround before setting the
HWS to be sure that the rings are truly stopped.
Reference: http://lkml.kernel.org/r/20140423202248.GA3621@amd.pavel.ucw.cz
Tested-by: Pavel Machek <pavel@ucw.cz>
Cc: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The status bits are unconditionally set, the control bits only enable
the actual interrupt generation. Which means if we get some random
other interrupts we'll bogusly complain about them.
So restrict the WARN to platforms with a sane hotplug interrupt
handling scheme. And even more important also don't attempt to process
the hpd bit since we've detected a storm already. Instead just clear
the bit silently.
This WARN has been introduced in
commit b8f102e8bf
Author: Egbert Eich <eich@suse.de>
Date: Fri Jul 26 14:14:24 2013 +0200
drm/i915: Add messages useful for HPD storm detection debugging (v2)
before that we silently handled the hpd event and so partially
defeated the storm detection.
v2: Pimp commit message (Jani)
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Egbert Eich <eich@suse.de>
Cc: bitlord <bitlord0xff@gmail.com>
Reported-by: bitlord <bitlord0xff@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The hw cursor is relatively adept at triggering underflows, which
manifest as a "blue flash" (since blue is configured as the underflow
color). Juggle a few things around to tighten up the timing for setting
cursor registers in DONE irq.
And most importantly, don't ever disable the hw cursor. Instead flip it
to a blank/empty cursor. This seems far more reliable, as even simply
clearing the cursor-enable bit (with no other updates in previous/
following frames) can in some cases cause underflow.
v1: original
v2: add missing locking spotted by Micah
Cc: Micah Richert <richert@braincorporation.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Since X11 is going to create an XR24 fb, if the pixel formats do not
match then crtc helpers will think it is a full modeset even if mode is
the same, which prevents smooth/flickerless handover from fbcon/plymouth
to X11.
Signed-off-by: Rob Clark <robdclark@gmail.com>
This reverts commit d2bee8fb6e.
Enabling autosuspend for Intel Bluetooth devices has been shown to not
work reliable. It does work for some people with certain combinations
of USB host controllers, but for others it puts the device to sleep and
it will not wake up for any event.
These events can be important ones like HCI Inquiry Complete or HCI
Connection Request. The events will arrive as soon as you poke the
device with a new command, but that is not something we can do in
these cases.
Initially there were patches to the xHCI USB controller that fixed
this for some people, but not for all. This could be well a problem
somewhere in the USB subsystem or in the USB host controllers or
just plain a hardware issue somewhere. At this moment we just do
not know and the only safe action is to revert this patch.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: Tedd Ho-Jeong An <tedd.an@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
brcmfmac has been broken on my cubietruck with a BCM43362:
brcmfmac: brcmf_chip_recognition: found AXI chip: BCM43362, rev=1
brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
since commit 5303626103: "brcmfmac: update core reset and disable routines".
The problem is that since this commit brcmf_chip_ai_resetcore no longer sets
BCMA_IOCTL itself before bringing the core out of reset, instead relying on
brcmf_chip_ai_coredisable to do so. But brcmf_chip_ai_coredisable is a nop
of the chip is already in reset. This patch modifies brcmf_chip_ai_coredisable
to always set BCMA_IOCTL even if the core is already in reset.
This fixes brcmfmac hanging in firmware loading on my board.
Cc: stable@vger.kernel.org # v3.14
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The commit "ath9k: move sc_flags to ath_common" moved setting
ATH_OP_INVALID flag below ieee80211_register_hw. This is causing
the flag never being cleared randomly as the drv_start is called
prior to setting flag. Fix this by setting the flag prior to
register_hw.
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
While porting a RS485 driver from 2.6.29 to 3.14, i noticed that the serial tty
driver could break it by using uart ports that it does not own :
1. uart_change_pm ist called during uart_open and calls the uart pm function
without checking for PORT_UNKNOWN.
The fix is to move uart_change_pm from uart_open to uart_port_startup.
2. The return code from the uart request_port call in uart_set_info is not
handled properly, leading to the situation that the serial driver also
thinks it owns the uart ports.
This can triggered by doing following actions :
setserial /dev/ttyS0 uart none # release the uart ports
modprobe lirc-serial # or any other device that uses the uart
setserial /dev/ttyS0 uart 16550 # gives no error and the uart tty driver
# can use the ports as well
Signed-off-by: Thomas Pfaff <tpfaff@pcs.com>
Reviewed-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The two functions to write out to the console (one used in normal
console mode and one in polling console mode) were slightly different.
One used a barrier() in its loop and the other a cpu_relax(). The
barrier() really doesn't do anything since we're using rd_regl() to
read the port anyway. Switch it to cpu_relax() to make things
consistent.
No known bugs / issues are fixed by this change--it just makes things
more consistent.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The s3c24xx_serial_console_putchar() is _only_ ever used by
s3c24xx_serial_console_write() and is called in a loop (indirectly
through uart_console_write()). There's no reason to call
s3c24xx_port_configured() for every iteration through the loop. Move
it outside the loop.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The two functions in the samsung serial driver used for writing
characters out to the port were inconsistent about whether they used
the passed in "port" or the global "cons_uart". There was no reason
to use the global and the use of the global in
s3c24xx_serial_put_poll_char() caused a crash in the case where you
used the serial port for kgdboc but not for console.
Fix it so we used the passed in variable.
Note that this doesn't fix all problems with the samsung serial
driver. Specifically:
* s3c24xx_serial_console_putchar() is still 99% identical to
s3c24xx_serial_put_poll_char() (the function signature is different,
but that's about it). A future patch will make them slightly less
identical and judging by other serial drivers we may need yet more
differences eventually.
* The samsung serial driver still doesn't allow you to have more than
one console port since it still uses the global cons_uart in
s3c24xx_serial_console_write().
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
__dma_tx_complete is not protected against concurrent
call of serial8250_tx_dma. it can lead to circular tail
index corruption or parallel call of serial_tx_dma on the
same data portion.
This patch fixes this issue by holding the port lock.
Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On transmit-hold-register empty, serial8250_tx_chars
should be called only if we don't use DMA.
DMA has its own tx cycle.
Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The race was introduced while development of linux-3.11 by
e8437d7ecb and
e9975fdec0.
Originally it was found and reproduced on linux-3.12.15 and
linux-3.12.15-rt25, by sending 500 byte blocks with 115kbaud to the
target uart in a loop with 100 milliseconds delay.
In short:
1. The consumer flush_to_ldisc is on to remove the head tty_buffer.
2. The producer adds a number of bytes, so that a new tty_buffer must
be allocated and added by __tty_buffer_request_room.
3. The consumer removes the head tty_buffer element, without handling
newly committed data.
Detailed example:
* Initial buffer:
* Head, Tail -> 0: used=250; commit=250; read=240; next=NULL
* Consumer: ''flush_to_ldisc''
* consumed 10 Byte
* buffer:
* Head, Tail -> 0: used=250; commit=250; read=250; next=NULL
{{{
count = head->commit - head->read; // count = 0
if (!count) { // enter
// INTERRUPTED BY PRODUCER ->
if (head->next == NULL)
break;
buf->head = head->next;
tty_buffer_free(port, head);
continue;
}
}}}
* Producer: tty_insert_flip_... 10 bytes + tty_flip_buffer_push
* buffer:
* Head, Tail -> 0: used=250; commit=250; read=250; next=NULL
* added 6 bytes: head-element filled to maximum.
* buffer:
* Head, Tail -> 0: used=256; commit=250; read=250; next=NULL
* added 4 bytes: __tty_buffer_request_room is called
* buffer:
* Head -> 0: used=256; commit=256; read=250; next=1
* Tail -> 1: used=4; commit=0; read=250 next=NULL
* push (tty_flip_buffer_push)
* buffer:
* Head -> 0: used=256; commit=256; read=250; next=1
* Tail -> 1: used=4; commit=4; read=250 next=NULL
* Consumer
{{{
count = head->commit - head->read;
if (!count) {
// INTERRUPTED BY PRODUCER <-
if (head->next == NULL) // -> no break
break;
buf->head = head->next;
tty_buffer_free(port, head);
// ERROR: tty_buffer head freed -> 6 bytes lost
continue;
}
}}}
This patch reintroduces a spin_lock to protect this case. Perhaps later
a lock-less solution could be found.
Signed-off-by: Manfred Schlaegl <manfred.schlaegl@gmx.at>
Cc: stable <stable@vger.kernel.org> # 3.11
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This series contains straight-forward fixes for different
Versatile Express infrastructure drivers:
- NULL pointer dereference on the error path in the clk driver
- out of boundary array access in the dcscb driver
- broken restart/power off implementation
- mis-interpreted voltage unit in the spc driver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQEcBAABAgAGBQJTWTroAAoJEL9jRaJfXa5PHMkIAJB2S6zuqIxn7qRsfeD5YauR
nz7AHjDaakoVy6YTaMdHQI+dXSK6BPUNvMbrKzW3WWbT4ktJ/r3k/OeeBv/2T93L
8KW1Bbif7kPfdfITwCCWDs5waTDVXSBC6AGGoXomzQIt4MqghhzoLRc6uvhnuYAL
R7ZJsTWRa+47LVOJsghVffMyNlwCMj//prW7PBY6RIZXhpcbI+FGYv5Rm1XRITWn
uL2cSulBmWeqMVCR/gFx8/K5TqZ90q835dD1Ggh+BeB1Vaifu9/cI3D8w0hl/xy9
nRneKdTaTEpKjgwI3up4vMFbLbMI7brdMphZ9ZeGgK+YuWXFDbKvvdwjvDJ4Tx0=
=BS4Q
-----END PGP SIGNATURE-----
Merge tag 'vexpress/fixes-for-3.15' of git://git.linaro.org/people/pawel.moll/linux into fixes
ARM Versatile Express fixes for 3.15
This series contains straight-forward fixes for different
Versatile Express infrastructure drivers:
- NULL pointer dereference on the error path in the clk driver
- out of boundary array access in the dcscb driver
- broken restart/power off implementation
- mis-interpreted voltage unit in the spc driver
* tag 'vexpress/fixes-for-3.15' of git://git.linaro.org/people/pawel.moll/linux:
ARM: vexpress/TC2: Convert OPP voltage to uV before storing
power/reset: vexpress: Fix restart/power off operation
arm/mach-vexpress: array accessed out of bounds
clk: vexpress: NULL dereference on error path
Includes an update to 3.15-rc2
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Currently we get the following kind of errors if we try to use interrupt
phandles to irqchips that have not yet initialized:
irq: no irq domain found for /ocp/pinmux@48002030 !
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x144/0x184()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-00038-g42a9708 #1012
(show_stack+0x14/0x1c)
(dump_stack+0x6c/0xa0)
(warn_slowpath_common+0x64/0x84)
(warn_slowpath_null+0x1c/0x24)
(of_device_alloc+0x144/0x184)
(of_platform_device_create_pdata+0x44/0x9c)
(of_platform_bus_create+0xd0/0x170)
(of_platform_bus_create+0x12c/0x170)
(of_platform_populate+0x60/0x98)
This is because we're wrongly trying to populate resources that are not
yet available. It's perfectly valid to create irqchips dynamically, so
let's fix up the issue by resolving the interrupt resources when
platform_get_irq is called.
And then we also need to accept the fact that some irqdomains do not
exist that early on, and only get initialized later on. So we can
make the current WARN_ON into just into a pr_debug().
We still attempt to populate irq resources when we create the devices.
This allows current drivers which don't use platform_get_irq to continue
to function. Once all drivers are fixed, this code can be removed.
Suggested-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Cc: stable@vger.kernel.org # v3.10+
Signed-off-by: Grant Likely <grant.likely@linaro.org>
slc_xmit is called within softirq context and locks sl->lock, but
slcan_write_wakeup is not softirq context, so we need to use
spin_[un]lock_bh!
Detected using kernel lock debugging mechanism.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
When trying to set a data bitrate on non CAN FD devices the 'ip' tool
answers with:
RTNETLINK answers: Unknown error 524
Rename '-ENOTSUPP' to '-EOPNOTSUPP' so that 'ip' answers correctly:
RTNETLINK answers: Operation not supported
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
When accessing the SJA1000 controller registers in the indirect access mode,
writing the register number and reading/writing the data has to be an atomic
attempt.
As the sja1000_isa driver is an old style driver with a fixed number of
instances the locking variable depends on the same index like all the other
configuration elements given on the module command line.
As a positive side effect dev->dev_id is populated by the instance index,
which was missing in 3e66d0138c ("can: populate netdev::dev_id for udev
discrimination").
Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Coverity complains that c_can_pci_probe() calls pci_enable_msi() without
checking the result:
CID 712278 (#1 of 1): Unchecked return value (CHECKED_RETURN) 3. check_return:
Calling pci_enable_msi_block without checking return value (as is done
elsewhere 88 out of 105 times).
88 pci_enable_msi(pdev);
This is CID 712278.
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Reported-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Commit 6439fbce10 (can: c_can: fix error checking of priv->instance in
probe()) found the warning but applied a suboptimal solution. Since, both
pdev->id and of_alias_get_id() return integers, it makes sense to convert the
variable to an integer and avoid the cast.
Signed-off-by: Wolfram Sang <wsa@sang-engineering.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
It's suffcient to kill the TXIE bit in the message control register
even if the documentation of C and D CAN says that it's not allowed to
do that while MSGVAL is set. Reality tells a different story and this
change gives us another 2% of CPU back for not waiting on I/O.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Mark suggested to use one IF for the softirq and the other for the
xmit function to avoid the xmit lock.
That requires to write the frame into the interface first, then handle
the echo skb and store the dlc before committing the TX request to the
message ram.
We use an atomic to handle the active buffers instead of reading the
MSGVAL register as thats way faster especially on PCH/x86.
Suggested-by: Mark <mark5@del-llc.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Instead of obfuscating the code by artificial 16 bit splits use the
proper 32 bit assignments and split the result when writing to the
interface.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Remove the MASK from the TX transfer side.
Make the code readable and get rid of the annoying IFX_WRITE_XXX_16BIT
macros which are just obfuscating the code.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Sigh!
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Alexander reported that the new optimized handling of the RX fifo
causes random packet loss on Intel PCH C_CAN hardware.
After a few fruitless debugging sessions I got hold of a PCH (eg20t)
afflicted system. That machine does not have the CAN interface wired
up, but it was possible to reproduce the issue with the HW loopback
mode.
As Alexander observed correctly, clearing the NewDat flag along with
reading out the message buffer causes that issue on C_CAN, while D_CAN
handles that correctly.
Instead of restoring the original message buffer handling horror the
following workaround solves the issue:
transfer buffer to IF without clearing the NewDat
handle the message
clear NewDat bit
That's similar to the original code but conditional for C_CAN.
I really wonder why all user manuals (C_CAN, Intel PCH and some more)
recommend to clear the NewDat bit right away. The knows it all Oracle
operated by Gurgle does not unearth any useful information either. I
simply cannot believe that we are the first to uncover that HW issue.
Reported-and-tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The RX buffer split causes packet loss in the hardware:
What happens is:
RX Packet 1 --> message buffer 1 (newdat bit is not cleared)
RX Packet 2 --> message buffer 2 (newdat bit is not cleared)
RX Packet 3 --> message buffer 3 (newdat bit is not cleared)
RX Packet 4 --> message buffer 4 (newdat bit is not cleared)
RX Packet 5 --> message buffer 5 (newdat bit is not cleared)
RX Packet 6 --> message buffer 6 (newdat bit is not cleared)
RX Packet 7 --> message buffer 7 (newdat bit is not cleared)
RX Packet 8 --> message buffer 8 (newdat bit is not cleared)
Clear newdat bit in message buffer 1
Clear newdat bit in message buffer 2
Clear newdat bit in message buffer 3
Clear newdat bit in message buffer 4
Clear newdat bit in message buffer 5
Clear newdat bit in message buffer 6
Clear newdat bit in message buffer 7
Clear newdat bit in message buffer 8
Now if during that clearing of newdat bits, a new message comes in,
the HW gets confused and drops it.
It does not matter how many of them you clear. I put a delay between
clear of buffer 1 and buffer 2 which was long enough that the message
should have been queued either in buffer 1 or buffer 9. But it did not
show up anywhere. The next message ended up in buffer 1. So the
hardware lost a packet of course without telling it via one of the
error handlers.
That does not happen on all clear newdat bit events. I see one of 10k
packets dropped in the scenario which allows us to reproduce. But the
trace looks always the same.
Not splitting the RX Buffer avoids the packet loss but can cause
reordering. It's hard to trigger, but it CAN happen.
With that mode we use the HW as it was probably designed for. We read
from the buffer 1 upwards and clear the buffer as we get the
message. That's how all microcontrollers use it. So I assume that the
way we handle the buffers was never really tested. According to the
public documentation it should just work :)
Let the user decide which evil is the lesser one.
[ Oliver Hartkopp: Provided a sane config option and help text and
made me switch to favour potential and unlikely reordering over
packet loss ]
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The driver handles pointlessly TWO interrupts per packet. The reason
is that it enables the status interrupt which fires for each rx and tx
packet and it enables the per message object interrupts as well.
The status interrupt merily acks or in case of D_CAN ignores the TX/RX
state and then the message object interrupt fires.
The message objects interrupts are only useful if all message objects
have hardware filters activated.
But we don't have that and its not simple to implement in that driver
without rewriting it completely.
So we can ditch the message object interrupts and handle the RX/TX
right away from the status interrupt. Instead of TWO we handle ONE.
Note: We must keep the TXIE/RXIE bits in the message buffers because
the status interrupt alone is not reliable enough in corner cases.
If we ever have the need for HW filtering, then this code needs a
complete overhaul and we can think about it then. For now we prefer a
lower interrupt load.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
On D_CAN the RXOK, TXOK and LEC bits are cleared/set on read of the
status register. No need to update them.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Instead of writing to the message object we can simply clear the
NewDat bit with the get method.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
If the allocation of the error skb fails, we still want to see the
error statistics.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Reading the LEC type with
return (mode & ENABLED) && (status & LEC_MASK);
is not guaranteed to return (status & LEC_MASK) if the enabled bit in
mode is set. It's guaranteed to return 0 or !=0.
Remove the inline function and call unconditionally into the
berr_handling code and return early when the reporting is disabled.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
If the allocation of an error skb fails, the state change handling
returns w/o doing any work. That leaves the interface in a wreckaged
state as the internal status is wrong.
Split the interface handling and the skb handling.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
There is no guarantee that the skb is in the same state after calling
net_receive_skb(). It might be freed or reused. Not really harmful as
its a read access, except you turn on the proper debugging options
which catch a use after free.
The whole can subsystem is full of this. Copy and paste ....
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The state change handler is called with device interrupts disabled
already. So no point in disabling them again when we enter bus off
state.
But what's worse is that we reenable the interrupts at the end of NAPI
poll unconditionally. So c_can_start() which is called from the
restart timer can trigger interrupts which confuse the hell out of the
half reinitialized driver/hw.
Remove the pointless device interrupt disable in the BUS_OFF handler
and prevent reenabling the device interrupts at the end of the poll
routine when the current state is BUS_OFF.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
c_can_start() enables interrupts way too early. The first enabling
happens when setting the control mode in c_can_chip_config() and then
again at the end of the function.
But that happens before napi_enable() and that means that an interrupt
which comes in will disable interrupts again and call napi_schedule,
which ignores the request and the later napi_enable() is not making
thinks work either. So the interface is up with all device interrupts
disabled.
Move the device interrupt after napi_enable() and add it to the other
callsites of c_can_start() in c_can_set_mode() and c_can_power_up()
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
All type checks in c_can.c are != BOSCH_D_CAN so nobody noticed so far
that the pci code does not update the type information.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
The kernel oopses in phy_lookup() due to 'phy->init_data' being NULL if we
register PHYs from a device tree probing driver and then call phy_get() on a
device that has no representation in the device tree (e.g. a PCI device).
Checking the pointer before dereferening it and skipping an interation if
it's NULL prevents this kernel oops.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When OMAP_CONTROL_USB was renamed to OMAP_CONTROL_PHY (commit
14da699b), its dependencies were lost in the process. Nothing in the
commit message indicates that this removal was intentional, so I think
it was by accident and the dependencies should be restored.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Acked-by: Roger Quadros <rogerq@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The top-level phy-samsung-usb2 driver may be configured as a
loadable module, which currently causes link errors because
of the dependency on the exynos{5250,4x12,4210}_usb2_phy_config
symbol. Solving this could be achieved by exporting these
symbols, but as the SoC-specific parts of the driver are not
currently built as modules, it seems better to just link
everything into one module and avoid the need for the export.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Kamil Debski <k.debski@samsung.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix driver new_id sysfs-attribute removal deadlock by making sure to
not hold any locks that the attribute operations grab when removing the
attribute.
Specifically, usb_serial_deregister holds the table mutex when
deregistering the driver, which includes removing the new_id attribute.
This can lead to a deadlock as writing to new_id increments the
attribute's active count before trying to grab the same mutex in
usb_serial_probe.
The deadlock can easily be triggered by inserting a sleep in
usb_serial_deregister and writing the id of an unbound device to new_id
during module unload.
As the table mutex (in this case) is used to prevent subdriver unload
during probe, it should be sufficient to only hold the lock while
manipulating the usb-serial driver list during deregister. A racing
probe will then either fail to find a matching subdriver or fail to get
the corresponding module reference.
Since v3.15-rc1 this also triggers the following lockdep warning:
======================================================
[ INFO: possible circular locking dependency detected ]
3.15.0-rc2 #123 Tainted: G W
-------------------------------------------------------
modprobe/190 is trying to acquire lock:
(s_active#4){++++.+}, at: [<c0167aa0>] kernfs_remove_by_name_ns+0x4c/0x94
but task is already holding lock:
(table_lock){+.+.+.}, at: [<bf004d84>] usb_serial_deregister+0x3c/0x78 [usbserial]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (table_lock){+.+.+.}:
[<c0075f84>] __lock_acquire+0x1694/0x1ce4
[<c0076de8>] lock_acquire+0xb4/0x154
[<c03af3cc>] _raw_spin_lock+0x4c/0x5c
[<c02bbc24>] usb_store_new_id+0x14c/0x1ac
[<bf007eb4>] new_id_store+0x68/0x70 [usbserial]
[<c025f568>] drv_attr_store+0x30/0x3c
[<c01690e0>] sysfs_kf_write+0x5c/0x60
[<c01682c0>] kernfs_fop_write+0xd4/0x194
[<c010881c>] vfs_write+0xbc/0x198
[<c0108e4c>] SyS_write+0x4c/0xa0
[<c000f880>] ret_fast_syscall+0x0/0x48
-> #0 (s_active#4){++++.+}:
[<c03a7a28>] print_circular_bug+0x68/0x2f8
[<c0076218>] __lock_acquire+0x1928/0x1ce4
[<c0076de8>] lock_acquire+0xb4/0x154
[<c0166b70>] __kernfs_remove+0x254/0x310
[<c0167aa0>] kernfs_remove_by_name_ns+0x4c/0x94
[<c0169fb8>] remove_files.isra.1+0x48/0x84
[<c016a2fc>] sysfs_remove_group+0x58/0xac
[<c016a414>] sysfs_remove_groups+0x34/0x44
[<c02623b8>] driver_remove_groups+0x1c/0x20
[<c0260e9c>] bus_remove_driver+0x3c/0xe4
[<c026235c>] driver_unregister+0x38/0x58
[<bf007fb4>] usb_serial_bus_deregister+0x84/0x88 [usbserial]
[<bf004db4>] usb_serial_deregister+0x6c/0x78 [usbserial]
[<bf005330>] usb_serial_deregister_drivers+0x2c/0x4c [usbserial]
[<bf016618>] usb_serial_module_exit+0x14/0x1c [sierra]
[<c009d6cc>] SyS_delete_module+0x184/0x210
[<c000f880>] ret_fast_syscall+0x0/0x48
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(table_lock);
lock(s_active#4);
lock(table_lock);
lock(s_active#4);
*** DEADLOCK ***
1 lock held by modprobe/190:
#0: (table_lock){+.+.+.}, at: [<bf004d84>] usb_serial_deregister+0x3c/0x78 [usbserial]
stack backtrace:
CPU: 0 PID: 190 Comm: modprobe Tainted: G W 3.15.0-rc2 #123
[<c0015e10>] (unwind_backtrace) from [<c0013728>] (show_stack+0x20/0x24)
[<c0013728>] (show_stack) from [<c03a9a54>] (dump_stack+0x24/0x28)
[<c03a9a54>] (dump_stack) from [<c03a7cac>] (print_circular_bug+0x2ec/0x2f8)
[<c03a7cac>] (print_circular_bug) from [<c0076218>] (__lock_acquire+0x1928/0x1ce4)
[<c0076218>] (__lock_acquire) from [<c0076de8>] (lock_acquire+0xb4/0x154)
[<c0076de8>] (lock_acquire) from [<c0166b70>] (__kernfs_remove+0x254/0x310)
[<c0166b70>] (__kernfs_remove) from [<c0167aa0>] (kernfs_remove_by_name_ns+0x4c/0x94)
[<c0167aa0>] (kernfs_remove_by_name_ns) from [<c0169fb8>] (remove_files.isra.1+0x48/0x84)
[<c0169fb8>] (remove_files.isra.1) from [<c016a2fc>] (sysfs_remove_group+0x58/0xac)
[<c016a2fc>] (sysfs_remove_group) from [<c016a414>] (sysfs_remove_groups+0x34/0x44)
[<c016a414>] (sysfs_remove_groups) from [<c02623b8>] (driver_remove_groups+0x1c/0x20)
[<c02623b8>] (driver_remove_groups) from [<c0260e9c>] (bus_remove_driver+0x3c/0xe4)
[<c0260e9c>] (bus_remove_driver) from [<c026235c>] (driver_unregister+0x38/0x58)
[<c026235c>] (driver_unregister) from [<bf007fb4>] (usb_serial_bus_deregister+0x84/0x88 [usbserial])
[<bf007fb4>] (usb_serial_bus_deregister [usbserial]) from [<bf004db4>] (usb_serial_deregister+0x6c/0x78 [usbserial])
[<bf004db4>] (usb_serial_deregister [usbserial]) from [<bf005330>] (usb_serial_deregister_drivers+0x2c/0x4c [usbserial])
[<bf005330>] (usb_serial_deregister_drivers [usbserial]) from [<bf016618>] (usb_serial_module_exit+0x14/0x1c [sierra])
[<bf016618>] (usb_serial_module_exit [sierra]) from [<c009d6cc>] (SyS_delete_module+0x184/0x210)
[<c009d6cc>] (SyS_delete_module) from [<c000f880>] (ret_fast_syscall+0x0/0x48)
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If no valid CHID value has previously been set on an HWA, writing a
value of all zeros will cause a kernel panic in uwb_radio_stop because
wusbhc->uwb_rc has not been set. This patch skips the call to
uwb_radio_stop if wusbhc->uwb_rc has not been initialized.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nesting a spin_lock_irq/unlock_irq inside a lock that has already
disabled interrupts will enable interrupts before we are ready when
spin_unlock_irq is called. This patch converts the inner lock to use
spin_lock and spin_unlock instead.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch converts the use of spin_lock_irq/spin_unlock_irq to
spin_lock_irqsave/spin_unlock_irqrestore in uwb_rc_set_drp_cmd_done
which is called from a USB completion handler. There are also
whitespace cleanups to make checkpatch.pl happy.
Signed-off-by: Thomas Pugliese <thomas.pugliese@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
For internal PHY (like UTMI), the phy clock may from internal pll,
it is on/off on the fly, the access PORTSC.PTS will hang without
phy clock. So, the usb_phy_init which will open phy clock needs to
be called before hw_phymode_configure.
See: http://marc.info/?l=linux-arm-kernel&m=139350618732108&w=2
For external PHY (like ulpi), it needs to configure portsc.pts before
visit viewport, or the viewport can't be visited. so phy_phymode_configure
needs to be called before usb_phy_init.
See: cd0b42c2a6
It may not the best solution, but it can work for all situations.
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Chris Ruehl <chris.ruehl@gtsys.com.hk>
Cc: shc_work@mail.ru
Cc: denis@eukrea.com
Cc: festevam@gmail.com
Cc: stable <stable@vger.kernel.org> # 3.14
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Quite a few fixes this time since I lost v3.15-rc2
window.
Most fixes are MUSB which learned to remove its debugfs directories
properly, got a fix for PHY handling and now knows that it should
make sure its clocks aren't gated before trying to access registers.
ffs got a race fix between ffs_epfile_io() and ffs_func_eps_disable().
dwc3 got a fix for system suspend/resume and now only iterates over
valid endpoints when trying to resize TX fifos.
usb_get_phy() now will properly return an error if try_module_get() fails.
We also have a revert for a NAPI conversion on the ethernet gadget which
was causing a kernel BUG.
Signed-of-by: Felipe Balbi <balbi@ti.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTVTiZAAoJEIaOsuA1yqREKHAP/ip+Exini4jKaVTnZkOSQkct
gc+SLRKEt2C+/VmoFJkGa3EzcCr6jNvGO4rrYUjgLti9+nON+/qjWof3AmrP9gIs
z1ZBXj4I2dOq7gILRlUdfuj5H3UAOg799mn+6DnPkjidR1PqqBlD1EoTFoGqh4Lc
bqiWout3R9aWoYjmFLYS6eXFQGeDCHdtSloVXUxYjMHsrNRIv4XL9DDGwcY2gGxc
6qskSCKP5HSCJbwS7jb4pf+J5nCuKASLTAGroSy8mV2cWxfGj+jLXegr4IdjaH0V
73UkMcufacncvhxA3GTEdjQTy6aBKGnLyZgSEIk30RvDz6C1z4J6v2lffm49bpaa
wnZ3g4AToagiXSeWUsi50Ri7oaksFnLSxCh6JYZ0CvTrbMhM3b1/R0r+hB/r5xba
xsjGIZPpp8CCx31cID/FNMP8gxBgtwCAE0WvYl5WlUl5ESXWyt6fQQAlCZLb4kny
fBgoM1IMuirQXKqNC62gSSKsSqSzZbJVK7dTc+nJFxDjRmmcgdrM1VuQyJMVY8rh
DklMYmfYTdP1JL410Ee3Z50c0SriUS3FLuDqkGd5pbKhbuGWTvoogPRY5d3pewrQ
Tq+O4GhYMlluDK9UF8BM4cbXQMu3ov2ddmm9H9ZH71fmVp8CFMdI0s5Q7BZGryh/
+9aatVH5usptuIiZrRlw
=aYvY
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-v3.15-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
Felipe writes:
usb: fixes for v3.15-rc3
Quite a few fixes this time since I lost v3.15-rc2
window.
Most fixes are MUSB which learned to remove its debugfs directories
properly, got a fix for PHY handling and now knows that it should
make sure its clocks aren't gated before trying to access registers.
ffs got a race fix between ffs_epfile_io() and ffs_func_eps_disable().
dwc3 got a fix for system suspend/resume and now only iterates over
valid endpoints when trying to resize TX fifos.
usb_get_phy() now will properly return an error if try_module_get() fails.
We also have a revert for a NAPI conversion on the ethernet gadget which
was causing a kernel BUG.
Signed-of-by: Felipe Balbi <balbi@ti.com>
A couple of things here:
- Fixes for pbias that didn't make it in during the merge window due to
the driver coming in via MMC. The conversion to use helpers is a
fix as it implements list_voltage() which the main user (MMC) relies
on for correct functioning.
- Change the !REGULATOR stub for optional regulators to return an
error rather than a dummy; this is more in keeping with the intended
use of optional regulators and fixes some issues seen MMC where it
got confused by a dummy being provided.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTWP4ZAAoJELSic+t+oim9D54P/1iF292i/GenPCAHJo/kIV/j
uoiTcE5igqVoEeEtseqkSOy2Wsf9rukNZvQOyyioT6Pm6f+zOKW7pLPuJZmjqiHk
9FOJYfQcoiYL7HpDMIAAANl5rSHlmDZPs4T40+pHh3LJB/NTnrig5MA0tfW7tcyi
TF4PadYavvNwUYivE8NrMJs0qnuzqiXvEFIqZCxR7zm0AYqdVMkI27f4uKTRodcW
8K8VkQ7F7gDyoCiD8ptviB6v9o2WofnZfLI+9qbxexKmb6TFRrvzTkQ8UdyV9LDs
pLstzJsef7IGUDD6F/i3joKzB8Dp9Qp0+ykrffIbRfm+2Jo0xWXX+h9Ko10m1jji
zhzi/dgWp+e7SkXNaWB4hX1mD+jO6KHEg7RRF0GG4Gv6Jql6shDqNwMLHS8TH/s3
owKHdIaYHoyOx73xTJEePFbHgZTc+7YcC9NPtPe0bN2uheSMV9aHePiLoKuzx832
ee6dPIqoMU/g8zvY5CPqLqdqx1Z64MNTg52QraGsYhQ7ik9cHf0cArp5QAbMjnKI
XC7VY0Fulc0rlKkmCQ3KKxs3w+ahRgrdC+Ogne5SHQsB+5eHSGw+t3MIXWq/iiaE
XwuAQKWIy/DbkG3LgcqQGCA5RgwNWO4lJ13mENtJ4CmYDqO0qDIEdKdZ0lqnLsz+
5siSNt87fIcj5BpX2ZRm
=t/Ad
-----END PGP SIGNATURE-----
Merge tag 'regulator-v3.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fixes from Mark Brown:
"A couple of things here:
- Fixes for pbias that didn't make it in during the merge window due
to the driver coming in via MMC. The conversion to use helpers is
a fix as it implements list_voltage() which the main user (MMC)
relies on for correct functioning.
- Change the !REGULATOR stub for optional regulators to return an
error rather than a dummy; this is more in keeping with the
intended use of optional regulators and fixes some issues seen MMC
where it got confused by a dummy being provided"
* tag 'regulator-v3.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: core: Return error in get optional stub
regulator: pbias: Convert to use regmap helper functions
regulator: pbias: Fix is_enabled callback implementation
A few driver specific fixes here:
- SH HSPI was dealing with its clocks incorrectly which meant it didn't
work on some SoCs, fixing this also requires a small fix to one of
the SoC clock trees to avoid breaking existing users.
- The SiRF driver appears to have had several quality problems, it's
fairly new and not widely used so this isn't too worrying.
- A brute force fix for excessive locking in the Atmel driver, it needs
further investigation but this deals with the immediate issue.
- A build fix for the Blackfin driver.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTWPNeAAoJELSic+t+oim9VOYP/1s4R3EsLg/CoO6T3jqDqizZ
0jnQgqTUi11q8+5ozLdt0zhmGOwmoTaqP3RhNqntwFyMucEWmBjrJcRlcmbfq5ve
IWAArM++RvzCgUmK2DfnQ+KxvLNbdDzO6Q+DIzUb1lia5T64Ope3JBWUG2CT5YSE
Yhi1qaktVWP57toZQmuidW+Q48d+fBxdzQ8VIfP1q2GqISwuabALjzp0I+oG5Sa1
3yd0037WmIYXUM+dKMijPQjNtB4FLJ545RR+Y5s9RXn9Pq/KpLL2aVCaPbDW36Oz
bK4zO80mS6zfurk9Yi7RiOV1uTCd/dg4G2MLTzrtP5LgdKpqthVElKbLJUv9cv0z
gZ19wFM0tGe3raxUsXUlcxAyETiNPP+pm6QriS9rgrdazIiS0gP6tvpfU8Szxv3o
EJMJEQ76ieuVA8LVLskPehNYTl5z4CiISS8SrBUdvV4P96RdyD4rGLdDJw5PDIEL
GBEpdcg48QFt6twO52xAQEzRx0T98c/C0GGYR38CbRiNFFZCh5IAr0po1iwTY3WC
vR/2YJw2Lf/+rf6Hu0cNuFd1csaTBQqh6x4JqVHdmL+xIqut2yhP3DLynK9+APR2
6oIHameZGAY1s0iDpCbeEZoTJF0uJw4+qV3xpCDnSTwiBQoD8whwJUnrFyKb1Mo2
+T5hNKls3vDpNwVPFueU
=kM6u
-----END PGP SIGNATURE-----
Merge tag 'spi-v3.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A few driver specific fixes here:
- SH HSPI was dealing with its clocks incorrectly which meant it
didn't work on some SoCs, fixing this also requires a small fix to
one of the SoC clock trees to avoid breaking existing users.
- The SiRF driver appears to have had several quality problems, it's
fairly new and not widely used so this isn't too worrying.
- A brute force fix for excessive locking in the Atmel driver, it
needs further investigation but this deals with the immediate
issue.
- A build fix for the Blackfin driver"
* tag 'spi-v3.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: atmel: Fix scheduling while atomic bug
spi: sh-hspi: Do not specifically request shyway_clk clock
ARM: shmobile: r8a7778: Use clks as MSTP007 parent
spi: sirf: make GPIO chipselect function work well
spi: sirf: set SPI controller in RISC IO chipselect mode
spi: sirf: correct TXFIFO empty interrupt status bit
spi: bfin5xx: fix build error
It is possible by passing a netlink socket to a more privileged
executable and then to fool that executable into writing to the socket
data that happens to be valid netlink message to do something that
privileged executable did not intend to do.
To keep this from happening replace bare capable and ns_capable calls
with netlink_capable, netlink_net_calls and netlink_ns_capable calls.
Which act the same as the previous calls except they verify that the
opener of the socket had the desired permissions as well.
Reported-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This fixes a seg fault on 'ethtool -A' entry if the
interface is down. Obviously we need to have the
phy device initialized / "connected" (see of_phy_connect())
to be able to advertise pause frame capabilities.
Fixes: 23402bddf9
Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
o In case QLC_83XX_MBX_CMD_NO_WAIT command type the calling
function does not free the memory as it does not wait for
response. So free it when get a response from adapter after
sending the command.
Signed-off-by: Rajesh Borundia <rajesh.borundia@qlogic.com>
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some firmware versions fails to reset the lock during
initialization. Force reset firmware API lock during driver
probe to ensure lock availability.
Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 1a699476e2 "ACPI / hotplug / PCI: Hotplug notifications from
acpi_bus_notify()" changed the root notify handler, acpi_bus_notify(),
to block unknown type norifications, but it overlooked the fact that
they might be propagated to drivers via the ->notify() callback.
Fix the problem by allowing drivers to receive unknown type
notifications via ->notify() as before.
Fixes: 1a699476e2 (ACPI / hotplug / PCI: Hotplug notifications from acpi_bus_notify())
Reported-and-tested-by: Mantas Mikulėnas <grawity@gmail.com>
Reported-and-tested-by: Sitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There are two breaks missing there. The result is that userspace
receives multiple messages which might be confusing.
Introduced-by: 3d249d4c "net: introduce ethernet teaming device"
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
I was told that the Cadence macb driver is also useful on Microblaze.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Mark Brown <broonie@kernel.org>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Redefine some macros that were conditioned upon SMC_DEBUG level.
By allowing compiler to verify parameters used by these macros
unconditionally, we can flag compilation failures.
Compiler will still optimize out the unused code path depending on
SMC_DEBUG, so this is a net gain.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Zi Shen Lim <zlim.lnx@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull libata fixes from Tejun Heo:
"Dan updated tag allocation to accomodate devices which choke when tags
jump back and forth. Quite a few ahci MSI related fixes. A couple
config dependency fixes and other misc fixes"
* 'for-3.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
libata/ahci: accommodate tag ordered controllers
ahci: Do not receive interrupts sent by dummy ports
ahci: Use pci_enable_msi_exact() instead of pci_enable_msi_range()
ahci: Ensure "MSI Revert to Single Message" mode is not enforced
ahci: do not request irq for dummy port
pata_samsung_cf: fix ata_host_activate() failure handling
pata_arasan_cf: fix ata_host_activate() failure handling
ata: fix i.MX AHCI driver dependencies
pata_at91: fix ata_host_activate() failure handling
libata: Update queued trim blacklist for M5x0 drives
libata: make AHCI_XGENE depend on PHY_XGENE
The restart/power off implementation in the vexpress driver
used to obtain the config function when necessary. This was
wrong in two respects:
1. It required memory allocation with disabled interrupts
(it worked, but lockdep - when enabled - reported warnings).
2. Used jiffies-based timeout, while jiffies are not running
at this stage of system shutdown (therefore a config
transaction error - if happened - would have never be reported).
Fixed by pre-allocating the config function per device
and using mdelay for timeout.
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Rob Herring <robh@kernel.org>
[grant.likely: fixed failure when root node specifies the interrupt parent]
Signed-off-by: Grant Likely <grant.likely@linaro.org>
According to:"On-The-Go and Embedded Host Supplement to the USB Revision 2.0
Specification July 27, 2012 Revision 2.0 version 1.1a"
- add a_wait_vrise to a_wait_vfall
- update condition from a_wait_vrise to a_wait_bcon
Signed-off-by: Li Jun <b47624@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The Tegra124 clock driver currently provides 3 clocks that don't actually
exist; 2 for NAND and one for UART5/UARTE. Delete these.
Cc: <stable@vger.kernel.org>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
An implementation error should not crash the kernel if it is avoidable.
Replace BUG() with WARN_ONCE().
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
In Matt Ropers primary plane series a set of prep patches like
commit af2b653bfb
Author: Matt Roper <matthew.d.roper@intel.com>
Date: Tue Apr 1 15:22:32 2014 -0700
drm/i915: Restrict plane loops to only operate on overlay planes (v2)
ensured that all exisiting users of the mode_config->plane_list
wouldn't change behaviour. Unfortunately tegra seems to have fallen
through the cracks. Fix it.
This regression was introduced in
commit e13161af80
Author: Matt Roper <matthew.d.roper@intel.com>
Date: Tue Apr 1 15:22:38 2014 -0700
drm: Add drm_crtc_init_with_planes() (v2)
The result was that we've unref'ed the fb for the primary plane twice,
leading to a use-after free bug. This is because the drm core will
already set crtc->primary->fb to NULL and do the unref for us, and the
crtc disable hook is called by the drm crtc helpers for exactly this
case.
Aside: Now that the fbdev helpers clean up planes there's no longer a
need to do this in drivers. So this could probably be nuked entirely
in linux-next.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The 'label' attribute was always created but returned -ENOENT
if there is no label and such behaviour is undefined from
libsensors' point of view.
Fixed by providing is_visible method in the attributes group,
so the attribute is not created at all when unnecessary.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The driver used to directly us a DT 'compatible' property for
the 'name' attribute of the hwmon devices. Unfortunately it
contains '-' which is illegal in this context. It messes up
libsensors and thus every application using it.
Fixed by providing equivalent (and simpler) name strings.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
If the allocation fails then we dereference the NULL in the error path.
Just return directly.
Fixes: ed27ff1db8 ('clk: Versatile Express clock generators ("osc") driver')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
When PPGTT was disabled by default, the patch also prevented the user
from overriding this behavior via module parameter. Being able to test
this on arbitrary kernels is extremely beneficial to track down the
remaining bugs. The patch that prevented this was:
commit 93a25a9e2d
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Mar 6 09:40:43 2014 +0100
drm/i915: Disable full ppgtt by default
By default PPGTT is set to -1. 0 means off, 1 means aliasing only, 2
means full, all other values are reserved.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
If the inherited BIOS framebuffer is smaller than the mode selected for
fbdev, then if we continue to use it then we cause display corruption as
we do not setup the panel fitter to upscale.
Regression from commit d978ef1445
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Fri Mar 7 08:57:51 2014 -0800
drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v12
v2: Add a debug message to track the discard of the BIOS fb.
v3: Ville pointed out the difference between ref/unref
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77767
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We already check that the buffer object we're accessing is registered with
the file. Now also make sure that we can't DMA across buffer object boundaries.
v2: Code commenting update.
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Work around BIOSes that don't report the entire Intel MCH area.
MCHBAR is not an architected PCI BAR, so MCH space is usually reported as a
PNP0C02 resource. The MCH space was once 16KB, but is 32KB in newer parts.
Some BIOSes still report a PNP0C02 resource that is only 16KB, which means
the rest of the MCH space is consumed but unreported.
This can cause resource map sanity check warnings or (theoretically) a
device conflict if we assigned the unreported space to another device.
The Intel perf event uncore driver tripped over this when it claimed the
MCH region:
resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01
Info: mapping multiple BARs. Your kernel is fine.
To prevent this, if we find a PNP0C02 resource that covers part of the MCH
space, extend it to cover the entire space.
References: http://lkml.kernel.org/r/20140224162400.GE16457@pd.tnic
Reported-and-tested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Borislav Petkov <bp@suse.de>
Acked-by: Stephane Eranian <eranian@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In usbdux_ao_cmd(), the channels for the command are transfered from the
cmd->chanlist and stored in the private data 'ao_chanlist'. The channel
numbers are bit-shifted when stored so that they become the "command"
that is transfered to the device. The channel to command conversion
results in the 'ao_chanlist' having these values for the channels:
channel 0 -> ao_chanlist = 0x00
channel 1 -> ao_chanlist = 0x40
channel 2 -> ao_chanlist = 0x80
channel 3 -> ao_chanlist = 0xc0
The problem is, the usbduxsub_ao_isoc_irq() function uses the 'chan' value
from 'ao_chanlist' to access the 'ao_readback' array in the private data.
So instead of accessing the array as 0, 1, 2, 3, it accesses it as 0x00,
0x40, 0x80, 0xc0.
Fix this by storing the raw channel number in 'ao_chanlist' and doing the
bit-shift when creating the command.
Fixes: a998a3db53 "staging: comedi: usbdux: cleanup the private data 'outBuffer'"
Cc: stable <stable@vger.kernel.org> # 3.12
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Acked-by: Bernd Porr <mail@berndporr.me.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The goal of this patch is to fix rtnelink notification. The main problem was
about notification for fdb entry with more than one remote. Before the patch,
when a remote was added to an existing fdb entry, the kernel advertised the
first remote instead of the added one. Also when a remote was removed from a fdb
entry with several remotes, the deleted remote was not advertised.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In ksz9021_load_values_from_of() val2 to val4 aren't tested against their
initialization value.
This causes the test to always succeed, and this value to be used as if it
was loaded from the devicetree instead of being ignored, in case of a
missing/invalid property in the ethernet OF device node.
As a result, the value "0" is written to the relevant registers.
Change the conditions to test against the right initialization value.
Signed-off-by: Hubert Chaumette <hchaumette@adeneo-embedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull input updates from Dmitry Torokhov:
"The main change is that we now publish "firmware ID" for the serio
devices to help userspace figure out the kind of touchpads it is
dealing with: i8042 will export PS/2 port's PNP IDs as firmware IDs.
You will also get more quirks for Synaptics touchpads in various
Lenovo laptops, a change to elantech driver to recognize even more
models, and fixups to wacom and couple other drivers"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: elantech - add support for newer elantech touchpads
Input: soc_button_array - fix a crash during rmmod
Input: synaptics - add min/max quirk for ThinkPad T431s, L440, L540, S1 Yoga and X1
Input: synaptics - report INPUT_PROP_TOPBUTTONPAD property
Input: Add INPUT_PROP_TOPBUTTONPAD device property
Input: i8042 - add firmware_id support
Input: serio - add firmware_id sysfs attribute
Input: wacom - handle 1024 pressure levels in wacom_tpc_pen
Input: wacom - references to 'wacom->data' should use 'unsigned char*'
Input: wacom - override 'pressure_max' with value from HID_USAGE_PRESSURE
Input: wacom - use full 32-bit HID Usage value in switch statement
Input: wacom - missed the last bit of expresskey for DTU-1031
Input: ads7846 - fix device usage within attribute show
Input: da9055_onkey - remove use of regmap_irq_get_virq()
There is a missing 0 entry from the MOD_SEL3 table.
Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The extra entry in the table makes SCIFA0_B, and all
peripherals after it, fail.
Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Since we set up device wake-up interrupts as pinctrl-single
interrupts, we now must use the standard request_irq and
related functions to manage them.
If the pin interrupts are enabled for some pins at boot,
the wake-up events can show up as constantly pending
at least on omaps and will hang the system unless the related
device driver clears the event at the device.
To fix this, let's clear the interrupt flags during init,
and print out a warning so the board maintainers can update
their drivers to do proper request_irq for the driver specific
wake-up events.
Cc: Haojian Zhuang <haojian.zhuang@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
s/interrupts-names/interrupt-names/g
s/clocks-names/clock-names/g
Some of the binding files and device tree files get this wrong and the
kernel won't be able to pick it up. Fix them up now so that they don't
get widely used.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by : Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
If I unplug the eDP monitor, the BIOS of my machine will enable the
VDD bit, then when the driver loads it will think VDD is enabled. It
will detect that the eDP is not enabled and return false from
intel_edp_init_connector. This will trigger a call to
edp_panel_vdd_off_sync(), which trigger a WARN saying that the
refcount of the power domain is less than zero.
The problem happens because the driver gets a refcount whenever it
enables the VDD bit, and puts the refcount whenever it disables the
VDD bit. But on this case, the BIOS enabled VDD, so all we do is to
call put() without calling get() first, so the code added is there to
make sure we always have the get() in case the BIOS enabled the bit.
This regression was introduced in
commit e9cb81a228
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Thu Nov 21 13:47:23 2013 -0200
drm/i915: get a runtime PM reference when the panel VDD is on
v2: - Rebase
Tested-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org (v3.13+)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
... our current modeset code isn't good enough yet to handle this. The
scenario is:
1. BIOS sets up a cloned config with lvds+external screen on the same
pipe, e.g. pipe B.
2. We read out that state for pipe B and assign the gmch_pfit state to
it.
3. The initial modeset switches the lvds to pipe A but due to lack of
atomic modeset we don't recompute the config of pipe B.
-> both pipes now claim (in the sw pipe config structure) to use the
gmch_pfit, which just won't work.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74081
Tested-by: max <manikulin@gmail.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Newer elantech touchpads are not recognized by the current driver, since it
fails to detect their firmware version number. This prevents more advanced
touchpad features from being usable such as two-finger scrolling. This
patch allows newer touchpads to be detected and be fully functional. Tested
on Sony Vaio SVF13N17PXB.
Signed-off-by: Jordan Rife <jrife0@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
When the system has zero or one button available, trying to rmmod
soc_button_array will cause crash. Fix this by properly handling -ENODEV
in probe().
Signed-off-by: Lejun Zhu <lejun.zhu@linux.intel.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
* Fix the platform data support for the at91 adc driver.
* A couple of related follow up patches get the support working again
for at91sam9260 and at91sam9g45 as the earlier patch results in a device
name change.
* A default timer value in the at91 adc driver was bonkers. Make it sane.
* Fix incorrect reporting of the integration time for the cm32181 light sensor
* Fix a missing break in the ad2s1200 driver which would have give a false
error return.
* Make sure buffer scan mask queries from userspace return 0/1 rather than
a fairly random value depending on their implementation of test_bit
* Fix leak of the i2c client and a null pointer dereference in the cm36651
driver.
* Fix a build warning on avr32 for the mxs-lradc (not exactly a critical
combination - but the issue was real).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJTSX1HAAoJEFSFNJnE9BaIGkoQAIotGana51TXPo9KYnQJaCYH
+xBfaaXEaR69lARoXT8SDGzyXPCQNOEbVfsXRwrVQ4Wl8x2hP8n9YdUrAHzZ/8O/
Wf8Z0jb81Q+KNJ+SMMgcy4kK5OU71EMMk5fbocPzD+WfQ+WlDr+My1F3yZ5UIvOM
nOUF6QCcYA0MN7dopEVIqyP8HZhrxR1YUvgzqOmp1fteYL4gFCU006WPSI30GxEv
fMM8MiWbbn9xjOsR7SBzaLEo0Hv3YC92zwSAuJxGClH/+9cKogWAaE/PiNUO3y6A
+2D0KQnGRopKy4j/QCjdPZsTmYDBxQ9vMlUOtRlOf1XAVjL6pZu2EJ2/ereShLW6
B4rev23tqgk9nyNk/Li4n+5krzvPqqOcbWNW1la769DkEt7LU+YU+hiShkDm1+0M
6hwxPd6gQxg0QUjuusi1+B5JqweAv+mEcCsQ+ga6ZK61X9bNJ6c/4YF451rkNhc6
mlC3ZqBvDALmNSVdCas0GOGHLaeWxfoT7E9G6p62h9uBVerqZ6epvlAUC6JOHotc
/qz/D1VL1+ptPAawXiFSNOb8RMJogdBfjPB9bOlYQSSHV3eF0RVNK6FQiqvc4mFX
or1pPG6lDLGm6g3NcDEjxEEVThevQpEwKmpM0TCEUMiIuxSHYN/M//P2PSeDvYwk
9k8x3fJae7dWNsGIT92y
=HMr3
-----END PGP SIGNATURE-----
Merge tag 'iio-fixes-for-3.15a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
First found of IIO fixes for the 3.15 cycle.
* Fix the platform data support for the at91 adc driver.
* A couple of related follow up patches get the support working again
for at91sam9260 and at91sam9g45 as the earlier patch results in a device
name change.
* A default timer value in the at91 adc driver was bonkers. Make it sane.
* Fix incorrect reporting of the integration time for the cm32181 light sensor
* Fix a missing break in the ad2s1200 driver which would have give a false
error return.
* Make sure buffer scan mask queries from userspace return 0/1 rather than
a fairly random value depending on their implementation of test_bit
* Fix leak of the i2c client and a null pointer dereference in the cm36651
driver.
* Fix a build warning on avr32 for the mxs-lradc (not exactly a critical
combination - but the issue was real).
A label just before a brace needs a following semicolon (empty statement).
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
When SMC_DEBUG >= 2, we hit the following compilation error:
drivers/net/ethernet/smsc/smc91x.c:85:0:
drivers/net/ethernet/smsc/smc91x.c: In function ‘smc_findirq’:
drivers/net/ethernet/smsc/smc91x.c:1784:9: error: ‘dev’ undeclared (first use in this function)
DBG(2, dev, "%s: %s\n", CARDNAME, __func__);
^
Fix it by passing in the appropriate netdev pointer.
Signed-off-by: Zi Shen Lim <zlim.lnx@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
1. Further PLL parameter fixes.
2. Fixes for HPD on DP
3. Could of different PM fixes
4. Disabling DPM on RV770
* 'drm-fixes-3.15' of git://people.freedesktop.org/~deathsimple/linux:
drm/radeon: don't allow runpm=1 on systems with out ATPX
drm/radeon: fix ATPX detection on non-VGA GPUs
drm/radeon/pm: don't walk the crtc list before it has been initialized (v2)
drm/radeon: properly unregister hwmon interface (v2)
drm/radeon: fix count in cik_sdma_ring_test()
drm/radeon/aux: fix hpd assignment for aux bus
drm/radeon: improve PLL limit handling in post div calculation
drm/radeon: use fixed PPL ref divider if needed
drm/radeon: disable dpm on rv770 by default
This patch adds phy_found error path when there is no phy device
and changes bus_name.
Signed-off-by: Byungho An <bh74.an@samsung.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch moves cksum_ctl to tx_rd_des23 from cksum_pktlen for correct checksum
offloading and modifies size for Tx/Rx descriptor.
Signed-off-by: Byungho An <bh74.an@samsung.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Execute "ethtool -L eth0 combined 0" in guest, if multiqueue
is enabled, virtnet_send_command() will return -EINVAL error,
there is a validation in QEMU.
But if multiqueue is disabled, virtnet_set_queues() will just
return zero (success). We should return error for this situation.
Signed-off-by: Amos Kong <akong@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The MAC address retrieved from dt was not actually written to the
hardware. This meant proper communication was only possible after
changing the MAC address.
Fix that by always writing the mac address during probing.
Signed-off-by: Max Schwarz <max.schwarz@online.de>
Acked-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Implement a recv budget so that in cases of high traffic we still allow other
taskets to get processed.
Without this, we can encounter a host of issues during high wireless traffic
reception depending on system load including rcu stall's detected (ARM),
soft lockups, failure to service critical tasks such as watchdog resets,
and triggering of the tx stuck tasklet.
The same thing was proposed previously by Ben:
http://www.spinics.net/lists/linux-wireless/msg112891.html
The only difference here is that I make sure only processed packets are counted
in the budget by checking at the end of the rx loop.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Acked-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
If a flush is requested, make sure to clear the descriptor once we've
processed it.
This resolves a hang that will occur if all RX descriptors are full when a
flush is requested.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Acked-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
static code analysis from cppcheck reports:
[drivers/net/wireless/rtlwifi/rtl8188ee/trx.c:322]:
(error) Uninitialized variable: packet_beacon
packet_beacon is not initialized and hence packet_beacon
contains garbage from the stack, so set it to false.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Cc: Stable <stable@vger.kernel.org> [3.10+]
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When disable beaconing we clear register with beacon and newer set it
back, what make we stop send beacons infinitely.
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
- Change a crucial semantic ordering in the GPIO irqchip
helpers.
- Fix two nasty regressions in the ACPI gpiolib extensions.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTUQ+6AAoJEEEQszewGV1zue0P/iXpOgzTffwqS67ZtRCjHk2C
nQ5plRWLgPXJndMuuGKu38kf1HkwKbdTUAZ+tqtVe/m1kGPcv+V5XkMiPCB+nzYw
eOyMTJCPLVv485BmSlKdHLrZW8wLvq03Hs+EsKJ90YxHUYFhJNnqUkuiHqidL+eg
b/Z8Nzq2x4VSji0n4vzJKdhiSwJt4uTo9hzkC+UHylL7mM3x5/+pfRPRpbToEBCH
zitDXgcCyXLCucHeEc10e7uHXwYxdiLC8WwxK+ztnEFCK0EWWRdlSg+C0PJEnnD9
4/kEZXn69dDTSpOxgNKjGm8NLrA5FOzN7YqMuznz88RWNvtTmd3NKm7tYTlS1T4D
8BO9TJkyY8bis49Q6pwgr5J9MNdEBZimUZUjHzJYdekKxY1WBT7xPKM7CvtH2d/3
gq0qBd8HGG5fmxs6cKxgOehyOnBBMVpxTSiQmNQxPqIcz4jrtnIqVTj3zkxcb7Kf
MttAGKNf2MqIFZmRXg3TXu+KhNZsQD8oL61xNknog3TosWoLC5yQTF7HCCU+8hIz
EdOmaMoAV+K8v7mY0/KWJiKros6RNHhRUdXK/jGpNl2U5yy+Rfp9SU7jzwmv8J+O
khDKGOb2KHbc9ydzW9Ut/65Ys6oMkIbiTnwZqsdTZ/Pv2nYDOyP9L1M6ng0k1tNj
lZ34WI4WAafxZwglhLdy
=Tc0Z
-----END PGP SIGNATURE-----
Merge tag 'gpio-v3.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull gpio fixes from Linus Walleij:
"A small batch of GPIO fixes for the v3.15 series. I expect more to
come in but I'm a bit behind on mail, might as well get these to you
right now:
- Change a crucial semantic ordering in the GPIO irqchip helpers
- Fix two nasty regressions in the ACPI gpiolib extensions"
* tag 'gpio-v3.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio / ACPI: Prevent potential wrap of GPIO value on OpRegion read
gpio / ACPI: Don't crash on NULL chip->dev
gpio: set data first, then chip and handler
The AS3722_GPIO_INV bit will always be blindly overwritten by
as3722_pinctrl_gpio_set_direction() and will be ignored when
setting the value of the GPIO in as3722_gpio_set() since the
enable_gpio_invert flag is never set. This will cause an
initially inverted GPIO to toggle when requested as an output,
which could be problematic if, for example, the GPIO controls
a critical regulator.
Instead of setting up the enable_gpio_invert flag, just leave
the invert bit alone and check it before setting the GPIO value.
Cc: <stable@vger.kernel.org> # v3.14+
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Some newer PX laptops have the pci device class
set to DISPLAY_OTHER rather than DISPLAY_VGA. This
properly detects ATPX on those laptops.
Based on a patch from: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Cc: airlied@gmail.com
Avoids a crash in certain cases when thermal irqs are generated
before the display structures have been initialized.
v2: fix the vblank and vrefresh helpers as well
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=73931
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
In the TB10x pin database, a port index of -1 is used to indicate
unmuxed GPIO pin groups. This bug fixes a 'cast to unsigned' bug of
this value.
Thanks to Dan Carpenter for highlighting this.
CC: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Christian Ruppert <christian.ruppert@abilis.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Should be 5 rather than 4.
Noticed-by: Mathias Fröhlich <Mathias.Froehlich@gmx.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Christian König <christian.koenig@amd.com>
In commit
commit 6375b768a9
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Mon Mar 3 11:33:36 2014 +0200
drm/i915: Reject >165MHz modes w/ DVI monitors
the driver started to filter out display modes which exceed the
single-link DVI 165Mz dotclock limits when the monitor doesn't report
itself as being HDMI compliant. The intent was to filter out all
EDID derived modes that require dual-link DVI to operate since we
don't support dual-link.
However the patch went a bit too far and also causes the driver to reject
such modes even when specified by the user. Normally we don't check the
sink limitations when setting a mode from the user. This allows the user
to specify any mode whether the sink reports to support it or not. This
can be useful since often the sinks support more modes than they report
in the EDID.
So relax the checks a bit, and apply the single-link DVI dotclock limit
only when filtering the mode list, and ignore the limit when setting
a user specified mode.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=72961
Tested-by: Nicholas Vinson <nvinson@comcast.net>
Cc: stable@vger.kernel.org [3.14]
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The hpd (hot plug detect) pin assignment got lost
in the conversion to to the common i2c over aux
code. Without this information, aux transactions
do not work properly. Fixes DP failures.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
* pm-sleep:
PM / suspend: Make cpuidle work in the "freeze" state
* pm-cpuidle:
intel_idle: fix IVT idle state table setting
* pm-cpufreq:
cpufreq: highbank: fix ARM_HIGHBANK_CPUFREQ dependency warning
cpufreq: ppc: Fix integer overflow in expression
cpufreq, powernv: Fix build failure on UP
cpufreq: unicore32: replace IS_ERR and PTR_ERR with PTR_ERR_OR_ZERO
When make ARCH=arm multi_v7_defconfig, we get the following warnings:
warning: (ARM_HIGHBANK_CPUFREQ) selects GENERIC_CPUFREQ_CPU0 which has
unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && HAVE_CLK
&& REGULATOR && OF && THERMAL && CPU_THERMAL)
To fix this, make ARM_HIGHBANK_CPUFREQ depend on ARCH_HAS_CPUFREQ and
REGULATOR instead of selecting them, PM_OPP will be selected by ARCH_HAS_CPUFREQ.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
On 32-bit, "12 * NSEC_PER_SEC" doesn't fit in "unsigned long"
(NSEC_PER_SEC is a "long" constant), causing an integer overflow:
drivers/cpufreq/ppc-corenet-cpufreq.c: In function 'corenet_cpufreq_cpu_init':
drivers/cpufreq/ppc-corenet-cpufreq.c:211:9: warning: integer overflow in expression [-Woverflow]
Force the intermediate to be 64-bit by adding an "ULL" suffix to the
constant multiplier to fix this.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Paul Gortmaker reported the following build failure of the powernv cpufreq
driver on UP configs:
drivers/cpufreq/powernv-cpufreq.c:241:2: error: implicit declaration of
function 'cpu_sibling_mask' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[3]: *** [drivers/cpufreq/powernv-cpufreq.o] Error 1
make[2]: *** [drivers/cpufreq] Error 2
make[1]: *** [drivers] Error 2
make: *** [sub-make] Error 2
The trouble here is that cpu_sibling_mask is defined only in <asm/smp.h>,
and <linux/smp.h> includes <asm/smp.h> only in SMP builds.
So fix this build failure by explicitly including <asm/smp.h> in the driver,
so that we get the definition of cpu_sibling_mask even in UP configurations.
Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch fixes coccinelle error regarding usage of IS_ERR and
PTR_ERR instead of PTR_ERR_OR_ZERO.
Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Ivy Town idle state table will not be set as intended. Fix it.
Picked up by Coverity - CID 1201420/1201421.
Fixes: 0138d8f075 ("intel_idle: fine-tune IVT residency targets")
Signed-off-by: Christoph Jaeger <christophjaeger@linux.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
This patch fixes a corner case in the previous USB Deadlock fix patch (12023e7
[SCSI] Fix USB deadlock caused by SCSI error handling).
The scenario is abort command, set flag, abort completes, send TUR, TUR
doesn't return, so we now try to abort the TUR, but scsi_abort_eh_cmnd()
will skip the abort because the flag is set and move straight to reset.
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
USB requires that every command be aborted first before we escalate to reset.
In particular, USB will deadlock if we try to reset first before aborting the
command.
Unfortunately, the flag we use to tell if a command has already been aborted:
SCSI_EH_ABORT_SCHEDULED is not cleared properly leading to cases where we can
requeue a command with the flag set and proceed immediately to reset if it
fails (thus causing USB to deadlock).
Fix by clearing the SCSI_EH_ABORT_SCHEDULED flag if it has been set. Which
means this will be the second time scsi_abort_command() has been called for
the same command. IE the first abort went out, did its thing, but now the
same command has timed out again.
So this flag gets cleared, and scsi_abort_command() returns FAILED, and _no_
asynchronous abort is being scheduled. scsi_times_out() will then proceed to
call scsi_eh_scmd_add(). But as we've cleared the SCSI_EH_ABORT_SCHEDULED
flag the SCSI_EH_CANCEL_CMD flag will continue to be set, and the command will
be aborted with the main SCSI EH routine.
Reported-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Andreas Reis <andreas.reis@gmail.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
We're seeing a case where the contents of scmd->result isn't being reset after
a SCSI command encounters an error, is resubmitted, times out and then gets
handled. The error handler acts on the stale result of the previous error
instead of the timeout. Fix this by properly zeroing the scmd->status before
the command is resubmitted.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
We unconditionally execute scsi_eh_get_sense() to make sure all failed
commands that should have sense attached, do. However, the routine forgets
that some commands, because of the way they fail, will not have any sense code
... we should not bother them with a REQUEST_SENSE command. Fix this by
testing to see if we actually got a CHECK_CONDITION return and skip asking for
sense if we don't.
Tested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
The size of the buffer allocated for generic_serial_bus region access
is not correct. This patch introduces acpi_ex_get_serial_access_length()
to be invoked to obtain correct data buffer length.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reported by: Lan Tianyu <tianyu.lan@intel.com>
Acked-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Jeff Kirsher says:
====================
Intel Wired LAN Driver Updates
This series contains updates to e1000e, igb, ixgbe and i40e.
Most notably are Jakub's patches to clean up the Rx time stamping
code for ixgbe and the fix up of debug messages with proper termination.
Jesse's i40e patch fixes an issue reported by Eric Dumazet that the
i40e driver was allowing the hardware to replicate the PSH flag on
all segments of a TSO operation. With this fix, we are now configuring
the CWR bit to only be set in the first packet of a TSO and we
enable TSO_ECN in order to advertise to the stack that we do the right
thing on the wire.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Tests have shown that when a power-up transition is followed by other
PHY operations too quickly, the USB port appears dead. Waiting 1ms fixes
this problem.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Cc: stable@vger.kernel.org [3.14]
Signed-off-by: Felipe Balbi <balbi@ti.com>
This patch reduce unecessary NETTX softirq call caused by
free skb header. You will see this softirq comes twice while
there is only one TX packet to be transmitted.
So using dev_kfree_skb() instead of dev_kfree_skb_any() to
avoid this problem.
Cc: David S. Miller <davem@davemloft.net>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Macpaul Lin <macpaul@gmail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Patch
commit 0479633686
Author: Christoph Hellwig <hch@infradead.org>
Date: Thu Feb 20 14:20:55 2014 -0800
[SCSI] do not manipulate device reference counts in scsi_get/put_command
Introduced a use after free:I in the kill case of scsi_prep_return we have to
release our device reference, but we do this trying to reference the just
freed command. Use the local sdev pointer instead.
Fixes: 0479633686
Reported-by: Joe Lawrence <joe.lawrence@stratus.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Patch
commit 0479633686
Author: Christoph Hellwig <hch@infradead.org>
Date: Thu Feb 20 14:20:55 2014 -0800
[SCSI] do not manipulate device reference counts in scsi_get/put_command
Introduced a use after free: when scsi_init_io fails we have to release our
device reference, but we do this trying to reference the just freed command.
Add a local scsi_device pointer to fix this.
Fixes: 0479633686
Reported-by: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Initialize local variable trans_support before it is used rather
than after. It is supposed to contain the value of a register on the
controller containing bits that describe which transport modes the
controller supports (e.g. "performant", "ioaccel1", "ioaccel2"). A
NULL pointer dereference will almost certainly occur if trans_support
is not initialized at the right point. If for example the uninitialized
trans_support value does not have the bit set for ioaccel2 support when it
should be, then ioaccel2_alloc_cmds_and_bft() will not get called as it
should be and the h->ioaccel2_blockFetchTable array will remain NULL
instead of being allocated. Too late, trans_support finally gets
initialized with the correct value with ioaccel2 mode bit set,
which later causes calc_bucket_map() to be called to fill in
h->ioaccel2_blockFetchTable[]. However h->ioaccel2_blockFetchTable
is NULL because it didn't get allocated because earlier trans_support
wasn't initialized at the right point.
Fixes: e1f7de0cdd
Signed-off-by: Stephen M. Cameron <scameron@beardog.cce.hp.com>
Reported-by: Baoquan He <bhe@redhat.com>
Tested-by: Baoquan He <bhe@redhat.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Until now, we were leaving the ->check_device() msi_chip operation
empty, which leads the PCI core to believe that we support both MSI
and MSI-X. In fact, we do not support MSI-X, so we have to tell this
to the PCI core by providing an implementation of this operation.
Fixes: 31f614edb7 ('irqchip: armada-370-xp: implement MSI support')
Cc: <stable@vger.kernel.org> # v3.13+
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397823593-1932-3-git-send-email-thomas.petazzoni@free-electrons.com
Tested-by: Neil Greatorex <neil@fatboyfat.co.uk>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
The armada_370_xp_alloc_msi() function returns a signed int, which is
negative on error. However, we store the return value into an
irq_hw_number_t, which is unsigned. Therefore, we actually never test
if armada_370_xp_alloc_msi() returns an error or not, which may lead
us to use hwirq numbers of as 0xffffffe4 (when
armada_370_xp_alloc_msi() returns -ENOSPC).
This commit fixes that by storing the return value of
armada_370_xp_alloc_msi() in a signed variable.
Fixes: 31f614edb7 ('irqchip: armada-370-xp: implement MSI support')
Cc: <stable@vger.kernel.org> # v3.13+
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397823593-1932-2-git-send-email-thomas.petazzoni@free-electrons.com
Tested-by: Neil Greatorex <neil@fatboyfat.co.uk>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Pull slave-dmaengine fixes from Vinod Koul:
"Back from long weekend here in India and now the time to send fixes
for slave dmaengine.
- Dan's fix of sirf xlate code
- Jean's fix for timberland
- edma fixes by Sekhar for SG handling and Yuan for changing init
call"
* 'fixes' of git://git.infradead.org/users/vkoul/slave-dma:
dma: fix eDMA driver as a subsys_initcall
dmaengine: sirf: off by one in of_dma_sirfsoc_xlate()
platform: Fix timberdale dependencies
dma: edma: fix incorrect SG list handling
We expect that all the Haswell series will need such quirks, sigh.
The T431s seems to be T430 hardware in a T440s case, using the T440s touchpad,
with the same min/max issue.
The X1 Carbon 3rd generation name says 2nd while it is a 3rd generation.
The X1 and T431s share a PnPID with the T540p, but the reported ranges are
closer to those of the T440s.
HdG: Squashed 5 quirk patches into one. T431s + L440 + L540 are written by me,
S1 Yoga and X1 are written by Benjamin Tissoires.
Hdg: Standardized S1 Yoga and X1 values, Yoga uses the same touchpad as the
X240, X1 uses the same touchpad as the T440.
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Check PNP ID of the PS/2 AUX port and report INPUT_PROP_TOPBUTTONPAD
property for for touchpads with top button areas.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Fill in the new serio firmware_id sysfs attribute for pnp instantiated
8042 serio ports.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
serio devices exposed via platform firmware interfaces such as ACPI may
provide additional identifying information of use to userspace.
We don't associate the serio devices with the firmware device (we don't
set it as parent), so there's no way for userspace to make use of this
information.
We cannot change the parent for serio devices instantiated though a
firmware interface as that would break suspend / resume ordering.
Therefore this patch adds a new firmware_id sysfs attribute so that
userspace can get a string from there with any additional identifying
information the firmware interface may provide.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Some tablet PC sensors (e.g. the 0xEC found in the Thinkpad Yoga) report
more than 256 pressure levels and will experience wraparound unless the
full range is read.
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
Tested-by: Aaron Skomra <Aaron.Skomra@wacom.com>
Reviewed-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
'wacom->data' contains raw binary data and can lead to unexpected behavior
if a byte under examination happens to have its MSB set.
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
Tested-by: Aaron Skomra <Aaron.Skomra@wacom.com>
Reviewed-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The 0xEC sensor is used in multiple tablet PCs and curiously has versions
that report 256 levels of pressure (Samsung Slate 7) as well as versions
that report 1024 levels (Lenovo Thinkpad Yoga). To allow both versions to
work properly, we allow the value of HID_USAGE_PRESSURE reported to
override pressure_max.
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
Tested-by: Aaron Skomra <Aaron.Skomra@wacom.com>
Reviewed-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
A HID Usage is a 32-bit value: an upper 16-bit "page" and a lower 16-bit
ID. While the two halves are normally reported seperately, only the
combination uniquely idenfifes a particular HID Usage.
The existing code performs the comparison in two steps, first performing a
switch on the ID and then verifying the page within each case. While this
works fine, it is very akward to handle two Usages that share a single ID,
such as HID_USAGE_PRESSURE and HID_USAGE_X because the case statement can
only have a single identifier.
To work around this, we now check the full 32-bit HID Usage directly rather
than first checking the ID and then the page. This allows the switch
statement to have distinct cases for e.g. HID_USAGE_PRESSURE and
HID_USAGE_X.
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
Tested-by: Aaron Skomra <Aaron.Skomra@wacom.com>
Reviewed-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
With commit e585c40ba (Input: ads7846 - convert to
hwmon_device_register_with_groups()) the device passed to the attribute's
show function isn't the spi device as before.
So fixup the passed device to ads7846_read12_ser.
Signed-off-by: Alexander Stein <alexanders83@web.de>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Using platform_get_irq_byname() to retrieve the IRQ number returns the
VIRQ number rather than the local IRQ number for the device. Passing that
value then into regmap_irq_get_virq() causes a failure because the
function is expecting the local IRQ number (e.g. 0, 1, 2, 3, etc).
This patch removes use of regmap_irq_get_virq() to prevent this failure
from happening.
Signed-off-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Pull drm fixes from Dave Airlie:
"Unfortunately this contains no easter eggs, its a bit larger than I'd
like, but I included a patch that just moves code from one file to
another and I'd like to avoid merge conflicts with that later, so it
makes it seem worse than it is,
Otherwise:
- radeon: fixes to use new microcode to stabilise some cards, use
some common displayport code, some runtime pm fixes, pll regression
fixes
- i915: fix for some context oopses, a warn in a used path, backlight
fixes
- nouveau: regression fix
- omap: a bunch of fixes"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (51 commits)
drm: bochs: drop unused struct fields
drm: bochs: add power management support
drm: cirrus: add power management support
drm: Split out drm_probe_helper.c from drm_crtc_helper.c
drm/plane-helper: Don't fake-implement primary plane disabling
drm/ast: fix value check in cbr_scan2
drm/nouveau/bios: fix a bit shift error introduced by 457e77b
drm/radeon/ci: make sure mc ucode is loaded before checking the size
drm/radeon/si: make sure mc ucode is loaded before checking the size
drm/radeon: improve PLL params if we don't match exactly v2
drm/radeon: memory leak on bo reservation failure. v2
drm/radeon: fix VCE fence command
drm/radeon: re-enable mclk dpm on R7 260X asics
drm/radeon: add support for newer mc ucode on CI (v2)
drm/radeon: add support for newer mc ucode on SI (v2)
drm/radeon: apply more strict limits for PLL params v2
drm/radeon: update CI DPM powertune settings
drm/radeon: fix runpm handling on APUs (v4)
drm/radeon: disable mclk dpm on R7 260X
drm/tegra: Remove gratuitous pad field
...
Add \n at the end of messages where missing, remove all \r.
Reported-by: Joe Perches <joe@perches.com>
Signed-off-by: Jakub Kicinski <kubakici@wp.pl>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Tested-by: Kavindya Deegala <kavindya.s.deegala@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Time stamping resources are per-interface so there is no need
to keep separate last_rx_timestamp for each Rx ring, move
last_rx_timestamp to the adapter structure.
With last_rx_timestamp inside adapter, ixgbe_ptp_rx_hwtstamp()
inline function is reduced to a single if statement so it is
no longer necessary. If statement is placed directly in
ixgbe_process_skb_fields() fixing likely/unlikely marking.
Checks for q_vector or adapter to be NULL are superfluous.
Comment about taking I/O hit is a leftover from previous design.
Signed-off-by: Jakub Kicinski <kubakici@wp.pl>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
RQDPC on i210/i211 is R/W not ReadClear. Clear after reading.
Signed-off-by: Todd Fujinaka <todd.fujinaka@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Some i2c fixes over DisplayPort.
* 'drm-next-3.15-wip' of git://people.freedesktop.org/~deathsimple/linux:
drm/radeon: Improve vramlimit module param documentation
drm/radeon: fix audio pin counts for DCE6+ (v2)
drm/radeon/dp: switch to the common i2c over aux code
drm/dp/i2c: Update comments about common i2c over dp assumptions (v3)
drm/dp/i2c: send bare addresses to properly reset i2c connections (v4)
drm/radeon/dp: handle zero sized i2c over aux transactions (v2)
drm/i915: support address only i2c-over-aux transactions
drm/tegra: dp: Support address-only I2C-over-AUX transactions
Fix following compilation warning:
drivers/net/ethernet/intel/e1000e/netdev.c:6238:12: warning
‘e1000e_pm_thaw’ defined but not used [-Wunused-function]
static int e1000e_pm_thaw(struct device *dev)
^
Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
When changing the interface mtu, the driver starts with a value
that doesn't include VLAN_HLEN. Later tests in the driver
set the rx_buffer_len based on the mtu. As a result, when
the user increases the mtu to 1504 (to support 802.1AD for example),
the driver rx_buffer_len does not change and frames longer
the 1522 bytes are rejected as too long.
Include VLAN_HLEN from the start so that an user mtu greater then
1500 bytes is correctly reflected in the driver rx_buffer_len.
CC: e1000-devel@lists.sourceforge.net
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Pull more networking fixes from David Miller:
1) Fix mlx4_en_netpoll implementation, it needs to schedule a NAPI
context, not synchronize it. From Chris Mason.
2) Ipv4 flow input interface should never be zero, it should be
LOOPBACK_IFINDEX instead. From Cong Wang and Julian Anastasov.
3) Properly configure MAC to PHY connection in mvneta devices, from
Thomas Petazzoni.
4) sys_recv should use SYSCALL_DEFINE. From Jan Glauber.
5) Tunnel driver ioctls do not use the correct namespace, fix from
Nicolas Dichtel.
6) Fix memory leak on seccomp filter attach, from Kees Cook.
7) Fix lockdep warning for nested vlans, from Ding Tianhong.
8) Crashes can happen in SCTP due to how the auth_enable value is
managed, fix from Vlad Yasevich.
9) Wireless fixes from John W Linville and co.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (45 commits)
net: sctp: cache auth_enable per endpoint
tg3: update rx_jumbo_pending ring param only when jumbo frames are enabled
vlan: Fix lockdep warning when vlan dev handle notification
seccomp: fix memory leak on filter attach
isdn: icn: buffer overflow in icn_command()
ip6_tunnel: use the right netns in ioctl handler
sit: use the right netns in ioctl handler
ip_tunnel: use the right netns in ioctl handler
net: use SYSCALL_DEFINEx for sys_recv
net: mdio-gpio: Add support for separate MDI and MDO gpio pins
net: mdio-gpio: Add support for active low gpio pins
net: mdio-gpio: Use devm_ functions where possible
ipv4, route: pass 0 instead of LOOPBACK_IFINDEX to fib_validate_source()
ipv4, fib: pass LOOPBACK_IFINDEX instead of 0 to flowi4_iif
mlx4_en: don't use napi_synchronize inside mlx4_en_netpoll
net: mvneta: properly configure the MAC <-> PHY connection in all situations
net: phy: add minimal support for QSGMII PHY
sfc:On MCDI timeout, issue an FLR (and mark MCDI to fail-fast)
mwifiex: fix hung task on command timeout
mwifiex: process event before command response
...
As reported by Eric Dumazet, the i40e driver was allowing the hardware
to replicate the PSH flag on all segments of a TSO operation.
This patch fixes the first/middle/last TCP flags settings which
makes the TSO operations work correctly.
With this change we are now configuring the CWR bit to only be set
in the first packet of a TSO, so this patch also enables TSO_ECN,
in order to advertise to the stack that we do the right thing
on the wire.
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Kavindya Deegala <kavindya.s.deegala@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Here are a few driver fixes for char/misc drivers that resolve reported
issues.
All have been in linux-next successfully for a few days.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEABECAAYFAlNRlx4ACgkQMUfUDdst+ylYCgCdHm8SDiXwRfhUQJcYYlXrI1xs
skwAn3p1ydnIyVZJ/B3uxTA/0/1Jof5Z
=no/7
-----END PGP SIGNATURE-----
Merge tag 'char-misc-3.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver fixes from Greg KH:
"Here are a few driver fixes for char/misc drivers that resolve
reported issues.
All have been in linux-next successfully for a few days"
* tag 'char-misc-3.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
Drivers: hv: vmbus: Negotiate version 3.0 when running on ws2012r2 hosts
Tools: hv: Handle the case when the target file exists correctly
vme_tsi148: Utilize to_pci_dev() macro
vme_tsi148: Fix PCI address mapping assumption
vme_tsi148: Fix typo in tsi148_slave_get()
w1: avoid recursive device_add
w1: fix netlink refcnt leak on error path
misc: Grammar s/addition/additional/
drivers: mcb: fix memory leak in chameleon_parse_cells() error path
mei: ignore client writing state during cb completion
mei: me: do not load the driver if the FW doesn't support MEI interface
GenWQE: Increase driver version number
GenWQE: Fix multithreading problems
GenWQE: Ensure rc is not returning an uninitialized value
GenWQE: Add wmb before DDCB is started
GenWQE: Enable access to VPD flash area
Here are some driver core fixes for 3.15-rc2. Also in here are some
documentation updates, as well as an API removal that had to wait for
after -rc1 due to the cleanups coming into you from multiple developer
trees (this one and the PPC tree.)
All have been in linux next successfully.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEABECAAYFAlNRl6cACgkQMUfUDdst+yllxACfV9fZ/A6IQja60AdPEo+oa6Cw
RiIAoJtH0D0G0eC4+/Qs9GSRMoB4jPPC
=Wi3a
-----END PGP SIGNATURE-----
Merge tag 'driver-core-3.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core fixes from Greg KH:
"Here are some driver core fixes for 3.15-rc2. Also in here are some
documentation updates, as well as an API removal that had to wait for
after -rc1 due to the cleanups coming into you from multiple developer
trees (this one and the PPC tree.)
All have been in linux next successfully"
* tag 'driver-core-3.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
drivers/base/dd.c incorrect pr_debug() parameters
Documentation: Update stable address in Chinese and Japanese translations
topology: Fix compilation warning when not in SMP
Chinese: add translation of io_ordering.txt
stable_kernel_rules: spelling/word usage
sysfs, driver-core: remove unused {sysfs|device}_schedule_callback_owner()
kernfs: protect lazy kernfs_iattrs allocation with mutex
fs: Don't return 0 from get_anon_bdev
Here are a few staging driver fixes for issues that have been reported
for 3.15-rc2.
Also dominating the diffstat for the pull request is the removal of the
rtl8187se driver. It's no longer needed in staging as a "real" driver
for this hardware is now merged in the tree in the "correct" location in
drivers/net/
All of these patches have been tested in linux-next.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEABECAAYFAlNRmSwACgkQMUfUDdst+ympmwCgmht0boH4QJSf8ojnkrgXhZOG
JUsAoJqfC22c/dKfLbMgXYuU12Kuidhe
=poU3
-----END PGP SIGNATURE-----
Merge tag 'staging-3.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging driver fixes from Greg KH:
"Here are a few staging driver fixes for issues that have been reported
for 3.15-rc2.
Also dominating the diffstat for the pull request is the removal of
the rtl8187se driver. It's no longer needed in staging as a "real"
driver for this hardware is now merged in the tree in the "correct"
location in drivers/net/
All of these patches have been tested in linux-next"
* tag 'staging-3.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
staging: r8188eu: Fix case where ethtype was never obtained and always be checked against 0
staging: r8712u: Fix case where ethtype was never obtained and always be checked against 0
staging: r8188eu: Calling rtw_get_stainfo() with a NULL sta_addr will return NULL
staging: comedi: fix circular locking dependency in comedi_mmap()
staging: r8723au: Add missing initialization of change_inx in sort algorithm
Staging: unisys: use after free in list_for_each()
staging: unisys: use after free in error messages
staging: speakup: fix misuse of kstrtol() in handle_goto()
staging: goldfish: Call free_irq in error path
staging: delete rtl8187se wireless driver
staging: rtl8723au: Fix buffer overflow in rtw_get_wfd_ie()
staging: gs_fpgaboot: remove __TIMESTAMP__ macro
staging: vme: fix memory leak in vme_user_probe()
staging: fpgaboot: clean up Makefile
staging/usbip: fix store_attach() sscanf return value check
staging/usbip: userspace - fix usbipd SIGSEGV from refresh_exported_devices()
staging: rtl8188eu: remove spaces, correct counts to unbreak P2P ioctls
staging/rtl8821ae: Fix OOM handling in _rtl_init_deferred_work()
Here are a number of small tty/serial driver fixes for 3.15-rc2. Also
in here are some Documentation file removals for drivers that we removed
a long time ago, no need to keep it around any longer.
All of these have been in linux-next for a bit.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEABECAAYFAlNRmhMACgkQMUfUDdst+yl1egCgi9FsrVUE57dZ2AJNuVwxeh90
cDQAoIAbaKSE1ooen/txjFI27rB92qgZ
=d+yo
-----END PGP SIGNATURE-----
Merge tag 'tty-3.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty/serial driver fixes from Greg KH:
"Here are a number of small tty/serial driver fixes for 3.15-rc2. Also
in here are some Documentation file removals for drivers that we
removed a long time ago, no need to keep it around any longer.
All of these have been in linux-next for a bit"
* tag 'tty-3.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
Revert "serial: 8250, disable "too much work" messages"
serial: amba-pl011: fix regression, causing an Oops on rmmod
tty: Fix help text of SYNCLINK_CS
tty: fix memleak in alloc_pid
ttyprintk: Allow built as a module
ttyprintk: Fix wrong tty_unregister_driver() call in the error path
serial: 8250, disable "too much work" messages
Documentation/serial: Delete obsolete driver documentation
serial: omap: Fix missing pm_runtime_resume handling by simplifying code
serial_core: Fix pm imbalance on unbind
serial: pl011: change Rx burst size to half of trigger level
serial: timberdale: Depend on X86_32
serial: st-asc: Fix SysRq char handling
Revert "serial: clps711x: Give a chance to perform useful tasks during wait loop"
serial_core: Fix conditional start_tx on ring buffer not empty
serial: efm32: use $vendor,$device scheme for compatible string
serial: omap: free the wakeup settings in remove
Here are a number of tiny USB fixes and new device ids for 3.15-rc2.
Nothing major, just issues some people have reported.
All of these have been in linux-next.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEABECAAYFAlNRmoQACgkQMUfUDdst+ynbMgCgn32vVlhBxMJuS5MXRMH+WUUj
6PkAn1jn+8gLz2aX5BkMKUuE2pgU2Phz
=pKvA
-----END PGP SIGNATURE-----
Merge tag 'usb-3.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are a number of tiny USB fixes and new device ids for 3.15-rc2.
Nothing major, just issues some people have reported.
All of these have been in linux-next"
* tag 'usb-3.15-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
uas: fix deadlocky memory allocations
uas: fix error handling during scsi_scan()
uas: fix GFP_NOIO under spinlock
uwb: adds missing error handling
USB: cdc-acm: Remove Motorola/Telit H24 serial interfaces from ACM driver
USB: ohci-jz4740: FEAT_POWER is a port feature, not a hub feature
USB: ohci-jz4740: Fix uninitialized variable warning
USB: EHCI: tegra: set txfill_tuning
usb: ehci-platform: Return immediately from suspend if ehci_suspend fails
usb: ehci-exynos: Return immediately from suspend if ehci_suspend fails
USB: fix crash during hotplug of PCI USB controller card
USB: cdc-acm: fix double usb_autopm_put_interface() in acm_port_activate()
usb: usb-common: fix typo for usb_state_string
USB: usb_wwan: fix handling of missing bulk endpoints
USB: pl2303: add ids for Hewlett-Packard HP POS pole displays
USB: cp210x: Add 8281 (Nanotec Plug & Drive)
usb: option driver, add support for Telit UE910v2
Revert "USB: serial: add usbid for dell wwan card to sierra.c"
USB: serial: ftdi_sio: add id for Brainboxes serial cards
Merge misc fixes from Andrew Morton:
"13 fixes"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
thp: close race between split and zap huge pages
mm: fix new kernel-doc warning in filemap.c
mm: fix CONFIG_DEBUG_VM_RB description
mm: use paravirt friendly ops for NUMA hinting ptes
mips: export flush_icache_range
mm/hugetlb.c: add cond_resched_lock() in return_unused_surplus_pages()
wait: explain the shadowing and type inconsistencies
Shiraz has moved
Documentation/vm/numa_memory_policy.txt: fix wrong document in numa_memory_policy.txt
powerpc/mm: fix ".__node_distance" undefined
kernel/watchdog.c:touch_softlockup_watchdog(): use raw_cpu_write()
init/Kconfig: move the trusted keyring config option to general setup
vmscan: reclaim_clean_pages_from_list() must use mod_zone_page_state()
shiraz.hashim@st.com email-id doesn't exist anymore as he has left the
company. Replace ST's id with shiraz.linux.kernel@gmail.com.
It also updates .mailmap file to fix address for 'git shortlog'.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Shiraz Hashim <shiraz.linux.kernel@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
John W. Linville says:
====================
pull request: wireless 2014-04-17
Please pull this batch of fixes intended for the 3.15 stream...
For the mac80211 bits, Johannes says:
"We have a fix from Chun-Yeow to not look at management frame bitrates
that are typically really low, two fixes from Felix for AP_VLAN
interfaces, a fix from Ido to disable SMPS settings when a monitor
interface is enabled, a radar detection fix from Michał and a fix from
myself for a very old remain-on-channel bug."
For the iwlwifi bits, Emmanuel says:
"I have new device IDs and a new firmware API. These are the trivial
ones. The less trivial ones are Johannes's fix that delays the
enablement of an interrupt coalescing hardware until after association
- this fixes a few connection problems seen in the field. Eyal has a
bunch of rate control fixes. I decided to add these for 3.15 because
they fix some disconnection and packet loss scenarios which were
reported by the field. I also have a fix for a memory leak that
happens only with a very new NIC."
Along with those...
Amitkumar Karwar fixes a couple of problems relating to driver/firmware
interactions in mwifiex.
Christian Engelmayer avoids a couple of potential memory leaks in
the new rsi driver.
Eliad Peller provides a wl18xx mailbox alignment fix for problems
when using new firmware.
Frederic Danis adds a couple of missing debugging strings to the
cw1200 driver.
Geert Uytterhoeven adds a variable initialization inside of the
rsi driver.
Luciano Coelho patches the wlcore code to ignore dummy packet events
in PLT mode in order to work around a firmware bug.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
The patch fixes a problem with dropped jumbo frames after usage of
'ethtool -G ... rx'.
Scenario:
1. ip link set eth0 up
2. ethtool -G eth0 rx N # <- This zeroes rx-jumbo
3. ip link set mtu 9000 dev eth0
The ethtool command set rx_jumbo_pending to zero so any received jumbo
packets are dropped and you need to use 'ethtool -G eth0 rx-jumbo N'
to workaround the issue.
The patch changes the logic so rx_jumbo_pending value is changed only if
jumbo frames are enabled (MTU > 1500).
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Acked-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
- Mostly cxgb4 fixes unblocked by the merge of some prerequisites via
the net tree.
- Drop deprecated MSI-X API use.
- A couple other miscellaneous things.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABCAAGBQJTUXCpAAoJEENa44ZhAt0h4tEP/1P1TqA/90sO7WeChze6H2ph
kkGJPsCj8i1AWpef/Ax2hvoH1pjxK/VQbpwgkGJElv+rRaP99pandYGPBFluUoJK
jI6D/mZSAsl6BXIZZCTcz9ttQNYacDdDL1I22WIdntkkCUsoP1awuHnXS4WLAiPA
3D1XmiSHTGv9nbqd2wKA3sHWFaUN/s+RqsvIXUcNrN4qEUL2KXPOyt7i4Pz8eUq7
/lxG1S854QUrZsW7qFR6Jc3clhNupUDWBBRrII3MOV98W3upHOVsFAdtcLZAkcTA
FBCk90VVi0hsPeHqqCZjKUW/JE414vEDzOZfmYOpMj0xzc9sF1POxlvqMfRjvKTD
fwYAkNLT7AW74jSU38KZl9pdLsQx187c75pcYUZ4ph6m6bozbtlPGkJaa3M3yyUb
DmWUZL1dX8i69dV+w/ABz/4uK0dbCwMeAM9cCCUiedqI5wIuEV4Ld3NOLe7HnAXz
O81UrVVnwrOVl8uPmGzY3VliU0OtFqhMBCxTgsZRxuBr9DSx/dUzb4Tzfw7e3Sc+
+uxMMnbuCDysqEfzKsLG0+qu9P3hcwyafTJ9u8pq0D+BCB3tA8ZIKiqrKeMBua2h
IJAy8M+zVG2HZCQFreH2oMnXmzVoyp+5Yl28izMDEfDptJ6hel4FLBiLLlYnU1DO
zxUN5X1yOHxFkK4YYetE
=/PTZ
-----END PGP SIGNATURE-----
Merge tag 'rdma-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband
Pull infiniband/rdma updates from Roland Dreier:
- mostly cxgb4 fixes unblocked by the merge of some prerequisites via
the net tree
- drop deprecated MSI-X API use.
- a couple other miscellaneous things.
* tag 'rdma-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband:
RDMA/cxgb4: Fix over-dereference when terminating
RDMA/cxgb4: Use uninitialized_var()
RDMA/cxgb4: Add missing debug stats
RDMA/cxgb4: Initialize reserved fields in a FW work request
RDMA/cxgb4: Use pr_warn_ratelimited
RDMA/cxgb4: Max fastreg depth depends on DSGL support
RDMA/cxgb4: SQ flush fix
RDMA/cxgb4: rmb() after reading valid gen bit
RDMA/cxgb4: Endpoint timeout fixes
RDMA/cxgb4: Use the BAR2/WC path for kernel QPs and T5 devices
IB/mlx5: Add block multicast loopback support
IB/mthca: Use pci_enable_msix_exact() instead of pci_enable_msix()
IB/qib: Use pci_enable_msix_range() instead of pci_enable_msix()
The AHCI spec allows implementations to issue commands in tag order
rather than FIFO order:
5.3.2.12 P:SelectCmd
HBA sets pSlotLoc = (pSlotLoc + 1) mod (CAP.NCS + 1)
or HBA selects the command to issue that has had the
PxCI bit set to '1' longer than any other command
pending to be issued.
The result is that commands posted sequentially (time-wise) may play out
of sequence when issued by hardware.
This behavior has likely been hidden by drives that arrange for commands
to complete in issue order. However, it appears recent drives (two from
different vendors that we have found so far) inflict out-of-order
completions as a matter of course. So, we need to take care to maintain
ordered submission, otherwise we risk triggering a drive to fall out of
sequential-io automation and back to random-io processing, which incurs
large latency and degrades throughput.
This issue was found in simple benchmarks where QD=2 seq-write
performance was 30-50% *greater* than QD=32 seq-write performance.
Tagging for -stable and making the change globally since it has a low
risk-to-reward ratio. Also, word is that recent versions of an unnamed
OS also does it this way now. So, drives in the field are already
experienced with this tag ordering scheme.
Cc: <stable@vger.kernel.org>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ed Ciechanowski <ed.ciechanowski@intel.com>
Reviewed-by: Matthew Wilcox <matthew.r.wilcox@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
In multiple MSI mode all AHCI ports (including dummy) get assigned
separate MSI vectors and (as result of execution
pci_enable_msi_exact() function) separate IRQ numbers, (mapped to the
MSI vectors).
Therefore, although interrupts from dummy ports are not desired they
are still enabled. We do not request IRQs for dummy ports, but that
only means we do not assign AHCI-specific ISRs to corresponding IRQ
numbers.
As result, dummy port interrupts still could come and traverse all the
way from the PCI device to the kernel, causing unnecessary overhead.
This update disables IRQs for dummy ports and prevents the described
issue.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Tested-by: David Milburn <dmilburn@redhat.com>
Cc: linux-ide@vger.kernel.org
Cc: stable@vger.kernel.org
Fixes: 5ca72c4f7c ("AHCI: Support multiple MSIs")
Host bridge drivers
- Fix OF interrupt mapping for DesignWare, R-Car, Tegra (Lucas Stach)
- Fix DesignWare iATU programming (Mohit Kumar)
Miscellaneous
- Fix powerpc NULL dereference from list_for_each_entry() update (Mike Qiu)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJTUUMAAAoJEFmIoMA60/r8OrUQAKXhI6kXjJ36sSHiioQBFxD9
fgJXDHS8gA4UD7ZV0BKQeA6kDM2v9A80UWLA2yLt+BWr0+DEgljsnRNWZjsrzoEn
JZantkukqKfdo6LseIwfFJM7LTWqP/q6enTMXIp9UjLxnBK+j0K7qU0+u/VjH0Ab
O8wouFu1B8REJDL5TvSjiEXO6uDtFPAuHQ1oAs5EeT35ZV54f8gSGyyUxLh1Fk18
qrD+ERN5VrVI5K2ENJwIOljAoaHMiseSZPFA8nQu/XMZ5N0dZuU2gXGFMt3yuZID
jTzq88umyEEMcbo+QqAW+rcoljq3GExBnOu2SF+0dvDWlXewsZz0WNdnKkUh5HCi
vnnwvkSB4bpnv+rtu0QQgOFoFDkQV+EYSy6dUEijtVTOijZ2ZxnzOO8/y4pocpnB
+hKehz0qNVl/RE9WMbCQ+TAb4K7+uECcilIUqq581BnmYFrH3FarfcDaHdWySI4O
AIs2RtgwtlZv1MBpejM4OS7REav2IUFj8CWsvRIIrsgfvKvl/1Rxg2eQE8KPFSdc
pi72CNKNvThzgAvpWjb0F/Wz7+0aWO6Nm0flYCBvcIB472x9dAzhVpoiKMf2BAII
S/uebuA7hCZtoGEWOSwtEBYm+i3UR07YCL2UFv8Pj523DaOeTFgSYp7YFFJV+WqO
AosR0V0L8mr2HMBK0KhN
=VgYj
-----END PGP SIGNATURE-----
Merge tag 'pci-v3.15-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
Pull PCI updates from Bjorn Helgaas:
"These are fixes for a powerpc NULL pointer dereference, an OF
interrupt mapping issue on some of the new host bridges, and a
DesignWare iATU issue.
Host bridge drivers
- Fix OF interrupt mapping for DesignWare, R-Car, Tegra (Lucas Stach)
- Fix DesignWare iATU programming (Mohit Kumar)
Miscellaneous
- Fix powerpc NULL dereference from list_for_each_entry() update (Mike Qiu)"
* tag 'pci-v3.15-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
PCI: tegra: Use new OF interrupt mapping when possible
PCI: rcar: Use new OF interrupt mapping when possible
PCI: designware: Use new OF interrupt mapping when possible
PCI: designware: Fix iATU programming for cfg1, io and mem viewport
PCI: designware: Fix comment for setting number of lanes
powerpc/PCI: Fix NULL dereference in sys_pciconfig_iobase() list traversal
Pull HID fixes from Jiri Kosina:
- fix for merge window mismerge in hid-sony, from Frank Praznik
- fix for Surface Type/Touch Cover 2 device, from Benjamin Tissoires
- quirk for ThinkPad Helix sensor hub from Stephen Chandler Paul
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
HID: core: do not scan constant input report
Revert "HID: microsoft: Add ID's for Surface Type/Touch Cover 2"
HID: sensor-hub: add sensor hub quirk for ThinkPad Helix
HID: sony: Fix cancel_work_sync mismerge
atmel_spi_lock does a spin_lock_irqsave, so we need to renable the
interrupts when we want to schedule.
Signed-off-by: Alexander Stein <alexanders83@web.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
bochs kms driver lacks power management support, thus
the vga display doesn't work any more after S3 resume.
Fix this by adding suspend and resume functions.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
cirrus kms driver lacks power management support, thus
the vga display doesn't work any more after S3 resume.
Fix this by adding suspend and resume functions.
Also make the mode_set function unblank the screen.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is leftover stuff from my previous doc round which I kinda wanted
to do but didn't yet due to rebase hell.
The modeset helpers and the probing helpers a independent and e.g.
i915 uses the probing stuff but has its own modeset infrastructure. It
hence makes to split this up. While at it add a DOC: comment for the
probing libraray.
It would be rather neat to pull some of the DocBook documenting these
two helpers into in-line DOC: comments. But unfortunately kerneldoc
doesn't support markdown or something similar to make nice-looking
documentation, so the current state is better.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
After thinking about this topic a bit more I've reached the conclusion
that implementing this doesn't make sense:
- The locking is all wrong: set_config(NULL) will also unlink encoders
and connectors, but those links are protected with the mode_config
mutex. In the ->disable_plane callback we only hold all modeset
locks, but eventually we want to switch to just grabbing the
per-crtc (and maybe per-plane) locks as needed, maybe based on
ww_mutexes. Having a callback which absolutely needs all modeset
locks is bad for this conversion.
Note that the same isn't true for the provided ->update_plane since
we've audited the crtc helpers to make sure that not encoder or
connector links are changed.
- There's no way to re-enable the plane with an ->update_plane: The
connectors/encoder links are lost and so we can't re-enable the
CRTC. Even without that issue the driver might have reassigned some
shared resources (as opposed to e.g. DPMS off, where drivers are not
allowed to do that to make sure the CRTC can be enabled again).
- The semantics don't make much sense: Userspace asked to scan out
black (or some other color if the driver supports a background
color), not that the screen be disabled.
- Implementing proper primary plane support (i.e. actually disabling
the primary plane without disabling the CRTC) is really simple, at
least if all the hw needs is flipping a bit. The big task is
auditing all the interactions with other ioctls when the CRTC is on
but there's no primary plane (e.g. pageflips). And some of that work
still needs to be done.
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
this is a typo vs the ums driver, fix to check correct value.
Found initially by Coverity.
Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Commit 457e77b264 added two checks applied to a
value received from nv_rd32(bios, 0x619f04). But after this new piece of code
is executed, the addr local variable does not hold the same value it used to
hold before the commit. Here is what is was assigned in the original code:
(u64)(nv_rd32(bios, 0x619f04) & 0xffffff00) << 8
in the committed code it ends up with this value:
(u64)(nv_rd32(bios, 0x619f04) >> 8) << 8
These expressions are obviously not equivalent.
My Nvidia video card does not show anything on the display when I boot a
kernel containing this commit.
The patch fixes the code so that the new checks are still done, but the
side effect of an incorrect addr value is gone.
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sergei Antonov <saproj@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
appeared in 3.15-rc1:
- fixes for primary-plane handling which caused crashes
- fix all kinds of uninit issues which prevented from unloading the omapdrm
module.
- fixes for HDMI enable/disable issues
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJTTkM7AAoJEPo9qoy8lh71JaQP/2NvUIr64vCXd39FqzrpwJ2n
iRwHFt0M5sHld6NCNVyaThQtmRAN7u7fkInwcUWPU1yv0HIkHB2CRAzTx3H1Ca73
S+eaqda6Rog2oGh/Q6xmpAjaxZX0td9QhhGfKm9MlNJQ/a50H/7ovq5XZu2etfj2
m1nW6L1U+43aZYDLjM6T6IOydqWZGZ0jv6sNOAa4vwWWIJ85y+MybL2AL6SOQXpR
LLbe/wI6eMBguJQOiLfZivFtlF7HzvT9I/VRhrtL+aanBOqVeqEFEcxJhutIl8/g
NOZo+XfeRJqGJ5FDbgwFqP/+sDQEKQBHL+9/XfUVdJmKI3ihyhF5o4jCPpkHqYTP
S3hyxQOkPZ/wgP8ucG0BvzhQRZoatSyIUbDE/98etmZ2pqLXk6d+tRs2uAev/0ec
WLDc8/JEbTOE9cG/VAqVZTPsucuoWZ8Ow70v65ZlloqiaD/6QAWigavcQA1EZO+F
cHBuwNXXAu8b2VV1cQcQVbihhga7lt1RFIzr7hQpniERK7tqeVqgapLWruxEJ5HZ
9HTRR+JIUydbXjsr0RtY3KIAKhKyfUiEAn7YIZBPpR7jSlUiexbX2ZrBN4Ea+sst
Kjs/I71KN6j7lI3hh3R+HKOeYw9wqXuoqtojCafx2JRMEMhiSpOrAZuOjsW0fWSD
AJhzTX8ZiFGFOB/oGdwp
=03GJ
-----END PGP SIGNATURE-----
Merge tag 'omapdrm-fixes-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next
Fixes for omapdrm, some of which were already present in 3.14, and some which
appeared in 3.15-rc1:
- fixes for primary-plane handling which caused crashes
- fix all kinds of uninit issues which prevented from unloading the omapdrm
module.
- fixes for HDMI enable/disable issues
* tag 'omapdrm-fixes-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux:
drm/omap: fix the handling of fb ref counts
drm/omap: protect omap_crtc's event with event_lock spinlock
drm/omap: Use old_fb to synchronize between successive page flips
drm/omap: Fix crash when using LCD3 overlay manager
drm/omap: gem sync: wait on correct events
drm/omap: Fix memory leak in omap_gem_op_async
drm/omap: remove warn from debugfs
drm/omap: remove extra plane->destroy from crtc destroy
drm/omap: print warning when rotating non-TILER fb
drm/omap: fix missing unref to fb's buf object
drm/omap: fix plane rotation
drm/omap: fix enabling/disabling of video pipeline
drm/omap: fix missing disable for unused encoder
drm/omap: fix race issue when unloading omapdrm
drm/omap: fix DMM driver (un)registration
drm/omap: fix uninit order in pdev_remove()
drm/omap: fix output enable/disable sequence
1. Fixing PLL regressions
2. A couple of memory reclocking and DPM fixes
3. Small cleanups
* 'drm-fixes-3.15' of git://people.freedesktop.org/~deathsimple/linux:
drm/radeon/ci: make sure mc ucode is loaded before checking the size
drm/radeon/si: make sure mc ucode is loaded before checking the size
drm/radeon: improve PLL params if we don't match exactly v2
drm/radeon: memory leak on bo reservation failure. v2
drm/radeon: fix VCE fence command
drm/radeon: re-enable mclk dpm on R7 260X asics
drm/radeon: add support for newer mc ucode on CI (v2)
drm/radeon: add support for newer mc ucode on SI (v2)
drm/radeon: apply more strict limits for PLL params v2
drm/radeon: update CI DPM powertune settings
drm/radeon: fix runpm handling on APUs (v4)
drm/radeon: disable mclk dpm on R7 260X
This contains a fix for the host1x driver writing to non-existent syncpt
registers.
A second commit removes an excess pad field in the parameter structure
for the DRM_TEGRA_SUBMIT IOCTL. Archeaology on earlier versions of this
file indicates that this was once there to pad an uneven number of u32
u32 fields, of which one was subsequently removed. Unfortunately nobody
remembered to get rid of the padding when that happened.
Both of these commits are Cc: stable because they fix issues that were
introduced back in v3.10.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJTT7oIAAoJEN0jrNd/PrOh+eEP/jTxGkbkGDlIhKXtjnNnoOZ2
CNAxpXETfO5WOxSP3LzJ8BhxZBHWrfJo6qWRhO9NAvAMc7jH7NYlijbPO0mS/Dwv
meFoMBN9RiMFRhdBBvxW3uwahgIc+GSUjcrv25BtTOpPmYSLldnWTdRBq5bzLYSB
iHpsv1iyVa/wI7iE5/VWwAy/JZPGEym7xgcE7IH2x2DVw4cNVZ4/OzBhN1STWWsL
bhR0M5/oKYboJoioZ3NDQ5XsAD6g15hdcW0+CxTJrA1sq5x1Juz/rwfk/+dUzC2f
O133QjbqyS1TY2mLhGk4sUnaFYVtsyIx+EIOWyHdrrIb6uFMjOThSq3MCdCHrRjP
hUghKJrNIGNkM8RrPngQGwUZfbRLzi5IqEFw8ZxNYwclZ1kpUW+vQs4maCG7rt4t
MEuIazUAoF7M0Xr59iF2LDrrZAOLWSjyiolX1nrJpDM+iYY/zaFe/yOU5B2+82dM
dIvEKf1Dm8Ys9RhNRW4qgSZQQHFkLXnwQAF6ulCeGgTtz1/daAchxv7zUIo5iMES
1IreKmUoMLpWBDHsUvGE9TsUlSo3tw/imMfLj1efHCtJl5Sn+cCXzcPtwrNf5SUY
5TZ9bKsduiLbDv5ov31lPFQUOLmOS7sJ+7phhOrI6RiNybxgGFymd0k+mW/GsMkN
5IPdu8D+GOQWtQjlqX0w
=yHpw
-----END PGP SIGNATURE-----
Merge tag 'drm/tegra/for-3.15-rc2' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Fixes for v3.15-rc2
This contains a fix for the host1x driver writing to non-existent syncpt
registers.
A second commit removes an excess pad field in the parameter structure
for the DRM_TEGRA_SUBMIT IOCTL. Archeaology on earlier versions of this
file indicates that this was once there to pad an uneven number of u32
u32 fields, of which one was subsequently removed. Unfortunately nobody
remembered to get rid of the padding when that happened.
Both of these commits are Cc: stable because they fix issues that were
introduced back in v3.10.
* tag 'drm/tegra/for-3.15-rc2' of git://anongit.freedesktop.org/tegra/linux:
drm/tegra: Remove gratuitous pad field
gpu: host1x: handle the correct # of syncpt regs
After hotplugging CPU1 the first call of interrupt handler for CPU1
oneshot timer was called on CPU0 because it fired before setting IRQ
affinity. Affected are SoCs where Multi Core Timer interrupts are
shared (SPI), e.g. Exynos 4210.
During setup of the MCT timers the clock event device should be
registered after setting the affinity for interrupt. This will prevent
starting the timer too early.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Tomasz Figa <t.figa@samsung.com>,
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: linux-arm-kernel@lists.infradead.org,
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20140416143316.299247848@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
The starting cpu is not yet in the online mask so irq_set_affinity()
fails which results in per cpu timers for this cpu ending up on some
other online cpu, ususally cpu 0.
Use irq_force_affinity() which disables the online mask check and
makes things work.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Tomasz Figa <t.figa@samsung.com>,
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: linux-arm-kernel@lists.infradead.org,
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20140416143316.106665251@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
To support the affinity setting of per cpu timers in the early startup
of a not yet online cpu, implement the force logic, which disables the
cpu online check.
Tagged for stable to allow a simple fix of the affected SoC clock
event drivers.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Tomasz Figa <t.figa@samsung.com>,
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: linux-arm-kernel@lists.infradead.org,
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20140416143315.916984416@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Merge ipmi fixes from Corey Minyard:
"Things collected since last kernel release.
Some of these are pretty important. The first three are bug fixes.
The next two are to hopefully make everyone happy about allowing
ACPI to be on all the time and not have IPMI have an effect on the
system when not in use. The last is a little cleanup"
* emailed patches from Corey Minyard <cminyard@mvista.com>:
ipmi: boolify some things
ipmi: Turn off all activity on an idle ipmi interface
ipmi: Turn off default probing of interfaces
ipmi: Reset the KCS timeout when starting error recovery
ipmi: Fix a race restarting the timer
Char: ipmi_bt_sm, fix infinite loop
The IPMI driver would wake up periodically looking for events and
watchdog pretimeouts. If there is nothing waiting for these events,
it's really kind of pointless to be checking for them. So modify the
driver so the message handler can pass down if it needs the lower layer
to be waiting for these. Modify the system interface lower layer to
turn off all timer and thread activity if the upper layer doesn't need
anything and it is not currently handling messages. And modify the
message handler to not restart the timer if its timer is not needed.
The timers and kthread will still be enabled if:
- the SI interface is handling a message.
- a user has enabled watching for events.
- the IPMI watchdog timer is in use (since it uses pretimeouts).
- the message handler is waiting on a remote response.
- a user has registered to receive commands.
This mostly affects interfaces without interrupts. Interfaces with
interrupts already don't use CPU in the system interface when the
interface is idle.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The default probing can cause problems with some system, slow booting,
extra CPU usages, etc. Turn it off by default and give a config option
to enable it.
From: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The OBF timer in KCS was not reset in one situation when error recovery
was started, resulting in an immediate timeout.
Reported-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
With recent changes it is possible for the timer handler to detect an
idle interface and not start the timer, but the thread to start an
operation at the same time. The thread will not start the timer in that
instance, resulting in the timer not running.
Instead, move all timer operations under the lock and start the timer in
the thread if it detect non-idle and the timer is not already running.
Moving under locks allows the last timeout to be set in both the thread
and the timer. 'Timer is not running' means that the timer is not
pending and smi_timeout() is not running. So we need a flag to detect
this correctly.
Also fix a few other timeout bugs: setting the last timeout when the
interrupt has to be disabled and the timer started, and setting the last
timeout in check_start_timer_thread possibly racing with the timer
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Bodo Stroesser <bstroesser@ts.fujitsu.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In read_all_bytes, we do
unsigned char i;
...
bt->read_data[0] = BMC2HOST;
bt->read_count = bt->read_data[0];
...
for (i = 1; i <= bt->read_count; i++)
bt->read_data[i] = BMC2HOST;
If bt->read_data[0] == bt->read_count == 255, we loop infinitely in the
'for' loop. Make 'i' an 'int' instead of 'char' to get rid of the
overflow and finish the loop after 255 iterations every time.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reported-and-debugged-by: Rui Hui Dian <rhdian@novell.com>
Cc: Tomas Cech <tcech@suse.cz>
Cc: Corey Minyard <minyard@acm.org>
Cc: <openipmi-developer@lists.sourceforge.net>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
- Fix completely broken 32-bit PV guests caused by x86 refactoring
32-bit thread_info.
- Only enable ticketlock slow path on Xen (not bare metal).
- Fix two bugs with PV guests not shutting down when requested.
- Fix a minor memory leak in xen-pciback error path.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAABAgAGBQJTT/hQAAoJEFxbo/MsZsTR6sMIAJs7mJXSqDQn3Z8O+TemRa53
p92ZomTNYALjUMglXcxJ2Zua6IsZMWdu7jcV1GoXC70V4YLmUs8KaBgZmI5ayUQy
bBpK+6WIAJyBkJdNH5fK3wggJ2UZjw0/twPNgd9gACwjUiYhx8iHN/hTGvu4qPBJ
MGAIlg6wdnGwRydi72uk9Am/xpebEdQy4DRD20vjwA/qUkT4uHVv/AA4hc4AK29w
ToK8qFSisgAlahcmq8/T4+OBFEKz78b9dQcdsGWyAk0ofWILfwD1l53xhzUin25s
JUVevWhhLCKRZBOq4Ykc5qyqnLff4m56rm/THQ6f0oRdJn/OR+SWOImda2Qqmvs=
=Gxpq
-----END PGP SIGNATURE-----
Merge tag 'stable/for-linus-3.15-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull Xen fixes from David Vrabel:
"Xen regression and bug fixes for 3.15-rc1:
- fix completely broken 32-bit PV guests caused by x86 refactoring
32-bit thread_info.
- only enable ticketlock slow path on Xen (not bare metal)
- fix two bugs with PV guests not shutting down when requested
- fix a minor memory leak in xen-pciback error path"
* tag 'stable/for-linus-3.15-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
xen/manage: Poweroff forcefully if user-space is not yet up.
xen/xenbus: Avoid synchronous wait on XenBus stalling shutdown/restart.
xen/spinlock: Don't enable them unconditionally.
xen-pciback: silence an unwanted debug printk
xen: fix memory leak in __xen_pcibk_add_pci_dev()
x86/xen: Fix 32-bit PV guests's usage of kernel_stack
drivers/video/fbdev/ and the fbdev framework core files are located in
drivers/video/fbdev/core/
The drivers/video/Kconfig is modified so that the DRM and the fbdev menu
options are in separate submenus, instead of both being mixed in the same
'Graphics support' menu level.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJTT2MbAAoJEPo9qoy8lh71EfgP/jYWv2TZ3jL+B6PeIufFXpPr
sf/nl+S5Pq/v0h0YxvgjjRHs9sjYiynSTR5xZXUoBsT7QZr/tF9FujJg2ZOc7V2c
4bPmxyaEm9igN6daXqOwM9R/VRb47IXXlwXvUXafJc9PtOLSHF3rZNetHUkElZVE
oeq4HANhqHp5Sa6bj0lDXcoLLf2kTdQMxrXYCwGWrYwUXJ6CKwM0LdlzytzvShWv
x7qTSwHiDEX8UGLb9pFLoXrIz5Fpviv+8dHdO6WrZ6E1w5RQ80x7Pjxvt6+VOD/3
FXGXvXaOluD5Kpyt1gLVL0Esq/NYLnySGaP1sFighZCvSGc8BNCc7WzKJsRecIcq
rj246WR+MfctYJTnEy00ltwGnqo1sU7VkCKp/Q33XYcVpLf/hw7KkvCOrIwQm3FW
jge94kxiuqjJGhkE2RTCjLW3f6JEMP/cBWijdIn3Vr7Mig7UWqPbbmaei9Aq5SZ6
kBXG5OKhwmn5uWzFAfrrZDZqGyoTPckZQXaJ+zrRGE+m89Xz1ZYas42xDaSuo9zM
iFFSxs2BUO8/KPMgkc4IrlPMLm0kbQIFJypU6Xmzj8LimLPAWOkKN6h736qZqBC7
jywLN8TaOaTA0OOi3fqq8CpQ4g7VJcoyN6pPWHqWz0VHoUYGskOXkVT0E6sR1ELH
VhG+OwfGjLu3mz1V6O4K
=pGBd
-----END PGP SIGNATURE-----
Merge tag 'fbdev-reorder-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux
Pull fbdev renaming patches from Tomi Valkeinen:
"Reorder drivers/video/ directory so that all fbdev drivers are now
located in drivers/video/fbdev/ and the fbdev framework core files are
located in drivers/video/fbdev/core/
The drivers/video/Kconfig is modified so that the DRM and the fbdev
menu options are in separate submenus, instead of both being mixed in
the same 'Graphics support' menu level"
* tag 'fbdev-reorder-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux:
video: Kconfig: move drm and fb into separate menus
fbdev: move fbdev core files to separate directory
video: move fbdev to drivers/video/fbdev
This reverts commit f4f653e987.
Jiri writes:
No, please drop this one. We need a better solution as it turned
out that some boxes need 16k loops and it will increase with new
processors :(.
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Martin Pluskal <mpluskal@suse.com>
Cc: Takashi Iwai <tiwai@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This fix the fsl usb gadget driver in a way that the usb device
will be only "pulled up" on requests only when vbus is powered
Signed-off-by: Suresh Gupta <suresh.gupta@freescale.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
The driver calls pci_enable_msi_range() function with the range of
[nvec..nvec] which is what pci_enable_msi_exact() function is for.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Cc: linux-ide@vger.kernel.org
Signed-off-by: Tejun Heo <tj@kernel.org>
The AHCI specification allows hardware to choose to revert to
single MSI mode when fewer messages are allocated than requested.
Yet, at least ICH10 chipset reverts to single MSI mode even when
enough messages are allocated in some cases (see below).
This update forces the driver to not rely on initialization of
multiple MSIs mode alone and always check if "MSI Revert to
Single Message" (MRSM) mode was enforced by the controller and
fallback to the single MSI mode in case it did.
That prevents a situation when the driver configured multiple
per-port IRQ handlers, but the controller sends all port's
interrupts to a single IRQ, which could easily screw up the
interrupt handling and lead to delays and possibly crashes.
The fix was tested on a 6-port controller that successfully
reverted to the single MSI mode:
00:1f.2 SATA controller: Intel Corporation 82801JI (ICH10 Family) SATA
AHCI Controller (prog-if 01 [AHCI 1.0])
Subsystem: Super Micro Computer Inc Device 10a7
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 101
I/O ports at f110 [size=8]
I/O ports at f100 [size=4]
I/O ports at f0f0 [size=8]
I/O ports at f0e0 [size=4]
I/O ports at f020 [size=32]
Memory at fbf00000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [80] MSI: Enable+ Count=1/16 Maskable- 64bit-
Capabilities: [70] Power Management version 3
Capabilities: [a8] SATA HBA v1.0
Capabilities: [b0] PCI Advanced Features
Kernel driver in use: ahci
With 6 ports just 8 MSI vectors should be enough, but the adapter
enforces the MRSM mode when less than 16 vectors are written to
the Multiple Messages Enable PCI register. I instigated MRSM mode
by forcing @nvec to 8 in ahci_init_interrupts().
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Cc: linux-ide@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Tejun Heo <tj@kernel.org>
Avoid a possible segfault.
Noticed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Avoid a possible segfault.
Noticed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
On bo reservation failure, we end up leaking fpriv.
v2 (chk): rebased and added missing free on vm failure as well
Fixes: 5e386b574c ("drm/radeon: fix missing bo reservation")
Cc: stable@vger.kernel.org
Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Due to a type mismatch that causes an implicit type conversion, the
upper 32 bits of the GPU address have been zeroed out when adding to the
command buffer.
Picked up by Coverity - CID 1198624.
Signed-off-by: Christoph Jaeger <christophjaeger@linux.com>
May fix stability issues with some newer cards.
v2: print out mc firmware version used and size
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Letting post and refernce divider get to big is bad for signal stability.
v2: increase the limit to 210
Signed-off-by: Christian König <christian.koenig@amd.com>
Using a notification type mask for the store event information chsc
is unsupported on some firmware levels. Retry SEI with that mask set
to zero (which is the old way of requesting only channel subsystem
related events).
Cc: <stable@vger.kernel.org>
Reported-and-tested-by: Stefan Haberland <stefan.haberland@de.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
I hit another BUG_ON with e240c1839d. In __get_priority_stripe(),
stripe count equals to 0 initially. Between atomic_inc and BUG_ON,
get_active_stripe() finds the stripe. So the stripe count isn't 1 any more.
V2: keeps the BUG_ON suggested by Neil.
Signed-off-by: Shaohua Li <shli@fusionio.com>
Signed-off-by: NeilBrown <neilb@suse.de>
At the moment the "Device Drivers / Graphics support" kernel config page
looks rather messy, with DRM and fbdev driver selections on the same
page, some on the top level Graphics support page, some under their
respective subsystems.
If I'm not mistaken, this is caused by the drivers depending on other
things than DRM or FB, which causes Kconfig to arrange the options in
not-so-neat manner.
Both DRM and FB have a main menuconfig option for the whole DRM or FB
subsystem. Optimally, this would be enough to arrange all DRM and FB
options under the respective subsystem, but for whatever reason this
doesn't work reliably.
This patch adds an explicit submenu for DRM and FB, making it much
clearer which options are related to FB, and which to DRM.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of having fbdev framework core files at the root fbdev
directory, mixed with random fbdev device drivers, move the fbdev core
files to a separate core directory. This makes it much clearer which of
the files are actually part of the fbdev framework, and which are part
of device drivers.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Rob Clark <robdclark@gmail.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The drivers/video directory is a mess. It contains generic video related
files, directories for backlight, console, linux logo, lots of fbdev
device drivers, fbdev framework files.
Make some order into the chaos by creating drivers/video/fbdev
directory, and move all fbdev related files there.
No functionality is changed, although I guess it is possible that some
subtle Makefile build order related issue could be created by this
patch.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Rob Clark <robdclark@gmail.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
pr_debug() parameters are reverse order of format string
Signed-off-by: Frank Rowand <frank.rowand@sonymobile.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
- Fix a couple of barnsjukdomar on the Rockchip driver.
- Remove an idiotic debug print I happened to leave behind
in the Nomadik driver.
- Fixup the Qualcomm MSM interrupt handling code for the
TLMM v2.
- Three patches renaming the Broadcom Capri driver to
BCM28155. This has been falling between the chairs for
some time due to some cross-tree synchronization
misunderstandings, now I'm fed up with this and just
rename it in this -rc1 phase.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTTPPzAAoJEEEQszewGV1zSBgP/iMS9y9LAouPmzkXseCeT4aM
eb2pEi1wtOSWCeGNMIx4X1GRkbHS+T+5Wk6dmh46RUn/8b1HY4gkLoJLnrQGML1l
zS9tdDyURGmGYuVAr0ghLq0LTruvcViCQageRzO8yllTkJb8Tf6rfKE2+y9BsGRH
CdBIE9/XYP2Z2Wwd0fLAPMFpa9wPz8eNeF7XGyQ20+DSuRzNMmDq6AUhmlCfIMnL
TxlJIT1vpAAt/e3wcRvmr2n/Nrlz28ajP/VmzSm2dSqTajy8ofWqgFwQLiItJJ3q
VuJto3eKy+xGT4IVO+ozXCZd0kDgaAeiz7PNWHpbFBec0y4QFmVFxtPpw/Zff7RH
136Vh0KahX47TaJ1GGvB5622OLjsQzwH2TY24Sn9WRzNT8VS0pv2F3RQk8tVrWrd
fquQksuMEaCay+MHcBhI1mJlQcgTFJNsenmY8KOIjFykeBz5x6bOtBkbOCjzuogr
yVgaOW/zV7b0zFQ6Vv9eZFf7WYhBXE7w1Im5D2EMR9mJpNBWbj9A8GQpCjc0+VXB
jN2hWmj5qQtQW6z67VEn3l8Mqzpazsu61zbcB3F4Ma0m247vakIkk5I8GMmLW3/c
UMr6RG2IHIaECNdS1Ir1UkBnDCFb7CQq3j0Bh2UynyU9jKGtRZU/P7SdD7LqHsi+
Q56kdNSbYdRPpjPWmZUA
=i5qY
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v3.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pincontrol fixes from Linus Walleij:
"A first set of pin control fixes for the v3.15 series:
- Fix a couple of barnsjukdomar on the Rockchip driver.
- Remove an idiotic debug print I happened to leave behind in the
Nomadik driver.
- Fixup the Qualcomm MSM interrupt handling code for the TLMM v2.
- Three patches renaming the Broadcom Capri driver to BCM28155. This
has been falling between the chairs for some time due to some
cross-tree synchronization misunderstandings, now I'm fed up with
this and just rename it in this -rc1 phase"
* tag 'pinctrl-v3.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: fix typo in bindings documentation
Update bcm_defconfig with new pinctrl CONFIG
pinctrl: Rename Broadcom Capri pinctrl driver
pinctrl: msm: Correct interrupt code for TLMM v2
pinctrl: nomadik: delete stray debug print
pinctrl: rockchip: handle first half of rk3188-bank0 correctly
pinctrl: rockchip: add return value to rockchip_set_mux
pinctrl: rockchip: fix offset of mux registers for rk3188
A recent commit ef2889f7ff "serial: pl011:
Move uart_register_driver call to device probe" introduced a regression,
causing the pl011 driver to Oops if more than 1 port have been probed. Fix
the Oops by only calling uart_unregister_driver() once after the last port
has been removed.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Enabling SYNCLINK_CS as a module builds synclink_cs, not synclinkmp.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The driver is well written to be used as a module, just the exit call
is missing.
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ttyprintk driver calls tty_unregister_driver() wrongly in the error
path of tty_register_driver(). Also, setting ttyprintk_driver to NULL
is utterly superfluous, so let's get rid of it, too.
Reported-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The 8250 driver now reports many of these:
serial8250: too much work for irq4
These messages turned out to be common these days with a use of
virtualization. I tried to increase the limit of processed characters
in commit e7328ae184 (serial: 8250,
increase PASS_LIMIT) in 2011. It was raised from 256 to 512, but it is
still not enough, apparently.
So disable the warning unless somebody turns on DEBUG (or
DYNAMIC_DEBUG _and_ the message).
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reported-by: Martin Pluskal <mpluskal@suse.com>
Reported-by: Takashi Iwai <tiwai@suse.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
References: https://bugzilla.novell.com/show_bug.cgi?id=868394
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The lack of pm_runtime_resume handling for the device state leads into
device wake-up interrupts not working after a while for runtime PM.
Also, serial-omap is confused about the use of device_may_wakeup.
The checks for device_may_wakeup should only be done for suspend and
resume, not for pm_runtime_suspend and pm_runtime_resume. The wake-up
events for PM runtime should always be enabled.
The lack of pm_runtime_resume handling leads into device wake-up
interrupts not working after a while for runtime PM.
Rather than try to patch over the issue of adding complex tests to
the pm_runtime_resume, let's fix the issues properly:
1. Make serial_omap_enable_wakeup deal with all internal PM state
handling so we don't need to test for up->wakeups_enabled elsewhere.
Later on once omap3 boots in device tree only mode we can also
remove the up->wakeups_enabled flag and rely on the wake-up
interrupt enable/disable state alone.
2. Do the device_may_wakeup checks in suspend and resume only,
for runtime PM the wake-up events need to be always enabled.
3. Finally just call serial_omap_enable_wakeup and make sure we
call it also in pm_runtime_resume.
4. Note that we also have to use disable_irq_nosync as serial_omap_irq
calls pm_runtime_get_sync.
Fixes: 2a0b965cfb (serial: omap: Add support for optional wake-up)
Cc: stable@vger.kernel.org # v3.13+
Signed-off-by: Tony Lindgren <tony@atomide.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When a serial port is closed, uart_close() takes care of shutting down the
hardware, and powering it down.
When a serial port is unbound while in use, uart_close() bypasses all of
this, as this is supposed to be done through uart_hangup() (invoked via
tty_vhangup() in uart_remove_one_port()).
However, uart_hangup() does not set the hardware's power state, leaving it
powered up. This may also lead to unbounded nesting counts in clock and
power management, depending on their internal implementation.
Make sure to power down the port in uart_hangup(), except when the port is
used as a serial console.
For serial consoles, this operation must be postponed until after the port
becomes completely unused. This case is not fixed yet, as it depends on a
(future) fix for the tty->count vs. port->count imbalance on failed
uart_open().
After this, the module clock used by the sh-sci driver is disabled on
unbind while the serial port is in use.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The amba-pl011.c driver sets DMA burst size equal to FIFO trigger level.
If now exactly DMA burst size bytes are received, the DMAC will retrieve
them all and no Rx timeout interrupt will be generated. To fix that set
the burst size to half the FIFO trigger level.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As far as I know the Timberdale chip was only used as a companion for
Intel Atom E600 series processors. As such, its drivers are only
useful on X86_32.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This driver, like several others, uses the upper bits of the character
to track both real and dummy state. Unfortunately it neglects to mask
these bits properly when passing the character data around. This means
neither break detection nor sysrq character handling work correctly.
This patch adds the requires masking and has been tested to confirm
that it correctly handles magic sysrq sequences on ST's B2020 board.
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 63e3ad3252,
since this not works as expected and produce runtime error:
BUG: sleeping function called from invalid context at drivers/tty/serial/clps711x.c:379
in_atomic(): 0, irqs_disabled(): 128, pid: 287, name: mount
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the serial_core ring buffer empties just as the tty layer receives
an XOFF, then start_tx will never be called when the tty layer
receives an XON as the serial_core ring buffer is empty. This will
possibly leave a few bytes trapped in the fifo for drivers that
disable the transmitter when flow controlled.
Signed-off-by: Seth Bollinger <sethb@digi.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wolfram Sang pointed out that "efm32,$device" is non-standard. So use the
common scheme and prefix device with "efm32-". The old compatible string
is left in place until arch/arm/boot/dts/efm32* is fixed.
Reported-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Only ws2012r2 hosts support the ability to reconnect to the host on VMBUS. This functionality
is needed by kexec in Linux. To use this functionality we need to negotiate version 3.0 of the
VMBUS protocol.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Cc: <stable@vger.kernel.org> [3.9+]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The topology_##name() macro does not use its argument when CONFIG_SMP is not
set, as it ultimately calls the cpu_data() macro.
So we avoid maintaining a possibly unused `cpu' variable, to avoid the
following compilation warning:
drivers/base/topology.c: In function ‘show_physical_package_id’:
drivers/base/topology.c:103:118: warning: unused variable ‘cpu’ [-Wunused-variable]
define_id_show_func(physical_package_id);
drivers/base/topology.c: In function ‘show_core_id’:
drivers/base/topology.c:106:106: warning: unused variable ‘cpu’ [-Wunused-variable]
define_id_show_func(core_id);
This can be seen with e.g. x86 defconfig and CONFIG_SMP not set.
Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <stable@vger.kernel.org> # 3.10.x
Cc: <stable@vger.kernel.org> # 3.13.x
Cc: <stable@vger.kernel.org> # 3.14.x
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Save some characters by using to_pci_dev() instead of container_of().
Signed-off-by: Aaron Sierra <asierra@xes-inc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Previously, tsi148_master_set() assumed the address contained in its
PCI bus resource represented the actual PCI bus address. This is a fine
assumption on some platforms. However, on platforms that don't use a
1:1 (CPU:PCI) mapping this results in the tsi148 driver configuring an
invalid master window translation.
This patch updates the vme_tsi148 driver to first convert the address
contained in the PCI bus resource into a PCI bus address before using
it.
[asierra: account for pcibios_resource_to_bus() prototype change]
Signed-off-by: Joe Schultz <jschultz@xes-inc.com>
Signed-off-by: Aaron Sierra <asierra@xes-inc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch corrects a typo where "vme_base" was used instead of
"*vme_base". The typo resulted in an incorrect value being returned
to userspace (via vme_user).
It also removes the following compile warning on some platforms:
warning: cast from pointer to integer of different size
[asierra: commit title/log rewording]
Signed-off-by: Joe Schultz <jschultz@xes-inc.com>
Signed-off-by: Aaron Sierra <asierra@xes-inc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
__w1_attach_slave_device calls device_add which calls w1_bus_notify
which calls the w1_bq27000 slave driver, which calls
platform_device_add and device_add and deadlocks on getting
&(&priv->bus_notifier)->rwsem as it is still held in the previous
device_add. This avoids the problem by processing the family
add/remove outside of the slave device_add call.
Commit 47eba33a09 introduced this deadlock and added
a KOBJ_ADD, as the add was already reported in device_register two add
events were being sent. This change suppresses the device_register
add so that any slave device sysfs entries are setup before the add
goes out.
Belisko Marek reported this change fixed the deadlock he was seeing on
ARM device tree, while testing on my x86-64 system never saw the
deadlock.
Reported-by: Belisko Marek <marek.belisko@gmail.com>
Signed-off-by: David Fries <David@Fries.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the message type is W1_MASTER_CMD or W1_SLAVE_CMD, then a reference
is taken when searching for the slave or master device. If there
isn't any following data m->len (mlen is a copy) is 0 and packing up
the message for later execution is skipped leaving nothing to
decrement the reference counts.
Way back when, m->len was checked before the search that increments the
reference count, but W1_LIST_MASTERS has no additional data, the check
was moved in 9be62e0b2f causing this bug.
This change reorders to put the check before the reference count is
incremented avoiding the problem.
Signed-off-by: David Fries <David@Fries.net>
Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There are also two allocations with GFP_KERNEL in the pre-/post_reset
code paths. That is no good because that is a part of the SCSI error handler.
Signed-off-by: Oliver Neukum <oliver@neukum.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
intfdata is set only after scsi_scan(). uas_pre_reset() however
needs intfdata to be valid and will follow the NULL pointer
killing khubd. intfdata must be preemptively set before the
host is registered and undone in the error case.
Signed-off-by: Oliver Neukum <oliver@neukum.org>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
