SWAPGS is used only for interrupts coming from user mode or for
returning to user mode. So there is no reason to use the PARAVIRT
framework, as it can easily be replaced by an ALTERNATIVE depending
on X86_FEATURE_XENPV.
There are several instances using the PV-aware SWAPGS macro in paths
which are never executed in a Xen PV guest. Replace those with the
plain swapgs instruction. For SWAPGS_UNSAFE_STACK the same applies.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Andy Lutomirski <luto@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20210120135555.32594-5-jgross@suse.com
Xen PV guests don't use IST. For double fault interrupts, switch to
the same model as NMI.
Correct a typo in a comment while copying it.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20210120135555.32594-4-jgross@suse.com
Xen PV guests don't use IST. For machine check interrupts, switch to the
same model as debug interrupts.
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20210120135555.32594-3-jgross@suse.com
AMD EthanolX CRB uses 2-byte POST codes which are sent to ports 0x80/0x81.
Currently ASPEED controller snoops only 0x80 port and therefore captures
only the lower byte of each POST code.
Enable secondary LPC snooping address to capture the higher byte of POST
codes.
Signed-off-by: Konstantin Aladyshev <aladyshev22@gmail.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Link: https://lore.kernel.org/r/20210127182326.424-1-aladyshev22@gmail.com
Signed-off-by: Joel Stanley <joel@jms.id.au>
It turns out that reasoning for lowering max. supported frequency is
wrong. Scrambling works just fine. Several now fixed bugs prevented
proper functioning, even with rates lower than 340 MHz. Issues were just
more pronounced with higher frequencies.
Fix that by allowing max. supported frequency in HW and fix the comment.
Fixes: cd9063757a ("drm/sun4i: DW HDMI: Lower max. supported rate for H6")
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Tested-by: Andre Heider <a.heider@gmail.com>
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210209175900.7092-6-jernej.skrabec@siol.net
As it turns out, vendor HDMI PHY driver for H6 has a pretty big table
of predefined values for various pixel clocks. However, most of them are
not useful/tested because they come from reference driver code. Vendor
PHY driver is concerned with only few of those, namely 27 MHz, 74.25
MHz, 148.5 MHz, 297 MHz and 594 MHz. These are all frequencies for
standard CEA modes.
Fix sun50i_h6_cur_ctr and sun50i_h6_phy_config with the values only for
aforementioned frequencies.
Table sun50i_h6_mpll_cfg doesn't need to be changed because values are
actually frequency dependent and not so much SoC dependent. See i.MX6
documentation for explanation of those values for similar PHY.
Fixes: c71c9b2fee ("drm/sun4i: Add support for Synopsys HDMI PHY")
Tested-by: Andre Heider <a.heider@gmail.com>
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210209175900.7092-5-jernej.skrabec@siol.net
As expected, HDMI controller clock should always match pixel clock. In
the past, changing HDMI controller rate would seemingly worsen
situation. However, that was the result of other bugs which are now
fixed.
Fix that by removing set_rate quirk and always set clock rate.
Fixes: 40bb9d3147 ("drm/sun4i: Add support for H6 DW HDMI controller")
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Tested-by: Andre Heider <a.heider@gmail.com>
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210209175900.7092-4-jernej.skrabec@siol.net
Channel 1 has polarity bits for vsync and hsync signals but driver never
sets them. It turns out that with pre-HDMI2 controllers seemingly there
is no issue if polarity is not set. However, with HDMI2 controllers
(H6) there often comes to de-synchronization due to phase shift. This
causes flickering screen. It's safe to assume that similar issues might
happen also with pre-HDMI2 controllers.
Solve issue with setting vsync and hsync polarity. Note that display
stacks with tcon top have polarity bits actually in tcon0 polarity
register.
Fixes: 9026e0d122 ("drm: Add Allwinner A10 Display Engine support")
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Tested-by: Andre Heider <a.heider@gmail.com>
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20210209175900.7092-3-jernej.skrabec@siol.net
- Move pr_fmt() before the includes on davinci driver (Bartosz
Golaszewski)
- Clarified timer interrupt must be specified on nuvoton DT bindings
(Jonathan Neuschäfer)
- Remove tango, sirf, u300 and atlas timer drivers (Arnd Bergman)
- Add suspend/resume on pit64b (Claudiu Beznea)
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEGn3N4YVz0WNVyHskqDIjiipP6E8FAmAhpWEACgkQqDIjiipP
6E8gLgf+Jq+yzWCYtBn4qcmgSaivqd5Z43dqQ3nQFad9LxM78Nmg6GlnJu8hUkz3
56Ho32kucjd8Y3OvYBWlXkYYgUAOOrrXTSfpNqwpisSab0+9u2Usw0727YbRUNSk
PRqSqiDjZo7RfbZFiq8zqUoba9kRjxTyS94DlFR5NA7zg/ctC7f6oXN8RALRg0ft
m2p4p+k+ekZ6XdzXIxMgJqk9UWjGUbfv631pRvvqvjTSTpkmKr2ffVWE0nlaz02P
IIlps+d/WMu7AypK+WydW/HFi40EdXu91WQvG4MKOt1So/WkBcsRF6EEqks8UczM
SE/89j8AoRcGyQRnIyaFwu7tIFJ23g==
=fxqm
-----END PGP SIGNATURE-----
Merge tag 'timers-v5.12-rc1' of https://git.linaro.org/people/daniel.lezcano/linux into timers/core
Pull clocksource/events updates from Daniel Lezcano:
- Drop dead code on efm32 (Uwe Kleine-König)
- Move pr_fmt() before the includes on davinci driver (Bartosz
Golaszewski)
- Clarified timer interrupt must be specified on nuvoton DT bindings
(Jonathan Neuschäfer)
- Remove tango, sirf, u300 and atlas timer drivers (Arnd Bergman)
- Add suspend/resume on pit64b (Claudiu Beznea)
Link: https://lore.kernel.org/r/3747fbde-134f-5e1d-47d5-8776c1a52aa1@linaro.org
Add the pinctrl entries for the GPIOs which are connected to the
push buttons on this board.
Signed-off-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20210201133000.23402-1-michael@walle.cc
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
The Ebang EBAZ4205 is a simple board based on the Xilinx Zynq-7000 SoC.
Its features are:
- one serial port
- 256 MB RAM
- 128 MB NAND flash
- SDcard slot
- IP101GA 10/100 Mbit Ethernet PHY (connected to PL IOs)
- two LEDs (connected to PL IOs)
- one Push Button (connect to PL IOs)
- (optional) RTC
- (optional) Input voltage supervisor
The NAND flash is not supported in mainline linux yet. Unfortunately,
the PHY is connected via the PL, thus for working ethernet the FPGA has
to be configured. Also, depending on the board variant, the PHY has no
external crystal and its clock needs to be driven by the PL. FCLK3 is
used for this and is kept enabled.
Signed-off-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20210120194033.26970-4-michael@walle.cc
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Add vendor prefix for Zhejiang Ebang Communication Co., Ltd.
Signed-off-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20210120194033.26970-2-michael@walle.cc
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
If LPC SNOOP driver is registered ahead of lpc-ctrl module, LPC
SNOOP block will be enabled without heart beating of LCLK until
lpc-ctrl enables the LCLK. This issue causes improper handling on
host interrupts when the host sends interrupt in that time frame.
Then kernel eventually forcibly disables the interrupt with
dumping stack and printing a 'nobody cared this irq' message out.
To prevent this issue, all LPC sub-nodes should enable LCLK
individually so this patch adds clock control logic into the LPC
SNOOP driver.
Fixes: 3772e5da44 ("drivers/misc: Aspeed LPC snoop output using misc chardev")
Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@intel.com>
Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>
Signed-off-by: John Wang <wangzhiqiang.bj@bytedance.com>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20201208091748.1920-1-wangzhiqiang.bj@bytedance.com
Signed-off-by: Joel Stanley <joel@jms.id.au>
- Add non-uniform erase fixes.
- Add Global Block Unlock command. It is defined by few flash
vendors, and it is used for now just by sst.
SPI NOR controller drivers changes:
- intel-spi: Add support for Intel Alder Lake-P SPI serial flash.
- hisi-sfc: Put child node np on error path.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEHUIqys8OyG1eHf7fS1VPR6WNFOkFAmAg2bMACgkQS1VPR6WN
FOlaLQgAnrV3BGJWTHmLSGo1z6dBRa3xGt34C3zwnUbyJwNTEUByMPG8Rj9jflsh
BT0lnICLNki0uCfWf/XpsLAFpDrxt57YkEajAOhLiJLDoKcPPS2TbIAE70WPsv9g
gS64lSoVi2D8cQqOBDfmrCMqfjbvpiAzQ1J63n580T2+2R676adrI7nchLd5gL5y
IFORRuioAy++s3eoT6x8W7QiHY8xwes5O0fo3EkQGoDMTPyXEfoQwEKrFHQgA+hp
QruZC9NegGuVhkQ3xz2C8bChsv5kuKhf8aaGyGcbA0FS0GNF3YgD+qgy3XTdgI6h
pCMUr6QLJbAvvOl8CE8pdZkEPaeSjQ==
=nhEB
-----END PGP SIGNATURE-----
Merge tag 'spi-nor/for-5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux into mtd/next
SPI NOR core changes:
- Add non-uniform erase fixes.
- Add Global Block Unlock command. It is defined by few flash
vendors, and it is used for now just by sst.
SPI NOR controller drivers changes:
- intel-spi: Add support for Intel Alder Lake-P SPI serial flash.
- hisi-sfc: Put child node np on error path.
We don't have a persistent fb holding a reference to the frontbuffer
object, so every time we do the get+put we throw the frontbuffer object
immediately away. And so the next time around we get a pristine
frontbuffer object with bits==0 even for the old vma. This confuses
the frontbuffer tracking code which understandably expects the old
frontbuffer to have the overlay's bit set.
Fix this by hanging on to the frontbuffer reference until the next
flip. And just to make this a bit more clear let's track the frontbuffer
explicitly instead of just grabbing it via the old vma.
Cc: stable@vger.kernel.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1136
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210209021918.16234-2-ville.syrjala@linux.intel.com
Fixes: 8e7cb1799b ("drm/i915: Extract intel_frontbuffer active tracking")
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 553c23bdb4)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
When starting an iomap write, gfs2_quota_lock_check -> gfs2_quota_lock
-> gfs2_quota_hold is called from gfs2_iomap_begin. At the end of the
write, before unlocking the quotas, punch_hole -> gfs2_quota_hold can be
called again in gfs2_iomap_end, which is incorrect and leads to a failed
assertion. Instead, move the call to gfs2_quota_unlock before the call
to punch_hole to fix that.
Fixes: 64bc06bb32 ("gfs2: iomap buffered write support")
Cc: stable@vger.kernel.org # v4.19+
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
mhi_deinit_chan_ctxt functionthat takes care of unitializing channel
resources, including unmapping coherent MHI areas, can be called
from different path in case of controller unregistering/removal:
- From a client driver remove callback, via mhi_unprepare_channel
- From mhi_driver_remove that unitialize all channels
mhi_driver_remove()
|-> driver->remove()
| |-> mhi_unprepare_channel()
| |-> mhi_deinit_chan_ctxt()
|...
|-> mhi_deinit_chan_ctxt()
This leads to double dma freeing...
Fix that by preventing deinit for already uninitialized channel.
Link: https://lore.kernel.org/r/1612894264-15956-1-git-send-email-loic.poulain@linaro.org
Fixes: a7f422f2f8 ("bus: mhi: Fix channel close issue on driver remove")
Reported-by: Kalle Valo <kvalo@codeaurora.org>
Tested-by: Kalle Valo <kvalo@codeaurora.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20210210082538.2494-2-manivannan.sadhasivam@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This error path leads to a Smatch warning:
drivers/net/wireless/ath/ath11k/mac.c:4269 ath11k_mac_op_start()
error: double unlocked '&ar->conf_mutex' (orig line 4251)
We're not holding the lock when we do the "goto err;" so it leads to a
double unlock. The fix is to hold the lock for a little longer.
Fixes: c83c500b55 ("ath11k: enable idle power save mode")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
[kvalo@codeaurora.org: move also rcu_assign_pointer() call]
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/YBk4GoeE+yc0wlJH@mwanda
Fix the following coccicheck warning:
./drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:3853:7-17:
WARNING: Comparison of 0/1 to bool variable.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1612840381-109714-1-git-send-email-jiapeng.chong@linux.alibaba.com
Fix the follow coccicheck warnings:
./drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c:2305:6-27:
WARNING: Comparison of 0/1 to bool variable.
./drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c:1376:5-26:
WARNING: Comparison of 0/1 to bool variable.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/1612839264-85773-1-git-send-email-jiapeng.chong@linux.alibaba.com
Use devm_hwrng_register to get rid of manual unregistration.
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
This patch fixes inconsistent of printing format with argument type.
Signed-off-by: Weili Qian <qianweili@huawei.com>
Reviewed-by: Zaibo Xu <xuzaibo@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
There is no need to reset hardware when Corrected Error(CE) happens.
Signed-off-by: Weili Qian <qianweili@huawei.com>
Reviewed-by: Zaibo Xu <xuzaibo@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
There is no need to share IRQ among several devices,
and set 'irqflag' as 0.
Signed-off-by: Sihang Chen <chensihang1@hisilicon.com>
Signed-off-by: Weili Qian <qianweili@huawei.com>
Reviewed-by: Zaibo Xu <xuzaibo@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Since the size of base number is 16 bits, update the value of
'QM_SQC_VFT_BASE_MASK_V2' as 'GENMASK(15, 0)'.
Signed-off-by: Weili Qian <qianweili@huawei.com>
Reviewed-by: Zaibo Xu <xuzaibo@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Add 'qp_stop_fail_cb' to ensure it is called as device is resetting.
Signed-off-by: Weili Qian <qianweili@huawei.com>
Reviewed-by: Zaibo Xu <xuzaibo@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Add waiting logic for resetting as removing driver,
otherwise call trace will occur due to releasing resource.
Signed-off-by: Weili Qian <qianweili@huawei.com>
Reviewed-by: Zaibo Xu <xuzaibo@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
When CONFIG_CPUMASK_OFFSTACK is disabled, clang reports a warning
about a bogus condition:
drivers/crypto/marvell/octeontx2/otx2_cptlf.c:334:21: error: address of array 'lfs->lf[slot].affinity_mask' will always evaluate to 'true' [-Werror,-Wpointer-bool-conversion]
if (lfs->lf[slot].affinity_mask)
~~ ~~~~~~~~~~~~~~^~~~~~~~~~~~~
In this configuration, the free_cpumask_var() function does nothing,
so the condition could be skipped.
When the option is enabled, there is no warning, but the check
is also redundant because free_cpumask_var() falls back to kfree(),
which is documented as ignoring NULL pointers.
Remove the check to avoid the warning.
Fixes: 6450601703 ("crypto: octeontx2 - add LF framework")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Enable PASID by setting 'sqc' and 'cqc' pasid bits
per queue in Kunpeng 930.
For Kunpeng 920, PASID is effective for all queues once set
in SVA scenarios.
Signed-off-by: Weili Qian <qianweili@huawei.com>
Signed-off-by: Hui Tang <tanghui20@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Calling 'dma_map_single' after the data is written to
ensure that the cpu cache and dma cache are consistent.
Signed-off-by: Weili Qian <qianweili@huawei.com>
Signed-off-by: Hui Tang <tanghui20@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Update since some special settings only for Kunpeng920.
Signed-off-by: Hui Tang <tanghui20@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
HPRE of Kunpeng 930 is updated on cluster numbers,
so we try to update this driver to make it running
okay on Kunpeng920/Kunpeng930 chips.
Signed-off-by: Hui Tang <tanghui20@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Remove casting the values returned by dma_alloc_coherent.
Signed-off-by: Xu Wang <vulab@iscas.ac.cn>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
In ocs_aes_ccm_write_b0(), 'q' (the octet length of the binary
representation of the octet length of the payload) is set to 'iv[0]',
while it should be set to 'iv[0] & 0x7' (i.e., only the last 3
bits of iv[0] should be used), as documented in NIST Special Publication
800-38C:
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38c.pdf
In practice, this is not an issue, since 'iv[0]' is checked to be in the
range [1-7] by ocs_aes_validate_inputs(), but let's fix the assignment
anyway, in order to make the code more robust.
Signed-off-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Use devm_hwrng_register to get rid of manual unregistration.
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Instead of yielding from the bowels of the asm routine if a reschedule
is needed, divide up the input into 4 KB chunks in the C glue. This
simplifies the code substantially, and avoids scheduling out the task
with the asm routine on the call stack, which is undesirable from a
CFI/instrumentation point of view.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
There is no need for elaborate yield handling in the bit-sliced NEON
implementation of AES, given that skciphers are naturally bounded by the
size of the chunks returned by the skcipher_walk API. So remove the
yield calls from the asm code.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Instead of calling into kernel_neon_end() and kernel_neon_begin() (and
potentially into schedule()) from the assembler code when running in
task mode and a reschedule is pending, perform only the preempt count
check in assembler, but simply return early in this case, and let the C
code deal with the consequences.
This reverts commit 6caf7adc5e.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Instead of calling into kernel_neon_end() and kernel_neon_begin() (and
potentially into schedule()) from the assembler code when running in
task mode and a reschedule is pending, perform only the preempt count
check in assembler, but simply return early in this case, and let the C
code deal with the consequences.
This reverts commit 7edc86cb1c.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Instead of calling into kernel_neon_end() and kernel_neon_begin() (and
potentially into schedule()) from the assembler code when running in
task mode and a reschedule is pending, perform only the preempt count
check in assembler, but simply return early in this case, and let the C
code deal with the consequences.
This reverts commit d82f37ab5e.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
