| Age | Commit message (Collapse) | Author |
|---|
|
usb-conn-gpio devices are a subnode of the USB interface controller, which
needs to be populated.
This allows having a non-type-c connector providing dual-role.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Link: https://lore.kernel.org/r/20220105071407.2240302-1-alexander.stein@ew.tq-group.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Upstream-Status: Backport [a102f07e4edf0f1cf06bf9825ab10e26a29dd945]
|
|
This reverts commit d021d751c14752a0266865700f6f212fab40a18c.
Re-enable the data-mapping property which was already used in the
5.4-2.3.0 downstream kernel.
In addition to the revert set bpc from the data-mapping value
as a WARN_ON is printed if missing.
Additionally fix mapping variable used uninitialized.
If a panel-dpi node does not have the data-mapping property defined an
uninitalized pointer is used with strcmp resulting in a kernel crash
during boot.
(backtrace from upstream 6.0 kernel)
[ 6.509726] 8<--- cut here ---
[ 6.513351] Unable to handle kernel NULL pointer dereference at virtual address 00000013
[ 6.522189] [00000013] *pgd=00000000
[ 6.526111] Internal error: Oops: 5 [#1] SMP ARM
[ 6.530833] Modules linked in:
[ 6.533983] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-6.0.0-devel+git.4fe89d07dcc2 #1
[ 6.542483] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
[ 6.548768] PC is at strcmp+0x0/0x34
[ 6.552449] LR is at panel_dpi_probe+0xc4/0x1f0
[ 6.557092] pc : [<c0640e50>] lr : [<c0760dc4>] psr: 60000013
[ 6.563470] sp : f083dcc0 ip : 00000001 fp : c15004d0
[ 6.568791] r10: 00000000 r9 : ef7f4d08 r8 : c2178000
[ 6.574115] r7 : c230b740 r6 : c256d100 r5 : 00000013 r4 : c256b4c0
[ 6.580757] r3 : 00000000 r2 : c2178000 r1 : c12bd7f0 r0 : 00000013
[ 6.587399] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 6.594659] Control: 10c5387d Table: 8000406a DAC: 00000051
[ 6.600507] Register r0 information: non-paged memory
[ 6.605676] Register r1 information: non-slab/vmalloc memory
[ 6.611457] Register r2 information: slab task_struct start c2178000 pointer offset 0
[ 6.619488] Register r3 information: NULL pointer
[ 6.624296] Register r4 information: slab kmalloc-128 start c256b480 pointer offset 64 size 128
[ 6.633208] Register r5 information: non-paged memory
[ 6.638367] Register r6 information: slab kmalloc-192 start c256d0c0 pointer offset 64 size 192
[ 6.647278] Register r7 information: slab kmalloc-256 start c230b700 pointer offset 64 size 256
[ 6.656191] Register r8 information: slab task_struct start c2178000 pointer offset 0
[ 6.664207] Register r9 information: non-slab/vmalloc memory
[ 6.669981] Register r10 information: NULL pointer
[ 6.674876] Register r11 information: non-slab/vmalloc memory
[ 6.680738] Register r12 information: non-paged memory
[ 6.685987] Process swapper/0 (pid: 1, stack limit = 0xaf192ddd)
[ 6.692202] Stack: (0xf083dcc0 to 0xf083e000)
[ 6.696672] dcc0: 00000000 c0e2f724 00000000 c12b606c 00000013 c0a01820 f083dd08 00000001
[ 6.705001] dce0: 00000000 c2178000 c17eea20 c0a06930 c230b7f4 c2178000 00000000 9fb7a78a
[ 6.713328] dd00: c230b740 c2112810 c1e74008 c2178000 00000000 c13c9e68 c1802000 c076116c
[ 6.721654] dd20: c21787a0 9fb7a78a c2178000 c2178000 c156455c f083dd50 2e266000 c1799dd4
[ 6.729980] dd40: 00000000 60000093 00000000 c018a198 00000001 00000080 00000000 00000001
[ 6.738303] dd60: c21787c0 c0e236f8 c2178000 c21787c0 00000001 c0181cac c2178000 c1799dd4
[ 6.746629] dd80: c2178000 c156455c c0e2f724 c17de9e0 a0000013 c0186f08 c0a0167c 00000001
[ 6.754952] dda0: 00000001 c2178000 c156a29c c021e0e8 a0000013 c1799dc4 a0000013 c1799dc4
[ 6.763277] ddc0: c0f7e79c c0e2f724 c0f7e860 9fb7a78a c0f7e79c 00000000 c2112810 c1766a80
[ 6.771602] dde0: 00000000 c17eea20 c13c9e68 c1802000 c15004d0 c079113c 00000000 c2112810
[ 6.779927] de00: c1766a80 00000000 c17eea20 c078e168 c21129bc c079e2c0 c2112810 c1766a80
[ 6.788250] de20: c2112810 00000000 c256b358 c078e534 c0f7e79c 9fb7a78a c0f7e860 c1e76200
[ 6.796577] de40: c2112810 c2112810 00000000 c256b358 c13c9e68 c078e6d4 c2112854 c2112810
[ 6.804900] de60: c1766a80 c2178000 c256b358 c078eedc 00000000 c1766a80 c078ee30 c2178000
[ 6.813226] de80: c256b358 c078c094 c20a98e4 c20a98b0 c2242054 9fb7a78a c20a98e4 c1766a80
[ 6.821550] dea0: c256b300 00000000 c1767dd8 c078d50c c12be0c8 c0e2f660 00000000 c1766a80
[ 6.829875] dec0: 00000000 c17ddb00 c1608fcc 00000000 c13c9e68 c078fe98 c2178000 c1532458
[ 6.838198] dee0: c17ddb00 c1532468 c2178000 c01022a4 c21f6067 c21f605a c21f6059 c014be00
[ 6.846523] df00: c2001300 c21f6000 00000129 c12f2658 c15004d0 00000000 c2178000 00000006
[ 6.854846] df20: 00000006 00000000 c2178000 c17ddb00 c1608fcc c1549870 c1549854 9fb7a78a
[ 6.863171] df40: c15638d4 00000007 c21f6000 c1549874 c1549854 c13c9e68 c1802000 c1501328
[ 6.871494] df60: 00000006 00000006 00000000 c15004d0 00000000 00000129 00000000 c1608f80
[ 6.879820] df80: c0e24474 00000000 00000000 00000000 00000000 00000000 00000000 c0e24488
[ 6.888142] dfa0: 00000000 c0e24474 00000000 c0100128 00000000 00000000 00000000 00000000
[ 6.896465] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 6.904788] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[ 6.913110] strcmp from panel_dpi_probe+0xc4/0x1f0
[ 6.918132] panel_dpi_probe from panel_simple_probe+0x27c/0x604
[ 6.924279] panel_simple_probe from platform_probe+0x58/0xbc
[ 6.930162] platform_probe from really_probe+0xd8/0x410
Upstream-Status: denied [Alternative solution being discused]
https://lore.kernel.org/all/20220628181838.2031-1-max.oss.09@gmail.com/
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
Explicitly get endpoint 1 being the sensor one as using overlays may
reverse node order in the final device tree blob.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Conflicts:
drivers/media/platform/mxc/capture/mxc_mipi_csi.c
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
(cherry picked from commit ad9b05bd70583805170e27ba98015502fe5517e0)
Upstream-Status: Inappropriate [NXP downstream camera stack]
|
|
With a recent change now it is possible to detect the strapping
option on SD8997, which allows to pick up a correct firmware
for either SDIO-SDIO or SDIO-UART.
This commit enables SDIO-UART firmware on SD8997.
Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220422090313.125857-3-andrejs.cainikovs@toradex.com
Upstream-Status: Backport [562354ab9f0aa4fcd8f2184506dcb9c18a792182]
|
|
Some WiFi/Bluetooth modules might have different host connection
options, allowing to either use SDIO for both WiFi and Bluetooth,
or SDIO for WiFi and UART for Bluetooth. It is possible to detect
whether a module has SDIO-SDIO or SDIO-UART connection by reading
its host strap register.
This change introduces a way to automatically select appropriate
firmware depending of the connection method, and removes a need
of symlinking or overwriting the original firmware file with a
required one.
Host strap register used in this commit comes from the NXP driver [1]
hosted at Code Aurora.
[1] https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/net/wireless/nxp/mxm_wifiex/wlan_src/mlinux/moal_sdio_mmc.c?h=rel_imx_5.4.70_2.3.2&id=688b67b2c7220b01521ffe560da7eee33042c7bd#n1274
Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>
Reviewed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220422090313.125857-2-andrejs.cainikovs@toradex.com
Upstream-Status: Backport [255ca28a659d3cfb069f73c7644853ed93aecdb0]
|
|
Add comments on the lt8912_write_lvds_config() config to document the
current settings and to make it clear that this is a hardcoded
configuration not relevant for the HDMI output (could be removed without
affecting the HDMI port).
No changes on the actual register writes.
Upstream-Status: Backport [fc44f3636a4db6544fd1532280e8adcd1ef13ba2]
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
|
|
Set bits per component (BPC) for LOGIC Technologies, Inc LT161010 and
LT170410 to avoid the following warning:
[ 1.780308] panel-simple panel-lvds: supply power not found, using
dummy regulator
[ 1.793608] ------------[ cut here ]------------
[ 1.803632] WARNING: CPU: 1 PID: 8 at drivers/gpu/drm/panel/
panel-simple.c:748 panel_simple_probe+0x2e4/0x4d0
Upstream-Status: Submitted [https://lore.kernel.org/all/20220831141622.39605-1-francesco.dolcini@toradex.com/]
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
It is possible that component_add() does return -EPROBE_DEFER if
something else is not ready. At that stage of the probe
sec_dsim_of_parse_resets() has already been called so the resets need to
be cleaned up to leave it in a clean state for the next try.
Upstream-Status: Pending [downstream graphics stack]
Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
|
|
The revert resolution of commit c0ce75395f8d ("soc: imx: gpcv2: allow
domains without power-sequence control") left a unused error label:
| drivers/soc/imx/gpcv2.c: In function ‘imx_pgc_domain_probe’:
| drivers/soc/imx/gpcv2.c:519:1: warning: label ‘out_genpd_remove’ defined but not used [-Wunused-label]
| 519 | out_genpd_remove:
| | ^~~~~~~~~~~~~~~~
Looks like we can savely remove this, but should return 'ret', rather
than '0' to report a possible error.
Fixes: c706fb45b357 ("Revert "soc: imx: gpcv2: allow domains without power-sequence control"")
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
This is the 5.15.77 stable release
Signed-off-by: Daiane Angolini <daiane.angolini@foundries.io>
|
|
This is the 5.15.76 stable release
Signed-off-by: Daiane Angolini <daiane.angolini@foundries.io>
|
|
This is the 5.15.75 stable release
Conflicts:
arch/arm/boot/dts/imx6dl.dtsi
arch/arm/boot/dts/imx6q.dtsi
arch/arm/boot/dts/imx6sl.dtsi
arch/arm/boot/dts/imx6sll.dtsi
arch/arm/boot/dts/imx6sx.dtsi
arch/arm/boot/dts/imx7d-sdb.dts
drivers/char/hw_random/imx-rngc.c
drivers/dma/mxs-dma.c
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
drivers/tty/serial/fsl_lpuart.c
drivers/usb/host/xhci.h
Signed-off-by: Daiane Angolini <daiane.angolini@foundries.io>
|
|
This is the 5.15.74 stable release
Signed-off-by: Daiane Angolini <daiane.angolini@foundries.io>
|
|
This is the 5.15.73 stable release
Signed-off-by: Daiane Angolini <daiane.angolini@foundries.io>
|
|
This is the 5.15.72 stable release
Signed-off-by: Daiane Angolini <daiane.angolini@foundries.io>
|
|
This is the 5.15.71 stable release
Conflicts:
drivers/net/phy/aquantia_main.c
drivers/tty/serial/fsl_lpuart.c
Signed-off-by: Daiane Angolini <daiane.angolini@foundries.io>
|
|
This is the 5.15.70 stable release
Signed-off-by: Daiane Angolini <daiane.angolini@foundries.io>
|
|
This is the 5.15.69 stable release
Conflicts:
drivers/soc/fsl/Kconfig
Signed-off-by: Daiane Angolini <daiane.angolini@foundries.io>
|
|
This is the 5.15.68 stable release
Conflicts:
drivers/soc/imx/gpcv2.c
Signed-off-by: Daiane Angolini <daiane.angolini@foundries.io>
|
|
This reverts commit c0ce75395f8d088ba56dcec3218c628ef2bb6d73.
Conflicts:
drivers/soc/imx/gpcv2.c
Signed-off-by: Daiane Angolini <daiane.angolini@foundries.io>
|
|
This is the 5.15.66 stable release
Conflicts:
drivers/usb/dwc3/host.c
Signed-off-by: Daiane Angolini <daiane.angolini@foundries.io>
|
|
This is the 5.15.65 stable release
Signed-off-by: Daiane Angolini <daiane.angolini@foundries.io>
|
|
This is the 5.15.64 stable release
Conflicts:
net/dsa/slave.c
Signed-off-by: Daiane Angolini <daiane.angolini@foundries.io>
|
|
This is the 5.15.63 stable release
Signed-off-by: Daiane Angolini <daiane.angolini@foundries.io>
Conflicts:
drivers/gpu/drm/imx/dcss/dcss-kms.c
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
|
|
This is the 5.15.62 stable release
|
|
This is the 5.15.61 stable release
Conflicts:
arch/arm/boot/dts/imx6ul.dtsi
drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.c
drivers/media/platform/nxp/imx-jpeg/mxc-jpeg.h
Signed-off-by: Daiane Angolini <daiane.angolini@foundries.io>
|
|
This reverts commit 63c92d710d16b9b620276cb118541ae6236464b8.
|
|
resolution change"
This reverts commit fec525237cf2e40e063ed6940e9bc4a02b1f9082.
|
|
s_selection"
This reverts commit 4f717113db7a97d020c3d149dc363e0a9ab120a0.
|
|
This reverts commit 13dd24a6f2c08ebd81351700b087f03ee73b15e1.
|
|
This reverts commit 9ae2d729de6350c53a06c57782751d84eb2c08d9.
|
|
contiguous format"
This reverts commit a73cf59f30bfa38046aa82cd7be283a0941fb2af.
|
|
commit 7c7f9bc986e698873b489c371a08f206979d06b7 upstream.
When a UART port is newly registered, uart_configure_port() seeks to
deassert RS485 Transmit Enable by setting the RTS bit in port->mctrl.
However a number of UART drivers interpret a set RTS bit as *assertion*
instead of deassertion: Affected drivers include those using
serial8250_em485_config() (except 8250_bcm2835aux.c) and some using
mctrl_gpio (e.g. imx.c).
Since the interpretation of the RTS bit is driver-specific, it is not
suitable as a means to centrally deassert Transmit Enable in the serial
core. Instead, the serial core must call on drivers to deassert it in
their driver-specific way. One way to achieve that is to call
->rs485_config(). It implicitly deasserts Transmit Enable.
So amend uart_configure_port() and uart_resume_port() to invoke
uart_rs485_config(). That allows removing calls to uart_rs485_config()
from drivers' ->probe() hooks and declaring the function static.
Skip any invocation of ->set_mctrl() if RS485 is enabled. RS485 has no
hardware flow control, so the modem control lines are irrelevant and
need not be touched. When leaving RS485 mode, reset the modem control
lines to the state stored in port->mctrl. That way, UARTs which are
muxed between RS485 and RS232 transceivers drive the lines correctly
when switched to RS232. (serial8250_do_startup() historically raises
the OUT1 modem signal because otherwise interrupts are not signaled on
ancient PC UARTs, but I believe that no longer applies to modern,
RS485-capable UARTs and is thus safe to be skipped.)
imx.c modifies port->mctrl whenever Transmit Enable is asserted and
deasserted. Stop it from doing that so port->mctrl reflects the RS232
line state.
8250_omap.c deasserts Transmit Enable on ->runtime_resume() by calling
->set_mctrl(). Because that is now a no-op in RS485 mode, amend the
function to call serial8250_em485_stop_tx().
fsl_lpuart.c retrieves and applies the RS485 device tree properties
after registering the UART port. Because applying now happens on
registration in uart_configure_port(), move retrieval of the properties
ahead of uart_add_one_port().
Link: https://lore.kernel.org/all/20220329085050.311408-1-matthias.schiffer@ew.tq-group.com/
Link: https://lore.kernel.org/all/8f538a8903795f22f9acc94a9a31b03c9c4ccacb.camel@ginzinger.com/
Fixes: d3b3404df318 ("serial: Fix incorrect rs485 polarity on uart open")
Cc: stable@vger.kernel.org # v4.14+
Reported-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Reported-by: Roosen Henri <Henri.Roosen@ginzinger.com>
Tested-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Link: https://lore.kernel.org/r/2de36eba3fbe11278d5002e4e501afe0ceaca039.1663863805.git.lukas@wunner.de
Signed-off-by: Daisuke Mizobuchi <mizo@atmark-techno.com>
Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 0ed12afa5655512ee418047fb3546d229df20aa1 upstream.
Several drivers that support setting the RS485 configuration via userspace
implement one or more of the following tasks:
- in case of an invalid RTS configuration (both RTS after send and RTS on
send set or both unset) fall back to enable RTS on send and disable RTS
after send
- nullify the padding field of the returned serial_rs485 struct
- copy the configuration into the uart port struct
- limit RTS delays to 100 ms
Move these tasks into the serial core to make them generic and to provide
a consistent behaviour among all drivers.
Signed-off-by: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Link: https://lore.kernel.org/r/20220410104642.32195-2-LinoSanfilippo@gmx.de
Signed-off-by: Daisuke Mizobuchi <mizo@atmark-techno.com>
Signed-off-by: Dominique Martinet <dominique.martinet@atmark-techno.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
FIFO receive
commit 702de2c21eed04c67cefaaedc248ef16e5f6b293 upstream.
We are seeing an IRQ storm on the global receive IRQ line under heavy
CAN bus load conditions with both CAN channels enabled.
Conditions:
The global receive IRQ line is shared between can0 and can1, either of
the channels can trigger interrupt while the other channel's IRQ line
is disabled (RFIE).
When global a receive IRQ interrupt occurs, we mask the interrupt in
the IRQ handler. Clearing and unmasking of the interrupt is happening
in rx_poll(). There is a race condition where rx_poll() unmasks the
interrupt, but the next IRQ handler does not mask the IRQ due to
NAPIF_STATE_MISSED flag (e.g.: can0 RX FIFO interrupt is disabled and
can1 is triggering RX interrupt, the delay in rx_poll() processing
results in setting NAPIF_STATE_MISSED flag) leading to an IRQ storm.
This patch fixes the issue by checking IRQ active and enabled before
handling the IRQ on a particular channel.
Fixes: dd3bd23eb438 ("can: rcar_canfd: Add Renesas R-Car CAN FD driver")
Suggested-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/all/20221025155657.1426948-2-biju.das.jz@bp.renesas.com
Cc: stable@vger.kernel.org
[mkl: adjust commit message]
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
[biju: removed gpriv from RCANFD_RFCC_RFIE macro]
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit d887087c896881715c1a82f1d4f71fbfe5344ffd upstream.
RZ/G2L has separate channel specific IRQs for transmit and error
interrupts. But the IRQ handler processes both channels, even if there
no interrupt occurred on one of the channels.
This patch fixes the issue by passing a channel specific context
parameter instead of global one for the IRQ register and the IRQ
handler, it just handles the channel which is triggered the interrupt.
Fixes: 76e9353a80e9 ("can: rcar_canfd: Add support for RZ/G2L family")
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/all/20221025155657.1426948-3-biju.das.jz@bp.renesas.com
Cc: stable@vger.kernel.org
[mkl: adjust commit message]
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
[biju: fixed the conflicts manually]
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This reverts commit 84f7a9de0602704bbec774a6c7f7c8c4994bee9c.
Because it introduces a problem that rq->__data_len is set to the wrong
value.
before the patch:
1) nr_bytes = rq->__data_len
2) rq->__data_len = sdp->sector_size
3) scsi_init_io()
4) rq->__data_len = nr_bytes
after the patch:
1) rq->__data_len = sdp->sector_size
2) scsi_init_io()
3) rq->__data_len = rq->__data_len -> __data_len is wrong
It will cause that io can only complete one segment each time, and the io
will requeue in scsi_io_completion_action(), which will cause severe
performance degradation.
Scsi write same is removed in commit e383e16e84e9 ("scsi: sd: Remove
WRITE_SAME support") from mainline, hence this patch is only needed for
stable kernels.
Fixes: 84f7a9de0602 ("scsi: sd: Remove a local variable")
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 84ce1ca3fe9e1249bf21176ff162200f1c4e5ed1 ]
Under memory pressure, enetc_refill_rx_ring() may fail, and when called
during the enetc_open() -> enetc_setup_rxbdr() procedure, this is not
checked for.
An extreme case of memory pressure will result in exactly zero buffers
being allocated for the RX ring, and in such a case it is expected that
hardware drops all RX packets due to lack of buffers.
This does not happen, because the reset-default value of the consumer
and produces index is 0, and this makes the ENETC think that all buffers
have been initialized and that it owns them (when in reality none were).
The hardware guide explains this best:
| Configure the receive ring producer index register RBaPIR with a value
| of 0. The producer index is initially configured by software but owned
| by hardware after the ring has been enabled. Hardware increments the
| index when a frame is received which may consume one or more BDs.
| Hardware is not allowed to increment the producer index to match the
| consumer index since it is used to indicate an empty condition. The ring
| can hold at most RBLENR[LENGTH]-1 received BDs.
|
| Configure the receive ring consumer index register RBaCIR. The
| consumer index is owned by software and updated during operation of the
| of the BD ring by software, to indicate that any receive data occupied
| in the BD has been processed and it has been prepared for new data.
| - If consumer index and producer index are initialized to the same
| value, it indicates that all BDs in the ring have been prepared and
| hardware owns all of the entries.
| - If consumer index is initialized to producer index plus N, it would
| indicate N BDs have been prepared. Note that hardware cannot start if
| only a single buffer is prepared due to the restrictions described in
| (2).
| - Software may write consumer index to match producer index anytime
| while the ring is operational to indicate all received BDs prior have
| been processed and new BDs prepared for hardware.
Normally, the value of rx_ring->rcir (consumer index) is brought in sync
with the rx_ring->next_to_use software index, but this only happens if
page allocation ever succeeded.
When PI==CI==0, the hardware appears to receive frames and write them to
DMA address 0x0 (?!), then set the READY bit in the BD.
The enetc_clean_rx_ring() function (and its XDP derivative) is naturally
not prepared to handle such a condition. It will attempt to process
those frames using the rx_swbd structure associated with index i of the
RX ring, but that structure is not fully initialized (enetc_new_page()
does all of that). So what happens next is undefined behavior.
To operate using no buffer, we must initialize the CI to PI + 1, which
will block the hardware from advancing the CI any further, and drop
everything.
The issue was seen while adding support for zero-copy AF_XDP sockets,
where buffer memory comes from user space, which can even decide to
supply no buffers at all (example: "xdpsock --txonly"). However, the bug
is present also with the network stack code, even though it would take a
very determined person to trigger a page allocation failure at the
perfect time (a series of ifup/ifdown under memory pressure should
eventually reproduce it given enough retries).
Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Link: https://lore.kernel.org/r/20221027182925.3256653-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit aefb62a9988749703435e941704624949a80a2a9 ]
When setting Bluefield to DPU NIC mode using mlxconfig tool + sync
firmware reset flow, we run into scenario where the host was not
eswitch manager at the time of mlx5 driver load but becomes eswitch manager
after the sync firmware reset flow. This results in null pointer
access of mpfs structure during mac filter add. This change prevents null
pointer access but mpfs table entries will not be added.
Fixes: 5ec697446f46 ("net/mlx5: Add support for devlink reload action fw activate")
Signed-off-by: Suresh Devarakonda <ramad@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Bodong Wang <bodong@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Link: https://lore.kernel.org/r/20221026135153.154807-12-saeed@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 416ef713631937cf5452476a7f1041a3ae7b06c6 ]
Update devlink health fw fatal reporter state to "healthy" is needed by
strictly calling devlink_health_reporter_state_update() after recovery
was done by PCI error handler. This is needed when fw_fatal reporter was
triggered due to PCI error. Poll health is called and set reporter state
to error. Health recovery failed (since EEH didn't re-enable the PCI).
PCI handlers keep on recover flow and succeed later without devlink
acknowledgment. Fix this by adding devlink state update at the end of
the PCI handler recovery process.
Fixes: 6181e5cb752e ("devlink: add support for reporter recovery completion")
Signed-off-by: Roy Novich <royno@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Aya Levin <ayal@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Link: https://lore.kernel.org/r/20221026135153.154807-11-saeed@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit fad1783a6d669ac82b6ea4f2f32b4ba2b5484920 ]
In case mlx5_pci_err_detected was called with state equals to
pci_channel_io_perm_failure, the driver will never come back up.
It is nice to know why the driver went to zombie land, so print some
useful information on pci err handlers.
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Stable-dep-of: 416ef7136319 ("net/mlx5: Update fw fatal reporter state on PCI handlers successful recover")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit bacd22df95147ed673bec4692ab2d4d585935241 ]
mlx5_cmd_cleanup_async_ctx should return only after all its callback
handlers were completed. Before this patch, the below race between
mlx5_cmd_cleanup_async_ctx and mlx5_cmd_exec_cb_handler was possible and
lead to a use-after-free:
1. mlx5_cmd_cleanup_async_ctx is called while num_inflight is 2 (i.e.
elevated by 1, a single inflight callback).
2. mlx5_cmd_cleanup_async_ctx decreases num_inflight to 1.
3. mlx5_cmd_exec_cb_handler is called, decreases num_inflight to 0 and
is about to call wake_up().
4. mlx5_cmd_cleanup_async_ctx calls wait_event, which returns
immediately as the condition (num_inflight == 0) holds.
5. mlx5_cmd_cleanup_async_ctx returns.
6. The caller of mlx5_cmd_cleanup_async_ctx frees the mlx5_async_ctx
object.
7. mlx5_cmd_exec_cb_handler goes on and calls wake_up() on the freed
object.
Fix it by syncing using a completion object. Mark it completed when
num_inflight reaches 0.
Trace:
BUG: KASAN: use-after-free in do_raw_spin_lock+0x23d/0x270
Read of size 4 at addr ffff888139cd12f4 by task swapper/5/0
CPU: 5 PID: 0 Comm: swapper/5 Not tainted 6.0.0-rc3_for_upstream_debug_2022_08_30_13_10 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Call Trace:
<IRQ>
dump_stack_lvl+0x57/0x7d
print_report.cold+0x2d5/0x684
? do_raw_spin_lock+0x23d/0x270
kasan_report+0xb1/0x1a0
? do_raw_spin_lock+0x23d/0x270
do_raw_spin_lock+0x23d/0x270
? rwlock_bug.part.0+0x90/0x90
? __delete_object+0xb8/0x100
? lock_downgrade+0x6e0/0x6e0
_raw_spin_lock_irqsave+0x43/0x60
? __wake_up_common_lock+0xb9/0x140
__wake_up_common_lock+0xb9/0x140
? __wake_up_common+0x650/0x650
? destroy_tis_callback+0x53/0x70 [mlx5_core]
? kasan_set_track+0x21/0x30
? destroy_tis_callback+0x53/0x70 [mlx5_core]
? kfree+0x1ba/0x520
? do_raw_spin_unlock+0x54/0x220
mlx5_cmd_exec_cb_handler+0x136/0x1a0 [mlx5_core]
? mlx5_cmd_cleanup_async_ctx+0x220/0x220 [mlx5_core]
? mlx5_cmd_cleanup_async_ctx+0x220/0x220 [mlx5_core]
mlx5_cmd_comp_handler+0x65a/0x12b0 [mlx5_core]
? dump_command+0xcc0/0xcc0 [mlx5_core]
? lockdep_hardirqs_on_prepare+0x400/0x400
? cmd_comp_notifier+0x7e/0xb0 [mlx5_core]
cmd_comp_notifier+0x7e/0xb0 [mlx5_core]
atomic_notifier_call_chain+0xd7/0x1d0
mlx5_eq_async_int+0x3ce/0xa20 [mlx5_core]
atomic_notifier_call_chain+0xd7/0x1d0
? irq_release+0x140/0x140 [mlx5_core]
irq_int_handler+0x19/0x30 [mlx5_core]
__handle_irq_event_percpu+0x1f2/0x620
handle_irq_event+0xb2/0x1d0
handle_edge_irq+0x21e/0xb00
__common_interrupt+0x79/0x1a0
common_interrupt+0x78/0xa0
</IRQ>
<TASK>
asm_common_interrupt+0x22/0x40
RIP: 0010:default_idle+0x42/0x60
Code: c1 83 e0 07 48 c1 e9 03 83 c0 03 0f b6 14 11 38 d0 7c 04 84 d2 75 14 8b 05 eb 47 22 02 85 c0 7e 07 0f 00 2d e0 9f 48 00 fb f4 <c3> 48 c7 c7 80 08 7f 85 e8 d1 d3 3e fe eb de 66 66 2e 0f 1f 84 00
RSP: 0018:ffff888100dbfdf0 EFLAGS: 00000242
RAX: 0000000000000001 RBX: ffffffff84ecbd48 RCX: 1ffffffff0afe110
RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffffffff835cc9bc
RBP: 0000000000000005 R08: 0000000000000001 R09: ffff88881dec4ac3
R10: ffffed1103bd8958 R11: 0000017d0ca571c9 R12: 0000000000000005
R13: ffffffff84f024e0 R14: 0000000000000000 R15: dffffc0000000000
? default_idle_call+0xcc/0x450
default_idle_call+0xec/0x450
do_idle+0x394/0x450
? arch_cpu_idle_exit+0x40/0x40
? do_idle+0x17/0x450
cpu_startup_entry+0x19/0x20
start_secondary+0x221/0x2b0
? set_cpu_sibling_map+0x2070/0x2070
secondary_startup_64_no_verify+0xcd/0xdb
</TASK>
Allocated by task 49502:
kasan_save_stack+0x1e/0x40
__kasan_kmalloc+0x81/0xa0
kvmalloc_node+0x48/0xe0
mlx5e_bulk_async_init+0x35/0x110 [mlx5_core]
mlx5e_tls_priv_tx_list_cleanup+0x84/0x3e0 [mlx5_core]
mlx5e_ktls_cleanup_tx+0x38f/0x760 [mlx5_core]
mlx5e_cleanup_nic_tx+0xa7/0x100 [mlx5_core]
mlx5e_detach_netdev+0x1ca/0x2b0 [mlx5_core]
mlx5e_suspend+0xdb/0x140 [mlx5_core]
mlx5e_remove+0x89/0x190 [mlx5_core]
auxiliary_bus_remove+0x52/0x70
device_release_driver_internal+0x40f/0x650
driver_detach+0xc1/0x180
bus_remove_driver+0x125/0x2f0
auxiliary_driver_unregister+0x16/0x50
mlx5e_cleanup+0x26/0x30 [mlx5_core]
cleanup+0xc/0x4e [mlx5_core]
__x64_sys_delete_module+0x2b5/0x450
do_syscall_64+0x3d/0x90
entry_SYSCALL_64_after_hwframe+0x46/0xb0
Freed by task 49502:
kasan_save_stack+0x1e/0x40
kasan_set_track+0x21/0x30
kasan_set_free_info+0x20/0x30
____kasan_slab_free+0x11d/0x1b0
kfree+0x1ba/0x520
mlx5e_tls_priv_tx_list_cleanup+0x2e7/0x3e0 [mlx5_core]
mlx5e_ktls_cleanup_tx+0x38f/0x760 [mlx5_core]
mlx5e_cleanup_nic_tx+0xa7/0x100 [mlx5_core]
mlx5e_detach_netdev+0x1ca/0x2b0 [mlx5_core]
mlx5e_suspend+0xdb/0x140 [mlx5_core]
mlx5e_remove+0x89/0x190 [mlx5_core]
auxiliary_bus_remove+0x52/0x70
device_release_driver_internal+0x40f/0x650
driver_detach+0xc1/0x180
bus_remove_driver+0x125/0x2f0
auxiliary_driver_unregister+0x16/0x50
mlx5e_cleanup+0x26/0x30 [mlx5_core]
cleanup+0xc/0x4e [mlx5_core]
__x64_sys_delete_module+0x2b5/0x450
do_syscall_64+0x3d/0x90
entry_SYSCALL_64_after_hwframe+0x46/0xb0
Fixes: e355477ed9e4 ("net/mlx5: Make mlx5_cmd_exec_cb() a safe API")
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Link: https://lore.kernel.org/r/20221026135153.154807-8-saeed@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 19b43a432e3e47db656a8269a74b50aef826950c ]
When tx_port_ts is set, the driver diverts all UPD traffic over PTP port
to a dedicated PTP-SQ. The SKBs are cached until the wire-CQE arrives.
When the packet size is greater then MTU, the firmware might drop it and
the packet won't be transmitted to the wire, hence the wire-CQE won't
reach the driver. In this case the SKBs are accumulated in the SKB fifo.
Add room check to consider the PTP-SQ SKB fifo, when the SKB fifo is
full, driver stops the queue resulting in a TX timeout. Devlink
TX-reporter can recover from it.
Fixes: 1880bc4e4a96 ("net/mlx5e: Add TX port timestamp support")
Signed-off-by: Aya Levin <ayal@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Link: https://lore.kernel.org/r/20221026135153.154807-5-saeed@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 888be6b279b7257b5f6e4c9527675bff0a335596 ]
An offloaded SA stops receiving after about 2^32 + replay_window
packets. For example, when SA reaches <seq-hi 0x1, seq 0x2c>, all
subsequent packets get dropped with SA-icv-failure (integrity_failed).
To reproduce the bug:
- ConnectX-6 Dx with crypto enabled (FW 22.30.1004)
- ipsec.conf:
nic-offload = yes
replay-window = 32
esn = yes
salifetime=24h
- Run netperf for a long time to send more than 2^32 packets
netperf -H <device-under-test> -t TCP_STREAM -l 20000
When 2^32 + replay_window packets are received, the replay window
moves from the 2nd half of subspace (overlap=1) to the 1st half
(overlap=0). The driver then updates the 'esn' value in NIC
(i.e. seq_hi) as follows.
seq_hi = xfrm_replay_seqhi(seq_bottom)
new esn in NIC = seq_hi + 1
The +1 increment is wrong, as seq_hi already contains the correct
seq_hi. For example, when seq_hi=1, the driver actually tells NIC to
use seq_hi=2 (esn). This incorrect esn value causes all subsequent
packets to fail integrity checks (SA-icv-failure). So, do not
increment.
Fixes: cb01008390bb ("net/mlx5: IPSec, Add support for ESN")
Signed-off-by: Hyong Youb Kim <hyonkim@cisco.com>
Acked-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Link: https://lore.kernel.org/r/20221026135153.154807-2-saeed@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit a6aa8d0ce2cfba57ac0f23293fcb3be0b9f53fba ]
Remove dir in nsim_dev_debugfs_init() when creating ports dir failed.
Otherwise, the netdevsim device will not be created next time. Kernel
reports an error: debugfs: Directory 'netdevsim1' with parent 'netdevsim'
already present!
Fixes: ab1d0cc004d7 ("netdevsim: change debugfs tree topology")
Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit ef3556ee16c68735ec69bd08df41d1cd83b14ad3 ]
Queueing packets doesn't guarantee their transmission. Update TX stats
after hardware confirms consuming submitted data.
This also fixes a possible race and NULL dereference.
bcm4908_enet_start_xmit() could try to access skb after freeing it in
the bcm4908_enet_poll_tx().
Reported-by: Florian Fainelli <f.fainelli@gmail.com>
Fixes: 4feffeadbcb2e ("net: broadcom: bcm4908enet: add BCM4908 controller driver")
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20221027112430.8696-1-zajec5@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 62a3106697f3c6f9af64a2cd0f9ff58552010dc8 ]
The variable bytes is being used to summate slot lengths,
however the value is never used afterwards. The summation
is redundant so remove variable bytes.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://lore.kernel.org/r/20211222003937.727325-1-colin.i.king@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Stable-dep-of: ef3556ee16c6 ("net: broadcom: bcm4908_enet: update TX stats after actual transmission")
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 9f172134dde7e4f5bf4b9139f23a1e741ec1c36e ]
Avoid the PHY library call unnecessarily into the suspend/resume
functions by setting phydev->mac_managed_pm to true. The SYSTEMPORT
driver essentially does exactly what mdio_bus_phy_resume() does by
calling phy_resume().
Fixes: fba863b81604 ("net: phy: make PHY PM ops a no-op if MAC driver manages PHY PM")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20221025234201.2549360-1-f.fainelli@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 0e7ce23a917a9cc83ca3c779fbba836bca3bcf1e ]
If of_device_register() returns error, the of node and the
name allocated in dev_set_name() is leaked, call put_device()
to give up the reference that was set in device_initialize(),
so that of node is put in logical_port_release() and the name
is freed in kobject_cleanup().
Fixes: 1acf2318dd13 ("ehea: dynamic add / remove port")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221025130011.1071357-1-yangyingliang@huawei.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit e2badb4bd33abe13ddc35975bd7f7f8693955a4b ]
The phylib callback is called after MAC driver's own resume callback is
called. For AVE driver, after resuming immediately, PHY state machine is
in PHY_NOLINK because there is a time lag from link-down to link-up due to
autoneg. The result is WARN_ON() dump in mdio_bus_phy_resume().
Since ave_resume() itself calls phy_resume(), AVE driver should manage
PHY PM. To indicate that MAC driver manages PHY PM, set
phydev->mac_managed_pm to true to avoid the unnecessary phylib call and
add missing phy_init_hw() to ave_resume().
Suggested-by: Heiner Kallweit <hkallweit1@gmail.com>
Fixes: fba863b81604 ("net: phy: make PHY PM ops a no-op if MAC driver manages PHY PM")
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Link: https://lore.kernel.org/r/20221024072227.24769-1-hayashi.kunihiko@socionext.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
