| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
Pull firewire fix from Stefan Richter:
"The 1394 drivers cannot and are not supposed to be built on platforms
which don't provide the DMA mapping API (regression since v3.16-rc1
with CONFIG_COMPILE_TEST=y on some architectures)"
* tag 'firewire-fix' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: IEEE 1394 (FireWire) support should depend on HAS_DMA
|
|
https://bugzilla.redhat.com/show_bug.cgi?id=1114768
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
Acer Aspire needs to be added to nomux blacklist, otherwise the touchpad
misbehaves rather randomly.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
|
Tested-and-reported-by: yullaw <yullaw@mageia.cz>
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
|
Detected symbol rate value was returned too small.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
|
Inversion ON was reported as inversion OFF and vice versa.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
|
FEC AUTO is valid for PSK-8 modulation too. Add it.
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
|
Only supported modulation for DVB-S is QPSK. Modulation parameter
contains invalid value for DVB-S on some cases, which leads driver
refusing tuning attempt. Due to that, hard code modulation to QPSK
in case of DVB-S.
Cc: stable@vger.kernel.org
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
|
|
Commit 568f194e8bd16c353ad50f9ab95d98b20578a39d ("net: ppp: use
sk_unattached_filter api") causes sk_chk_filter() to be called twice when
setting a PPP pass or active filter. This applies to both the generic PPP
subsystem implemented by drivers/net/ppp/ppp_generic.c and the ISDN PPP
subsystem implemented by drivers/isdn/i4l/isdn_ppp.c. The first call is from
within get_filter(). The second one is through the call chain
ppp_ioctl() or isdn_ppp_ioctl()
--> sk_unattached_filter_create()
--> __sk_prepare_filter()
--> sk_chk_filter()
The first call from within get_filter() should be deleted as get_filter() is
called just before calling sk_unattached_filter_create() later on, which
eventually calls sk_chk_filter() anyway.
For 3.15.x, this proposed change is a bugfix rather than a pure optimization as
in that branch, sk_chk_filter() may replace filter codes by other codes which
are not recognized when executing sk_chk_filter() a second time. So with
3.15.x, if sk_chk_filter() is called twice, the second invocation may yield
EINVAL (this depends on the filter codes found in the filter to be set, but
because the replacement is done for frequently used codes, this is almost
always the case). The net effect is that setting pass and/or active PPP filters
does not work anymore, since sk_unattached_filter_create() always returns
EINVAL due to the second call to sk_chk_filter(), regardless whether the filter
was originally sane or not.
Signed-off-by: Christoph Schulz <develop@kristov.de>
Acked-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Napi id was not marked for gro_skb, this will lead rx busy loop won't
work correctly since they stack never try to call low latency receive
method because of a zero socket napi id. Fix this by marking napi id
for gro_skb.
The transaction rate of 1 byte netperf tcp_rr gets about 50% increased
(from 20531.68 to 30610.88).
Cc: Amir Vadai <amirv@mellanox.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Obvious copy/paste error when I converted the ad_select to the new
option API. "lacp_rate" there should be "ad_select" so we can get the
proper value.
CC: Jay Vosburgh <j.vosburgh@gmail.com>
CC: Veaceslav Falico <vfalico@gmail.com>
CC: Andy Gospodarek <andy@greyhouse.net>
CC: David S. Miller <davem@davemloft.net>
Fixes: 9e5f5eebe765 ("bonding: convert ad_select to use the new option
API")
Reported-by: Karim Scheik <karim.scheik@prisma-solutions.at>
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The PPP channel MTU is used with Multilink PPP when ppp_mp_explode() (see
ppp_generic module) tries to determine how big a fragment might be. According
to RFC 1661, the MTU excludes the 2-byte PPP protocol field, see the
corresponding comment and code in ppp_mp_explode():
/*
* hdrlen includes the 2-byte PPP protocol field, but the
* MTU counts only the payload excluding the protocol field.
* (RFC1661 Section 2)
*/
mtu = pch->chan->mtu - (hdrlen - 2);
However, the pppoe module *does* include the PPP protocol field in the channel
MTU, which is wrong as it causes the PPP payload to be 1-2 bytes too big under
certain circumstances (one byte if PPP protocol compression is used, two
otherwise), causing the generated Ethernet packets to be dropped. So the pppoe
module has to subtract two bytes from the channel MTU. This error only
manifests itself when using Multilink PPP, as otherwise the channel MTU is not
used anywhere.
In the following, I will describe how to reproduce this bug. We configure two
pppd instances for multilink PPP over two PPPoE links, say eth2 and eth3, with
a MTU of 1492 bytes for each link and a MRRU of 2976 bytes. (This MRRU is
computed by adding the two link MTUs and subtracting the MP header twice, which
is 4 bytes long.) The necessary pppd statements on both sides are "multilink
mtu 1492 mru 1492 mrru 2976". On the client side, we additionally need "plugin
rp-pppoe.so eth2" and "plugin rp-pppoe.so eth3", respectively; on the server
side, we additionally need to start two pppoe-server instances to be able to
establish two PPPoE sessions, one over eth2 and one over eth3. We set the MTU
of the PPP network interface to the MRRU (2976) on both sides of the connection
in order to make use of the higher bandwidth. (If we didn't do that, IP
fragmentation would kick in, which we want to avoid.)
Now we send a ICMPv4 echo request with a payload of 2948 bytes from client to
server over the PPP link. This results in the following network packet:
2948 (echo payload)
+ 8 (ICMPv4 header)
+ 20 (IPv4 header)
---------------------
2976 (PPP payload)
These 2976 bytes do not exceed the MTU of the PPP network interface, so the
IP packet is not fragmented. Now the multilink PPP code in ppp_mp_explode()
prepends one protocol byte (0x21 for IPv4), making the packet one byte bigger
than the negotiated MRRU. So this packet would have to be divided in three
fragments. But this does not happen as each link MTU is assumed to be two bytes
larger. So this packet is diveded into two fragments only, one of size 1489 and
one of size 1488. Now we have for that bigger fragment:
1489 (PPP payload)
+ 4 (MP header)
+ 2 (PPP protocol field for the MP payload (0x3d))
+ 6 (PPPoE header)
--------------------------
1501 (Ethernet payload)
This packet exceeds the link MTU and is discarded.
If one configures the link MTU on the client side to 1501, one can see the
discarded Ethernet frames with tcpdump running on the client. A
ping -s 2948 -c 1 192.168.15.254
leads to the smaller fragment that is correctly received on the server side:
(tcpdump -vvvne -i eth3 pppoes and ppp proto 0x3d)
52:54:00:ad:87:fd > 52:54:00:79:5c:d0, ethertype PPPoE S (0x8864),
length 1514: PPPoE [ses 0x3] MLPPP (0x003d), length 1494: seq 0x000,
Flags [end], length 1492
and to the bigger fragment that is not received on the server side:
(tcpdump -vvvne -i eth2 pppoes and ppp proto 0x3d)
52:54:00:70:9e:89 > 52:54:00:5d:6f:b0, ethertype PPPoE S (0x8864),
length 1515: PPPoE [ses 0x5] MLPPP (0x003d), length 1495: seq 0x000,
Flags [begin], length 1493
With the patch below, we correctly obtain three fragments:
52:54:00:ad:87:fd > 52:54:00:79:5c:d0, ethertype PPPoE S (0x8864),
length 1514: PPPoE [ses 0x1] MLPPP (0x003d), length 1494: seq 0x000,
Flags [begin], length 1492
52:54:00:70:9e:89 > 52:54:00:5d:6f:b0, ethertype PPPoE S (0x8864),
length 1514: PPPoE [ses 0x1] MLPPP (0x003d), length 1494: seq 0x000,
Flags [none], length 1492
52:54:00:ad:87:fd > 52:54:00:79:5c:d0, ethertype PPPoE S (0x8864),
length 27: PPPoE [ses 0x1] MLPPP (0x003d), length 7: seq 0x000,
Flags [end], length 5
And the ICMPv4 echo request is successfully received at the server side:
IP (tos 0x0, ttl 64, id 21925, offset 0, flags [DF], proto ICMP (1),
length 2976)
192.168.222.2 > 192.168.15.254: ICMP echo request, id 30530, seq 0,
length 2956
The bug was introduced in commit c9aa6895371b2a257401f59d3393c9f7ac5a8698
("[PPPOE]: Advertise PPPoE MTU") from the very beginning. This patch applies
to 3.10 upwards but the fix can be applied (with minor modifications) to
kernels as old as 2.6.32.
Signed-off-by: Christoph Schulz <develop@kristov.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This reverts commit 38aecea0ccbb909d635619cba22f1891e589b434.
This breaks Haswell Thinkpad + Lenovo dock in SST mode with a HDMI monitor attached.
Before this we can 1920x1200 mode, after this we only ever get 1024x768, and
a lot of deferring.
This didn't revert clean, but this should be fine.
bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1117008
Cc: stable@vger.kernel.org # v3.15
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
* Remove a duplicate copy of linux_banner from the arm64 EFI stub
which, apart from reducing code duplication also stops the arm64 stub
being rebuilt every time make is invoked - Ard Biesheuvel
* Fix the EFI fdt code to not report a boot error if UEFI is
unavailable since booting without UEFI parameters is a valid use case
for non-UEFI platforms - Catalin Marinas
* Include a .bss section in the EFI boot stub PE/COFF headers to fix a
memory corruption bug - Michael Brown
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
|
|
This reverts commit 886129a8eebeb (ACPI / video: change acpi-video
brightness_switch_enabled default to 0) as it is reported to cause
problems to happen.
Fixes: 886129a8eebeb (ACPI / video: change acpi-video brightness_switch_enabled default to 0)
Link: http://marc.info/?l=linux-acpi&m=140534286826819&w=2
Reported by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Dashes are not allowed in hwmon name attributes.
Use "da9055" instead of "da9055-hwmon".
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Cc: stable@vger.kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
Dashes are not allowed in hwmon name attributes.
Use "da9052" instead of "da9052-hwmon".
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Cc: stable@vger.kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
|
|
commit 98ec77397a5c68ce753dc283aaa6f4742328bcdd
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Wed Apr 30 17:43:01 2014 +0300
drm/i915: Make primary_enabled match the actual hardware state
introduced more accurate tracking of the primary plane and some
checks. It missed the plane->pipe reassignement code for gen2/3
though, which the checks caught and resulted in WARNING backtraces.
Since we only use this path if the plane is on and on the wrong pipe
we can just always set the tracking bit to "enabled".
Reported-and-tested-by: Paul Bolle <pebolle@tiscali.nl>
Cc: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The sata on fsl mpc8315e is broken after the commit 8a4aeec8d2d6
("libata/ahci: accommodate tag ordered controllers"). The reason is
that the ata controller on this SoC only implement a queue depth of
16. When issuing the commands in tag order, all the commands in tag
16 ~ 31 are mapped to tag 0 unconditionally and then causes the sata
malfunction. It makes no senses to use a 32 queue in software while
the hardware has less queue depth. So consider the queue depth
implemented by the hardware when requesting a command tag.
Fixes: 8a4aeec8d2d6 ("libata/ahci: accommodate tag ordered controllers")
Cc: stable@vger.kernel.org
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
|
|
The hwrng core asks for random data in the hwrng_register() call itself
from commit d9e7972619. This doesn't play well with virtio -- the
DRIVER_OK bit is only set by virtio core on a successful probe, and
we're not yet out of our probe routine when this call is made. This
causes the host to not acknowledge any requests we put in the virtqueue,
and the insmod or kernel boot process just waits for data to arrive from
the host, which never happens.
CC: Kees Cook <keescook@chromium.org>
CC: Jason Cooper <jason@lakedaemon.net>
CC: Herbert Xu <herbert@gondor.apana.org.au>
CC: <stable@vger.kernel.org> # For v3.15+
Reviewed-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Commit d9e7972619334 "hwrng: add randomness to system from rng sources"
added a call to rng_get_data() from the hwrng_register() function.
However, some rng devices need initialization before data can be read
from them.
This commit makes the call to rng_get_data() depend on no init fn
pointer being registered by the device. If an init function is
registered, this call is made after device init.
CC: Kees Cook <keescook@chromium.org>
CC: Jason Cooper <jason@lakedaemon.net>
CC: Herbert Xu <herbert@gondor.apana.org.au>
CC: <stable@vger.kernel.org> # For v3.15+
Signed-off-by: Amit Shah <amit.shah@redhat.com>
Reviewed-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
commit c675949ec58ca50d5a3ae3c757892f1560f6e896
drm/i915: do not setup backlight if not available according to VBT
caused a regression on the HP Chromebook 14 (with Celeron 2955U CPU),
which has a misconfigured VBT. Apply quirk to ignore the VBT backlight
presence check during backlight setup.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79813
Signed-off-by: Scot Doyle <lkml14@scotdoyle.com>
Tested-by: Stefan Nagy <public@stefan-nagy.at>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
This reverts commit 773875bfb6737982903c42d1ee88cf60af80089c.
It is very much needed and the lack of dithering has been reported by
a large list of people with various gen2/3 hardware.
Also, the original patch was complete non-sense since the WARNING
backtraces in the references bugzilla are about
gmch_pfit.lvds_border_bits mismatch, not at all about the dither bit.
That one seems to work.
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Hans de Bruin <jmdebruin@xmsnet.nl>
Cc: stable@vger.kernel.org
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
RGMII_MODE_EN bit was defined to 0, while it is actually 6. It was not
much of a problem on older designs where this was a no-op, and the RGMII
data-path would always be enabled, but newer GENET controllers need to
explicitely enable their RGMII data-pad using this bit.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This family of chips was long ago supported by the pre-cfi driver.
CFI code tested on several Zaurus SL-5500 (Collie) 2x16 on 32 bit bus.
Function is_LH28F640BF() mimics is_m29ew() from cmdset_0002.c
Buffer write fixes as seen in 2007 patch c/o
Anti Sullin <anti.sullin <at> artecdesign.ee>
http://comments.gmane.org/gmane.linux.ports.arm.kernel/36733
[Brian: this patch is semi-urgent, because the following patch switches
to using CFI detection for a chip which (until now) is unsupported by
the CFI driver
9218310 ARM: 8084/1: sa1100: collie: revert back to cfi_probe
]
Signed-off-by: Andrea Adami <andrea.adami@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
In commit 67a9ad9b8a6f ("mtd: nand: Warn the user if the selected ECC
strength is too weak"), a check was added to inform the user when the
ECC used for a NAND device is weaker than the recommended ECC
advertised by the NAND chip. However, the warning uses WARN_ON(),
which has two undesirable side-effects:
- It just prints to the kernel log the fact that there is a warning
in this file, at this line, but it doesn't explain anything about
the warning itself.
- It dumps a stack trace which is very noisy, for something that the
user is most likely not able to fix. If a certain ECC used by the
kernel is weaker than the advertised one, it's most likely to make
sure the kernel uses an ECC that is compatible with the one used by
the bootloader, and changing the bootloader may not necessarily be
easy. Therefore, normal users would not be able to do anything to
fix this very noisy warning, and will have to suffer from it at
every kernel boot. At least every time I see this stack trace in my
kernel boot log, I wonder what new thing is broken, just to realize
that it's once again this NAND ECC warning.
Therefore, this commit turns:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at /home/thomas/projets/linux-2.6/drivers/mtd/nand/nand_base.c:4051 nand_scan_tail+0x538/0x780()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 3.16.0-rc3-dirty #4
[<c000e3dc>] (unwind_backtrace) from [<c000bee4>] (show_stack+0x10/0x14)
[<c000bee4>] (show_stack) from [<c0018180>] (warn_slowpath_common+0x6c/0x8c)
[<c0018180>] (warn_slowpath_common) from [<c001823c>] (warn_slowpath_null+0x1c/0x24)
[<c001823c>] (warn_slowpath_null) from [<c02c50cc>] (nand_scan_tail+0x538/0x780)
[<c02c50cc>] (nand_scan_tail) from [<c0639f78>] (orion_nand_probe+0x224/0x2e4)
[<c0639f78>] (orion_nand_probe) from [<c026da00>] (platform_drv_probe+0x18/0x4c)
[<c026da00>] (platform_drv_probe) from [<c026c1f4>] (really_probe+0x80/0x218)
[<c026c1f4>] (really_probe) from [<c026c47c>] (__driver_attach+0x98/0x9c)
[<c026c47c>] (__driver_attach) from [<c026a8f0>] (bus_for_each_dev+0x64/0x94)
[<c026a8f0>] (bus_for_each_dev) from [<c026bae4>] (bus_add_driver+0x144/0x1ec)
[<c026bae4>] (bus_add_driver) from [<c026cb00>] (driver_register+0x78/0xf8)
[<c026cb00>] (driver_register) from [<c026da5c>] (platform_driver_probe+0x20/0xb8)
[<c026da5c>] (platform_driver_probe) from [<c00088b8>] (do_one_initcall+0x80/0x1d8)
[<c00088b8>] (do_one_initcall) from [<c0620c9c>] (kernel_init_freeable+0xf4/0x1b4)
[<c0620c9c>] (kernel_init_freeable) from [<c049a098>] (kernel_init+0x8/0xec)
[<c049a098>] (kernel_init) from [<c00095f0>] (ret_from_fork+0x14/0x24)
---[ end trace 62f87d875aceccb4 ]---
Into the much shorter, and much more useful:
nand: WARNING: MT29F2G08ABAEAWP: the ECC used on your system is too weak compared to the one required by the NAND chip
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
4th set of fixes for IIO in the 3.16 cycle
* Fix incorrect handling of the iio_event_spec mask_shared_by_type
bitmap. The point of this was to allow multiple channels to specify
elements that lead to the same sysfs attribute. A but in the handling
meant that this failed. The handling is modified to be similar to that
used for the main IIO info_mask_shared_by_type which works correclty.
* The acceleration scale factors reported by the mma8452 driver gave
accelerations in g, wherease the IIO ABI is in m/s^2. The fix simply
corrects the reported scale factors.
|
|
git://git.linaro.org/people/mike.turquette/linux
Pull clock driver fixes from Mike Turquette:
"This batch of fixes is for a handful of clock drivers from Allwinner,
Samsung, ST & TI. Most of them are of the "this hardware won't work
without this fix" variety, including patches that fix platforms that
did not boot under certain configurations. Other fixes are the result
of changes to the clock core introduced in 3.15 that had subtle
impacts on the clock drivers.
There are no fixes to the clock framework core in this pull request"
* tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mike.turquette/linux:
clk: spear3xx: Set proper clock parent of uart1/2
clk: spear3xx: Use proper control register offset
clk: qcom: HDMI source sel is 3 not 2
clk: sunxi: fix devm_ioremap_resource error detection code
clk: s2mps11: Fix double free corruption during driver unbind
clk: ti: am43x: Fix boot with CONFIG_SOC_AM33XX disabled
clk: exynos5420: Remove aclk66_peric from the clock tree description
clk/exynos5250: fix bit number for tv sysmmu clock
clk: s3c64xx: Hookup SPI clocks correctly
clk: samsung: exynos4: Remove SRC_MASK_ISP gates
clk: samsung: add more aliases for s3c24xx
clk: samsung: fix several typos to fix boot on s3c2410
clk: ti: set CLK_SET_RATE_NO_REPARENT for ti,mux-clock
clk: ti: am43x: Fix boot with CONFIG_SOC_AM33XX disabled
clk: ti: dra7: return error code in failure case
clk: ti: apll: not allocating enough data
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Olof Johansson:
"This week's arm-soc fixes:
- Another set of OMAP fixes
* Clock fixes
* Restart handling
* PHY regulators
* SATA hwmod data for DRA7
+ Some trivial fixes and removal of a bit of dead code
- Exynos fixes
* A bunch of clock fixes
* Some SMP fixes
* Exynos multi-core timer: register as clocksource and fix ftrace.
+ a few other minor fixes
There's also a couple more patches, and at91 fix for USB caused by
common clock conversion, and more MAINTAINERS entries for shmobile.
We're definitely switching to only regression fixes from here on out,
we've been a little less strict than usual up until now"
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (26 commits)
ARM: at91: at91sam9x5: add clocks for usb device
ARM: EXYNOS: Register cpuidle device only on exynos4210 and 5250
ARM: dts: Add clock property for mfc_pd in exynos5420
clk: exynos5420: Add IDs for clocks used in PD mfc
ARM: EXYNOS: Add support for clock handling in power domain
ARM: OMAP2+: Remove non working OMAP HDMI audio initialization
ARM: imx: fix shared gate clock
ARM: dts: Update the parent for Audss clocks in Exynos5420
ARM: EXYNOS: Update secondary boot addr for secure mode
ARM: dts: Fix TI CPSW Phy mode selection on IGEP COM AQUILA.
ARM: dts: am335x-evmsk: Enable the McASP FIFO for audio
ARM: dts: am335x-evm: Enable the McASP FIFO for audio
ARM: OMAP2+: Make GPMC skip disabled devices
ARM: OMAP2+: create dsp device only on OMAP3 SoCs
ARM: dts: dra7-evm: Make VDDA_1V8_PHY supply always on
ARM: DRA7/AM43XX: fix header definition for omap44xx_restart
ARM: OMAP2+: clock/dpll: fix _dpll_test_fint arithmetics overflow
ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss
ARM: DRA7: hwmod: Fixup SATA hwmod
ARM: OMAP3: PRM/CM: Add back macros used by TI DSP/Bridge driver
...
|
|
Commit b3d681a4fc108f9653bbb44e4f4e72db2b8a5734 ("firewire: Use
COMPILE_TEST for build testing") added COMPILE_TEST as an alternative
dependency for the purpose of build testing the firewire core.
However, this bypasses all other implicit dependencies assumed by PCI,
like HAS_DMA.
If NO_DMA=y:
drivers/built-in.o: In function `fw_iso_buffer_destroy':
(.text+0x36a096): undefined reference to `dma_unmap_page'
drivers/built-in.o: In function `fw_iso_buffer_map_dma':
(.text+0x36a164): undefined reference to `dma_map_page'
drivers/built-in.o: In function `fw_iso_buffer_map_dma':
(.text+0x36a172): undefined reference to `dma_mapping_error'
drivers/built-in.o: In function `sbp2_send_management_orb':
sbp2.c:(.text+0x36c6b4): undefined reference to `dma_map_single'
sbp2.c:(.text+0x36c6c8): undefined reference to `dma_mapping_error'
sbp2.c:(.text+0x36c772): undefined reference to `dma_map_single'
sbp2.c:(.text+0x36c786): undefined reference to `dma_mapping_error'
sbp2.c:(.text+0x36c854): undefined reference to `dma_unmap_single'
sbp2.c:(.text+0x36c872): undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `sbp2_map_scatterlist':
sbp2.c:(.text+0x36ccbc): undefined reference to `scsi_dma_map'
sbp2.c:(.text+0x36cd36): undefined reference to `dma_map_single'
sbp2.c:(.text+0x36cd4e): undefined reference to `dma_mapping_error'
sbp2.c:(.text+0x36cd84): undefined reference to `scsi_dma_unmap'
drivers/built-in.o: In function `sbp2_unmap_scatterlist':
sbp2.c:(.text+0x36cda6): undefined reference to `scsi_dma_unmap'
sbp2.c:(.text+0x36cdc6): undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `complete_command_orb':
sbp2.c:(.text+0x36d6ac): undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `sbp2_scsi_queuecommand':
sbp2.c:(.text+0x36d8e0): undefined reference to `dma_map_single'
sbp2.c:(.text+0x36d8f6): undefined reference to `dma_mapping_error'
Add an explicit dependency on HAS_DMA to fix this.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
|
We need to only register with the iwpm core once. Currently it is
being done for every adapter, which causes a failure for each adapter
but the first, making multiple adapters unusable.
Fixes: 9eccfe109b27 ("RDMA/cxgb4: Add support for iWARP Port Mapper user space service")
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Roland Dreier <roland@purestorage.com>
|
|
The uarts only work when the parent is ras_ahb_clk. The stale 3.5
based ST tree does this in the board file.
Add it to the clk init function. Not pretty, but the mess there is
amazing anyway.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
The control register is at offset 0x10, not 0x0. This is wreckaged
since commit 5df33a62c (SPEAr: Switch to common clock framework).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
Pull slave-dmaengine fixes from Vinod Koul:
"We have two small fixes. First one from Daniel to handle 0-length
packets for usb cppi dma. Second by Russell for imx-sdam cyclic
residue reporting"
* 'fixes' of git://git.infradead.org/users/vkoul/slave-dma:
Update imx-sdma cyclic handling to report residue
dma: cppi41: handle 0-length packets
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into fixes
Merge "Samsung fixes-3 for 3.16" from Kukjin Kim:
Samsung fixes-3 for v3.16
- update the parent for Auudss clock because kernel will be hang
during late boot if the parent clock is disabled in bootloader.
- enable clk handing in power domain because while power domain
on/off, its regarding clock source will be reset and it causes
a problem so need to handle it.
- add mux clocks to be used by power domain for exynos5420-mfc
during power domain on/off and property in device tree also.
- register cpuidle only for exynos4210 and exynos5250 because a
system failure will be happened on other exynos SoCs.
* tag 'samsung-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: EXYNOS: Register cpuidle device only on exynos4210 and 5250
ARM: dts: Add clock property for mfc_pd in exynos5420
clk: exynos5420: Add IDs for clocks used in PD mfc
ARM: EXYNOS: Add support for clock handling in power domain
ARM: dts: Update the parent for Audss clocks in Exynos5420
Signed-off-by: Olof Johansson <olof@lixom.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are some small USB fixes, PHY driver fixes (they ended up in this
tree for lack of somewhere else to put them), and some new USB device
ids"
* tag 'usb-3.16-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
phy: omap-usb2: Balance pm_runtime_enable() on probe failure and remove
phy: core: Fix error path in phy_create()
drivers: phy: phy-samsung-usb2.c: Add missing MODULE_DEVICE_TABLE
phy: omap-usb2: fix devm_ioremap_resource error detection code
phy: sun4i: depend on RESET_CONTROLLER
USB: serial: ftdi_sio: Add Infineon Triboard
USB: ftdi_sio: Add extra PID.
usb: option: Add ID for Telewell TW-LTE 4G v2
USB: cp210x: add support for Corsair usb dongle
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull tty/serial fixes from Greg KH:
"Here are some small serial fixes that resolve some reported problems
that started in 3.15 with some serial drivers.
And there's a new dt binding for a serial driver, which was all that
was needed for the renesas serial driver"
* tag 'tty-3.16-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
serial: sh-sci: Add device tree support for r8a7{778,740,3a4} and sh73a0
serial: imx: Fix build breakage
serial: arc_uart: Use uart_circ_empty() for open-coded comparison
serial: Test for no tx data on tx restart
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver fixes from Greg KH:
"Here are two hyperv driver fixes, and one i8k driver fix for 3.16"
* tag 'char-misc-3.16-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
i8k: Fix non-SMP operation
Drivers: hv: util: Fix a bug in the KVP code
Drivers: hv: vmbus: Fix a bug in the channel callback dispatch code
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull IIO fixes from Greg KH:
"Here are some IIO driver fixes for 3.16-rc5. Nothing major, just
resolves some minor issues that have been reported"
* tag 'staging-3.16-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
iio: ti_am335x_adc: Fix: Use same step id at FIFOs both ends
iio:tcs3472: Check for buffer enabled and locking
iio: hid-sensor-prox: Fix return values
iio: hid-sensor-gyro-3d: Fix return values
iio: hid-sensor-als: Fix return values
iio: hid-sensor-magn-3d: Fix return values
iio: hid-sensor-accel-3d: Fix return values
iio: hid-sensor-press: Fix return values
|
|
The userspace interface for acceleration sensors is documented as using
m/s^2 units [Documentation/ABI/testing/sysfs-bus-iio]
The fullscale raw value for the mma8452 (-2048) corresponds to -2G, -4G or -8G
depending on the seleted mode.
The scale table was converting to G rather than m/s^2.
Change the scaling table to match the documented interface.
Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Cc: stable@vger.kernel.org
|
|
If probe fails then we need to call pm_runtime_disable() to balance
out the previous pm_runtime_enable() call. Else it will cause
unbalanced pm_runtime_enable() call in the succeding probe call.
This anomaly was observed when the call to devm_phy_create() failed
with -EPROBE_DEFER.
Balance out the pm_runtime_enable() call in .remove() as well.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Prevent resources from being freed twice in case device_add() call
fails within phy_create(). Also use ida_simple_remove() instead of
ida_remove() as we had used ida_simple_get() to allocate the ida.
Cc: 3.13+ <stable@vger.kernel.org> # 3.13+
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Allow phy-exynos-usb2 to be autoloaded based on devicetree information.
Tested on Odroid X2 with its USB subsystem build as modules.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
devm_ioremap_resource returns an ERR_PTR value, not NULL, on failure.
A simplified version of the semantic match that finds this problem is as
follows:
// <smpl>
@@
expression e,e1;
statement S;
@@
*e = devm_ioremap_resource(...);
if (!e1) S
// </smpl>
Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The driver depend on the reset framework in a mandatory way. Make sure
reset_control_get is defined by adding this dependency in Kconfig
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This adds support for Infineon TriBoard TC1798 [1]. Only interface 1
is used as serial line (see [2], Figure 8-6).
[1] http://www.infineon.com/cms/de/product/microcontroller/development-tools-software-and-kits/tricore-tm-development-tools-software-and-kits/starterkits-and-evaluation-boards/starter-kit-tc1798/channel.html?channel=db3a304333b8a7ca0133cfa3d73e4268
[2] http://www.infineon.com/dgdl/TriBoardManual-TC1798-V10.pdf?folderId=db3a304412b407950112b409ae7c0343&fileId=db3a304333b8a7ca0133cfae99fe426a
Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
Cc: Johan Hovold <johan@kernel.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commits 9ec36ca (of/irq: do irq resolution in platform_get_irq)
and ad69674 (of/irq: do irq resolution in platform_get_irq_byname)
change the semantics of platform_get_irq and platform_get_irq_byname
to always rely on devicetree information if devicetree is enabled
and if a devicetree node is attached to the device. The functions
now return an error if the devicetree data does not include interrupt
information, even if the information is available as platform resource
data.
This causes mfd client drivers to fail if the interrupt number is
passed via platform resources. Therefore, if of_irq_get fails, try
platform_get_resource as method of last resort. This restores the
original functionality for drivers depending on platform resources
to get irq information.
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Rob Herring <robh@kernel.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Fix breakage introduced by
commit c557d392fbf5badd693ea1946a4317c87a26a716,
'serial: Test for no tx data on tx restart'.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The transport offset of the IPv4 packet should be fixed and wouldn't
be out of the hw limitation, so the r8152_csum_workaround() should
be used for IPv6 packets.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
On BE3, if the clear-interrupt bit of the EQ doorbell is not set the first
time it is armed, ocassionally we have observed that the EQ doesn't raise
anymore interrupts even if it is in armed state.
This patch fixes this by setting the clear-interrupt bit when EQs are
armed for the first time in be_open().
Signed-off-by: Suresh Reddy <Suresh.Reddy@emulex.com>
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
