| Age | Commit message (Collapse) | Author |
|---|
|
Plane rotation with omapdrm is currently broken.
It seems omap_plane_mode_set() expects width and height in screen
coordinates, so pass it like that.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
|
|
At the moment the omap_crtc_pre_apply() handles the enabling, disabling
and configuring of encoders and panels separately from the CRTC (i.e.
the overlay manager).
However, this doesn't work correctly. The encoder driver has to be in
control of its video input (i.e. the crtc) for correct operation.
This problem causes bugs with (at least) HDMI: the HDMI encoder supplies
pixel clock for DISPC, and DISPC supplies video stream for HDMI. The
current code first enables the HDMI encoder, and CRTC after that.
However, the encoder expects the video stream to start during the
encoder's enable, and if it doesn't, there will be sync lost errors.
The encoder enables its video source by calling src->enable(), and this
call goes to omapdrm (omap_crtc_enable), but omapdrm doesn't do anything
in that function. Similarly for disable, which goes to
omap_crtc_disable().
This patch moves the code to setup and enable/disable the crtc to
omap_crtc_enable. and omap_crtc_disable().
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
|
|
When an encoder is no longer connected to a crtc, the driver will leave
the encoder enabled.
This patch adds code to track the encoder used for a crtc, and when the
encoder changes, the old one is disabled.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
|
|
At module unload, omap_fbdev_free() gets called which releases the
framebuffers. However, the framebuffers are still used by crtcs, and
will be released only later at vsync. The driver doesn't wait for this,
and goes on to release the rest of the resources, which often
causes a crash.
This patchs adds a omap_crtc_flush() function which waits until the crtc
has finished with its apply queue and page flips.
The function utilizes a simple polling while-loop, as the performance is
not an issue here.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
|
|
At the moment the DMM driver is never unregistered, even if it's
registered in the omapdrm module's init function. This means we'll get
errors when reloading the omapdrm module.
Fix this by unregistering the DMM driver properly, and also change the
module init to fail if DMM driver cannot be registered, simplifying the
unregister path as we don't need to keep the state whether we registered
the DMM driver or not.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
|
|
When unloading omapdrm driver, the omapdrm platform device is
uninitialized last, after the displays have been disconnected omap_crtc
callbacks have been removed. As the omapdrm pdev uninitialization needs
the features uninitialized in earlier steps, a crash is guaranteed.
This patch fixes the uninitialize order so that the omapdrm pdev is
removed first.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Rob Clark <robdclark@gmail.com>
|
|
At the moment it's quite easy to get the following errors when the HDMI
output is enabled or disabled:
[drm:omap_crtc_error_irq] *ERROR* tv: errors: 00008000
The reason for the errors is that the omapdrm driver doesn't properly
handle the sync-lost irqs that happen when enabling the DIGIT crtc,
which is used for HDMI and analog TV. The driver does disable the
sync-lost irq properly, but it fails to wait until the output has been
fully enabled (i.e. the first vsync), so the sync-lost errors are still
seen occasionally.
This patch makes the omapdrm act the same way as the omapfb does:
- When enabling a display, we'll wait for the first vsync.
- When disabling a display, we'll wait for framedone if available, or
odd and even vsyncs.
These changes make sure the output is fully enabled or disabled at the
end of the function.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: Sanjay Singh Rawat <sanjay.rawat@linaro.org>
Reviewed-by: Rob Clark <robdclark@gmail.com>
|
|
The CW1200 WLAN chip driver had been in the kernel for a while,
we only need to activate it for the Ux500 properly. The latter
require some elaborative work, but in the meantime, let's make
sure we atleast compile it in.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Signed-off-by: Kailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
nft_cmp_fast is used for equality comparisions of size <= 4. For
comparisions of size < 4 byte a mask is calculated that is applied to
both the data from userspace (during initialization) and the register
value (during runtime). Both values are stored using (in effect) memcpy
to a memory area that is then interpreted as u32 by nft_cmp_fast.
This works fine on little endian since smaller types have the same base
address, however on big endian this is not true and the smaller types
are interpreted as a big number with trailing zero bytes.
The mask therefore must not include the lower bytes, but the higher bytes
on big endian. Add a helper function that does a cpu_to_le32 to switch
the bytes on big endian. Since we're dealing with a mask of just consequitive
bits, this works out fine.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
[ 251.920788] INFO: trying to register non-static key.
[ 251.921386] the code is fine but needs lockdep annotation.
[ 251.921386] turning off the locking correctness validator.
[ 251.921386] CPU: 2 PID: 15715 Comm: socket_listen Not tainted 3.14.0+ #294
[ 251.921386] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 251.921386] 0000000000000000 000000009d18c210 ffff880075f039b8 ffffffff816b7ecd
[ 251.921386] ffffffff822c3b10 ffff880075f039c8 ffffffff816b36f4 ffff880075f03aa0
[ 251.921386] ffffffff810c65ff ffffffff810c4a85 00000000fffffe01 ffffffffa0075172
[ 251.921386] Call Trace:
[ 251.921386] [<ffffffff816b7ecd>] dump_stack+0x45/0x56
[ 251.921386] [<ffffffff816b36f4>] register_lock_class.part.24+0x38/0x3c
[ 251.921386] [<ffffffff810c65ff>] __lock_acquire+0x168f/0x1b40
[ 251.921386] [<ffffffff810c4a85>] ? trace_hardirqs_on_caller+0x105/0x1d0
[ 251.921386] [<ffffffffa0075172>] ? nf_nat_setup_info+0x252/0x3a0 [nf_nat]
[ 251.921386] [<ffffffff816c1215>] ? _raw_spin_unlock_bh+0x35/0x40
[ 251.921386] [<ffffffffa0075172>] ? nf_nat_setup_info+0x252/0x3a0 [nf_nat]
[ 251.921386] [<ffffffff810c7272>] lock_acquire+0xa2/0x120
[ 251.921386] [<ffffffffa008ab90>] ? ipv4_confirm+0x90/0xf0 [nf_conntrack_ipv4]
[ 251.921386] [<ffffffffa0055989>] __nf_conntrack_confirm+0x129/0x410 [nf_conntrack]
[ 251.921386] [<ffffffffa008ab90>] ? ipv4_confirm+0x90/0xf0 [nf_conntrack_ipv4]
[ 251.921386] [<ffffffffa008ab90>] ipv4_confirm+0x90/0xf0 [nf_conntrack_ipv4]
[ 251.921386] [<ffffffff815e7b00>] ? ip_fragment+0x9f0/0x9f0
[ 251.921386] [<ffffffff815d8c5a>] nf_iterate+0xaa/0xc0
[ 251.921386] [<ffffffff815e7b00>] ? ip_fragment+0x9f0/0x9f0
[ 251.921386] [<ffffffff815d8d14>] nf_hook_slow+0xa4/0x190
[ 251.921386] [<ffffffff815e7b00>] ? ip_fragment+0x9f0/0x9f0
[ 251.921386] [<ffffffff815e98f2>] ip_output+0x92/0x100
[ 251.921386] [<ffffffff815e8df9>] ip_local_out+0x29/0x90
[ 251.921386] [<ffffffff815e9240>] ip_queue_xmit+0x170/0x4c0
[ 251.921386] [<ffffffff815e90d5>] ? ip_queue_xmit+0x5/0x4c0
[ 251.921386] [<ffffffff81601208>] tcp_transmit_skb+0x498/0x960
[ 251.921386] [<ffffffff81602d82>] tcp_connect+0x812/0x960
[ 251.921386] [<ffffffff810e3dc5>] ? ktime_get_real+0x25/0x70
[ 251.921386] [<ffffffff8159ea2a>] ? secure_tcp_sequence_number+0x6a/0xc0
[ 251.921386] [<ffffffff81606f57>] tcp_v4_connect+0x317/0x470
[ 251.921386] [<ffffffff8161f645>] __inet_stream_connect+0xb5/0x330
[ 251.921386] [<ffffffff8158dfc3>] ? lock_sock_nested+0x33/0xa0
[ 251.921386] [<ffffffff810c4b5d>] ? trace_hardirqs_on+0xd/0x10
[ 251.921386] [<ffffffff81078885>] ? __local_bh_enable_ip+0x75/0xe0
[ 251.921386] [<ffffffff8161f8f8>] inet_stream_connect+0x38/0x50
[ 251.921386] [<ffffffff8158b157>] SYSC_connect+0xe7/0x120
[ 251.921386] [<ffffffff810e3789>] ? current_kernel_time+0x69/0xd0
[ 251.921386] [<ffffffff810c4a85>] ? trace_hardirqs_on_caller+0x105/0x1d0
[ 251.921386] [<ffffffff810c4b5d>] ? trace_hardirqs_on+0xd/0x10
[ 251.921386] [<ffffffff8158c36e>] SyS_connect+0xe/0x10
[ 251.921386] [<ffffffff816caf69>] system_call_fastpath+0x16/0x1b
[ 312.014104] INFO: rcu_sched detected stalls on CPUs/tasks: {} (detected by 0, t=60003 jiffies, g=42359, c=42358, q=333)
[ 312.015097] INFO: Stall ended before state dump start
Fixes: 93bb0ceb75be ("netfilter: conntrack: remove central spinlock nf_conntrack_lock")
Cc: Jesper Dangaard Brouer <brouer@redhat.com>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
Dan Carpenter's static code checker reports:
The patch 473ed7be0da0: "gpio / ACPI: Add support for ACPI GPIO
operation regions" from Mar 14, 2014, leads to the following static
checker warning:
drivers/gpio/gpiolib-acpi.c:454 acpi_gpio_adr_space_handler()
warn: should 'gpiod_get_raw_value(desc) << i' be a 64 bit type?
This is due the fact that *value is of type u64 and gpiod_get_raw_value()
returns int. Since i can be larger than 31, it is possible that the value
returned gets wrapped.
Fix this by casting the return of gpiod_get_raw_value() to u64 first before
shift.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Commit aa92b6f689ac (gpio / ACPI: Allocate ACPI specific data directly in
acpi_gpiochip_add()) moved ACPI handle checking to acpi_gpiochip_add() but
forgot to check whether chip->dev is NULL before dereferencing it.
Since chip->dev pointer is optional we can end up with crash like following:
BUG: unable to handle kernel NULL pointer dereference at 00000138
IP: [<c126c2b3>] acpi_gpiochip_add+0x13/0x190
*pde = 00000000
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: ssb(+) ...
CPU: 0 PID: 512 Comm: modprobe Tainted: G W 3.14.0-rc7-next-20140324-t1 #24
Hardware name: Dell Inc. Latitude D830 /0UY141, BIOS A02 06/07/2007
task: f5799900 ti: f543e000 task.ti: f543e000
EIP: 0060:[<c126c2b3>] EFLAGS: 00010282 CPU: 0
EIP is at acpi_gpiochip_add+0x13/0x190
EAX: 00000000 EBX: f57824c4 ECX: 00000000 EDX: 00000000
ESI: f57824c4 EDI: 00000010 EBP: f543fc54 ESP: f543fc40
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
CR0: 8005003b CR2: 00000138 CR3: 355f8000 CR4: 000007d0
Stack:
f543fc5c fd1f7790 f57824c4 000000be 00000010 f543fc84 c1269f4e f543fc74
fd1f78bd 00008002 f57822b0 f5782090 fd1f8400 00000286 fd1f9994 00000000
f5782000 f543fc8c fd1f7e39 f543fcc8 fd1f0bd8 000000c0 00000000 00000000
Call Trace:
[<fd1f7790>] ? ssb_pcie_mdio_write+0xa0/0xd0 [ssb]
[<c1269f4e>] gpiochip_add+0xee/0x300
[<fd1f78bd>] ? ssb_pcicore_serdes_workaround+0xfd/0x140 [ssb]
[<fd1f7e39>] ssb_gpio_init+0x89/0xa0 [ssb]
[<fd1f0bd8>] ssb_attach_queued_buses+0xc8/0x2d0 [ssb]
[<fd1f0f65>] ssb_bus_register+0x185/0x1f0 [ssb]
[<fd1f3120>] ? ssb_pci_xtal+0x220/0x220 [ssb]
[<fd1f106c>] ssb_bus_pcibus_register+0x2c/0x80 [ssb]
[<fd1f40dc>] ssb_pcihost_probe+0x9c/0x110 [ssb]
[<c1276c8f>] pci_device_probe+0x6f/0xc0
[<c11bdb55>] ? sysfs_create_link+0x25/0x40
[<c131d8b9>] driver_probe_device+0x79/0x360
[<c1276512>] ? pci_match_device+0xb2/0xc0
[<c131dc51>] __driver_attach+0x71/0x80
[<c131dbe0>] ? __device_attach+0x40/0x40
[<c131bd87>] bus_for_each_dev+0x47/0x80
[<c131d3ae>] driver_attach+0x1e/0x20
[<c131dbe0>] ? __device_attach+0x40/0x40
[<c131d007>] bus_add_driver+0x157/0x230
[<c131e219>] driver_register+0x59/0xe0
...
Fix this by checking chip->dev pointer against NULL first. Also we can now
remove redundant check in acpi_gpiochip_request/free_interrupts().
Reported-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Sabrina Dubroca <sd@queasysnail.net>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Tested-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
During irq mapping, in irq_set_chip_and_handler() the process
of setting this up may incur calls to lock the irqchip, which
in turn may need to dereference and use the chip data. So set
the data first, then set the chip and handler.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
When we are zeroing space andit is covered by a delalloc range, we
need to punch the delalloc range out before we truncate the page
cache. Failing to do so leaves and inconsistency between the page
cache and the extent tree, which we later trip over when doing
direct IO over the same range.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Tested-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
|
|
Similar to the write_begin problem, xfs-vm_write_end will truncate
back to the old EOF, potentially removing page cache from over the
top of delalloc blocks with valid data in them. Fix this by
truncating back to just the start of the failed write.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Tested-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
|
|
If we fail a write beyond EOF and have to handle it in
xfs_vm_write_begin(), we truncate the inode back to the current inode
size. This doesn't take into account the fact that we may have
already made successful writes to the same page (in the case of block
size < page size) and hence we can truncate the page cache away from
blocks with valid data in them. If these blocks are delayed
allocation blocks, we now have a mismatch between the page cache and
the extent tree, and this will trigger - at minimum - a delayed
block count mismatch assert when the inode is evicted from the cache.
We can also trip over it when block mapping for direct IO - this is
the most common symptom seen from fsx and fsstress when run from
xfstests.
Fix it by only truncating away the exact range we are updating state
for in this write_begin call.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Tested-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
|
|
When a write fails, if we don't clear the delalloc flags from the
buffers over the failed range, they can persist beyond EOF and cause
problems. writeback will see the pages in the page cache, see they
are dirty and continually retry the write, assuming that the page
beyond EOF is just racing with a truncate. The page will eventually
be released due to some other operation (e.g. direct IO), and it
will not pass through invalidation because it is dirty. Hence it
will be released with buffer_delay set on it, and trigger warnings
in xfs_vm_releasepage() and assert fail in xfs_file_aio_write_direct
because invalidation failed and we didn't write the corect amount.
This causes failures on block size < page size filesystems in fsx
and fsstress workloads run by xfstests.
Fix it by completely trashing any state on the buffer that could be
used to imply that it contains valid data when the delalloc range
over the buffer is punched out during the failed write handling.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Tested-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>
|
|
Fixed the missing comma in DT node example.
Signed-off-by: Sherman Yin <syin@broadcom.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
To be consistent with other Broadcom drivers, the Broadcom Capri pinctrl
driver and its related CONFIG option are renamed to bcm281xx.
This commit updates the defconfig that enables the pinctrl driver.
Signed-off-by: Sherman Yin <syin@broadcom.com>
Reviewed-by: Matt Porter <mporter@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
To be consistent with other Broadcom drivers, the Broadcom Capri pinctrl
driver and its related CONFIG option are renamed to bcm281xx.
Devicetree compatible string and binding documentation use
"brcm,bcm11351-pinctrl" to match the machine binding here:
Documentation/devicetree/bindings/arm/bcm/bcm11351.txt
This driver supports pinctrl on BCM11130, BCM11140, BCM11351, BCM28145
and BCM28155 SoCs.
Signed-off-by: Sherman Yin <syin@broadcom.com>
Reviewed-by: Matt Porter <mporter@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Acking interrupts are done differently between on v2 and v3, so add an extra
attribute to the pingroup struct to let the platform definitions control this.
Also make sure to start dual edge detection by detecting the rising edge.
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
I left this in by mistake, get rid of it.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
The first half of pinbank 0 only has one muxing function (as gpios) and
does not have a special mux-register.
Therefore ensure that no other mux function can be selected and also do not
write to a non-existent register.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
In a following change, rockchip_set_mux gets the possibility to fail.
Therefore add a return value to it and honor error codes in functions
using rockchip_set_mux.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
The correct value of .mux_offset for rk3188 seems to be 0x60
instead of 0x68.
Heiko adds:
GPIO0 only has the second two IOMUX registers:
- GRF_GPIO0C_IOMUX at 0x68
- GRF_GPIO0D_IOMUX at 0x6c
which I guess is where my mistake comes from.
It looks like there does no iomux register exist at all
for the first 16 pins.
In any case, the current number is wrong, and the 0x60
offset is the correct one, but I guess we need to
determine what the affected pins do - do they always have a
gpio mux or such?
Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
This enables the STMicroelectronics MEMS sensors for accelerometer,
gyroscope, magnetometer and pressure that are mounted on the Ux500
models.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Since there are SD-card support in u300, it's reasonable to
support partitions for block devices as default.
While updating the defconfig, we rebase it towards Kconfig changes.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
There are both (e)MMC/SD-card support in ux500, thus it's reasonable to
support partitions for block devices as default.
While updating the defconfig, we rebase it towards Kconfig changes.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Update the ux500 defconfig to match the latest output of
savedefconfig.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Have the KB(),MB(),GB() macros produce unsigned longs to avoid
unintended sign extension issues with the gen2 memory size
detection.
What happens is first the uint8_t returned by
read_pci_config_byte() gets promoted to an int which gets
multiplied by another int from the MB() macro, and finally the
result gets sign extended to size_t.
Although this shouldn't be a problem in practice as all affected
gen2 platforms are 32bit AFAIK, so size_t will be 32 bits.
Reported-by: Bjorn Helgaas <bhelgaas@google.com>
Suggested-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/1397382303-17525-1-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
Running:
make O=dir x86_64_defconfig
make O=dir kvmconfig
the second command dirties the source tree with file ".config",
symlink "source" and objects in folder "scripts".
Fixed by using properly prefixed paths in the arch Makefile.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Acked-by: Borislav Petkov <bp@suse.de>
Cc: Pekka Enberg <penberg@kernel.org>
Link: http://lkml.kernel.org/r/1397377568-8375-1-git-send-email-borneo.antonio@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
The code to handle any length SG lists calls edma_resume()
even before edma_start() is called. This is incorrect
because edma_resume() enables edma events on the channel
after which CPU (in edma_start) cannot clear posted
events by writing to ECR (per the EDMA user's guide).
Because of this EDMA transfers fail to start if due
to some reason there is a pending EDMA event registered
even before EDMA transfers are started. This can happen if
an EDMA event is a byproduct of device initialization.
Fix this by calling edma_resume() only if it is not the
first batch of MAX_NR_SG elements.
Without this patch, MMC/SD fails to function on DA850 EVM
with DMA. The behaviour is triggered by specific IP and
this can explain why the issue was not reported before
(example with MMC/SD on AM335x).
Tested on DA850 EVM and AM335x EVM-SK using MMC/SD card.
Cc: stable@vger.kernel.org # v3.12.x+
Cc: Joel Fernandes <joelf@ti.com>
Acked-by: Joel Fernandes <joelf@ti.com>
Tested-by: Jon Ringle <jringle@gridpoint.com>
Tested-by: Alexander Holler <holler@ahsoftware.de>
Reported-by: Jon Ringle <jringle@gridpoint.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
|
c7a507eea1db1430476289f525f9c853d5d485e8
(ASoC: fsi: fixup SND_SOC_DAIFMT_CBx_CFx flags)
exchanged sound flags, but armadillo800eva flags needs IB_NF.
The recorded sound will be noise without this patch.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
|
|
e1508289404ab6ca28e0dc931612600f0441c417
(ASoC: rcar: fixup SND_SOC_DAIFMT_CBx_CFx flags)
corrected SND_SOC_DAIFMT_CBx_CFx definition.
But then, Lager board was maintenanced other branch.
This patch correct SND_SOC_DAIFMT_CBx_CFx flag for lager
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
|
|
The BPF_S_ANC_NLATTR and BPF_S_ANC_NLATTR_NEST extensions fail to check
for a minimal message length before testing the supplied offset to be
within the bounds of the message. This allows the subtraction of the nla
header to underflow and therefore -- as the data type is unsigned --
allowing far to big offset and length values for the search of the
netlink attribute.
The remainder calculation for the BPF_S_ANC_NLATTR_NEST extension is
also wrong. It has the minuend and subtrahend mixed up, therefore
calculates a huge length value, allowing to overrun the end of the
message while looking for the netlink attribute.
The following three BPF snippets will trigger the bugs when attached to
a UNIX datagram socket and parsing a message with length 1, 2 or 3.
,-[ PoC for missing size check in BPF_S_ANC_NLATTR ]--
| ld #0x87654321
| ldx #42
| ld #nla
| ret a
`---
,-[ PoC for the same bug in BPF_S_ANC_NLATTR_NEST ]--
| ld #0x87654321
| ldx #42
| ld #nlan
| ret a
`---
,-[ PoC for wrong remainder calculation in BPF_S_ANC_NLATTR_NEST ]--
| ; (needs a fake netlink header at offset 0)
| ld #0
| ldx #42
| ld #nlan
| ret a
`---
Fix the first issue by ensuring the message length fulfills the minimal
size constrains of a nla header. Fix the second bug by getting the math
for the remainder calculation right.
Fixes: 4738c1db15 ("[SKFILTER]: Add SKF_ADF_NLATTR instruction")
Fixes: d214c7537b ("filter: add SKF_AD_NLATTR_NEST to look for nested..")
Cc: Patrick McHardy <kaber@trash.net>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Acked-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Extend commit 13378cad02afc2adc6c0e07fca03903c7ada0b37
("ipv4: Change rt->rt_iif encoding.") from 3.6 to return valid
RTA_IIF on 'ip route get ... iif DEVICE' instead of rt_iif 0
which is displayed as 'iif *'.
inet_iif is not appropriate to use because skb_iif is not set.
Use the skb->dev->ifindex instead.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This reverts commit e3a8786c10e75903f1269474e21fe8cb49c3a670. While
this commit allows to use the mvneta driver as a module on some
configurations, it breaks other configurations even if mvneta is used
built-in.
This breakage is due to the fact that on some RGMII platforms, the PCS
bit has to be set, and on some other platforms, it has to be
cleared. At the moment, we lack informations to know exactly the
significance of this bit (the datasheet only says "enables PCS"), and
so we can't produce a patch that will work on all platforms at this
point. And since this change is breaking the network completely for
many users, it's much better to revert it for now. We'll come back
later with a proper fix that takes into account all platforms.
Basically:
* Armada XP GP is configured as RGMII-ID, and needs the PCS bit to be
set.
* Armada 370 Mirabox is configured as RGMII-ID, and needs the PCS bit
to be cleared.
And at the moment, we don't know how to make the distinction between
those two cases. One hint is that the Armada XP GP appears in fact to
be using a QSGMII connection with the PHY (Quad-SGMII), but
configuring it as SGMII doesn't work, while RGMII-ID works. This needs
more investigation, but in the mean time, let's unbreak the network
for all those users.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reported-by: Arnaud Ebalard <arno@natisbad.org>
Reported-by: Alexander Reuter <Alexander.Reuter@gmx.net>
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=73401
Cc: stable@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
pci_match_id() just match the static pci_device_id, which may return NULL if
someone binds the driver to a device manually using
/sys/bus/pci/drivers/.../new_id.
This patch wrap up a helper function __mlx4_remove_one() which does the tear
down function but preserve the drv_data. Functions like
mlx4_pci_err_detected() and mlx4_restart_one() will call this one with out
releasing drvdata.
Fixes: 97a5221 "net/mlx4_core: pass pci_device_id.driver_data to __mlx4_init_one during reset".
CC: Bjorn Helgaas <bhelgaas@google.com>
CC: Amir Vadai <amirv@mellanox.com>
CC: Jack Morgenstein <jackm@dev.mellanox.co.il>
CC: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Acked-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Plug a group_info refcount leak in ping_init.
group_info is only needed during initialization and
the code failed to release the reference on exit.
While here move grabbing the reference to a place
where it is actually needed.
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Zhang Dongxing <dongxing.zhang@intel.com>
Signed-off-by: xiaoming wang <xiaoming.wang@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Per bindings of fixed-clock, #clock-cells is a required property. Let's
add it for those fixed rate clocks.
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
|
|
This is likely a copy-and-paste error from the
ARM GIC documentation, that has already been fixed.
address-cells should have been set to 0, as with the size
cells. As having those properties set to 0 is the
same thing as not specifying them, drop them completely.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
|
|
In case the bootloader has incorrectly configured the ALT mode of
MX6SL_PAD_ECSPI1_SS0 pad, we end up with the following probe error:
m25p80 spi0.0: found mr25h256, expected m25p32
m25p80 spi0.0: mr25h256 (32 Kbytes)
In order to avoid this issue, add an entry for MX6SL_PAD_ECSPI1_SS0 pad, so
that kernel configures the ECSPI chip select as GPIO functionality, which
results in correct SPI NOR probe.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
|
|
The 'remote-endpoint' property should point back to ipu_di1_lvds1
rather than ipu_di0_lvds0.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
|
|
Since commit (655b43c staging: imx-drm-core: Use OF graph to find
components and connections between encoder and crtcs), 'crtcs' becomes a
dead property. Remove it.
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
Acked-by: Tim Harvey <tharvey@gateworks.com>
|
|
With the recent imx-drm device tree binding changes, we need to add IPU
DI ports and endpoints for adapting.
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
Acked-by: Lothar Waßmann <LW@KARO-electronics.de>
|
|
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
|
|
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
|
|
GPIO7_12 switches the D+/D- USB lines on and off. When we use this as
VBUS regulator it means that USB device mode can never work as VBUS is
never turned on in Device mode.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
|
|
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
|
