| Age | Commit message (Collapse) | Author |
|---|
|
Move the mode handling to the platform_set_mode callback.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
[b-liu@ti.com: revise subject prefix]
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Now that the DMA engine check was moved to musb_tx_dma_porgram(), both
musb_tx_dma_set_mode_cppi_tusb() and musb_tx_dma_set_mode_mentor() always
return 0, so we can make both these functions *void*.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
[b-liu@ti.com: revise subject prefix]
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
to its caller
Commit 754fe4a92c07 ("usb: musb: Remove ifdefs for TX DMA for musb_host.c")
looks incomplete: the DMA engine checks are done outside the Mentor/UX500
handler but inside the CPPI/TUSB handler. Move the checks out of the CPPI/
TUSB handler into its caller, musb_tx_dma_program().
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
[b-liu@ti.com: revise subject prefix]
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
urb->status is set when endpoint csr RXSTALL, H_ERROR, DATAERROR or
INCOMPRX bit is set. Those bits mean a broken pipe, so don't start next
urb when any of these bits is set by checking urb->status.
To minimize the risk of regression, only do so for RX, until we have a
test case to understand the behavior of TX.
The patch fixes system freeze issue caused by repeatedly invoking RX ISR
while removing a usb uart device connected to a hub, in which case the
hub has no chance to report the disconnect event due to the kernel is
busy in processing the RX interrupt flooding.
Fix checkpatch complaint (qh != NULL) as while.
Reported-by: Max Uvarov <muvarov@gmail.com>
Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The MUSB Programming Guide states that the driver should clear RXCSR
bit2 when the controller sets the bit.
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
I got one of these cards for testing uas with, it seems that with streams
it dma-s all over the place, corrupting memory. On my first tests it
managed to dma over the BIOS of the motherboard somehow and completely
bricked it.
Tests on another motherboard show that it does work with streams disabled.
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Now that we've gotten rid of all the users of this flag we can
retire the number, leaving a slot open for a future flag user.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
|
|
Several people have reported that UBSAN doesn't like the pointer
arithmetic in ehci_hub_control():
u32 __iomem *status_reg = &ehci->regs->port_status[
(wIndex & 0xff) - 1];
u32 __iomem *hostpc_reg = &ehci->regs->hostpc[(wIndex & 0xff) - 1];
If wIndex is 0 (and it often is), these calculations underflow and
UBSAN complains.
According to the C standard, pointer computations leading to locations
outside the bounds of an array object (other than 1 position past the
end) are undefined. In this case, the compiler would be justified in
concluding the wIndex can never be 0 and then optimizing away the
tests for !wIndex that occur later in the subroutine. (Although,
since ehci->regs->port_status and ehci->regs->hostpc are both 0-length
arrays and are thus GCC extensions to the C standard, it's not clear
what the compiler is really allowed to do.)
At any rate, we can avoid all these difficulties, at the cost of
making the code slightly longer, by not decrementing the index when it
is equal to 0. The runtime effect is minimal, and anyway
ehci_hub_control() is not on a hot path.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Reported-by: Meelis Roos <mroos@linux.ee>
Reported-by: Martin_MOKREJÅ <mmokrejs@gmail.com>
Reported-by: "Navin P.S" <navinp1912@gmail.com>
CC: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit 198de51dbc34 ("USB: uas: Limit qdepth at the scsi-host level")
removed the scsi_change_queue_depth() call from uas_slave_configure()
assuming that the slave would inherit the host's queue_depth, which
that commit sets to the same value.
This is incorrect, without the scsi_change_queue_depth() call the slave's
queue_depth defaults to 1, introducing a performance regression.
This commit restores the call, fixing the performance regression.
Cc: stable@vger.kernel.org
Fixes: 198de51dbc34 ("USB: uas: Limit qdepth at the scsi-host level")
Reported-by: Tom Yan <tom.ty89@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit 198de51dbc34 ("USB: uas: Limit qdepth at the scsi-host level") made
qdepth limit set in host template (`.can_queue = MAX_CMNDS`) redundant.
Removing it to avoid confusion.
Signed-off-by: Tom Yan <tom.ty89@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The Acer C120 LED Projector is a USB-3 connected pico projector which
takes both its power and video data from USB-3.
In combination with some hubs this device does not play well with
lpm, so disable lpm for it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Properly sort all the entries by vendor id.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b1c127ae990b ("usb: host: xhci: plat: make use of new methods in
xhci_plat_priv") sets xhci->quirks before calling xhci_gen_setup(), which
will overwrite them.
Don't overwite the quirks, just add the new ones
Fixes: b1c127ae990b ("usb: host: xhci: plat: make use of new methods in xhci_plat_priv")
Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
On some platforms, the clocks might be registered by a platform
driver. When this is the case, the clock platform driver may very well
be probed after xhci-plat, in which case the first probe() invocation
of xhci-plat will receive -EPROBE_DEFER as the return value of
devm_clk_get().
The current code handles that as a normal error, and simply assumes
that this means that the system doesn't have a clock for the XHCI
controller, and continues probing without calling
clk_prepare_enable(). Unfortunately, this doesn't work on systems
where the XHCI controller does have a clock, but that clock is
provided by another platform driver. In order to fix this situation,
we handle the -EPROBE_DEFER error condition specially, and abort the
XHCI controller probe(). It will be retried later automatically, the
clock will be available, devm_clk_get() will succeed, and the probe()
will continue with the clock prepared and enabled as expected.
In practice, such issue is seen on the ARM64 Marvell 7K/8K platform,
where the clocks are registered by a platform driver.
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
If commands timeout we mark them for abortion, then stop the command
ring, and turn the commands to no-ops and finally restart the command
ring.
If the host is working properly the no-op commands will finish and
pending completions are called.
If we notice the host is failing, driver clears the command ring and
completes, deletes and frees all pending commands.
There are two separate cases reported where host is believed to work
properly but is not. In the first case we successfully stop the ring
but no abort or stop command ring event is ever sent and host locks up.
The second case is if a host is removed, command times out and driver
believes the ring is stopped, and assumes it will be restarted, but
actually ends up timing out on the same command forever.
If one of the pending commands has the xhci->mutex held it will block
xhci_stop() in the remove codepath which otherwise would cleanup pending
commands.
Add a check that clears all pending commands in case host is removed,
or we are stuck timing out on the same command. Also restart the
command timeout timer when stopping the command ring to ensure we
recive an ring stop/abort event.
Cc: stable <stable@vger.kernel.org>
Tested-by: Joe Lawrence <joe.lawrence@stratus.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Under stress occasions some TI devices might not return early when
reading the status register during the quirk invocation of xhci_irq made
by usb_hcd_pci_remove. This means that instead of returning, we end up
handling this interruption in the middle of a shutdown. Since
xhci->event_ring has already been freed in xhci_mem_cleanup, we end up
accessing freed memory, causing the Oops below.
commit 8c24d6d7b09d ("usb: xhci: stop everything on the first call to
xhci_stop") is the one that changed the instant in which we clean up the
event queue when stopping a device. Before, we didn't call
xhci_mem_cleanup at the first time xhci_stop is executed (for the shared
HCD), instead, we only did it after the invocation for the primary HCD,
much later at the removal path. The code flow for this oops looks like
this:
xhci_pci_remove()
usb_remove_hcd(xhci->shared)
xhci_stop(xhci->shared)
xhci_halt()
xhci_mem_cleanup(xhci); // Free the event_queue
usb_hcd_pci_remove(primary)
xhci_irq() // Access the event_queue if STS_EINT is set. Crash.
xhci_stop()
xhci_halt()
// return early
The fix modifies xhci_stop to only cleanup the xhci data when releasing
the primary HCD. This way, we still have the event_queue configured
when invoking xhci_irq. We still halt the device on the first call to
xhci_stop, though.
I could reproduce this issue several times on the mainline kernel by
doing a bind-unbind stress test with a specific storage gadget attached.
I also ran the same test over-night with my patch applied and didn't
observe the issue anymore.
[ 113.334124] Unable to handle kernel paging request for data at address 0x00000028
[ 113.335514] Faulting instruction address: 0xd00000000d4f767c
[ 113.336839] Oops: Kernel access of bad area, sig: 11 [#1]
[ 113.338214] SMP NR_CPUS=1024 NUMA PowerNV
[c000000efe47ba90] c000000000720850 usb_hcd_irq+0x50/0x80
[c000000efe47bac0] c00000000073d328 usb_hcd_pci_remove+0x68/0x1f0
[c000000efe47bb00] d00000000daf0128 xhci_pci_remove+0x78/0xb0
[xhci_pci]
[c000000efe47bb30] c00000000055cf70 pci_device_remove+0x70/0x110
[c000000efe47bb70] c00000000061c6bc __device_release_driver+0xbc/0x190
[c000000efe47bba0] c00000000061c7d0 device_release_driver+0x40/0x70
[c000000efe47bbd0] c000000000619510 unbind_store+0x120/0x150
[c000000efe47bc20] c0000000006183c4 drv_attr_store+0x64/0xa0
[c000000efe47bc60] c00000000039f1d0 sysfs_kf_write+0x80/0xb0
[c000000efe47bca0] c00000000039e14c kernfs_fop_write+0x18c/0x1f0
[c000000efe47bcf0] c0000000002e962c __vfs_write+0x6c/0x190
[c000000efe47bd90] c0000000002eab40 vfs_write+0xc0/0x200
[c000000efe47bde0] c0000000002ec85c SyS_write+0x6c/0x110
[c000000efe47be30] c000000000009260 system_call+0x38/0x108
Signed-off-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Cc: Roger Quadros <rogerq@ti.com>
Cc: joel@jms.id.au
Cc: stable@vger.kernel.org
Reviewed-by: Roger Quadros <rogerq@ti.com>
Cc: <stable@vger.kernel.org> #v4.3+
Tested-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This flag is a no-op now (see commit 47b0eeb3dc8a "clk: Deprecate
CLK_IS_ROOT", 2016-02-02) so remove it.
Cc: Purna Chandra Mandal <purna.mandal@microchip.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: <linux-mips@linux-mips.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
|
|
This flag is a no-op now (see commit 47b0eeb3dc8a "clk: Deprecate
CLK_IS_ROOT", 2016-02-02) so remove it.
Cc: Gerhard Sittig <gsi@denx.de>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus
Felipe writes:
Here's the first set of fixes for v4.7-rc
cycle. Nothing extra fancy this time around.
Patches range from MS OS Descriptor usage fixes, to
Clear Stall EP command fix on dwc3, to some f_fs
fixes and out of bounds accesses on renesas driver.
|
|
This flag is a no-op now (see commit 47b0eeb3dc8a "clk: Deprecate
CLK_IS_ROOT", 2016-02-02) so remove it.
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
|
|
git://git.pengutronix.de/git/pza/linux into drm-fixes
mediatek-drm fixes
- remove an invalid, unreachable error message and NULL pointer dereference
- remove a spurious drm_connector_unregister call from the DSI driver
* tag 'mediatek-drm-fixes-2016-06-01' of git://git.pengutronix.de/git/pza/linux:
drm/mediatek: mtk_dsi: Remove spurious drm_connector_unregister
drm/mediatek: mtk_dpi: remove invalid error message
|
|
The address check in acpi_hw_get_access_bit_width() should be byte width
based, not bit width based. This patch fixes this mistake.
For those who want to review acpi_hw_access_bit_width(), here is the
concerns and the design details of the function:
It is supposed that the GAS Address field should be aligned to the byte
width indicated by the GAS AccessSize field. Similarly, for the old non
GAS register, it is supposed that its Address should be aligned to its
Length.
For the "AccessSize = 0 (meaning ANY)" case, we try to return the maximum
instruction width (64 for MMIO or 32 for PIO) or the user expected access
bit width (64 for acpi_read()/acpi_write() or 32 for acpi_hw_read()/
acpi_hw_write()) and it is supposed that the GAS Address field should
always be aligned to the maximum expected access bit width (otherwise it
can't be accessed using ANY access bit width).
The problem is in acpi_tb_init_generic_address(), where the non GAS
register's Length is converted into the GAS BitWidth field, its Address is
converted into the GAS Address field, and the GAS AccessSize field is left
0 but most of the registers actually cannot be accessed using "ANY"
accesses.
As a conclusion, when AccessSize = 0 (ANY), the Address should either be
aligned to the BitWidth (wrong conversion) or aligned to 32 for PIO or 64
for MMIO (real GAS). Since currently, max_bit_width is 32, then:
1. BitWidth for the wrong conversion is 8,16,32; and
2. The Address of the real GAS should always be aligned to 8,16,32.
The address alignment check to exclude false matched real GAS is not
necessary. Thus this patch fixes the issue by removing the address
alignment check.
On the other hand, we in fact could use a simpler check of
"reg->bit_width < max_bit_width" to exclude the "BitWidth=64 PIO" case that
may be issued from acpi_read()/acpi_write() in the future.
Fixes: b314a172ee96 (ACPICA: Hardware: Add optimized access bit width support)
Reported-and-tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Mike Marshall <hubcap@omnibond.com>
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The return value of clamp_val() has to be stored actually.
Fixes: b7898fda5bc7 (cpufreq: Support for fast frequency switching)
Reported-by: Steve Muckle <steve.muckle@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
"Here are three pin control fixes for v4.7. Not much, and just driver
fixes:
- add device tree matches to MAINTAINERS
- inversion bug in the Nomadik driver
- dual edge handling bug in the mediatek driver"
* tag 'pinctrl-v4.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: mediatek: fix dual-edge code defect
MAINTAINERS: Add file patterns for pinctrl device tree bindings
pinctrl: nomadik: fix inversion of gpio direction
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf
Pull dma-buf updates from Sumit Semwal:
- use of vma_pages instead of explicit computation
- DocBook and headerdoc updates for dma-buf
* tag 'dma-buf-for-4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf:
dma-buf: use vma_pages()
fence: add missing descriptions for fence
doc: update/fixup dma-buf related DocBook
reservation: add headerdoc comments
dma-buf: headerdoc fixes
|
|
In commit 86d3473224b0 some of the checking for a valid timeval
was subtley changed which caused -EINVAL to be returned whenever
the timeval was null.
However, it is possible to set the timezone data while specifying
a NULL timeval, which is usually done to handle systems where the
RTC keeps local time instead of UTC. Thus the patch causes such
systems to have the time incorrectly set.
This patch addresses the issue by handling the error conditionals
in the same way as was done previously.
Fixes: 86d3473224b0 "time: Introduce do_sys_settimeofday64()"
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Baolin Wang <baolin.wang@linaro.org>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Shuah Khan <shuahkh@osg.samsung.com>
Link: http://lkml.kernel.org/r/1464807207-16530-2-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
We're missing entries for mlock2, copy_file_range, preadv2 and pwritev2
in our compat syscall table, so hook them up. Only the last two need
compat wrappers.
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
Fixes commit 60f9ce3ada53
("thermal: of-thermal: allow setting trip_temp on hardware")
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: linux-pm@vger.kernel.org
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
The freq_table array is not populated before calling
thermal_of_cooling_register. The code which populates the freq table was
introduced in commit f6859014.
This should be done before registering new thermal cooling device.
The log shows effects of this wrong decision.
[ 2.172614] cpu cpu1: Failed to get voltage for frequency 1984518656000: -34
[ 2.220863] cpu cpu0: Failed to get voltage for frequency 1984524416000: -34
Cc: <stable@vger.kernel.org> # 3.19+
Fixes: f6859014c7e7 ("thermal: cpu_cooling: Store frequencies in descending order")
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
Acked-by: Javi Merino <javi.merino@arm.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
Connectors are unregistered by mtk_drm_drv via drm_connector_unregister_all().
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
Do not try to dereference dpi if it is NULL.
Since dpi can never be NULL when mtk_dpi_set_display_mode() is called,
remove the message.
Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
|
|
The firmware found in the touch screen of an SP3 is buggy and may miss
to send lift off reports for contacts. Try to work around that issue by
using MT_QUIRK_NOT_SEEN_MEANS_UP.
based on a patch from: Daniel Martin <consume.noise@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
If kmalloc() returned NULL we would end up dereferencing "state" a
couple lines later.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
|
|
Reset crtc->state to NULL after freeing the state object and call
__drm_atomic_helper_crtc_destroy_state() helper instead of manually
calling drm_property_unreference_blob().
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
|
|
Flushing a work that reschedules itself is not a sensible operation. It needs
to be killed. Failure to do so leads to a kernel panic in the timer code.
CC: stable@vger.kernel.org
Signed-off-by: Oliver Neukum <ONeukum@suse.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
|
|
Signed-off-by: Yan, Zheng <zyan@redhat.com>
|
|
There are several issues in fscache revalidation code.
- In ceph_revalidate_work(), fscache_invalidate() is called when
fscache_check_consistency() return 0. This is complete wrong
because 0 means cache is valid.
- Handle_cap_grant() calls ceph_queue_revalidate() if client
already has CAP_FILE_CACHE. This code is confusing. Client
should revalidate the cache each time it got CAP_FILE_CACHE
anew.
- In Handle_cap_grant(), fscache_invalidate() is called if MDS
revokes CAP_FILE_CACHE. This is inconsistency with the case
that inode get evicted. In the later case, the cache is not
discarded. Client may use the cache when inode is reloaded.
This patch moves the fscache revalidation into ceph_get_caps().
Client revalidates the cache after it gets CAP_FILE_CACHE.
i_rdcache_gen should keep constance while CAP_FILE_CACHE is
used. If i_fscache_gen is not equal to i_rdcache_gen, client
needs to check cache's consistency.
Signed-off-by: Yan, Zheng <zyan@redhat.com>
|
|
All other filesystems do not add dirty pages to fscache. They all
disable fscache when inode is opened for write. Only ceph adds
dirty pages to fscache, but the code is buggy.
Signed-off-by: Yan, Zheng <zyan@redhat.com>
|
|
ceph_fill_file_size() has already called ceph_fscache_invalidate()
if it return true.
Signed-off-by: Yan, Zheng <zyan@redhat.com>
|
|
If readpages fails, fscache needs to cleanup its internal state.
Signed-off-by: Yan, Zheng <zyan@redhat.com>
|
|
__fscache_check_consistency() calls check_consistency() callback
and return the callback's return value. But the return type of
check_consistency() is bool. So __fscache_check_consistency()
return 1 if the cache is inconsistent. This is inconsistent with
the document.
Signed-off-by: Yan, Zheng <zyan@redhat.com>
Acked-by: David Howells <dhowells@redhat.com>
|
|
Signed-off-by: Yan, Zheng <zyan@redhat.com>
Acked-by: David Howells <dhowells@redhat.com>
|
|
As of core revision 2.60a the recommended programming model is to set
the ClearPendIN bit when issuing a Clear Stall EP command for IN
endpoints. This is to prevent an issue where some (non-compliant) hosts
may not send ACK TPs for pending IN transfers due to a mishandled error
condition. Synopsys STAR 9000614252.
Signed-off-by: John Youn <johnyoun@synopsys.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
|
|
Pull networking fixes from David Miller:
1) Fix negative error code usage in ATM layer, from Stefan Hajnoczi.
2) If CONFIG_SYSCTL is disabled, the default TTL is not initialized
properly. From Ezequiel Garcia.
3) Missing spinlock init in mvneta driver, from Gregory CLEMENT.
4) Missing unlocks in hwmb error paths, also from Gregory CLEMENT.
5) Fix deadlock on team->lock when propagating features, from Ivan
Vecera.
6) Work around buffer offset hw bug in alx chips, from Feng Tang.
7) Fix double listing of SCTP entries in sctp_diag dumps, from Xin
Long.
8) Various statistics bug fixes in mlx4 from Eric Dumazet.
9) Fix some randconfig build errors wrt fou ipv6 from Arnd Bergmann.
10) All of l2tp was namespace aware, but the ipv6 support code was not
doing so. From Shmulik Ladkani.
11) Handle on-stack hrtimers properly in pktgen, from Guenter Roeck.
12) Propagate MAC changes properly through VLAN devices, from Mike
Manning.
13) Fix memory leak in bnx2x_init_one(), from Vitaly Kuznetsov.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (62 commits)
sfc: Track RPS flow IDs per channel instead of per function
usbnet: smsc95xx: fix link detection for disabled autonegotiation
virtio_net: fix virtnet_open and virtnet_probe competing for try_fill_recv
bnx2x: avoid leaking memory on bnx2x_init_one() failures
fou: fix IPv6 Kconfig options
openvswitch: update checksum in {push,pop}_mpls
sctp: sctp_diag should dump sctp socket type
net: fec: update dirty_tx even if no skb
vlan: Propagate MAC address to VLANs
atm: iphase: off by one in rx_pkt()
atm: firestream: add more reserved strings
vxlan: Accept user specified MTU value when create new vxlan link
net: pktgen: Call destroy_hrtimer_on_stack()
timer: Export destroy_hrtimer_on_stack()
net: l2tp: Make l2tp_ip6 namespace aware
Documentation: ip-sysctl.txt: clarify secure_redirects
sfc: use flow dissector helpers for aRFS
ieee802154: fix logic error in ieee802154_llsec_parse_dev_addr
net: nps_enet: Disable interrupts before napi reschedule
net/lapb: tuse %*ph to dump buffers
...
|
|
- Fixed black screen for some resolutions of G200e rev4
- Fixed testm & testn which had predetermined value.
Reported-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Mathieu Larouche <mathieu.larouche@matrox.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Pull sparc fixes from David Miller:
"sparc64 mmu context allocation and trap return bug fixes"
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
sparc64: Fix return from trap window fill crashes.
sparc: Harden signal return frame checks.
sparc64: Take ctx_alloc_lock properly in hugetlb_setup().
|
|
Since the introduction of (struct_mutex) lockless GEM bo freeing, there
are a pair of driver vfuncs for freeing the GEM bo, of which the driver
may choose to only implement driver->gem_object_free_unlocked (and so
avoid taking the struct_mutex along the free path). However, the CMA GEM
helpers were still calling driver->gem_free_object directly, now NULL,
and promptly dying on the fancy new lockless drivers. Oops.
Robert Foss bisected this to b82caafcf2303 (drm/vc4: Use lockless gem BO
free callback) on his vc4 device, but that just serves as an enabler for
9f0ba539d13ae (drm/gem: support BO freeing without dev->struct_mutex).
Reported-by: Robert Foss <robert.foss@collabora.com>
Fixes: 9f0ba539d13ae (drm/gem: support BO freeing without dev->struct_mutex)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Robert Foss <robert.foss@collabora.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Robert Foss <robert.foss@collabora.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
After commit 027b3f8ba9277410c3191d72d1ed2c6146d8a668 ("drm/modes: stop
handling framebuffer special") extra fb refs are left around when doing
atomic modesetting.
The problem is that the new drm_property_change_valid_get() does not
return anything in the '**ref' parameter, which causes
drm_property_change_valid_put() to do nothing.
For some reason this doesn't cause problems with legacy API.
Also, previously the code only set the 'ref' variable for fbs, with this
patch the 'ref' is set for all objects.
Fixes: 027b3f8ba927 ("drm/modes: stop handling framebuffer special")
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
drm_atomic_set_mode_prop_for_crtc() does not clear the state->mode, so
old data may be left there when a new mode is set, possibly causing odd
issues.
This patch improves the situation by always clearing the state->mode
first.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Commit 652353e6e561c2aeeac62df183f721f6f9b5b45f ("drm/sti: set CRTC
modesetting parameters") added a hack to avoid warnings related to
setting mode with atomic API. With the previous patch, the hack should
no longer be necessary.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
