Shenwei Wang [Mon, 11 Jan 2021 23:41:41 +0000 (17:41 -0600)]
MLK-25166-1 gpio: gpio-scu: gpio driver over scu fw misc api
This is a gpio driver to control the PINs which are managed by scu fw.
Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
Franck LENORMAND [Fri, 20 Mar 2020 09:42:48 +0000 (10:42 +0100)]
SSI-87: firmware: imx: scu: Support reception of message of any size
The word of a message can arrive in any order and the current driver
cannot receive more than 4-word message.
As the message can arrive in any order, the position where they
should be stored is stored in the sc_chan struct:
- initialized at the index of the MU slot
- incremented each time after a new word is stored
Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com>
Franck LENORMAND [Fri, 13 Mar 2020 10:53:38 +0000 (11:53 +0100)]
SSI-87: firmware: imx: scu: Support reception of any size message
The implementation was limiting the size of a message which can be
received to 4 but soem response can be bigger. For example the
response of the 'sc_seco_secvio_config' API is 6 words.
This patch removes this limitation relying on the count of word
received instead of the index of the chan.
It does so by duplicating imx_scu_call_rpc as imx_scu_call_big_rpc
in order to cahnge the RX method using imx_scu_big_rx_callback
instead of imx_scu_rx_callback.
Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com>
Joakim Zhang [Mon, 11 Jan 2021 05:06:22 +0000 (13:06 +0800)]
LF-3095-2 net: stmmac: re-init rx buffers when mac resume back
During suspend/resume stress test, we found descriptor write back by DMA
could exhibit unusual behavior, e.g.:
003 [0xc4310030]: 0x0 0x40 0x0 0xb5010040
We can see that desc3 write back is 0xb5010040, it is still ownd by DMA,
so application would not recycle this buffer. It will trigger fatal bus
error when DMA try to use this descriptor again. When current descriptor
move to this bad descriptor, it would not receive any more. To fix this
issue, we should re-init all rx buffers when mac resume back. This issue
can be reproduced on i.MX8MP EVK board.
Reviewed-by: Jun Li <jun.li@nxp.com>
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
Joakim Zhang [Wed, 6 Jan 2021 09:47:03 +0000 (17:47 +0800)]
LF-3095-1 net: stmmac: fix watchdog timeout during suspend/resume stress test
stmmac_xmit() call stmmac_tx_timer_arm() at the end to modify tx timer to
do the transmission cleanup work. Imagine such a situation, stmmac enters
suspend immediately after tx timer modified, it's expire callback
stmmac_tx_clean() would not be invoked. This could affect BQL, since
netdev_tx_sent_queue() has been called, but netdev_tx_completed_queue()
have not been involved, as a result, dql_avail(&dev_queue->dql) finally always
return a negative value.
__dev_queue_xmit->__dev_xmit_skb->qdisc_run->__qdisc_run->qdisc_restart->dequeue_skb:
if ((q->flags & TCQ_F_ONETXQUEUE) &&
netif_xmit_frozen_or_stopped(txq)) // __QUEUE_STATE_STACK_XOFF is set
Net core will stop transmitting any more. Finillay, net watchdong would timeout.
To fix this issue, we should call netdev_tx_reset_queue() in stmmac_resume().
Reviewed-by: Jun Li <jun.li@nxp.com>
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
Jacky Bai [Mon, 18 Jan 2021 07:25:03 +0000 (15:25 +0800)]
LF-3211 watchdog: imx7ulp: Add explict memory barrier for unlock sequence
Add explict memory barrier for the wdog unlock sequence.
Suggested-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
Horia Geantă [Thu, 7 Jan 2021 15:03:40 +0000 (17:03 +0200)]
LF-3120 crypto: caam - fix programming of RNG sample size
There are cases when default / POR value for RTSDCTL[ENT_DLY] is
equal or greater than minimum value that kernel tries to program (3200).
In this case, (re-)programming of RTSDCTL[ENT_DLY] and related RTFRQMIN,
RTFRQMAX is skipped - this logic is fine.
However, RNG sample size (RTSDCTL[SAMP_SIZE]) and associated self-test
parameters must be (re-)programmed irrespective of this condition.
This solves the issue of RNG performance dropping after a suspend/resume
cycle on parts where caam loses power AND default value for
RTSDCTL[ENT_DLY] is >= 3200 AND RNG handles are successfully instantiated.
Fixes:
29d925df53cf ("LF-2943 crypto: caam - optimize RNG sample size")
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Reviewed-by: Varun Sethi <v.sethi@nxp.com>
Horia Geantă [Wed, 13 Jan 2021 11:26:25 +0000 (13:26 +0200)]
LF-3079 crypto: caam/jr - fix shared IRQ line handling
There are cases when the interrupt status register (JRINTR) is non-zero,
even though:
1. An interrupt was generated, but it was masked OR
2. There was no interrupt generated at all
for the corresponding job ring.
1. The case when interrupt is masked (JRCFGR_LS[IMSK]=1b'1)
while other events have happened and are being accounted for, e.g.
-JRINTR[HALT]=2b'10 - input job ring underwent a flush of all on-going
jobs and processing of still-existing jobs (sitting in the ring) has been
halted
-JRINTR[HALT]=2b'01 - input job ring is currently undergoing a flush
-JRINTR[ENTER_FAIL]=1b'1 - SecMon / SNVS transitioned to FAIL MODE
It doesn't matter whether these events would assert the interrupt signal
or not, interrupt is anyhow masked.
2. The case when interrupt is not masked (JRCFGR_LS[IMSK]=1b'0), however
the events accounted for in JRINTR do not generate interrupts, e.g.:
-JRINTR[HALT]=2b'01
-JRINTR[ENTER_FAIL]=1b'1 and JRCFGR_MS[FAIL_MODE]=1b'0
Currently in these cases, when the JR interrupt handler is invoked (as a
consequence of JR sharing the interrupt line with other devices - e.g.
the two JRs on i.MX7ULP) it continues execution instead of returning
IRQ_NONE.
This could lead to situations like interrupt handler clearing JRINTR (and
thus also the JRINTR[HALT] field) while corresponding job ring is
suspended and then that job ring failing on resume path, due to expecting
JRINTR[HALT]=b'10 and reading instead JRINTR[HALT]=b'00.
Fix this by checking status of JRINTR[JRI] in the JR interrupt handler.
If JRINTR[JRI]=1b'0, there was no interrupt generated for this JR and
handler must return IRQ_NONE.
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Reviewed-by: Varun Sethi <v.sethi@nxp.com>
Ran Wang [Tue, 15 Sep 2020 08:46:35 +0000 (16:46 +0800)]
arm: dts: ls1021a: fix flextimer failed to wake system
The data of property 'fsl,rcpm-wakeup' is not corrcet, which causing
RCPM driver incorrectly program register IPPDEXPCR1, then flextimer is
wrongly clock gated during system suspend, can't send interrupt to
wake.
Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
Acked-by: Li Yang <leoyang.li@nxp.com>
Sandor Yu [Mon, 4 Jan 2021 07:52:13 +0000 (15:52 +0800)]
MLK-25216: phy: imx hdmi: fine tune phy to pass HDMI CTS
Fine tune hdmi phy to pass HDMI electrical CTS.
Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
Sandor Yu [Wed, 13 Jan 2021 06:00:46 +0000 (14:00 +0800)]
MLK-25156: drm: dw_hdmi: reset hdmi phy power
reset hdmi phy power.
Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
Sandor Yu [Tue, 12 Jan 2021 02:53:28 +0000 (10:53 +0800)]
MLK-25228: drm: dw-hdmi: Pass CTS 7-30 Audio InfoFrame
Set the value of SS1-SS0 and SF3-SF0 to zero to pass CTS 7-30.
Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Peng Fan [Wed, 13 Jan 2021 10:27:05 +0000 (18:27 +0800)]
LF-3097/LF-3172 virtio: ivshmem: check peer_state early
We enable the virtio_ivshmem driver and add
shared memory region including pci devices in cell file. But we not
start backend.
There might be garbage data in "vi_dev->virtio_header", so we need to
check peer_state to abort the probe earlier.
Note: patch accepted by Jailhouse Linux repo
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Zhao Qiang [Fri, 27 Nov 2020 03:16:02 +0000 (11:16 +0800)]
wdt: sp805: add watchdog_stop on reboot
Call watchdog_stop_on_reboot in probe func
Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
Daniel Baluta [Tue, 12 Jan 2021 13:27:28 +0000 (15:27 +0200)]
LF-3167-5 arch: arm64: Fix user supplied widget name
simple-card uses 'Headphones' instead of 'Headphone Jack'
for gpio pin name,
Without the current patch we get this error:
asoc-simple-card sof-sound-wm8960: ASoC: DAPM unknown pin Headphones
Reviewed-by: Viorel Suman <viorel.suman@nxp.com>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Daniel Baluta [Mon, 11 Jan 2021 18:35:14 +0000 (20:35 +0200)]
LF-3167-4 arch: arm64: imx8mp-evk-sof-wm8960: Fix detect gpios
There is no mic-det-gpio so remove it. Fix hp-det-gpio flags
to match non-sof usecase.
Reviewed-by: Viorel Suman <viorel.suman@nxp.com>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Daniel Baluta [Mon, 11 Jan 2021 18:25:51 +0000 (20:25 +0200)]
LF-3167-3 arch: arm64: imx8mp-evk-sof-wm8960: Fix routes connections
According to 8MPLUSS-BB schematic:
- HP_MIC1P -> LINPUT3 / JD2
- X -> LINPUT2
- HP_MIC1N -> LINPUT1
- HP_JD -> RINPUT3 / JD3
- X -> RINPUT2
- X -> RINPUT1
Fix the routing map according to schematic.
Reviewed-by: Viorel Suman <viorel.suman@nxp.com>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Daniel Baluta [Mon, 11 Jan 2021 18:10:50 +0000 (20:10 +0200)]
LF-3167-2 arch: arm64: Fix capture with wm8960 codec
Add MICB -> Mic Jack connection in order to power up Microphone.
Reviewed-by: Viorel Suman <viorel.suman@nxp.com>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Daniel Baluta [Mon, 11 Jan 2021 17:58:07 +0000 (19:58 +0200)]
LF-3167-1 arch: arm64: Fix routing dts property
Property name for routing used by simple card is 'routing' not
'audio-routing'.
Reviewed-by: Viorel Suman <viorel.suman@nxp.com>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Ming Qian [Wed, 6 Jan 2021 01:56:49 +0000 (09:56 +0800)]
MLK-25203-2:[8QM_MEK/8QXP_MEK]mxc:vpu_malone: set data of skip event to 0xff
driver will use the data to report the skipped frame.
but the vpu driver of 8q can't get the skipped frame id,
so set it to an invalid value.
Signed-off-by: Ming Qian <ming.qian@nxp.com>
Reviewed-by: Shijie Qin <shijie.qin@nxp.com>
(cherry picked from commit
f9782fd6e516647ad73476bb9d39eb2dd892ae05)
Ming Qian [Mon, 4 Jan 2021 06:49:48 +0000 (14:49 +0800)]
MLK-25205: [8QM_MEK/8QXP_MEK]mxc:vpu_malone: exchange the V4L2_PIX_FMT_VC1_ANNEX_G and V4L2_PIX_FMT_VC1_ANNEX_L
Due to historical reasons,
we have made a mistake abort vc1_l and vc1_g,
they are reversed.
so we need to exchange them in driver,
and the userspace also needs to be modified accordingly
Signed-off-by: Ming Qian <ming.qian@nxp.com>
Reviewed-by: Shijie Qin <shijie.qin@nxp.com>
(cherry picked from commit
9e4f4f44257312c2b4df47d0005762e8068e1bd0)
Ming Qian [Mon, 4 Jan 2021 06:09:59 +0000 (14:09 +0800)]
MLK-25203:[8QM_MEK/8QXP_MEK]mxc:vpu_malone: align custom interface to imx_vpu.h
we have add a header file imx_vpu.h
to define the custom interface based on v4l2 driver.
to unify the interface,
we need to align the 8qm/qxp v4l2 driver to this header.
Signed-off-by: Ming Qian <ming.qian@nxp.com>
Reviewed-by: Shijie Qin <shijie.qin@nxp.com>
(cherry picked from commit
8cfb286daa653c5876c157d20bed6a44420bab27)
Ming Qian [Wed, 30 Dec 2020 02:04:27 +0000 (10:04 +0800)]
MLK-25196:[8QM_MEK/8QXP_MEK]mxc:vpu_malone: add a header file to define custom driver interface
To unify the driver interface on 8q and 8m,
we need to add a new header file to define custom interfaces
Signed-off-by: Ming Qian <ming.qian@nxp.com>
Reviewed-by: Shijie Qin <shijie.qin@nxp.com>
(cherry picked from commit
47c536bc846dfec04cf5eb502b895a65ecd5376d)
Haibo Chen [Tue, 12 Jan 2021 08:35:36 +0000 (16:35 +0800)]
LF-3151 arm: imx7ulp: save/restore port PCR register for PM_SUSPEND_MEM mode
For imx7ulp PM_SUSPEND_MEM mode, all port related register will lost.
This patch add the save/restore operation. This will benefit gpio-irq.
Without this patch, gpio irq can't work after system PM.
This patch depend on the dts file, the sequence of gpio definition must
be gpio_ptc gpio_ptd gpio_pte gpio_ptf.
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Acked-by: Jacky Bai <ping.bai@nxp.com>
Alice Guo [Tue, 12 Jan 2021 09:21:25 +0000 (17:21 +0800)]
LF-3176 dts: imx8mq: fix PCIe interrupt-map error
The fourth number in interrupt-map represents different interrupt
sources so that should be set to a different value.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Richard Zhu [Tue, 12 Jan 2021 03:13:54 +0000 (11:13 +0800)]
LF-1112 PCI: imx: kernel oops during Browse /sys file system test
Refer to commit
075af61c19cd ("PCI: imx6: Limit DBI register length"),
i.MX6QP PCIe has the similar issue.
Define the length of the DBI registers and limit config space to its
length for i.MX6QP PCIe too.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Peter Chen <peter.chen@nxp.com>
Li Jun [Sun, 13 Oct 2019 11:55:04 +0000 (19:55 +0800)]
LF-3039 usb: chipidea: imx: turn off vbus comparator when suspend
As we use bvalid for vbus wakeup source, to save power when
suspend, turn off the vbus comparator for imx7d and imx8mm.
Below is this bit description from RM of iMX8MM
"VBUS Valid Comparator Enable:
This signal controls the USB OTG PHY VBUS Valid comparator which
indicates whether the voltage on the USB_OTG*_VBUS pin is below
the VBUS Valid threshold. The VBUS Valid threshold is nominally
4.75V on this USB PHY. The VBUS Valid threshold can be adjusted
using the USBNC_OTGn_PHY_CFG1[OTGTUNE0] bit field. Status of the
VBUS Valid comparator, when it is enabled, is reported on the
USBNC_OTGn_PHY_STATUS[VBUS_VLD] bit.
When OTGDISABLE0 (USBNC_USB_OTGx_PHY_CFG2[10])is set to 1'b0 and
DRVVBUS0 is set to 1'b1, the Bandgap circuitry and VBUS Valid
comparator are powered, even in Suspend or Sleep mode.
DRVVBUS0 should be reset to 1'b0 when the internal VBUS Valid comparator
is not required, to reduce quiescent current in Suspend or Sleep mode.
- 0 The VBUS Valid comparator is disabled
- 1 The VBUS Valid comparator is enabled"
Reviewed-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Li Jun <jun.li@nxp.com>
(cherry picked from commit
dc5f8b1958cf0b9a01813e65c8b8e084c6d1b208)
Li Jun [Mon, 11 Jan 2021 10:59:44 +0000 (18:59 +0800)]
LF-3141-5 usb: chipidea: imx: remove one duplicated reg define
Rremove one definition of MX7D_USB_OTG_PHY_CFG1.
Reviewed-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Li Jun <jun.li@nxp.com>
Peter Chen [Thu, 22 Dec 2016 03:19:03 +0000 (11:19 +0800)]
LF-3141-4 usb: chipidea: usbmisc_imx: add power_lost_check API for imx7ulp
For imx7ulp, the power of USB controller may be lost, add power_lost_check
API for USB recovery.
(This is a reworked cherry-pick patch of MLK-13638-5)
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Li Jun <jun.li@nxp.com>
(cherry picked from commit
64a3e0c3eb5b884862459ce9ae003df35ef29405)
(cherry picked from commit
5fab364d5ab4577e4b16e1efc53fe67dde4016a4)
Li Jun [Mon, 30 Mar 2015 05:19:42 +0000 (13:19 +0800)]
LF-3141-3 usb: chipidea: usbmisc_imx: add power lost check for i.MX7D
Add power lost check implementation for i.MX7D.
(This is a reworked cherry-pick patch of MLK-10510-3)
Acked-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Li Jun <jun.li@freescale.com>
(cherry picked from commit
59102c3b9756923f1c8cdba8bcab7b8611685321)
(cherry picked from commit
cf5e629825d1cc97d32deddbf452424c704f97f0)
Li Jun [Thu, 15 Jan 2015 11:13:13 +0000 (19:13 +0800)]
LF-3141-2 usb: chipidea: imx: usb resume from power lost during system sleep
i.MX6SX mega off can shutdown domain power supply if none of peripheral
in this domain is registered as wakeup source, this patch adds usb controller
imx specific re-init after resume from such power lost during system sleep.
(This is a reworked cherry-pick patch of MLK-10102-1)
Signed-off-by: Li Jun <jun.li@freescale.com>
(cherry picked from commit
cd37f9b7157322e28c1d336e42813d441eb1f778)
Signed-off-by: Peter Chen <peter.chen@nxp.com>
(cherry picked from commit
bd6e7339b6137fe4af490f6647e2cb6338cc88b5)
Li Jun [Sun, 13 Oct 2019 11:49:59 +0000 (19:49 +0800)]
LF-3141-1 usb: chipidea: imx: group usbmisc operations for PM
As there maybe more APIs of usbmisc for suspend and resume, group
them into imx_usbmisc_suspend/resume, no function change.
(This is reworked cherry-pick patch of MLK-21900-1)
Reviewed-by: Peter Chen <peter.chen@nxp.com>
Signed-off-by: Li Jun <jun.li@nxp.com>
(cherry picked from commit
29f824ce614ac2c932eab6d97493ce350db74d50)
Jason Liu [Fri, 8 Jan 2021 10:13:16 +0000 (18:13 +0800)]
LF-3147 usb: typec: gpio-switch: fix the stack-out-of-bounds access
KASAN complains about the stack-out-of-bounds access as the following.
The reason is that the const char* name of sw_desc was not initialized,
which leaves the name is wild and bring in illegal access and KASAN err.
The fix is to explicitly initialized const char* name = NULL of sw_desc.
[ 5.930564] BUG: KASAN: stack-out-of-bounds in string_nocheck+0xd8/0x140
[ 5.930594] Read of size 1 at addr
ffff0000c0bef9f0 by task kworker/2:1/33
[ 5.944526] CPU: 2 PID: 33 Comm: kworker/2:1 Not tainted
5.10.4-00832-g9b9f5dcc807a #212
[ 5.944539] Hardware name: NXP i.MX8MPlus EVK board (DT)
[ 5.944575] Workqueue: events deferred_probe_work_func
[ 5.977344] Call trace:
[ 5.979833] dump_backtrace+0x0/0x2b8
[ 5.983535] show_stack+0x18/0x68
[ 5.986885] dump_stack+0x100/0x168
[ 5.990413] print_address_description.constprop.0+0x70/0x4e4
[ 5.996193] kasan_report+0x134/0x200
[ 5.999883] __asan_load1+0xa8/0xb8
[ 6.003406] string_nocheck+0xd8/0x140
[ 6.007183] string+0xe4/0xf0
[ 6.010189] vsnprintf+0x238/0x990
[ 6.013623] kvasprintf+0xb0/0x1b0
[ 6.017055] kvasprintf_const+0xc8/0x178
[ 6.021017] kobject_set_name_vargs+0x54/0xf0
[ 6.025406] dev_set_name+0xa4/0xd8
[ 6.028926] typec_switch_register+0x11c/0x1c8
[ 6.033402] typec_switch_gpio_probe+0x13c/0x1d0
[ 6.038055] platform_drv_probe+0x70/0xd0
[ 6.042092] really_probe+0x148/0x518
[ 6.045784] driver_probe_device+0x78/0xe8
[ 6.049911] __device_attach_driver+0xcc/0xf8
[ 6.054297] bus_for_each_drv+0xf0/0x160
[ 6.058247] __device_attach+0x184/0x1f0
[ 6.062200] device_initial_probe+0x14/0x20
[ 6.066411] bus_probe_device+0xec/0x100
[ 6.070362] deferred_probe_work_func+0xac/0xf0
[ 6.074922] process_one_work+0x3e0/0x668
[ 6.078961] worker_thread+0x3d0/0x670
[ 6.082748] kthread+0x21c/0x228
[ 6.086005] ret_from_fork+0x10/0x34
[ 6.091109] The buggy address belongs to the page:
[ 6.095931] page:(____ptrval____) refcount:0 mapcount:0 mapping:
0000000000000000 index:0x0 pfn:0x100bef
[ 6.105356] flags: 0xbfffc0000000000()
[ 6.109148] raw:
0bfffc0000000000 fffffe0002e2fbc8 fffffe0002e2fbc8 0000000000000000
[ 6.116923] raw:
0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[ 6.124689] page dumped because: kasan: bad access detected
[ 6.131793] addr
ffff0000c0bef9f0 is located in stack of task kworker/2:1/33 at offset 64 in frame:
[ 6.140869] typec_switch_gpio_probe+0x0/0x1d0
[ 6.146837] this frame has 1 object:
[ 6.150435] [32, 64) 'sw_desc'
[ 6.155101] Memory state around the buggy address:
[ 6.159922]
ffff0000c0bef880: f1 f1 f1 f1 00 00 00 00 f3 f3 f3 f3 00 00 00 00
[ 6.167174]
ffff0000c0bef900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 6.174424] >
ffff0000c0bef980: 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 f3 f3
[ 6.181665] ^
[ 6.188567]
ffff0000c0befa00: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 6.195817]
ffff0000c0befa80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 6.203061] ==================================================================
Signed-off-by: Jason Liu <jason.hui.liu@nxp.com>
Reviewed-by: Jun Li <jun.li@nxp.com>
Sandor Yu [Wed, 30 Dec 2020 08:12:52 +0000 (16:12 +0800)]
MLK-25199-7: arm64: dts: freescale: add hdcp-config property for imx8
Add hdcp-config property for imx8 hdmi tx hdcp.
hdcp-config default configurate to 3.
hdcp-config = <0x1> /* For HDCP1.4 only */
hdcp-config = <0x2> /* For HDCP2.2 only */
hdcp-config = <0x3> /* For both HDCP2.2 and HDCP1.4 */
Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
Sandor Yu [Wed, 30 Dec 2020 08:08:14 +0000 (16:08 +0800)]
MLK-25199-6: drm: imx: mhdp: Default enable HDCP driver
Select DRM_CDNS_HDMI_HDCP, enable HDCP driver.
Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
Sandor Yu [Wed, 30 Dec 2020 08:07:41 +0000 (16:07 +0800)]
MLK-25199-5: drm: bridge: mhdp_hdcp: add HDMI TX HDCP driver
This patch adds an initial HDMI TX HDCP driver
for Cadence MHDP HDMI TX hardware.
Both HDCP2.2 and HDCP1.4 are supported.
HDCP function could be enabled by command:
modetest -w CONNECTOR_ID:"Content Protection":1
Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
Sandor Yu [Wed, 30 Dec 2020 08:05:29 +0000 (16:05 +0800)]
MLK-25199-4: drm: bridge: mhdp_hdmi: set clear avmute bit
Sync HDMI TX configuation with 4.14 hdmi driver.
Clear avmute bit must be set otherwise imx8qm hdcp not work.
Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
Sandor Yu [Wed, 30 Dec 2020 08:04:20 +0000 (16:04 +0800)]
MLK-25199-3: drm: bridge: mhdp_common: add apb config function
Add apb config function, move mhdp poll function
to mhdp head file, they will be used by hdcp driver.
Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
Sandor Yu [Thu, 31 Dec 2020 02:13:55 +0000 (10:13 +0800)]
MLK-25199-2: drm: mhdp: Fix typo for hdmi phy configuration table
Fix typo for imx8qm hdmi phy configuration table.
Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
Sandor Yu [Wed, 30 Dec 2020 08:02:52 +0000 (16:02 +0800)]
MLK-25199-1: drm: mhdp: Add hdmi phy reset/poweroff function
Add hdmi phy reset and power off function.
Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
Sandor Yu [Thu, 3 Dec 2020 13:27:37 +0000 (21:27 +0800)]
MLK-25101: drm: imx: dw_hdmi: Keep hdmi phy in poweron status
The pixel clock of display controller lcdifv3 source from hdmi phy.
When hdmi cable plugout irq trigger,
hdmi phy will be poweroff immediately in hdmi controller driver.
But DRM and user app may still working until they received plugout event.
For such case, the kernel will dump.
[ 89.707045] ------------[ cut here ]------------
[ 89.711705] [CRTC:39:crtc-2] vblank wait timed out
[ 89.716563] WARNING: CPU: 2 PID: 7 at drivers/gpu/drm/drm_atomic_helper.c:1467 drm_atomic_helper_wait_for_vblanks.part.0+0x274/0x290
[ 89.728472] Modules linked in:
[ 89.731533] CPU: 2 PID: 7 Comm: kworker/u8:0 Not tainted
5.4.70-00041-g631cb8d6e2b2-dirty #23
[ 89.740055] Hardware name: NXP i.MX8MPlus EVK board (DT)
[Playing (No Repeated)][Vol=1.0][ 89.745372] Workqueue: events_unbound commit_work
[00:00:04/00:02:18][ 89.752939] pstate:
40000005 (nZcv daif -PAN -UAO)
[ 89.759376] pc : drm_atomic_helper_wait_for_vblanks.part.0+0x274/0x290
[ 89.765905] lr : drm_atomic_helper_wait_for_vblanks.part.0+0x274/0x290
[ 89.772431] sp :
ffff800011c43ca0
[ 89.775744] x29:
ffff800011c43ca0 x28:
0000000000000000
[ 89.781054] x27:
000000000000055f x26:
0000000000000070
[ 89.786363] x25:
ffff00017786b800 x24:
0000000000000001
[ 89.791674] x23:
0000000000000038 x22:
0000000000000004
[ 89.796983] x21:
ffff00016a375400 x20:
ffff00017786b088
[ 89.802293] x19:
0000000000000002 x18:
0000000000000010
[ 89.807604] x17:
0000000000000000 x16:
0000000000000000
[ 89.812913] x15:
ffff0001760c5870 x14:
ffffffffffffffff
[ 89.818225] x13:
ffff800091c439f7 x12:
ffff800011c439ff
[ 89.823537] x11:
ffff800011a11000 x10:
ffff800011b36328
[ 89.828847] x9 :
0000000000000000 x8 :
ffff800011b37000
[ 89.834158] x7 :
ffff80001069fc68 x6 :
0000000000000341
[ 89.839469] x5 :
0000000000000000 x4 :
ffff00017f3a0188
[ 89.844778] x3 :
ffff00017f3a6f20 x2 :
ffff00017f3a0188
[ 89.850088] x1 :
4d8823010d259700 x0 :
0000000000000000
[ 89.855404] Call trace:
[ 89.857854] drm_atomic_helper_wait_for_vblanks.part.0+0x274/0x290
[ 89.864033] drm_atomic_helper_wait_for_vblanks+0x14/0x20
[ 89.869433] lcdifv3_drm_atomic_commit_tail+0x64/0x7c
[ 89.874484] commit_tail+0x9c/0x138
[ 89.877970] commit_work+0x10/0x18
[ 89.881372] process_one_work+0x198/0x320
[ 89.885382] worker_thread+0x48/0x420
[ 89.889042] kthread+0x138/0x158
[ 89.892272] ret_from_fork+0x10/0x1c
[ 89.895847] ---[ end trace
ed53d661901a6437 ]---
Keep hdmi phy in poweron status when cable plugout to workaround the issue.
HDMI phy power off function will be move to lcdifv3 or hdmi phy driver
later.
Signed-off-by: Sandor Yu <Sandor.yu@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
(cherry picked from commit
8fb049834bff5edfd15d62bee9bda333c2ddfcee)
Horia Geantă [Thu, 24 Dec 2020 10:17:03 +0000 (12:17 +0200)]
mailbox: imx: fix compilation warnings
Fix the following compilation warnings on 64-bit platforms by using
the proper format (%zu) for size_t (return type for sizeof()):
In file included from ./include/linux/device.h:15,
from ./include/linux/firmware/imx/ipc.h:11,
from drivers/mailbox/imx-mailbox.c:7:
drivers/mailbox/imx-mailbox.c: In function ‘imx_mu_seco_tx’:
drivers/mailbox/imx-mailbox.c:313:5: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 3 has type ‘long unsigned int’ [-Wformat=]
313 | "Exceed max msg size (%u) on TX, got: %i\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/dev_printk.h:19:22: note: in definition of macro ‘dev_fmt’
19 | #define dev_fmt(fmt) fmt
| ^~~
drivers/mailbox/imx-mailbox.c:312:4: note: in expansion of macro ‘dev_err’
312 | dev_err(priv->dev,
| ^~~~~~~
drivers/mailbox/imx-mailbox.c:313:28: note: format string is defined here
313 | "Exceed max msg size (%u) on TX, got: %i\n",
| ~^
| |
| unsigned int
| %lu
In file included from ./include/linux/device.h:15,
from ./include/linux/firmware/imx/ipc.h:11,
from drivers/mailbox/imx-mailbox.c:7:
drivers/mailbox/imx-mailbox.c: In function ‘imx_mu_seco_rxdb’:
CC drivers/mailbox/pcc.o
drivers/mailbox/imx-mailbox.c:374:22: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 3 has type ‘long unsigned int’ [-Wformat=]
374 | dev_err(priv->dev, "Exceed max msg size (%u) on RX, got: %i\n",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/dev_printk.h:19:22: note: in definition of macro ‘dev_fmt’
19 | #define dev_fmt(fmt) fmt
| ^~~
drivers/mailbox/imx-mailbox.c:374:3: note: in expansion of macro ‘dev_err’
374 | dev_err(priv->dev, "Exceed max msg size (%u) on RX, got: %i\n",
| ^~~~~~~
drivers/mailbox/imx-mailbox.c:374:45: note: format string is defined here
374 | dev_err(priv->dev, "Exceed max msg size (%u) on RX, got: %i\n",
| ~^
| |
| unsigned int
| %lu
Fixes:
eff00db88291 ("LF-3112: mailbox: imx: fix build warnings caused by type mismatch")
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Acked-by: Jason Liu <jason.hui.liu@nxp.com>
Jacky Bai [Thu, 7 Jan 2021 01:30:20 +0000 (09:30 +0800)]
MLK-24135 clk: imx: Add a temporary workaround for suspend hang casued by the EQOS module
Keep the EQOS clocks always on to wrokaround the system hang issue when
doing suspend/resume stress test. The root cause is still under debug.
For now, we just add this workaround to make sure the system suspend/resume
function is ok when EQOS is enanble. this workaround will be removed
when the root cause is found.
(cherry-picked from kernel 5.4, and refined by Joakim.)
Reviewed-by: Fugang Duan <fugang.duan@nxp.com>
Reviewed-by: Li Jun <jun.li@nxp.com>
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com>
Stéphane Dion [Tue, 24 Mar 2020 13:05:20 +0000 (14:05 +0100)]
LF-3029 arm64: dts: imx8dxl: add v2x subsystem
This patch adds the V2X subsystem in which the different
MUs to access the V2X are listed. Without this patch the DXL
fails to enter KS1 as V2X resource is left ON and suspend
power is very high.
Signed-off-by: Stéphane Dion <stephane.dion_1@nxp.com>
Signed-off-by: Nitin Garg <nitin.garg@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Nitin Garg [Thu, 7 Jan 2021 01:59:22 +0000 (19:59 -0600)]
LF-2692: clk: imx: scu: Do not enable runtime PM for CPU clks
Since CPU clocks are managed by CPUFREQ, do not enable
runtime PM otherwise rpm gets out of status as cpufreq
also manages clock states.
Signed-off-by: Nitin Garg <nitin.garg@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
Adrian Alonso [Mon, 21 Dec 2020 16:30:08 +0000 (10:30 -0600)]
MLK-25186: sound: soc: fsl: imx pcm512: cleanup remove tdm slots
Cleanup remove tdm slot settings, same effect by using
setting cpu_dai bit clock ratio.
Signed-off-by: Adrian Alonso <adrian.alonso@nxp.com>
Adrian Alonso [Fri, 18 Dec 2020 17:29:28 +0000 (11:29 -0600)]
MLK-25185: sound: soc: fsl: imx pcm512x: fix mclk selection on master mode
Fix mclk selection when codec is in master mode to properly
get PCM512x sck rate
Signed-off-by: Adrian Alonso <adrian.alonso@nxp.com>
Adrian Alonso [Fri, 18 Dec 2020 15:00:31 +0000 (09:00 -0600)]
MLK-25184: sound: soc: fsl: imx pcm512x: gate external clocks
Gate external audio clocks on codec master mode when
playback completes
Signed-off-by: Adrian Alonso <adrian.alonso@nxp.com>
Shengjiu Wang [Tue, 5 Jan 2021 07:54:51 +0000 (15:54 +0800)]
LF-2654: ASoC: fsl_micfil: Remove irq off when enable hwvad
Use the trace, we can see that latency of irqsoff is too long.
sh-606 1dN.1 0us@: _raw_spin_lock_irq <-rpm_resume
sh-606 1dN.1 409730us : _raw_spin_unlock_irqrestore <-micfil_hwvad_handler
sh-606 1dN.1 409731us : tracer_hardirqs_on <-micfil_hwvad_handler
sh-606 1dN.1 409734us : <stack trace>
that cause the error log:
[18636.948715] cpu cpu0: _set_opp_voltage: failed to set voltage (
1000000 1000000 1000000 mV): -110
[18636.957524] cpufreq: __target_index: Failed to change cpu frequency: -110
So remove the irq disable operation in micfil_hwvad_handler.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Reviewed-by: Peng Zhang <peng.zhang_8@nxp.com>
Fancy Fang [Thu, 31 Dec 2020 02:21:44 +0000 (10:21 +0800)]
LF-3090-2 clk: imx7d: add 'CLK_SET_RATE_PARENT' for 'lcdif_pixel_src'
Add flag 'CLK_SET_RATE_PARENT' to 'IMX7D_LCDIF_PIXEL_ROOT_SRC' to
propagate rate changes from LCDIF pixel clock to video PLL which
can provide more accurate clock rate for LCDIF pixel clock.
Signed-off-by: Fancy Fang <chen.fang@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
Fancy Fang [Wed, 30 Dec 2020 08:34:57 +0000 (16:34 +0800)]
LF-3090-1 arm: dts: imx7s: assign PLL video as source of lcdif pixel
Current LCDIF pixel clock source comes from osc_24m like below:
lcdif_pixel_src 1 1 0
24000000 0 0 50000
lcdif_pixel_cg 1 1 0
24000000 0 0 50000
lcdif_pixel_pre_div 1 1 0
8000000 0 0 50000
lcdif_pixel_post_div 1 1 0
8000000 0 0 50000
lcdif_pixel_root_clk 1 1 0
8000000 0 0 50000
But osc_24m cannot meet LCDIF requirement for different display
modes obviously. So assign the video PLL for its parent and the
clock tree becomes as below:
pll_video_main 1 1 1
736000000 0 0 50000
pll_video_main_bypass 1 1 1
736000000 0 0 50000
pll_video_main_clk 1 1 1
736000000 0 0 50000
pll_video_test_div 1 1 2
184000000 0 0 50000
pll_video_post_div 1 1 1
46000000 0 0 50000
lcdif_pixel_src 1 1 0
46000000 0 0 50000
lcdif_pixel_cg 1 1 0
46000000 0 0 50000
lcdif_pixel_pre_div 1 1 0
9200000 0 0 50000
lcdif_pixel_post_div 1 1 0
9200000 0 0 50000
lcdif_pixel_root_clk 1 1 0
9200000 0 0 50000
Signed-off-by: Fancy Fang <chen.fang@nxp.com>
Reviewed-by: Robby Cai <robby.cai@nxp.com>
Jason Liu [Mon, 4 Jan 2021 07:20:25 +0000 (15:20 +0800)]
LF-3112: mailbox: imx: fix build warnings caused by type mismatch
drivers/mailbox/imx-mailbox.c: In function ‘imx_mu_seco_tx’:
drivers/mailbox/imx-mailbox.c:313:5: warning: format ‘%li’ expects argument of type ‘long int’, but argument 3 has type ‘unsigned int’ [-Wformat=]
"Exceed max msg size (%li) on TX, got: %i\n",
^
drivers/mailbox/imx-mailbox.c: In function ‘imx_mu_seco_rxdb’:
drivers/mailbox/imx-mailbox.c:374:22: warning: format ‘%li’ expects argument of type ‘long int’, but argument 3 has type ‘unsigned int’ [-Wformat=]
"Exceed max msg size (%li) on RX, got: %i\n",
use %u instead of %li to fix the type mismatch issue
Signed-off-by: Jason Liu <jason.hui.liu@nxp.com>
Acked-by: Peng Fan <peng.fan@nxp.com>
Robin Gong [Mon, 4 Jan 2021 16:58:42 +0000 (00:58 +0800)]
MLK-25206-5: arm64: dts: imx8mp-evk-rpmsg: enable sdma1
enable sdma1 as i.mx8mm-evk-rpmsg.dts.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Robin Gong [Mon, 4 Jan 2021 16:57:44 +0000 (00:57 +0800)]
MLK-25206-4: arm64: dts: imx8mn-evk-rpmsg: enable sdma1
enable sdma1 as i.mx8mm-evk-rpmsg.dts.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Robin Gong [Mon, 4 Jan 2021 16:56:46 +0000 (00:56 +0800)]
MLK-25206-3: arm64: dts: imx8mn-ddr4-evk-rpmsg: enable sdma1
enable sdma1 as i.mx8mm-evk-rpmsg.dts.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Robin Gong [Mon, 4 Jan 2021 16:54:45 +0000 (00:54 +0800)]
MLK-25206-2: arm64: dts: imx8mn-ddr3l-evk-rpmsg: enable sdma1
enable sdma1 as i.mx8mm-evk-rpmsg.dts.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Robin Gong [Mon, 4 Jan 2021 16:49:06 +0000 (00:49 +0800)]
MLK-25206-1: arm64: dts: imx8mm-evk-rpmsg: enable sdma1
Enable sdma1 since Yocto use sdma1 as udev rule to trigger firmware
loader, actually, m4 do not need to disable sdma1 because it's standlone
demo which means don't care kernel bootup. Enable it in rpmsg dtb to
ensure sdma firmware load successfully as the default dtb.
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Reviewed-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Richard Zhu [Mon, 4 Jan 2021 05:22:37 +0000 (13:22 +0800)]
LF-3103 phy: freescale: pcie: fix the imx8mp evk ep rc link degrade issue
Similar to commit
17db82300f80 ("MLK-25089 phy: freescale: pcie: fix the
imx8mp evk ep rc link speed issue")
Fine tune the PHY parameters, let the PCIe link up to GEN3 between two
i.MX865 EVK boards in the i.MX EP RC validation system.
Since this fine tuned is only specified for EVK boards. Add the command
parameter to specify it when do the EP RC tests between two i.MX8MP EVK
boards. Use the "pcie_phy_tuned=yes" to enable the PHY fine-tune.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Peter Chen <peter.chen@nxp.com>
Jason Liu [Mon, 4 Jan 2021 09:15:40 +0000 (17:15 +0800)]
Merge tag 'v5.10.4' into lf-5.10.y
This is the 5.10.4 stable release
* tag 'v5.10.4': (717 commits)
Linux 5.10.4
x86/CPU/AMD: Save AMD NodeId as cpu_die_id
drm/edid: fix objtool warning in drm_cvt_modes()
...
Signed-off-by: Jason Liu <jason.hui.liu@nxp.com>
Conflicts:
drivers/gpu/drm/imx/dcss/dcss-plane.c
drivers/media/i2c/ov5640.c
Jason Liu [Mon, 4 Jan 2021 08:59:51 +0000 (16:59 +0800)]
Merge tag 'v5.10.3' into lf-5.10.y
This is the 5.10.3 stable release
* tag 'v5.10.3': (41 commits)
Linux 5.10.3
md: fix a warning caused by a race between concurrent md_ioctl()s
nl80211: validate key indexes for cfg80211_registered_device
...
Signed-off-by: Jason Liu <jason.hui.liu@nxp.com>
Jason Liu [Mon, 4 Jan 2021 09:15:07 +0000 (17:15 +0800)]
Merge tag 'v5.10.2' into lf-5.10.y
This is the 5.10.2 stable release
* tag 'v5.10.2': (17 commits)
Linux 5.10.2
serial: 8250_omap: Avoid FIFO corruption caused by MDR1 access
ALSA: pcm: oss: Fix potential out-of-bounds shift
...
Signed-off-by: Jason Liu <jason.hui.liu@nxp.com>
Conflicts:
drivers/usb/host/xhci-hub.c
drivers/usb/host/xhci.h
Greg Kroah-Hartman [Wed, 30 Dec 2020 10:54:29 +0000 (11:54 +0100)]
Linux 5.10.4
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Link: https://lore.kernel.org/r/20201229103832.108495696@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yazen Ghannam [Mon, 9 Nov 2020 21:06:56 +0000 (21:06 +0000)]
x86/CPU/AMD: Save AMD NodeId as cpu_die_id
[ Upstream commit
028c221ed1904af9ac3c5162ee98f48966de6b3d ]
AMD systems provide a "NodeId" value that represents a global ID
indicating to which "Node" a logical CPU belongs. The "Node" is a
physical structure equivalent to a Die, and it should not be confused
with logical structures like NUMA nodes. Logical nodes can be adjusted
based on firmware or other settings whereas the physical nodes/dies are
fixed based on hardware topology.
The NodeId value can be used when a physical ID is needed by software.
Save the AMD NodeId to struct cpuinfo_x86.cpu_die_id. Use the value
from CPUID or MSR as appropriate. Default to phys_proc_id otherwise.
Do so for both AMD and Hygon systems.
Drop the node_id parameter from cacheinfo_*_init_llc_id() as it is no
longer needed.
Update the x86 topology documentation.
Suggested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20201109210659.754018-2-Yazen.Ghannam@amd.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Linus Torvalds [Thu, 17 Dec 2020 17:27:57 +0000 (09:27 -0800)]
drm/edid: fix objtool warning in drm_cvt_modes()
commit
d652d5f1eeeb06046009f4fcb9b4542249526916 upstream.
Commit
991fcb77f490 ("drm/edid: Fix uninitialized variable in
drm_cvt_modes()") just replaced one warning with another.
The original warning about a possibly uninitialized variable was due to
the compiler not being smart enough to see that the case statement
actually enumerated all possible cases. And the initial fix was just to
add a "default" case that had a single "unreachable()", just to tell the
compiler that that situation cannot happen.
However, that doesn't actually fix the fundamental reason for the
problem: the compiler still doesn't see that the existing case
statements enumerate all possibilities, so the compiler will still
generate code to jump to that unreachable case statement. It just won't
complain about an uninitialized variable any more.
So now the compiler generates code to our inline asm marker that we told
it would not fall through, and end end result is basically random. We
have created a bridge to nowhere.
And then, depending on the random details of just exactly what the
compiler ends up doing, 'objtool' might end up complaining about the
conditional branches (for conditions that cannot happen, and that thus
will never be taken - but if the compiler was not smart enough to figure
that out, we can't expect objtool to do so) going off in the weeds.
So depending on how the compiler has laid out the result, you might see
something like this:
drivers/gpu/drm/drm_edid.o: warning: objtool: do_cvt_mode() falls through to next function drm_mode_detailed.isra.0()
and now you have a truly inscrutable warning that makes no sense at all
unless you start looking at whatever random code the compiler happened
to generate for our bare "unreachable()" statement.
IOW, don't use "unreachable()" unless you have an _active_ operation
that generates code that actually makes it obvious that something is not
reachable (ie an UD instruction or similar).
Solve the "compiler isn't smart enough" problem by just marking one of
the cases as "default", so that even when the compiler doesn't otherwise
see that we've enumerated all cases, the compiler will feel happy and
safe about there always being a valid case that initializes the 'width'
variable.
This also generates better code, since now the compiler doesn't generate
comparisons for five different possibilities (the four real ones and the
one that can't happen), but just for the three real ones and "the rest"
(which is that last one).
A smart enough compiler that sees that we cover all the cases won't care.
Cc: Lyude Paul <lyude@redhat.com>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Damien Le Moal [Fri, 20 Nov 2020 01:55:12 +0000 (10:55 +0900)]
null_blk: Fail zone append to conventional zones
commit
2e896d89510f23927ec393bee1e0570db3d5a6c6 upstream.
Conventional zones do not have a write pointer and so cannot accept zone
append writes. Make sure to fail any zone append write command issued to
a conventional zone.
Reported-by: Naohiro Aota <naohiro.aota@wdc.com>
Fixes:
e0489ed5daeb ("null_blk: Support REQ_OP_ZONE_APPEND")
Cc: stable@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Damien Le Moal [Fri, 20 Nov 2020 01:55:11 +0000 (10:55 +0900)]
null_blk: Fix zone size initialization
commit
0ebcdd702f49aeb0ad2e2d894f8c124a0acc6e23 upstream.
For a null_blk device with zoned mode enabled is currently initialized
with a number of zones equal to the device capacity divided by the zone
size, without considering if the device capacity is a multiple of the
zone size. If the zone size is not a divisor of the capacity, the zones
end up not covering the entire capacity, potentially resulting is out
of bounds accesses to the zone array.
Fix this by adding one last smaller zone with a size equal to the
remainder of the disk capacity divided by the zone size if the capacity
is not a multiple of the zone size. For such smaller last zone, the zone
capacity is also checked so that it does not exceed the smaller zone
size.
Reported-by: Naohiro Aota <naohiro.aota@wdc.com>
Fixes:
ca4b2a011948 ("null_blk: add zone support")
Cc: stable@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steven Rostedt (VMware) [Mon, 14 Dec 2020 17:33:51 +0000 (12:33 -0500)]
Revert: "ring-buffer: Remove HAVE_64BIT_ALIGNED_ACCESS"
commit
adab66b71abfe206a020f11e561f4df41f0b2aba upstream.
It was believed that metag was the only architecture that required the ring
buffer to keep 8 byte words aligned on 8 byte architectures, and with its
removal, it was assumed that the ring buffer code did not need to handle
this case. It appears that sparc64 also requires this.
The following was reported on a sparc64 boot up:
kernel: futex hash table entries: 65536 (order: 9,
4194304 bytes, linear)
kernel: Running postponed tracer tests:
kernel: Testing tracer function:
kernel: Kernel unaligned access at TPC[552a20] trace_function+0x40/0x140
kernel: Kernel unaligned access at TPC[552a24] trace_function+0x44/0x140
kernel: Kernel unaligned access at TPC[552a20] trace_function+0x40/0x140
kernel: Kernel unaligned access at TPC[552a24] trace_function+0x44/0x140
kernel: Kernel unaligned access at TPC[552a20] trace_function+0x40/0x140
kernel: PASSED
Need to put back the 64BIT aligned code for the ring buffer.
Link: https://lore.kernel.org/r/CADxRZqzXQRYgKc=y-KV=S_yHL+Y8Ay2mh5ezeZUnpRvg+syWKw@mail.gmail.com
Cc: stable@vger.kernel.org
Fixes:
86b3de60a0b6 ("ring-buffer: Remove HAVE_64BIT_ALIGNED_ACCESS")
Reported-by: Anatoly Pugachev <matorola@gmail.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nikita Shubin [Tue, 1 Dec 2020 09:55:07 +0000 (12:55 +0300)]
rtc: ep93xx: Fix NULL pointer dereference in ep93xx_rtc_read_time
commit
00c33482bb6110bce8110daa351f9b3baf4df7dc upstream.
Mismatch in probe platform_set_drvdata set's and method's that call
dev_get_platdata will result in "Unable to handle kernel NULL pointer
dereference", let's use according method for getting driver data after
platform_set_drvdata.
8<--- cut here ---
Unable to handle kernel NULL pointer dereference at virtual address
00000000
pgd = (ptrval)
[
00000000] *pgd=
00000000
Internal error: Oops: 5 [#1] ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted
5.9.10-00003-g723e101e0037-dirty #4
Hardware name: Technologic Systems TS-72xx SBC
PC is at ep93xx_rtc_read_time+0xc/0x2c
LR is at __rtc_read_time+0x4c/0x8c
[...]
[<
c02b01c8>] (ep93xx_rtc_read_time) from [<
c02ac38c>] (__rtc_read_time+0x4c/0x8c)
[<
c02ac38c>] (__rtc_read_time) from [<
c02ac3f8>] (rtc_read_time+0x2c/0x4c)
[<
c02ac3f8>] (rtc_read_time) from [<
c02acc54>] (__rtc_read_alarm+0x28/0x358)
[<
c02acc54>] (__rtc_read_alarm) from [<
c02abd80>] (__rtc_register_device+0x124/0x2ec)
[<
c02abd80>] (__rtc_register_device) from [<
c02b028c>] (ep93xx_rtc_probe+0xa4/0xac)
[<
c02b028c>] (ep93xx_rtc_probe) from [<
c026424c>] (platform_drv_probe+0x24/0x5c)
[<
c026424c>] (platform_drv_probe) from [<
c0262918>] (really_probe+0x218/0x374)
[<
c0262918>] (really_probe) from [<
c0262da0>] (device_driver_attach+0x44/0x60)
[<
c0262da0>] (device_driver_attach) from [<
c0262e70>] (__driver_attach+0xb4/0xc0)
[<
c0262e70>] (__driver_attach) from [<
c0260d44>] (bus_for_each_dev+0x68/0xac)
[<
c0260d44>] (bus_for_each_dev) from [<
c026223c>] (driver_attach+0x18/0x24)
[<
c026223c>] (driver_attach) from [<
c0261dd8>] (bus_add_driver+0x150/0x1b4)
[<
c0261dd8>] (bus_add_driver) from [<
c026342c>] (driver_register+0xb0/0xf4)
[<
c026342c>] (driver_register) from [<
c0264210>] (__platform_driver_register+0x30/0x48)
[<
c0264210>] (__platform_driver_register) from [<
c04cb9ac>] (ep93xx_rtc_driver_init+0x10/0x1c)
[<
c04cb9ac>] (ep93xx_rtc_driver_init) from [<
c000973c>] (do_one_initcall+0x7c/0x1c0)
[<
c000973c>] (do_one_initcall) from [<
c04b9ecc>] (kernel_init_freeable+0x168/0x1ac)
[<
c04b9ecc>] (kernel_init_freeable) from [<
c03b2228>] (kernel_init+0x8/0xf4)
[<
c03b2228>] (kernel_init) from [<
c00082c0>] (ret_from_fork+0x14/0x34)
Exception stack(0xc441dfb0 to 0xc441dff8)
dfa0:
00000000 00000000 00000000 00000000
dfc0:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dfe0:
00000000 00000000 00000000 00000000 00000013 00000000
Code:
e12fff1e e92d4010 e590303c e1a02001 (
e5933000)
---[ end trace
c914d6030eaa95c8 ]---
Fixes:
b809d192eb98 ("rtc: ep93xx: stop setting platform_data")
Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201201095507.10317-1-nikita.shubin@maquefel.me
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Zhuguangqing [Fri, 6 Nov 2020 09:22:43 +0000 (17:22 +0800)]
thermal/drivers/cpufreq_cooling: Update cpufreq_state only if state has changed
commit
236761f19a4f373354f1dcf399b57753f1f4b871 upstream.
If state has not changed successfully and we updated cpufreq_state,
next time when the new state is equal to cpufreq_state (not changed
successfully last time), we will return directly and miss a
freq_qos_update_request() that should have been.
Fixes:
5130802ddbb1 ("thermal: cpu_cooling: Switch to QoS requests for freq limits")
Cc: v5.4+ <stable@vger.kernel.org> # v5.4+
Signed-off-by: Zhuguangqing <zhuguangqing@xiaomi.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20201106092243.15574-1-zhuguangqing83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjorn Andersson [Sun, 22 Nov 2020 05:41:32 +0000 (21:41 -0800)]
remoteproc: sysmon: Ensure remote notification ordering
commit
138a6428ba9023ae29e103e87a223575fbc3d2b7 upstream.
The reliance on the remoteproc's state for determining when to send
sysmon notifications to a remote processor is racy with regard to
concurrent remoteproc operations.
Further more the advertisement of the state of other remote processor to
a newly started remote processor might not only send the wrong state,
but might result in a stream of state changes that are out of order.
Address this by introducing state tracking within the sysmon instances
themselves and extend the locking to ensure that the notifications are
consistent with this state.
Fixes:
1f36ab3f6e3b ("remoteproc: sysmon: Inform current rproc about all active rprocs")
Fixes:
1877f54f75ad ("remoteproc: sysmon: Add notifications for events")
Fixes:
1fb82ee806d1 ("remoteproc: qcom: Introduce sysmon")
Cc: stable@vger.kernel.org
Reviewed-by: Rishabh Bhatnagar <rishabhb@codeaurora.org>
Link: https://lore.kernel.org/r/20201122054135.802935-2-bjorn.andersson@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
DingHua Ma [Tue, 1 Dec 2020 00:10:00 +0000 (08:10 +0800)]
regulator: axp20x: Fix DLDO2 voltage control register mask for AXP22x
commit
291de1d102fafef0798cdad9666cd4f8da7da7cc upstream.
When I use the axp20x chip to power my SDIO device on the 5.4 kernel,
the output voltage of DLDO2 is wrong. After comparing the register
manual and source code of the chip, I found that the mask bit of the
driver register of the port was wrong. I fixed this error by modifying
the mask register of the source code. This error seems to be a copy
error of the macro when writing the code. Now the voltage output of
the DLDO2 port of axp20x is correct. My development environment is
Allwinner A40I of arm architecture, and the kernel version is 5.4.
Signed-off-by: DingHua Ma <dinghua.ma.sz@gmail.com>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Cc: <stable@vger.kernel.org>
Fixes:
db4a555f7c4c ("regulator: axp20x: use defines for masks")
Link: https://lore.kernel.org/r/20201201001000.22302-1-dinghua.ma.sz@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jubin Zhong [Wed, 2 Dec 2020 02:33:42 +0000 (10:33 +0800)]
PCI: Fix pci_slot_release() NULL pointer dereference
commit
4684709bf81a2d98152ed6b610e3d5c403f9bced upstream.
If kobject_init_and_add() fails, pci_slot_release() is called to delete
slot->list from parent->slots. But slot->list hasn't been initialized
yet, so we dereference a NULL pointer:
Unable to handle kernel NULL pointer dereference at virtual address
00000000
...
CPU: 10 PID: 1 Comm: swapper/0 Not tainted 4.4.240 #197
task:
ffffeb398a45ef10 task.stack:
ffffeb398a470000
PC is at __list_del_entry_valid+0x5c/0xb0
LR is at pci_slot_release+0x84/0xe4
...
__list_del_entry_valid+0x5c/0xb0
pci_slot_release+0x84/0xe4
kobject_put+0x184/0x1c4
pci_create_slot+0x17c/0x1b4
__pci_hp_initialize+0x68/0xa4
pciehp_probe+0x1a4/0x2fc
pcie_port_probe_service+0x58/0x84
driver_probe_device+0x320/0x470
Initialize slot->list before calling kobject_init_and_add() to avoid this.
Fixes:
8a94644b440e ("PCI: Fix pci_create_slot() reference count leak")
Link: https://lore.kernel.org/r/1606876422-117457-1-git-send-email-zhongjubin@huawei.com
Signed-off-by: Jubin Zhong <zhongjubin@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org # v5.9+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Mon, 23 Nov 2020 10:23:12 +0000 (11:23 +0100)]
of: fix linker-section match-table corruption
commit
5812b32e01c6d86ba7a84110702b46d8a8531fe9 upstream.
Specify type alignment when declaring linker-section match-table entries
to prevent gcc from increasing alignment and corrupting the various
tables with padding (e.g. timers, irqchips, clocks, reserved memory).
This is specifically needed on x86 where gcc (typically) aligns larger
objects like struct of_device_id with static extent on 32-byte
boundaries which at best prevents matching on anything but the first
entry. Specifying alignment when declaring variables suppresses this
optimisation.
Here's a 64-bit example where all entries are corrupt as 16 bytes of
padding has been inserted before the first entry:
ffffffff8266b4b0 D __clk_of_table
ffffffff8266b4c0 d __of_table_fixed_factor_clk
ffffffff8266b5a0 d __of_table_fixed_clk
ffffffff8266b680 d __clk_of_table_sentinel
And here's a 32-bit example where the 8-byte-aligned table happens to be
placed on a 32-byte boundary so that all but the first entry are corrupt
due to the 28 bytes of padding inserted between entries:
812b3ec0 D __irqchip_of_table
812b3ec0 d __of_table_irqchip1
812b3fa0 d __of_table_irqchip2
812b4080 d __of_table_irqchip3
812b4160 d irqchip_of_match_end
Verified on x86 using gcc-9.3 and gcc-4.9 (which uses 64-byte
alignment), and on arm using gcc-7.2.
Note that there are no in-tree users of these tables on x86 currently
(even if they are included in the image).
Fixes:
54196ccbe0ba ("of: consolidate linker section OF match table declarations")
Fixes:
f6e916b82022 ("irqchip: add basic infrastructure")
Cc: stable <stable@vger.kernel.org> # 3.9
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20201123102319.8090-2-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Felix Fietkau [Sat, 10 Oct 2020 13:20:18 +0000 (15:20 +0200)]
mt76: add back the SUPPORTS_REORDERING_BUFFER flag
commit
ed89b89330b521f20682ead6bf93e1014b21a200 upstream.
It was accidentally dropped while adding multiple wiphy support
Fixes fast-rx support and avoids handling reordering in both mac80211
and the driver
Cc: stable@vger.kernel.org
Fixes:
c89d36254155 ("mt76: add function for allocating an extra wiphy")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Masami Hiramatsu [Tue, 8 Dec 2020 08:54:09 +0000 (17:54 +0900)]
tracing: Disable ftrace selftests when any tracer is running
commit
60efe21e5976d3d4170a8190ca76a271d6419754 upstream.
Disable ftrace selftests when any tracer (kernel command line options
like ftrace=, trace_events=, kprobe_events=, and boot-time tracing)
starts running because selftest can disturb it.
Currently ftrace= and trace_events= are checked, but kprobe_events
has a different flag, and boot-time tracing didn't checked. This unifies
the disabled flag and all of those boot-time tracing features sets
the flag.
This also fixes warnings on kprobe-event selftest
(CONFIG_FTRACE_STARTUP_TEST=y and CONFIG_KPROBE_EVENTS=y) with boot-time
tracing (ftrace.event.kprobes.EVENT.probes) like below;
[ 59.803496] trace_kprobe: Testing kprobe tracing:
[ 59.804258] ------------[ cut here ]------------
[ 59.805682] WARNING: CPU: 3 PID: 1 at kernel/trace/trace_kprobe.c:1987 kprobe_trace_self_tests_ib
[ 59.806944] Modules linked in:
[ 59.807335] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.10.0-rc7+ #172
[ 59.808029] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/204
[ 59.808999] RIP: 0010:kprobe_trace_self_tests_init+0x5f/0x42b
[ 59.809696] Code: e8 03 00 00 48 c7 c7 30 8e 07 82 e8 6d 3c 46 ff 48 c7 c6 00 b2 1a 81 48 c7 c7 7
[ 59.812439] RSP: 0018:
ffffc90000013e78 EFLAGS:
00010282
[ 59.813038] RAX:
00000000ffffffef RBX:
0000000000000000 RCX:
0000000000049443
[ 59.813780] RDX:
0000000000049403 RSI:
0000000000049403 RDI:
000000000002deb0
[ 59.814589] RBP:
ffffc90000013e90 R08:
0000000000000001 R09:
0000000000000001
[ 59.815349] R10:
0000000000000001 R11:
0000000000000000 R12:
00000000ffffffef
[ 59.816138] R13:
ffff888004613d80 R14:
ffffffff82696940 R15:
ffff888004429138
[ 59.816877] FS:
0000000000000000(0000) GS:
ffff88807dcc0000(0000) knlGS:
0000000000000000
[ 59.817772] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 59.818395] CR2:
0000000001a8dd38 CR3:
0000000002222000 CR4:
00000000000006a0
[ 59.819144] Call Trace:
[ 59.819469] ? init_kprobe_trace+0x6b/0x6b
[ 59.819948] do_one_initcall+0x5f/0x300
[ 59.820392] ? rcu_read_lock_sched_held+0x4f/0x80
[ 59.820916] kernel_init_freeable+0x22a/0x271
[ 59.821416] ? rest_init+0x241/0x241
[ 59.821841] kernel_init+0xe/0x10f
[ 59.822251] ret_from_fork+0x22/0x30
[ 59.822683] irq event stamp:
16403349
[ 59.823121] hardirqs last enabled at (
16403359): [<
ffffffff810db81e>] console_unlock+0x48e/0x580
[ 59.824074] hardirqs last disabled at (
16403368): [<
ffffffff810db786>] console_unlock+0x3f6/0x580
[ 59.825036] softirqs last enabled at (
16403200): [<
ffffffff81c0033a>] __do_softirq+0x33a/0x484
[ 59.825982] softirqs last disabled at (
16403087): [<
ffffffff81a00f02>] asm_call_irq_on_stack+0x10
[ 59.827034] ---[ end trace
200c544775cdfeb3 ]---
[ 59.827635] trace_kprobe: error on probing function entry.
Link: https://lkml.kernel.org/r/160741764955.3448999.3347769358299456915.stgit@devnote2
Fixes:
4d655281eb1b ("tracing/boot Add kprobe event support")
Cc: Ingo Molnar <mingo@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Carlos Garnacho [Tue, 1 Dec 2020 13:57:27 +0000 (14:57 +0100)]
platform/x86: intel-vbtn: Allow switch events on Acer Switch Alpha 12
commit
fe6000990394639ed374cb76c313be3640714f47 upstream.
This 2-in-1 model (Product name: Switch SA5-271) features a SW_TABLET_MODE
that works as it would be expected, both when detaching the keyboard and
when folding it behind the tablet body.
It used to work until the introduction of the allow list at
commit
8169bd3e6e193 ("platform/x86: intel-vbtn: Switch to an allow-list
for SW_TABLET_MODE reporting"). Add this model to it, so that the Virtual
Buttons device announces the EV_SW features again.
Fixes:
8169bd3e6e193 ("platform/x86: intel-vbtn: Switch to an allow-list for SW_TABLET_MODE reporting")
Cc: stable@vger.kernel.org
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Link: https://lore.kernel.org/r/20201201135727.212917-1-carlosg@gnome.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Williams [Fri, 20 Nov 2020 16:50:07 +0000 (08:50 -0800)]
libnvdimm/namespace: Fix reaping of invalidated block-window-namespace labels
commit
2dd2a1740ee19cd2636d247276cf27bfa434b0e2 upstream.
A recent change to ndctl to attempt to reconfigure namespaces in place
uncovered a label accounting problem in block-window-type namespaces.
The ndctl "create.sh" test is able to trigger this signature:
WARNING: CPU: 34 PID: 9167 at drivers/nvdimm/label.c:1100 __blk_label_update+0x9a3/0xbc0 [libnvdimm]
[..]
RIP: 0010:__blk_label_update+0x9a3/0xbc0 [libnvdimm]
[..]
Call Trace:
uuid_store+0x21b/0x2f0 [libnvdimm]
kernfs_fop_write+0xcf/0x1c0
vfs_write+0xcc/0x380
ksys_write+0x68/0xe0
When allocated capacity for a namespace is renamed (new UUID) the labels
with the old UUID need to be deleted. The ndctl behavior to always
destroy namespaces on reconfiguration hid this problem.
The immediate impact of this bug is limited since block-window-type
namespaces only seem to exist in the specification and not in any
shipping products. However, the label handling code is being reused for
other technologies like CXL region labels, so there is a benefit to
making sure both vertical labels sets (block-window) and horizontal
label sets (pmem) have a functional reference implementation in
libnvdimm.
Fixes:
c4703ce11c23 ("libnvdimm/namespace: Fix label tracking error")
Cc: <stable@vger.kernel.org>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lad Prabhakar [Thu, 26 Nov 2020 19:11:43 +0000 (19:11 +0000)]
memory: renesas-rpc-if: Fix unbalanced pm_runtime_enable in rpcif_{enable,disable}_rpm
commit
61a6d854b9555b420fbfae62ef26baa8b9493b32 upstream.
rpcif_enable_rpm calls pm_runtime_enable, so rpcif_disable_rpm needs to
call pm_runtime_disable and not pm_runtime_put_sync.
Fixes:
ca7d8b980b67f ("memory: add Renesas RPC-IF driver")
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@gmail.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201126191146.8753-3-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lad Prabhakar [Thu, 26 Nov 2020 19:11:42 +0000 (19:11 +0000)]
memory: renesas-rpc-if: Return correct value to the caller of rpcif_manual_xfer()
commit
a0453f4ed066cae651b3119ed11f52d31dae1eca upstream.
In the error path of rpcif_manual_xfer() the value of ret is overwritten
by value returned by reset_control_reset() function and thus returning
incorrect value to the caller.
This patch makes sure the correct value is returned to the caller of
rpcif_manual_xfer() by dropping the overwrite of ret in error path.
Also now we ignore the value returned by reset_control_reset() in the
error path and instead print a error message when it fails.
Fixes:
ca7d8b980b67f ("memory: add Renesas RPC-IF driver")
Reported-by: Pavel Machek <pavel@denx.de>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Pavel Machek (CIP) <pavel@denx.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201126191146.8753-2-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lad Prabhakar [Thu, 26 Nov 2020 19:11:44 +0000 (19:11 +0000)]
memory: renesas-rpc-if: Fix a node reference leak in rpcif_probe()
commit
4e6b86b409f9fc63fedb39d6e3a0202c4b0244ce upstream.
Release the node reference by calling of_node_put(flash) in the probe.
Fixes:
ca7d8b980b67f ("memory: add Renesas RPC-IF driver")
Reported-by: Pavel Machek <pavel@denx.de>
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Pavel Machek (CIP) <pavel@denx.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201126191146.8753-4-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Mon, 3 Aug 2020 14:36:07 +0000 (17:36 +0300)]
memory: jz4780_nemc: Fix an error pointer vs NULL check in probe()
commit
96999c797ec1ef41259f00b4ddf9cf33b342cb78 upstream.
The devm_ioremap() function returns NULL on error, it doesn't return
error pointers. This bug could lead to an Oops during probe.
Fixes:
f046e4a3f0b9 ("memory: jz4780_nemc: Only request IO memory the driver will use")
Cc: <stable@vger.kernel.org>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20200803143607.GC346925@mwanda
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
SeongJae Park [Mon, 14 Dec 2020 09:08:40 +0000 (10:08 +0100)]
xenbus/xenbus_backend: Disallow pending watch messages
commit
9996bd494794a2fe393e97e7a982388c6249aa76 upstream.
'xenbus_backend' watches 'state' of devices, which is writable by
guests. Hence, if guests intensively updates it, dom0 will have lots of
pending events that exhausting memory of dom0. In other words, guests
can trigger dom0 memory pressure. This is known as XSA-349. However,
the watch callback of it, 'frontend_changed()', reads only 'state', so
doesn't need to have the pending events.
To avoid the problem, this commit disallows pending watch messages for
'xenbus_backend' using the 'will_handle()' watch callback.
This is part of XSA-349
Cc: stable@vger.kernel.org
Signed-off-by: SeongJae Park <sjpark@amazon.de>
Reported-by: Michael Kurth <mku@amazon.de>
Reported-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
SeongJae Park [Mon, 14 Dec 2020 09:07:13 +0000 (10:07 +0100)]
xen/xenbus: Count pending messages for each watch
commit
3dc86ca6b4c8cfcba9da7996189d1b5a358a94fc upstream.
This commit adds a counter of pending messages for each watch in the
struct. It is used to skip unnecessary pending messages lookup in
'unregister_xenbus_watch()'. It could also be used in 'will_handle'
callback.
This is part of XSA-349
Cc: stable@vger.kernel.org
Signed-off-by: SeongJae Park <sjpark@amazon.de>
Reported-by: Michael Kurth <mku@amazon.de>
Reported-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
SeongJae Park [Mon, 14 Dec 2020 09:05:47 +0000 (10:05 +0100)]
xen/xenbus/xen_bus_type: Support will_handle watch callback
commit
be987200fbaceaef340872841d4f7af2c5ee8dc3 upstream.
This commit adds support of the 'will_handle' watch callback for
'xen_bus_type' users.
This is part of XSA-349
Cc: stable@vger.kernel.org
Signed-off-by: SeongJae Park <sjpark@amazon.de>
Reported-by: Michael Kurth <mku@amazon.de>
Reported-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
SeongJae Park [Mon, 14 Dec 2020 09:04:18 +0000 (10:04 +0100)]
xen/xenbus: Add 'will_handle' callback support in xenbus_watch_path()
commit
2e85d32b1c865bec703ce0c962221a5e955c52c2 upstream.
Some code does not directly make 'xenbus_watch' object and call
'register_xenbus_watch()' but use 'xenbus_watch_path()' instead. This
commit adds support of 'will_handle' callback in the
'xenbus_watch_path()' and it's wrapper, 'xenbus_watch_pathfmt()'.
This is part of XSA-349
Cc: stable@vger.kernel.org
Signed-off-by: SeongJae Park <sjpark@amazon.de>
Reported-by: Michael Kurth <mku@amazon.de>
Reported-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
SeongJae Park [Mon, 14 Dec 2020 09:02:45 +0000 (10:02 +0100)]
xen/xenbus: Allow watches discard events before queueing
commit
fed1755b118147721f2c87b37b9d66e62c39b668 upstream.
If handling logics of watch events are slower than the events enqueue
logic and the events can be created from the guests, the guests could
trigger memory pressure by intensively inducing the events, because it
will create a huge number of pending events that exhausting the memory.
Fortunately, some watch events could be ignored, depending on its
handler callback. For example, if the callback has interest in only one
single path, the watch wouldn't want multiple pending events. Or, some
watches could ignore events to same path.
To let such watches to volutarily help avoiding the memory pressure
situation, this commit introduces new watch callback, 'will_handle'. If
it is not NULL, it will be called for each new event just before
enqueuing it. Then, if the callback returns false, the event will be
discarded. No watch is using the callback for now, though.
This is part of XSA-349
Cc: stable@vger.kernel.org
Signed-off-by: SeongJae Park <sjpark@amazon.de>
Reported-by: Michael Kurth <mku@amazon.de>
Reported-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pawel Wieczorkiewicz [Mon, 14 Dec 2020 09:25:57 +0000 (10:25 +0100)]
xen-blkback: set ring->xenblkd to NULL after kthread_stop()
commit
1c728719a4da6e654afb9cc047164755072ed7c9 upstream.
When xen_blkif_disconnect() is called, the kernel thread behind the
block interface is stopped by calling kthread_stop(ring->xenblkd).
The ring->xenblkd thread pointer being non-NULL determines if the
thread has been already stopped.
Normally, the thread's function xen_blkif_schedule() sets the
ring->xenblkd to NULL, when the thread's main loop ends.
However, when the thread has not been started yet (i.e.
wake_up_process() has not been called on it), the xen_blkif_schedule()
function would not be called yet.
In such case the kthread_stop() call returns -EINTR and the
ring->xenblkd remains dangling.
When this happens, any consecutive call to xen_blkif_disconnect (for
example in frontend_changed() callback) leads to a kernel crash in
kthread_stop() (e.g. NULL pointer dereference in exit_creds()).
This is XSA-350.
Cc: <stable@vger.kernel.org> # 4.12
Fixes:
a24fa22ce22a ("xen/blkback: don't use xen_blkif_get() in xen-blkback kthread")
Reported-by: Olivier Benjamin <oliben@amazon.com>
Reported-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Signed-off-by: Pawel Wieczorkiewicz <wipawel@amazon.de>
Reviewed-by: Julien Grall <jgrall@amazon.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Tue, 8 Dec 2020 19:03:26 +0000 (20:03 +0100)]
driver: core: Fix list corruption after device_del()
commit
66482f640755b31cb94371ff6cef17400cda6db5 upstream.
The device_links_purge() function (called from device_del()) tries to
remove the links.needs_suppliers list entry, but it's using
list_del(), hence it doesn't initialize after the removal. This is OK
for normal cases where device_del() is called via device_destroy().
However, it's not guaranteed that the device object will be really
deleted soon after device_del(). In a minor case like HD-audio codec
reconfiguration that re-initializes the device after device_del(), it
may lead to a crash by the corrupted list entry.
As a simple fix, replace list_del() with list_del_init() in order to
make the list intact after the device_del() call.
Fixes:
e2ae9bcc4aaa ("driver core: Add support for linking devices during device addition")
Cc: <stable@vger.kernel.org>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20201208190326.27531-1-tiwai@suse.de
Cc: Saravana Kannan <saravanak@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maarten Lankhorst [Tue, 24 Nov 2020 11:57:07 +0000 (12:57 +0100)]
dma-buf/dma-resv: Respect num_fences when initializing the shared fence list.
commit
bf8975837dac156c33a4d15d46602700998cb6dd upstream.
We hardcode the maximum number of shared fences to 4, instead of
respecting num_fences. Use a minimum of 4, but more if num_fences
is higher.
This seems to have been an oversight when first implementing the
api.
Fixes:
04a5faa8cbe5 ("reservation: update api and add some helpers")
Cc: <stable@vger.kernel.org> # v3.17+
Reported-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201124115707.406917-1-maarten.lankhorst@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wang Hai [Tue, 1 Dec 2020 13:59:29 +0000 (21:59 +0800)]
device-dax/core: Fix memory leak when rmmod dax.ko
commit
1aa574312518ef1d60d2dc62d58f7021db3b163a upstream.
When I repeatedly modprobe and rmmod dax.ko, kmemleak report a
memory leak as follows:
unreferenced object 0xffff9a5588c05088 (size 8):
comm "modprobe", pid 261, jiffies
4294693644 (age 42.063s)
...
backtrace:
[<
00000000e007ced0>] kstrdup+0x35/0x70
[<
000000002ae73897>] kstrdup_const+0x3d/0x50
[<
000000002b00c9c3>] kvasprintf_const+0xbc/0xf0
[<
000000008023282f>] kobject_set_name_vargs+0x3b/0xd0
[<
00000000d2cbaa4e>] kobject_set_name+0x62/0x90
[<
00000000202e7a22>] bus_register+0x7f/0x2b0
[<
000000000b77792c>] 0xffffffffc02840f7
[<
000000002d5be5ac>] 0xffffffffc02840b4
[<
00000000dcafb7cd>] do_one_initcall+0x58/0x240
[<
00000000049fe480>] do_init_module+0x56/0x1e2
[<
0000000022671491>] load_module+0x2517/0x2840
[<
000000001a2201cb>] __do_sys_finit_module+0x9c/0xe0
[<
000000003eb304e7>] do_syscall_64+0x33/0x40
[<
0000000051c5fd06>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
When rmmod dax is executed, dax_bus_exit() is missing. This patch
can fix this bug.
Fixes:
9567da0b408a ("device-dax: Introduce bus + driver model")
Cc: <stable@vger.kernel.org>
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Link: https://lore.kernel.org/r/20201201135929.66530-1-wanghai38@huawei.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
William Breathitt Gray [Sat, 14 Nov 2020 23:28:05 +0000 (18:28 -0500)]
counter: microchip-tcb-capture: Fix CMR value check
commit
3418bd7cfce0bd8ef1ccedc4655f9f86f6c3b0ca upstream.
The ATMEL_TC_ETRGEDG_* defines are not masks but rather possible values
for CMR. This patch fixes the action_get() callback to properly check
for these values rather than mask them.
Fixes:
106b104137fd ("counter: Add microchip TCB capture counter")
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20201114232805.253108-1-vilhelm.gray@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicolin Chen [Thu, 29 Oct 2020 00:48:20 +0000 (17:48 -0700)]
clk: tegra: Do not return 0 on failure
commit
6160aca443148416994c022a35c77daeba948ea6 upstream.
Return values from read_dt_param() will be either TRUE (1) or
FALSE (0), while dfll_fetch_pwm_params() returns 0 on success
or an ERR code on failure.
So this patch fixes the bug of returning 0 on failure.
Fixes:
36541f0499fe ("clk: tegra: dfll: support PWM regulator control")
Cc: <stable@vger.kernel.org>
Signed-off-by: Nicolin Chen <nicoleotsuka@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Terry Zhou [Fri, 6 Nov 2020 10:00:39 +0000 (11:00 +0100)]
clk: mvebu: a3700: fix the XTAL MODE pin to MPP1_9
commit
6f37689cf6b38fff96de52e7f0d3e78f22803ba0 upstream.
There is an error in the current code that the XTAL MODE
pin was set to NB MPP1_31 which should be NB MPP1_9.
The latch register of NB MPP1_9 has different offset of 0x8.
Signed-off-by: Terry Zhou <bjzhou@marvell.com>
[pali: Fix pin name in commit message]
Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes:
7ea8250406a6 ("clk: mvebu: Add the xtal clock for Armada 3700 SoC")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20201106100039.11385-1-pali@kernel.org
Reviewed-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Cercueil [Sat, 12 Dec 2020 13:57:33 +0000 (13:57 +0000)]
clk: ingenic: Fix divider calculation with div tables
commit
11a163f2c7d6a9f27ce144cd7e367a81c851621a upstream.
The previous code assumed that a higher hardware value always resulted
in a bigger divider, which is correct for the regular clocks, but is
an invalid assumption when a divider table is provided for the clock.
Perfect example of this is the PLL0_HALF clock, which applies a /2
divider with the hardware value 0, and a /1 divider otherwise.
Fixes:
a9fa2893fcc6 ("clk: ingenic: Add support for divider tables")
Cc: <stable@vger.kernel.org> # 5.2
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20201212135733.38050-1-paul@crapouillou.net
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yangtao Li [Tue, 10 Nov 2020 06:24:40 +0000 (14:24 +0800)]
pinctrl: sunxi: Always call chained_irq_{enter, exit} in sunxi_pinctrl_irq_handler
commit
a1158e36f876f6269978a4176e3a1d48d27fe7a1 upstream.
It is found on many allwinner soc that there is a low probability that
the interrupt status cannot be read in sunxi_pinctrl_irq_handler. This
will cause the interrupt status of a gpio bank to always be active on
gic, preventing gic from responding to other spi interrupts correctly.
So we should call the chained_irq_* each time enter sunxi_pinctrl_irq_handler().
Signed-off-by: Yangtao Li <frank@allwinnertech.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/85263ce8b058e80cea25c6ad6383eb256ce96cc8.1604988979.git.frank@allwinnertech.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Zhao Heming [Thu, 19 Nov 2020 11:41:34 +0000 (19:41 +0800)]
md/cluster: fix deadlock when node is doing resync job
commit
bca5b0658020be90b6b504ca514fd80110204f71 upstream.
md-cluster uses MD_CLUSTER_SEND_LOCK to make node can exclusively send msg.
During sending msg, node can concurrently receive msg from another node.
When node does resync job, grab token_lockres:EX may trigger a deadlock:
```
nodeA nodeB
-------------------- --------------------
a.
send METADATA_UPDATED
held token_lockres:EX
b.
md_do_sync
resync_info_update
send RESYNCING
+ set MD_CLUSTER_SEND_LOCK
+ wait for holding token_lockres:EX
c.
mdadm /dev/md0 --remove /dev/sdg
+ held reconfig_mutex
+ send REMOVE
+ wait_event(MD_CLUSTER_SEND_LOCK)
d.
recv_daemon //METADATA_UPDATED from A
process_metadata_update
+ (mddev_trylock(mddev) ||
MD_CLUSTER_HOLDING_MUTEX_FOR_RECVD)
//this time, both return false forever
```
Explaination:
a. A send METADATA_UPDATED
This will block another node to send msg
b. B does sync jobs, which will send RESYNCING at intervals.
This will be block for holding token_lockres:EX lock.
c. B do "mdadm --remove", which will send REMOVE.
This will be blocked by step <b>: MD_CLUSTER_SEND_LOCK is 1.
d. B recv METADATA_UPDATED msg, which send from A in step <a>.
This will be blocked by step <c>: holding mddev lock, it makes
wait_event can't hold mddev lock. (btw,
MD_CLUSTER_HOLDING_MUTEX_FOR_RECVD keep ZERO in this scenario.)
There is a similar deadlock in commit
0ba959774e93
("md-cluster: use sync way to handle METADATA_UPDATED msg")
In that commit, step c is "update sb". This patch step c is
"mdadm --remove".
For fixing this issue, we can refer the solution of function:
metadata_update_start. Which does the same grab lock_token action.
lock_comm can use the same steps to avoid deadlock. By moving
MD_CLUSTER_HOLDING_MUTEX_FOR_RECVD from lock_token to lock_comm.
It enlarge a little bit window of MD_CLUSTER_HOLDING_MUTEX_FOR_RECVD,
but it is safe & can break deadlock.
Repro steps (I only triggered 3 times with hundreds tests):
two nodes share 3 iSCSI luns: sdg/sdh/sdi. Each lun size is 1GB.
```
ssh root@node2 "mdadm -S --scan"
mdadm -S --scan
for i in {g,h,i};do dd if=/dev/zero of=/dev/sd$i oflag=direct bs=1M \
count=20; done
mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sdg /dev/sdh \
--bitmap-chunk=1M
ssh root@node2 "mdadm -A /dev/md0 /dev/sdg /dev/sdh"
sleep 5
mkfs.xfs /dev/md0
mdadm --manage --add /dev/md0 /dev/sdi
mdadm --wait /dev/md0
mdadm --grow --raid-devices=3 /dev/md0
mdadm /dev/md0 --fail /dev/sdg
mdadm /dev/md0 --remove /dev/sdg
mdadm --grow --raid-devices=2 /dev/md0
```
test script will hung when executing "mdadm --remove".
```
# dump stacks by "echo t > /proc/sysrq-trigger"
md0_cluster_rec D 0 5329 2 0x80004000
Call Trace:
__schedule+0x1f6/0x560
? _cond_resched+0x2d/0x40
? schedule+0x4a/0xb0
? process_metadata_update.isra.0+0xdb/0x140 [md_cluster]
? wait_woken+0x80/0x80
? process_recvd_msg+0x113/0x1d0 [md_cluster]
? recv_daemon+0x9e/0x120 [md_cluster]
? md_thread+0x94/0x160 [md_mod]
? wait_woken+0x80/0x80
? md_congested+0x30/0x30 [md_mod]
? kthread+0x115/0x140
? __kthread_bind_mask+0x60/0x60
? ret_from_fork+0x1f/0x40
mdadm D 0 5423 1 0x00004004
Call Trace:
__schedule+0x1f6/0x560
? __schedule+0x1fe/0x560
? schedule+0x4a/0xb0
? lock_comm.isra.0+0x7b/0xb0 [md_cluster]
? wait_woken+0x80/0x80
? remove_disk+0x4f/0x90 [md_cluster]
? hot_remove_disk+0xb1/0x1b0 [md_mod]
? md_ioctl+0x50c/0xba0 [md_mod]
? wait_woken+0x80/0x80
? blkdev_ioctl+0xa2/0x2a0
? block_ioctl+0x39/0x40
? ksys_ioctl+0x82/0xc0
? __x64_sys_ioctl+0x16/0x20
? do_syscall_64+0x5f/0x150
? entry_SYSCALL_64_after_hwframe+0x44/0xa9
md0_resync D 0 5425 2 0x80004000
Call Trace:
__schedule+0x1f6/0x560
? schedule+0x4a/0xb0
? dlm_lock_sync+0xa1/0xd0 [md_cluster]
? wait_woken+0x80/0x80
? lock_token+0x2d/0x90 [md_cluster]
? resync_info_update+0x95/0x100 [md_cluster]
? raid1_sync_request+0x7d3/0xa40 [raid1]
? md_do_sync.cold+0x737/0xc8f [md_mod]
? md_thread+0x94/0x160 [md_mod]
? md_congested+0x30/0x30 [md_mod]
? kthread+0x115/0x140
? __kthread_bind_mask+0x60/0x60
? ret_from_fork+0x1f/0x40
```
At last, thanks for Xiao's solution.
Cc: stable@vger.kernel.org
Signed-off-by: Zhao Heming <heming.zhao@suse.com>
Suggested-by: Xiao Ni <xni@redhat.com>
Reviewed-by: Xiao Ni <xni@redhat.com>
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Zhao Heming [Thu, 19 Nov 2020 11:41:33 +0000 (19:41 +0800)]
md/cluster: block reshape with remote resync job
commit
a8da01f79c89755fad55ed0ea96e8d2103242a72 upstream.
Reshape request should be blocked with ongoing resync job. In cluster
env, a node can start resync job even if the resync cmd isn't executed
on it, e.g., user executes "mdadm --grow" on node A, sometimes node B
will start resync job. However, current update_raid_disks() only check
local recovery status, which is incomplete. As a result, we see user will
execute "mdadm --grow" successfully on local, while the remote node deny
to do reshape job when it doing resync job. The inconsistent handling
cause array enter unexpected status. If user doesn't observe this issue
and continue executing mdadm cmd, the array doesn't work at last.
Fix this issue by blocking reshape request. When node executes "--grow"
and detects ongoing resync, it should stop and report error to user.
The following script reproduces the issue with ~100% probability.
(two nodes share 3 iSCSI luns: sdg/sdh/sdi. Each lun size is 1GB)
```
# on node1, node2 is the remote node.
ssh root@node2 "mdadm -S --scan"
mdadm -S --scan
for i in {g,h,i};do dd if=/dev/zero of=/dev/sd$i oflag=direct bs=1M \
count=20; done
mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sdg /dev/sdh
ssh root@node2 "mdadm -A /dev/md0 /dev/sdg /dev/sdh"
sleep 5
mdadm --manage --add /dev/md0 /dev/sdi
mdadm --wait /dev/md0
mdadm --grow --raid-devices=3 /dev/md0
mdadm /dev/md0 --fail /dev/sdg
mdadm /dev/md0 --remove /dev/sdg
mdadm --grow --raid-devices=2 /dev/md0
```
Cc: stable@vger.kernel.org
Signed-off-by: Zhao Heming <heming.zhao@suse.com>
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan Cameron [Sun, 20 Sep 2020 11:27:42 +0000 (12:27 +0100)]
iio:adc:ti-ads124s08: Fix alignment and data leak issues.
commit
1e405bc2512f80a903ddd6ba8740cee885238d7f upstream.
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv() data with alignment
explicitly requested. This data is allocated with kzalloc() so no
data can leak apart from previous readings.
In this driver the timestamp can end up in various different locations
depending on what other channels are enabled. As a result, we don't
use a structure to specify it's position as that would be misleading.
Fixes:
e717f8c6dfec ("iio: adc: Add the TI ads124s08 ADC code")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200920112742.170751-9-jic23@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan Cameron [Sun, 20 Sep 2020 11:27:41 +0000 (12:27 +0100)]
iio:adc:ti-ads124s08: Fix buffer being too long.
commit
b0bd27f02d768e3a861c4e6c27f8e369720e6c25 upstream.
The buffer is expressed as a u32 array, yet the extra space for
the s64 timestamp was expressed as sizeof(s64)/sizeof(u16).
This will result in 2 extra u32 elements.
Fix by dividing by sizeof(u32).
Fixes:
e717f8c6dfec ("iio: adc: Add the TI ads124s08 ADC code")
Signed-off-by: Jonathan Cameron<Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200920112742.170751-8-jic23@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonathan Cameron [Sun, 20 Sep 2020 11:27:39 +0000 (12:27 +0100)]
iio:imu:bmi160: Fix alignment and data leak issues
commit
7b6b51234df6cd8b04fe736b0b89c25612d896b8 upstream.
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable array in the iio_priv() data with alignment
explicitly requested. This data is allocated with kzalloc() so no
data can leak apart from previous readings.
In this driver, depending on which channels are enabled, the timestamp
can be in a number of locations. Hence we cannot use a structure
to specify the data layout without it being misleading.
Fixes:
77c4ad2d6a9b ("iio: imu: Add initial support for Bosch BMI160")
Reported-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Daniel Baluta <daniel.baluta@gmail.com>
Cc: Daniel Baluta <daniel.baluta@oss.nxp.com>
Cc: <Stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200920112742.170751-6-jic23@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
projects / linux.git / log