While reading the TCB field in t4_tcb_get_field32() the wrong mask is
passed as a parameter which leads the driver eventually to a kernel
panic/app segfault from access to an illegal SRQ index while flushing the
SRQ completions during connection teardown.
Fixes: 11a27e2121 ("iw_cxgb4: complete the cached SRQ buffers")
Link: https://lore.kernel.org/r/20200511185608.5202-1-bharat@chelsio.com
Signed-off-by: Potnuri Bharat Teja <bharat@chelsio.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Do not decrease the reference count of resource tracker object twice in
the error flow of res_get_common_doit.
Fixes: c5dfe0ea6f ("RDMA/nldev: Add resource tracker doit callback")
Link: https://lore.kernel.org/r/20200507062942.98305-1-leon@kernel.org
Signed-off-by: Maor Gottlieb <maorg@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
The IB core pkey cache is populated by procedure ib_cache_update().
Initially, the pkey cache pointer is NULL. ib_cache_update allocates a
buffer and populates it with the device's pkeys, via repeated calls to
procedure ib_query_pkey().
If there is a failure in populating the pkey buffer via ib_query_pkey(),
ib_cache_update does not replace the old pkey buffer cache with the
updated one -- it leaves the old cache as is.
Since initially the pkey buffer cache is NULL, when calling
ib_cache_update the first time, a failure in ib_query_pkey() will cause
the pkey buffer cache pointer to remain NULL.
In this situation, any calls subsequent to ib_get_cached_pkey(),
ib_find_cached_pkey(), or ib_find_cached_pkey_exact() will try to
dereference the NULL pkey cache pointer, causing a kernel panic.
Fix this by checking the ib_cache_update() return value.
Fixes: 8faea9fd4a ("RDMA/cache: Move the cache per-port data into the main ib_port_data")
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Link: https://lore.kernel.org/r/20200507071012.100594-1-leon@kernel.org
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
The commit noted below fixed a case where a pq is left on the sdma wait
list.
It however missed another case.
user_sdma_send_pkts() has two calls from hfi1_user_sdma_process_request().
If the first one fails as indicated by -EBUSY, the pq will be placed on
the waitlist as by design.
If the second call then succeeds, the pq is still on the waitlist setting
up a race with the interrupt handler if a subsequent request uses a
different SDMA engine
Fix by deleting the first call.
The use of pcount and the intent to send a short burst of packets followed
by the larger balance of packets was never correctly implemented, because
the two calls always send pcount packets no matter what. A subsequent
patch will correct that issue.
Fixes: 9a293d1e21 ("IB/hfi1: Ensure pq is not left on waitlist")
Link: https://lore.kernel.org/r/20200504130917.175613.43231.stgit@awfm-01.aw.intel.com
Cc: <stable@vger.kernel.org>
Reviewed-by: Kaike Wan <kaike.wan@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Local variable netdev is not used in these calls.
It should be noted, that this change is required to work in bonded mode.
Otherwise we would get the following assert:
"RTNL: assertion failed at net/core/dev.c (5665)"
With the calltrace as follows:
dump_stack+0x19/0x1b
netdev_master_upper_dev_get+0x61/0x70
i40iw_addr_resolve_neigh+0x1e8/0x220
i40iw_make_cm_node+0x296/0x700
? i40iw_find_listener.isra.10+0xcc/0x110
i40iw_receive_ilq+0x3d4/0x810
i40iw_puda_poll_completion+0x341/0x420
i40iw_process_ceq+0xa5/0x280
i40iw_ceq_dpc+0x1e/0x40
tasklet_action+0x83/0x140
__do_softirq+0x125/0x2bb
call_softirq+0x1c/0x30
do_softirq+0x65/0xa0
irq_exit+0x105/0x110
do_IRQ+0x56/0xf0
common_interrupt+0x16a/0x16a
? cpuidle_enter_state+0x57/0xd0
cpuidle_idle_call+0xde/0x230
arch_cpu_idle+0xe/0xc0
cpu_startup_entry+0x14a/0x1e0
start_secondary+0x1f7/0x270
start_cpu+0x5/0x14
Link: https://lore.kernel.org/r/20200428131511.11049-1-den@openvz.org
Signed-off-by: Denis V. Lunev <den@openvz.org>
Acked-by: Shiraz Saleem <shiraz.saleem@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
In the mlx4_ib_post_send() flow, some functions call ib_get_cached_pkey()
without checking its return value. If ib_get_cached_pkey() returns an
error code, these functions should return failure.
Fixes: 1ffeb2eb8b ("IB/mlx4: SR-IOV IB context objects and proxy/tunnel SQP support")
Fixes: 225c7b1fee ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters")
Fixes: e622f2f4ad ("IB: split struct ib_send_wr")
Link: https://lore.kernel.org/r/20200426075921.130074-1-leon@kernel.org
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
The commit below modified rxe_create_mmap_info() to return ERR_PTR's but
didn't update the callers to handle them. Modify rxe_create_mmap_info() to
only return ERR_PTR and fix all error checking after
rxe_create_mmap_info() is called.
Ensure that all other exit paths properly set the error return.
Fixes: ff23dfa134 ("IB: Pass only ib_udata in function prototypes")
Link: https://lore.kernel.org/r/20200425233545.17210-1-sudipm.mukherjee@gmail.com
Link: https://lore.kernel.org/r/20200511183742.GB225608@mwanda
Cc: stable@vger.kernel.org [5.4+]
Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Commit de462e5f10 ("bootconfig: Fix to remove bootconfig
data from initrd while boot") causes a cosmetic regression
on dmesg, which warns "no bootconfig data" message without
bootconfig cmdline option.
Fix setup_boot_config() by moving no bootconfig check after
commandline option check.
Link: http://lkml.kernel.org/r/9b1ba335-071d-c983-89a4-2677b522dcc8@molgen.mpg.de
Link: http://lkml.kernel.org/r/158916116468.21787.14558782332170588206.stgit@devnote2
Fixes: de462e5f10 ("bootconfig: Fix to remove bootconfig data from initrd while boot")
Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Setting the initial state of input-device switches must be done before
registering the input-device.
Otherwise the initial state will get send out as an event as soon
as input_sync() gets called.
E.g. when undocking a tablet using intel-vbtn to report SW_TABLET_MODE
and SW_DOCK before this commit we would get (evemu-record output):
E: 0.000001 0005 0005 0001 # EV_SW / SW_DOCK 1
E: 0.000001 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms
E: 0.000109 0005 0005 0000 # EV_SW / SW_DOCK 0
E: 0.000109 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms
E: 0.000133 0005 0001 0001 # EV_SW / SW_TABLET_MODE 1
E: 0.000133 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- +0ms
The first SW_DOCK=1 report is spurious, setting the initial switch
state before registering the input-device fixes this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
This is a preparation patch for calling detect_tablet_mode() from
intel_vbtn_input_setup() without needing a forward declaration.
Note this commit makes no functional changes, the moved block of code
is completely unchanged.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
On some Asus devices, e.g. the T100TA, when the charger is connected
we not only get a WMI event with code 0x58, but immediately after that
event we also get an even with code 0x79.
This is likely related to these devices having an Asus WMI device with a
device-id of 0x00120066, which seems to provide some sort of charger-type
info. The T100TA charger over a micro-USB connector, the embedded-
controller register read when calling asus_wmi_get_devstate(0x00120066)
returns different values when connected to a USB port (max 500mA charging)
vs when connected to a 2A capable wall-charger. But the AML code reading
this mangles the return value so that we can no longer tell the difference.
So for now the meaning of the value return when getting the status of
device-id 0x00120066 is unclear.
This commit adds a key-mapping of code 0x79 to KE_IGNORE, silencing the
kernel logging the following message every time the charger is plugged-in:
[ 79.639548] asus_wmi: Unknown key 79 pressed
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
On Asus 2-in-1s with a detachable keyboard the Asus WMI interface
reports if the tablet is attached to the keyboard or not.
Report if the 2-in-1 is in tablet or clamshell mode to userspace
by reporting SW_TABLET_MODE events to userspace.
This has been tested on a T100TA, T100CHI, T100HA and T200TA.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Move the asus_wmi_input_init() and asus_wmi_input_exit() functions to
below the WMI helpers, so that further patches in this patch-set can use
the WMI helpers inside asus_wmi_input_init() without needing a forward
declaration.
Note this commit makes no functional changes, the moved block of code
is completely unchanged.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The variable status is being initialized with a value that is never read
and it is being updated later with a new value. The initialization is
redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The WMI INIT method on for some reason turns on the camera LED on these
2-in-1s, without the WMI interface allowing further control over the LED.
To fix this commit b5f7311d3a ("platform/x86: asus-nb-wmi: Do not load
on Asus T100TA and T200TA") added a blacklist with these 2 models on it
since the WMI driver did not add any extra functionality to these models.
Recently I've been working on making more 2-in-1 models report their
tablet-mode (SW_TABLET_MODE) to userspace; and I've found that these 2
Asus models report this through WMI. This commit reverts the adding
of the blacklist, so that the Asus WMI driver can be used on these
models to report their tablet-mode.
Note, not calling INIT is also not an option, because then we will not
receive events when the tablet-mode changes. So the LED issue will need
to be fixed somewhere else entirely.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
The thermal handle object may fail initialization when the module is
loaded in the first place. Avoid attempting to use it on resume then.
Fixes: 6d232b29cf ("ACPICA: Dispatcher: always generate buffer objects for ASL create_field() operator")
Reported-by: Dominik Mierzejewski <dominik@greysector.net>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207491
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
After commit 6d232b29cf ("ACPICA: Dispatcher: always generate buffer
objects for ASL create_field() operator") ACPICA creates buffers even
when new fields are small enough to fit into an integer.
Many SNC calls counted on the old behaviour.
Since sony-laptop already handles the INTEGER/BUFFER case in
sony_nc_buffer_call, switch sony_nc_int_call to use its more generic
function instead.
Fixes: 6d232b29cf ("ACPICA: Dispatcher: always generate buffer objects for ASL create_field() operator")
Reported-by: Dominik Mierzejewski <dominik@greysector.net>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207491
Reported-by: William Bader <williambader@hotmail.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1830150
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Pull ARM cpufreq updates for v5.8 from Viresh Kumar:
"- Build OMAP cpufreq driver by default for ARCH_OMAP2PLUS platform
(Anders Roxell).
- Fix compatible bindings for qcom cpufreq driver (Ansuel Smith).
- Update qoriq cpufreq driver to automatically loaded when built as
module and related changes (Mian Yousaf Kaukab and Geert
Uytterhoeven).
- Add support for r8a7742 to cpufreq-dt platform driver (Lad
Prabhakar).
- Add support for i.MX7ULP to imx cpufreq driver (Peng Fan)."
* 'cpufreq/arm/linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm:
cpufreq: qoriq: Add platform dependencies
clk: qoriq: add cpufreq platform device
cpufreq: qoriq: convert to a platform driver
cpufreq: qcom: fix wrong compatible binding
cpufreq: imx-cpufreq-dt: support i.MX7ULP
cpufreq: dt: Add support for r8a7742
cpufreq: Add i.MX7ULP to cpufreq-dt-platdev blacklist
cpufreq: omap: Build driver by default for ARCH_OMAP2PLUS
The current minimum required version of binutils is 2.23, which supports
the INVPCID instruction mnemonic. Replace the byte-wise specification of
INVPCID with the proper mnemonic.
[ bp: Add symbolic operand names for increased readability and flip
their order like the insn expects them for the AT&T syntax. ]
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20200508092247.132147-1-ubizjak@gmail.com
Signed-off-by: Borislav Petkov <bp@suse.de>
It does nothing, because the corresponding bit s not flipped on in .formats
and the audio SRAM DMA engine is not able to handle 20-bit transfers
anyway.
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Link: https://lore.kernel.org/r/20200511210134.1224532-3-lkundrak@v3.sk
Signed-off-by: Mark Brown <broonie@kernel.org>
In order to fix issue described in:
"ASoC: Intel: sst: ipc command timeout"
https://patchwork.kernel.org/patch/11482829/
use readq function, which is meant to read 64 bit values from registers.
On 32 bit platforms it falls back to two readl calls.
Reported-by: Brent Lu <brent.lu@intel.com>
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Tested-by: Brent Lu <brent.lu@intel.com>
Acked-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20200507133405.32251-2-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Baytrail has 64 bit registers, so we should use *read64* to read from it
and then use proper mask values to check status.
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Tested-by: Brent Lu <brent.lu@intel.com>
Acked-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20200507133405.32251-1-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The current codebase makes use of the zero-length array language extension
to the C90 standard, but the preferred mechanism to declare variable-length
types such as these as a flexible array member [1][2], introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning in
case the flexible array does not occur last in the structure, which will
help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that dynamic memory allocations won't be affected by this
change:
Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero. [1]
sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type [1]. There are some instances of code in which
the sizeof() operator is being incorrectly/erroneously applied to
zero-length arrays, and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also help
to get completely rid of those sorts of issues.
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 7649773293 ("cxgb3/l2t: Fix undefined behaviour")
Link: https://lore.kernel.org/r/20200507190544.GA15633@embeddedor
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The platform_get_irq*() interfaces return either a negative error number or
a valid IRQ. 0 is not a valid return value, so check for "< 0" to detect
failure as recommended by the function documentation.
On failure, return the error number from platform_get_irq*() instead of
making up a new one.
Link: https://lore.kernel.org/r/cover.1583952275.git.amanharitsh123@gmail.com
[bhelgaas: commit log, squash into one patch]
Signed-off-by: Aman Sharma <amanharitsh123@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Richard Zhu <hongxing.zhu@nxp.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Karthikeyan Mitran <m.karthikeyan@mobiveil.co.in>
Cc: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Ryder Lee <ryder.lee@mediatek.com>
Cc: Marc Gonzalez <marc.w.gonzalez@free.fr>
These interfaces return a negative error number or an IRQ:
platform_get_irq()
platform_get_irq_optional()
platform_get_irq_byname()
platform_get_irq_byname_optional()
The function comments suggest checking for error like this:
irq = platform_get_irq(...);
if (irq < 0)
return irq;
which is what most callers (~900 of 1400) do, so it's implicit that IRQ 0
is invalid. But some callers check for "irq <= 0", and it's not obvious
from the source that we never return an IRQ 0.
Make this more explicit by updating the comments to say that an IRQ number
is always non-zero and adding a WARN() if we ever do return zero. If we do
return IRQ 0, it likely indicates a bug in the arch-specific parts of
platform_get_irq().
Relevant prior discussion at [1, 2].
[1] https://lore.kernel.org/r/Pine.LNX.4.64.0701250940220.25027@woody.linux-foundation.org/
[2] https://lore.kernel.org/r/Pine.LNX.4.64.0701252029570.25027@woody.linux-foundation.org/
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Speed-up a bit this IRQ processing as there is no need to protect
return value or printing.
Signed-off-by: Bernard Zhao <bernard@vivo.com>
Acked-by: Lukasz Luba <lukasz.luba@arm.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Kbuild warns when this file is built as a loadable module:
WARNING: modpost: missing MODULE_LICENSE() in drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.o
see include/linux/module.h for more information
Add the missing license/author/description tags.
Fixes: 8174a8512e ("pinctrl: mediatek: make MediaTek pinctrl v2 driver ready for buidling loadable module")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20200505140848.554957-1-arnd@arndb.de
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
These are called when a GPIO is to be used as IRQ.
Without these custom callbacks, when an interrupt is requested directly
and not through gpiod_to_irq(), the request fails because the GPIO is
not necesarily in input mode. These callbacks simply enforce that the
requested GPIO is in input mode.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20200503164549.163884-1-paul@crapouillou.net
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
[Why]
For MST case: when update_config is called to disable a stream,
this clears the settings for all the streams on that link.
We should only clear the settings for the stream that was disabled.
[How]
Clear the settings after the call to remove display is called.
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Leo (Hanghong) Ma <hanghong.ma@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
On my raven1 system (rev c6) with VBIOS 113-RAVEN-114 GFXOFF is
not stable (resulting in large block tiling noise in some applications).
Disabling GFXOFF via the quirk list fixes the problems for me.
Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Wakeup capable GPIO IRQs routed via PDC are not being migrated when a CPU
is hotplugged. Add affinity callbacks to msmgpio IRQ chip to update the
affinity of wakeup capable IRQs.
Fixes: e35a6ae0eb ("pinctrl/msm: Setup GPIO chip in hierarchy")
Signed-off-by: Venkata Narendra Kumar Gutta <vnkgutta@codeaurora.org>
[mkshah: updated commit text and minor code fixes]
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/1588314617-4556-1-git-send-email-mkshah@codeaurora.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Some versions of GCC are known to suffer from a BTI code generation bug,
meaning that CONFIG_CC_HAS_BRANCH_PROT_PAC_RET_BTI cannot be solely used
to determine whether or not we can compile with kernel with BTI enabled.
Update the BTI Kconfig entry to refer to the relevant GCC bugzilla entry
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94697) and update the check
now that the fix has been merged into GCC release 10.1.
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
i915_gem_evict_something() is charged with finding a slot within the GTT
that we may reuse. Since our goal is not to stall, we first look for a
slot that only overlaps idle vma. To this end, on the first pass we move
any active vma to the end of the search list. However, we only stopped
moving active vma after we see the first active vma twice. If during the
search, that first active vma completed, we would not notice and keep on
extending the search list.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1746
Fixes: 2850748ef8 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
Fixes: b1e3177bd1 ("drm/i915: Coordinate i915_active with its own mutex")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: <stable@vger.kernel.org> # v5.5+
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200509115217.26853-1-chris@chris-wilson.co.uk
When CONFIG_VIRT_CPU_ACCOUNTING is selected, system call exception
handler doesn't fit below 0xd00 and build fails.
As exception 0xd00 doesn't exist and is never generated by 40x,
comment it out in order to get more space for system call exception.
Fixes: 9e27086292 ("powerpc/32: Warn and return ENOSYS on syscalls from kernel")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/633165d72f75b4ef4c0901aebe99d3915c93e9a2.1589043863.git.christophe.leroy@csgroup.eu
Expired intervals would still match and be dumped to user space until
garbage collection wiped them out. Make sure they stop matching and
disappear (from users' perspective) as soon as they expire.
Fixes: 8d8540c4f5 ("netfilter: nft_set_rbtree: add timeout support")
Signed-off-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
If the flow timer expires, the gc sets on the NF_FLOW_TEARDOWN flag.
Otherwise, the flowtable software path might race to refresh the
timeout, leaving the state machine in inconsistent state.
Fixes: c29f74e0df ("netfilter: nf_flow_table: hardware offload support")
Reported-by: Paul Blakey <paulb@mellanox.com>
Reviewed-by: Roi Dayan <roid@mellanox.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Use master-abort to send the stop condition after an address cycle
rather than resetting the controller.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
If we timeout during a message transfer, the control register may
contain bits that cause an action to be set. Read-modify-writing the
register leaving these bits set may trigger the hardware to attempt
one of these actions unintentionally.
Always clear these bits when cleaning up after a message or after
a timeout.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Remove unnecessary show_state() in the loop inside
i2c_pxa_pio_set_master(), which can be unnecessarily verbose.
Remove the i2c_pxa_scream_blue_murder() in i2c_pxa_pio_xfer(), which
will trigger if we are probing the I2C bus and a slave does not
respond; this is a normal event, and not something to report.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Ensure that the various timeout messages can identify where in the code
they were produced from to aid debugging.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Running i2cdetect on a PXA I2C adapter is very noisy; it complains
whenever a slave fails to respond to the address cycle. Since it is
normal to probe for slaves in this way, we should not fill the kernel
log. This is especially true with SFP modules that take a while to
respond on the I2C bus, and probing via the I2C bus is the only way to
detect that they are ready.
Fix this by changing the internal transfer return code from I2C_RETRY
to a new NO_SLAVE code (mapped to -ENXIO, as per the I2C documentation
for this condition, but we still return -EREMOTEIO to the I2C stack to
maintain long established driver behaviour.)
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Most of i2c_pxa_pio_xfer() and i2c_pxa_xfer() are identical; the only
differences are that i2c_pxa_pio_xfer() may reset the bus, and they
use different underlying transfer functions. The retry loop is the
same. Consolidate these two functions.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
When I play with terminus fonts I noticed the efi early printk does
not work because the earlycon code assumes font width is 8.
Here add the code to adapt with larger fonts. Tested with all kinds
of kernel built-in fonts on my laptop. Also tested with a local draft
patch for 14x28 !bold terminus font.
Signed-off-by: Dave Young <dyoung@redhat.com>
Link: https://lore.kernel.org/r/20200412024927.GA6884@dhcp-128-65.nay.redhat.com
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
SSI BUSIF buffer is possible to overflow or underflow, especially in a
hypervisor environment. If there is no interrupt support, it will eventually
lead to errors in pcm data.
This patch adds overflow and underflow interrupt support for SSI BUSIF buffer.
Reported-by: Chen Li <licheng0822@thundersoft.com>
Signed-off-by: Yongbo Zhang <giraffesnn123@gmail.com>
Tested-by: Chen Li <licheng0822@thundersoft.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/20200512093003.28332-1-giraffesnn123@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
* MSI support for Intel Merrifield
* Refactor gpio-pch to be up-to-date with recent kernel APIs
* Miscellaneous cleanups here and there
The following is an automated git shortlog grouped by driver:
ich:
- fix a typo
merrifield:
- Better show how GPIO and IRQ bases are derived from hardware
- Switch over to MSI interrupts
pch:
- Use in pch_irq_type() macros provided by IRQ core
- Refactor pch_irq_type() to avoid unnecessary locking
- Get rid of unneeded variable in IRQ handler
- Use BIT() and GENMASK() where it's appropriate
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEqaflIX74DDDzMJJtb7wzTHR8rCgFAl65YWMACgkQb7wzTHR8
rCgOfRAApn+H8DzunFCHdskAwE8RZlPqwYA0McawGnnOExKEohkXO/8ckaQ1OA+e
7TeR5H2wJQzRChj4d9bAirmwOT0PGL8IrWsfZOPV4TUpF0LpRfmZr+Y0lzV83eB0
C/qfPRTjKLIcBSLpyayW9dEBKS0G6NlPgM9GSfR/Vkzw+Lv5LwHSHjGjgRM+vFk6
XMc+0dmxicOAhx9i1nVjoQVXJJ/zOMmZZ4/+7ShglXevkRHlZzBoxizLxM3swTka
9dQ4CoTWNvmNfTYAsBWFuXNrL5aiNKM/eynQio8rlDMOM/KoiP3KtKr7NZBcKnai
RUUa19l96IxNaE/u1HY9FuaBP0VwQ3CuCWSI5aYjj4dfpUk0dMcNJNjoZ4u9F9xZ
Rn7tFLvmyhXBvrFKcZglKfD7u/SE2YzPLR4IMBjbBdYBSrsktOpJBZbvRm2ZzxJv
UE4CY2A2e6BC9YUD0IwokiP76h/YGMYbRf+3mYt0zJAaQFnWBBixRBDAQHqMjV99
jC6iIJJKHbL9Ai9QnlZ1P6edHJG0FsuvAN4D6ufZhjI9Df5n2ou7pfwTZrWOY/zh
+RNEHrC3jCoux1FRtcYjL9N4ax9WiIVClc/wkp52pRauRtptNFg9sjuz9KM7dPNl
jyyqA3FLDR3wG5wcpbSP1/xzhbHrSTDUbIN6Pr8R/QZnNIEZt2U=
=P708
-----END PGP SIGNATURE-----
Merge tag 'intel-gpio-v5.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-gpio-intel into devel
intel-gpio for v5.8-1
* MSI support for Intel Merrifield
* Refactor gpio-pch to be up-to-date with recent kernel APIs
* Miscellaneous cleanups here and there
The following is an automated git shortlog grouped by driver:
ich:
- fix a typo
merrifield:
- Better show how GPIO and IRQ bases are derived from hardware
- Switch over to MSI interrupts
pch:
- Use in pch_irq_type() macros provided by IRQ core
- Refactor pch_irq_type() to avoid unnecessary locking
- Get rid of unneeded variable in IRQ handler
- Use BIT() and GENMASK() where it's appropriate
