When sending data into a tcp socket in repair state we should check
for the amount of data being 0 explicitly. Otherwise we'll have an skb
with seq == end_seq in rcv queue, but tcp doesn't expect this to happen
(in particular a warn_on in tcp_recvmsg shoots).
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Reported-by: Giorgos Mavrikas <gmavrikas@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
vmxnet3 has a 16Kbytes limit per tx descriptor, that happened to work
as long as we provided PAGE_SIZE fragments.
Our stack can now build larger fragments, so we need to split them to
the 16kbytes boundary.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: jongman heo <jongman.heo@samsung.com>
Tested-by: jongman heo <jongman.heo@samsung.com>
Cc: Shreyas Bhatewara <sbhatewara@vmware.com>
Reviewed-by: Bhavesh Davda <bhavesh@vmware.com>
Signed-off-by: Shreyas Bhatewara <sbhatewara@vmware.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When creating an L2TPv3 Ethernet session, if register_netdev() should fail for
any reason (for example, automatic naming for "l2tpeth%d" interfaces hits the
32k-interface limit), the netdev is freed in the error path. However, the
l2tp_eth_sess structure's dev pointer is left uncleared, and this results in
l2tp_eth_delete() then attempting to unregister the same netdev later in the
session teardown. This results in an oops.
To avoid this, clear the session dev pointer in the error path.
Signed-off-by: Tom Parkin <tparkin@katalix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There are systems where video module known to work fine regardless
of broken _DOD and ignoring returned value here doesn't cause
any issues later. This should fix brightness controls on some laptops.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47861
Signed-off-by: Igor Murzov <e-mail@date.by>
Reviewed-by: Sergey V <sftp.mtuci@gmail.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
following were the errors reported
drivers/thermal/rcar_thermal.c: In function ‘rcar_thermal_probe’:
drivers/thermal/rcar_thermal.c:214:10: warning: passing argument 3 of ‘thermal_zone_device_register’ makes integer from pointer without a cast [enabled by default]
include/linux/thermal.h:166:29: note: expected ‘int’ but argument is of type ‘struct rcar_thermal_priv *’
drivers/thermal/rcar_thermal.c:214:10: error: too few arguments to function ‘thermal_zone_device_register’
include/linux/thermal.h:166:29: note: declared here
make[1]: *** [drivers/thermal/rcar_thermal.o] Error 1
make: *** [drivers/thermal/rcar_thermal.o] Error 2
with gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
Signed-off-by: Devendra Naga <develkernel412222@gmail.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
If T4 configuration file gets loaded from the /lib/firmware/cxgb4/ directory
then offload capabilities of the cards were getting disabled during
initialization. Hence ULDs do not get an UP event from the LLD.
Signed-off-by: Jay Hernandez <jay@chelsio.com>
Signed-off-by: Vipul Pandya <vipul@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Based on commit b27393aecf
Calling mdiobus_free without calling mdiobus_unregister causes
BUG_ON(). This patch fixes the issue.
The semantic patch that found this issue(http://coccinelle.lip6.fr/):
// <smpl>
@@
expression E;
@@
... when != mdiobus_unregister(E);
+ mdiobus_unregister(E);
mdiobus_free(E);
// </smpl>
Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Based on commit b27393aecf
Calling mdiobus_free without calling mdiobus_unregister causes
BUG_ON(). This patch fixes the issue.
The semantic patch that found this issue(http://coccinelle.lip6.fr/):
// <smpl>
@@
expression E;
@@
... when != mdiobus_unregister(E);
+ mdiobus_unregister(E);
mdiobus_free(E);
// </smpl>
Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Tested-by: Roland Stigge <stigge@antcom.de>
Tested-by: Alexandre Pereira da Silva <aletes.xgr@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since commit 96bed4b9 (use FW 7.8.2) BRB HW block needs to be
initialized using fw values for all devices.
Otherwise ETS on 57712/578xx will not work.
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Change the email address of the powernow-k8 maintainer.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABAgAGBQJQlFWVAAoJEKhOf7ml8uNsi7MQAI5FZNla5D7fXf6JuI4n53S6
2aLFzkf9q0ievYBBeyDphLnmIWS44yfJN+OKyhvyd/BF4tlvmrZVzUjMHAFWaLe6
Eza8wRgtc8igGgQtE06xpnmaYOfNUU4B408SU+SqSurIvV9s2s1F3t8+gBaCPymk
9UxYVaE1rAHxTLzoDryhQ3H2GbWle08e44ce5kLW1GEGbC0B6l6Dfsrag+lzPedd
5QNBcoq+Fv0kvzSUJFNDwMwGrg5F7KL21EsfRJtPLXPVtMRTO1OdL1enWLDOE+jw
K0lpw/GQQx7sqyPRHrH4hTZrPHfzeY2mRAl/Q3pro/nqEy4jhfQjrH3G0s8o/xgQ
w1sKf0rDmUSA2+FhcGEMWm/eMYOE1oOyZVdxn0B1e8gN5yOqXfyho0CIvz8YMyAy
DoCjURor92teddNF83THKTDlIK248x4eCKThDIXleYE+t5th6aQdHoeQgmXQ4Y+g
eTUjFnT0glxWpyhoeTHSvhd61xgYU3aRG99OX/Y5teIIHW5rUyXhd9O1hl53UoVt
SSq7V5LRxJTU+hnW/FX19B/1/XfDe5BW6Z9+yGtibGHq4sSCb1yJeWaLOVCg3u3D
TOdbtl14ohq+zvs9MhKyTOxh710I+e10CGQHqY61MK5n+seG6YZw98GAepLQqnMW
T4VZrJBNCrXd94+4OxcU
=jN09
-----END PGP SIGNATURE-----
Merge tag 'pm-for-3.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management update from Rafael J. Wysocki:
"Change the email address of the powernow-k8 maintainer."
* tag 'pm-for-3.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpufreq / powernow-k8: Change maintainer's email address
Return errno - not an NFS4ERR_. This worked because NFS4ERR_ACCESS == EACCES.
Signed-off-by: Weston Andros Adamson <dros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Pull more scsi target fixes from Nicholas Bellinger:
"This series is a second round of target fixes for v3.7-rc4 that have
come into target-devel over the last days, and are important enough to
be applied ASAP.
All are being CC'ed to stable. The most important two are:
- target: Re-add explict zeroing of INQUIRY bounce buffer memory to
fix a regression for handling zero-length payloads, a bug that went
during v3.7-rc1, and hit >= v3.6.3 stable. (nab + paolo)
- iscsi-target: Fix a long-standing missed R2T wakeup race in TX
thread processing when using a single queue slot. (Roland)
Thanks to Roland & PureStorage team for helping to track down this
long standing race with iscsi-target single queue slot operation.
Also, the tcm_fc(FCoE) regression bug that was observed recently with
-rc2 code has also been resolved with the cancel_delayed_work() return
bugfix (commit c0158ca64d: "workqueue: cancel_delayed_work() should
return %false if work item is idle") now in -rc3. Thanks again to Yi
Zou, MDR, Robert Love @ Intel for helping to track this down."
* git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
target: Fix incorrect usage of nested IRQ spinlocks in ABORT_TASK path
iscsi-target: Fix missed wakeup race in TX thread
target: Avoid integer overflow in se_dev_align_max_sectors()
target: Don't return success from module_init() if setup fails
target: Re-add explict zeroing of INQUIRY bounce buffer memory
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIVAwUAUJP/EhOxKuMESys7AQIVrQ/8CgzkMigNI9ryQ4zURibgnK0z9b0OU6mo
0dizoDr48JrK4+DmEmx2GjvV2C5ur6qu5dYf2NiEP2zHXDT0m1BihzVAoiqOfh9R
TlfsSYTdmUH7s0/1VdB0IwVeh46wFYxArroyedPLjftWBK/iR/h6qJ4R1OIpwZR8
b4f9hDwZtdWKrJSwgtJWeMDLw/phYxGDdcD77C9s1WN2OQT532N6Eoea+2kGKSNY
C51en4uBMWajbc2iVSMLQ6dgydcEGTM3gO6gawx3uEwXjl+HoycBbGiu0b/fvnmG
PAbMu2jBgh+uWScHkWQUa+KzYSUraQOOq1J89mfTDMZ3NZ4qUAChcPyfpz9ya0bl
nsPX8oElOY21Hlsx532OQvlNGQTw4rt9czK81svrjbBZm94gd10LJNte/8T5wUC0
i9BZ5ajV9bZZ3fCM+nuQhCjWITn3PSWI6v/a3bV781IkySBLuL9OtlVZrVCO/5Ew
uG0Z64d5PNc8cZthq6PHVGbWlN2bEyx6sIB+Wr6wRPSqF5jRaS+N6oL8rUZIomC6
DuVrZ6hxzsIHpFWYqlqGPal9ViEvnnNOPLGBPRTvXn4vdefwijHfiui2GMtQpL6D
w8qRzJksuzqAzJ1topvgMVIoJ1HkUu30F2X5cQnOeVYanjNduJ3oAEXCDFh2qLuS
CCje/Adr2cM=
=6uE0
-----END PGP SIGNATURE-----
Merge tag 'frv-fixes-20121102' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-frv
Pull FRV fixes from David Howells:
"A collection of small fixes for the FRV architecture."
* tag 'frv-fixes-20121102' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-frv:
frv: fix the broken preempt
frv: switch to saner kernel_execve() semantics
FRV: Fix the new-style kernel_thread() stuff
FRV: Fix the preemption handling
FRV: gcc-4.1.2 also inlines weak functions
FRV: Don't objcopy the GNU build_id note
FRV: Add missing linux/export.h #inclusions
This hashtable implementation is using hlist buckets to provide a simple
hashtable to prevent it from getting reimplemented all over the kernel.
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
[ Merging this now, so that subsystems can start applying Sasha's
patches that use this - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Omap no longer needs this option, mach/gpio.h is
empty.
Also remove mach/irqs.h from gpio-omap.h and
include it directly from the related omap1
gpio init files.
Otherwise omap2+ build fails for MULTI_PLATFORM.
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
Cc: Liam Girdwood <lrg@ti.com>
Cc: alsa-devel@alsa-project.org
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Now mach/hardware.h is empty for omap2+ and can be
removed except for plat-omap/dmtimer.c for omap1.
Also the include of mach/irqs.h can now be removed
for shared plat-omap/i2c.c as it's no longer needed.
Signed-off-by: Tony Lindgren <tony@atomide.com>
For OMAP devices, the 32kHz counter is the default clock-source for the kernel.
However, this is not the only possible clock-source the kernel can use for OMAP
devices.
When booting with device-tree, if the 32kHz counter is the desired clock-source
for the kernel, then parse the device-tree blob to ensure that the counter is
present and if so map memory for the counter using the device-tree of_iomap()
function so we are no longer reliant on the OMAP HWMOD framework to do this for
us.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
In order to add device-tree support to the timer driver the following changes
were made ...
1. Allocate system timers (used for clock-events and clock-source) based upon
timer properties rather than using an hard-coded timer instance ID. To allow
this a new helper function called omap_dmtimer_find_by_property() has been
added for finding a timer with the particular properties in the device-tree
blob. Please note that this is an internal helper function for system timers
only to find a timer in the device-tree blob. This cannot be used by device
drivers, another API has been added for that (see below). Timers that are
allocated for system timers are dynamically disabled at boot time by adding
a status property with the value "disabled" to the timer's device-tree node.
Please note that when allocating system timers we now pass a timer ID and
timer property. The timer ID is only be used for allocating a timer when
booting without device-tree. Once device-tree migration is complete, all
the timer ID references will be removed.
2. System timer resources (memory and interrupts) are directly obtained from
the device-tree timer node when booting with device-tree, so that system
timers are no longer reliant upon the OMAP HWMOD framework to provide these
resources.
3. If DT blob is present, then let device-tree create the timer devices
dynamically.
4. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and hence cannot be used to identify a timer
instance. Due to this the following changes were made ...
a). The API omap_dm_timer_request_specific() is not supported when using
device-tree, because it uses the device ID to request a specific timer.
This function will return an error if called when device-tree is present.
Users of this API should use omap_dm_timer_request_by_cap() instead.
b). When removing the DMTIMER driver, the timer "id" was used to identify the
timer instance. The remove function has been modified to use the device
name instead of the "id".
5. When device-tree is present the platform_data structure will be NULL and so
check for this.
6. The OMAP timer device tree binding has the following optional parameters ...
a). ti,timer-alwon --> Timer is in an always-on power domain
b). ti,timer-dsp --> Timer can generate an interrupt to the on-chip DSP
c). ti,timer-pwm --> Timer can generate a PWM output
d). ti,timer-secure --> Timer is reserved on a secure OMAP device
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
OMAP3 devices may or may not have security features enabled. Security enabled
devices are known as high-secure (HS) and devices without security are known as
general purpose (GP).
Some OMAP3 boards, such as the OMAP3 beagle board, only use GP devices and for
GP devices there is a 12th timer available on-chip that can operate at 32kHz.
The clock for 12th timer is generated by an internal oscillator and is unique
this timer. Boards such as the beagle board use this timer as a 32kHz based
clock-events timer because early versions of the board had a hardware problem
preventing them from using other on-chip timers clocked by a external 32kHz
clock.
When booting with device-tree all OMAP3 devices use timer 1 by default for
the clock-events timer. Therefore, add a generic machine descriptor for boards
with OMAP3 GP devices so that they can use the 12th timer as the clock-events
timer instead of the default.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Currently OMAP timers can be requested by requesting any available or by a
numerical device ID. If a specific timer is required because it has a particular
capability, such as can interrupt the on-chip DSP in addition to the ARM CPU,
then the user needs to know the device ID of the timer with this feature.
Therefore, add a new API called omap_dm_timer_request_by_cap() that allows
drivers to request a timer by capability.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
OMAP3 devices may or may not have security features enabled. Security enabled
devices are known as high-secure (HS) and devices without security are known as
general purpose (GP).
For OMAP3 devices there are 12 general purpose timers available. On secure
devices the 12th timer is reserved for secure usage and so cannot be used by
the kernel, where as for a GP device it is available. We can detect the OMAP
device type, secure or GP, at runtime via an on-chip register. Today, when not
using DT, we do not register the 12th timer as a linux device if the device is
secure.
When using device tree, device tree is going to register all the timer devices
it finds in the device tree blob. To prevent device tree from registering 12th
timer on a secure OMAP3 device we can add a status property to the timer
binding with the value "disabled" at boot time. Note that timer 12 on a OMAP3
device has a property "ti,timer-secure" to indicate that it will not be
available on a secure device and so for secure OMAP3 devices, we search for
timers with this property and then disable them. Using the prom_add_property()
function to dynamically add a property was a recommended approach suggested by
Rob Herring [1].
I have tested this on an OMAP3 GP device and faking it to pretend to be a
secure device to ensure that any timers marked with "ti,timer-secure" are not
registered on boot. I have also made sure that all timers are registered as
expected on a GP device by default.
[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/79203
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Just get %icc2 into the state we would have after local_irq_disable()
and physical IRQ having happened since then. Then we can simply
use preempt_schedule_irq() and be done with the whole mess.
Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
The kernel_thread() changes for FRV don't work, and FRV fails to boot,
starting with:
commit 02ce496f15
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Tue Sep 18 22:18:51 2012 -0400
Subject: frv: split ret_from_fork, simplify kernel_thread() a lot
The problem is that the userspace registers are completely cleared when a
kernel thread is created and all subsequent user threads are then copied from
that. Unfortunately, however, the TBR and PSR registers are restored from the
pt_regs and the values they should be set to are clobbered by the memset.
Instead, copy across the old user registers as normal, and then merely alter
GR8 and GR9 in it if we're going to execute a kernel thread.
Signed-off-by: David Howells <dhowells@redhat.com>
Fix the preemption handling in FRV code where the PREEMPT_ACTIVE value is
incorrectly loaded into the threadinfo flags rather than the threadinfo
preemption count.
Unfortunately, the code cannot be simply converted to use
preempt_schedule_irq() as is because FRV uses virtual interrupt disablement to
cut down on the cost of actually disabling interrupts and thus
local_irq_enable() doesn't actually enable interrupts.
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Al Viro <viro@ZenIV.linux.org.uk>
gcc-4.1.2 inlines weak functions, which causes FRV to fail when the dummy
thread_info_cache_init() gets inlined into start_kernel().
Signed-off-by: David Howells <dhowells@redhat.com>
Don't let objcopy transfer the GNU build_id note into the loadable image as it
is located at address 0 and the image ends up >3G in size.
Signed-off-by: David Howells <dhowells@redhat.com>
When watching the irqs name of tegra i2c, all instances
irq name shows as tegra_i2c.
Passing the device name properly to have the irq names with
instance like tegra-i2c.0, tegra-i2c.1 etc.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Acked-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Make sure to clk_prepare as well as clk_enable.
Signed-off-by: Philippe Begnic <philippe.begnic@stericsson.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
This I2C master can do DMA and PIOQUEUE (PIO with FIFO). Originally,
only PIOQUEUE was supported and it had issues, then DMA support was added
this cycle. The original intention was to keep PIOQUEUE since it has
less overhead what is nice for small transfers. However, runtime
switching between PIOQEUE and DMA depending on the transfer size never
worked despite a lot of trying. Since PIOQUEUE mode itself was flaky
(polling at places where interrupts failed to work) and the
implementation also imposed a size limit for transfers, it is best to
remove the support, so users don't fall over its limitations. It also
makes the driver a lot cleaner and more robust. If somebody really wants
less overhead, plain PIO mode could still be implemented with the
addidtional advantage that this mode is also available on MX23, too.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Reviewed-by: Marek Vasut <marex@denx.de>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJQkvQbAAoJEI9vqH3mFV2slX0P/1trXh121qyahs82VY3t7iDN
z4hxO7DW+xum3NYvuJx5/egkkl3NiS1Wyq47RIEdIgI/Isr0tenvmG3f2czl3Qtj
omcNJtLKVo7WxODnl16S6VGDvyRA4OkxzVGD9eidD8Z4+jXLvYyL4WKPiO5SEzTi
jA54j4w+mk2mpFw/5w4IjmDFr7zBKI7ewL7aJ32spcacT+onzSnQzWyod/30cEen
krmMr7M+jBUfGweWYRsM4ur9vf2cNECXQSFMMssDsKd1kHKQmf8lS1qy2rC5PX15
0uK1s/AvzrbTl+PxRg4L/m/R//owdaT3w1mUXQd2LyZdgXq/qAvcPNg+DygIl+MJ
uL+Bb+CD5g7G4YGNTY15oShLUaxVGwZzKV0Xgw0jZYkKgCO8gEduRUlSP3IpVdbD
0kulkyMJoIvw93p8af/ey8YD3YfAaS/qCn4qwQ6UJG7G32ATDDsF093q+y3m6DiX
mPx6i2BY7Jmr2uSiac4eU6L7Myu+JthUwjhfIC9NCwY7nV0mlsq53fKJt8/5Tuu5
MwzorUFTfJkKXaVNhATkVA+E4uTbQhqxvFxzNe+8ojwSIeN758LR80zrRTe5fwQx
qJdyBytLZF8YKhIjoBELgqgfb7QofAXk6FPmQ+4jwgFngrgcx5hizVd7PEoJW2SW
/cJq2tpfr2/pD6BmyFoq
=X45P
-----END PGP SIGNATURE-----
Merge tag 'xtensa-next-20121101' of git://github.com/czankel/xtensa-linux
Pull Xtensa fixes from Chris Zankel:
"Some important bug fixes.
With the change to uapi, there was a bug introduced that results in an
empty syscall table (mult-inclusion bug). Switching to the generic
thread/execve allowed us to fix a bug we had in vfork()."
* tag 'xtensa-next-20121101' of git://github.com/czankel/xtensa-linux:
xtensa: switch to generic sys_execve()
xtensa: switch to generic kernel_execve()
xtensa: switch to generic kernel_thread()
xtensa: reset windowbase/windowstart when cloning the VM
xtensa: use physical addresses for bus addresses
xtensa: allow multi-inclusion for uapi/unistd.h
When buffer sharing with the i915 and using a 1680x1050 monitor,
the i915 gives is a 6912 buffer for the 6720 width, the code doesn't
render this properly as it uses one value to set the base address for
reading from the vmap and for where to start on the device.
This fixes it by calculating the values correctly for the device and
for the pixmap. No idea how I haven't seen this before now.
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
The following fixes build errors on sparc. Without any DT support,
of_match_ptr is NULL and the below is a no-op. However, if just
CONFIG_OF is defined then so is of_match_ptr.
All useful parts of the gpio-fan DT support rely on CONFIG_OF_GPIO
anyway, so of_match_table should too.
Signed-off-by: Jamie Lentin <jm@lentin.co.uk>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Inki writes:
"As I posted before, we have added a new git repository for Exynos drm
to MAINTAINERS file so change it to new one like below,
from git://git.infradead.org/users/kmpark/linux-samsung
to git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos
And this pull request includes the following:
- fix display on issue when user requested dpms mode changing.
- add git repository for Exynos drm to MAINTAINERS file.
- add support for ARCH_MULTIPLATFORM.
- and code clean."
* 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
drm: exynos: removed warning due to missing typecast for mixer driver data
drm/exynos: add support for ARCH_MULTIPLATFORM
MAINTAINERS: Add git repository for Exynos DRM
drm/exynos: fix display on issue
Alex writes:
"This request is mostly load detection fixes from Egbert and me."
* 'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: add load detection support for ext DAC on R200 (v2)
DRM/radeon: For single CRTC GPUs move handling of CRTC_CRT_ON to crtc_dpms().
DRM/Radeon: Fix TV DAC Load Detection for single CRTC chips.
DRM/Radeon: Clean up code in TV DAC load detection.
drm/radeon: fix ATPX function documentation
drivers/gpu/drm/radeon/evergreen_cs.c: Remove unnecessary semicolon
DRM/Radeon: On DVI-I use Load Detection when EDID is bogus.
DRM/Radeon: Fix primary DAC Load Detection for RV100 chips.
DRM/Radeon: Fix Load Detection on legacy primary DAC.
Daniel Vetter writes"
Nothing big at all for -fixes, just small stuff:
- Two patches to fix bugs on i830M
- ums regression fixer due to kicking firmeware fbs (Chris)
- tune down a too loud warning (Jani)
- be more careful with sdvo infoframes, which fixes a long-standing
sdvo-hdmi regression"
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: Only kick out vesafb if we takeover the fbcon with KMS
drm/i915: be less verbose about inability to provide vendor backlight
drm/i915: clear the entire sdvo infoframe buffer
drm/i915: VGA needs to be on pipe A on i830M
drm/i915: fix overlay on i830M
For OMAP4 devices, timers 5-8 have both a L3 bus address and a Cortex-A9
private bus address. Currently the device-tree source only contains the
L3 bus address for these timers. Update these timers to include the
Cortex-A9 private address and make the default address the Cortex-A9
private bus address to match the current HWMOD implementation.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Fix double sizeof when parsing IPv6 address from
user space because it breaks get/del by specific IPv6 address.
Problem noticed by David Binderman:
https://bugzilla.kernel.org/show_bug.cgi?id=49171
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: David S. Miller <davem@davemloft.net>
Reading TCP stats when using TCP Illinois congestion control algorithm
can cause a divide by zero kernel oops.
The division by zero occur in tcp_illinois_info() at:
do_div(t, ca->cnt_rtt);
where ca->cnt_rtt can become zero (when rtt_reset is called)
Steps to Reproduce:
1. Register tcp_illinois:
# sysctl -w net.ipv4.tcp_congestion_control=illinois
2. Monitor internal TCP information via command "ss -i"
# watch -d ss -i
3. Establish new TCP conn to machine
Either it fails at the initial conn, or else it needs to wait
for a loss or a reset.
This is only related to reading stats. The function avg_delay() also
performs the same divide, but is guarded with a (ca->cnt_rtt > 0) at its
calling point in update_params(). Thus, simply fix tcp_illinois_info().
Function tcp_illinois_info() / get_info() is called without
socket lock. Thus, eliminate any race condition on ca->cnt_rtt
by using a local stack variable. Simply reuse info.tcpv_rttcnt,
as its already set to ca->cnt_rtt.
Function avg_delay() is not affected by this race condition, as
its called with the socket lock.
Cc: Petr Matousek <pmatouse@redhat.com>
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Correct spelling typo in net/sctp/socket.c
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix off-by-one error because IFNAMSIZ == 16 and when this
code gets executed we stick a NULL byte where we should not.
How to reproduce:
with CONFIG_CC_STACKPROTECTOR=y (otherwise it may pass by silently)
modprobe bonding; echo 1 > /sys/class/net/bond0/bonding/mode;
echo "AAAAAAAAAAAAAAAA" > /sys/class/net/bond0/bonding/active_slave;
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
Note: Sorry for the second patch but I missed this one while checking
the file. You can squash them into one patch.
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix off-by-one error because IFNAMSIZ == 16 and when this
code gets executed we stick a NULL byte where we should not.
How to reproduce:
with CONFIG_CC_STACKPROTECTOR=y (otherwise it may pass by silently)
modprobe bonding; echo 1 > /sys/class/net/bond0/bonding/mode;
echo "AAAAAAAAAAAAAAAA" > /sys/class/net/bond0/bonding/primary;
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
