aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2022-07-04arm64: fix oops in concurrently setting insn_emulation sysctlshaibinzhang (张海斌)1-4/+5
emulation_proc_handler() changes table->data for proc_dointvec_minmax and can generate the following Oops if called concurrently with itself: | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 | Internal error: Oops: 96000006 [#1] SMP | Call trace: | update_insn_emulation_mode+0xc0/0x148 | emulation_proc_handler+0x64/0xb8 | proc_sys_call_handler+0x9c/0xf8 | proc_sys_write+0x18/0x20 | __vfs_write+0x20/0x48 | vfs_write+0xe4/0x1d0 | ksys_write+0x70/0xf8 | __arm64_sys_write+0x20/0x28 | el0_svc_common.constprop.0+0x7c/0x1c0 | el0_svc_handler+0x2c/0xa0 | el0_svc+0x8/0x200 To fix this issue, keep the table->data as &insn->current_mode and use container_of() to retrieve the insn pointer. Another mutex is used to protect against the current_mode update but not for retrieving insn_emulation as table->data is no longer changing. Co-developed-by: hewenliang <hewenliang4@huawei.com> Signed-off-by: hewenliang <hewenliang4@huawei.com> Signed-off-by: Haibin Zhang <haibinzhang@tencent.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Link: https://lore.kernel.org/r/20220128090324.2727688-1-hewenliang4@huawei.com Link: https://lore.kernel.org/r/9A004C03-250B-46C5-BF39-782D7551B00E@tencent.com Signed-off-by: Will Deacon <will@kernel.org>
2022-07-04powerpc/powernv: delay rng platform device creation until later in bootJason A. Donenfeld1-6/+10
The platform device for the rng must be created much later in boot. Otherwise it tries to connect to a parent that doesn't yet exist, resulting in this splat: [ 0.000478] kobject: '(null)' ((____ptrval____)): is not initialized, yet kobject_get() is being called. [ 0.002925] [c000000002a0fb30] [c00000000073b0bc] kobject_get+0x8c/0x100 (unreliable) [ 0.003071] [c000000002a0fba0] [c00000000087e464] device_add+0xf4/0xb00 [ 0.003194] [c000000002a0fc80] [c000000000a7f6e4] of_device_add+0x64/0x80 [ 0.003321] [c000000002a0fcb0] [c000000000a800d0] of_platform_device_create_pdata+0xd0/0x1b0 [ 0.003476] [c000000002a0fd00] [c00000000201fa44] pnv_get_random_long_early+0x240/0x2e4 [ 0.003623] [c000000002a0fe20] [c000000002060c38] random_init+0xc0/0x214 This patch fixes the issue by doing the platform device creation inside of machine_subsys_initcall. Fixes: f3eac426657d ("powerpc/powernv: wire up rng during setup_arch") Cc: stable@vger.kernel.org Reported-by: Sachin Sant <sachinp@linux.ibm.com> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Tested-by: Sachin Sant <sachinp@linux.ibm.com> [mpe: Change "of node" to "platform device" in change log] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220630121654.1939181-1-Jason@zx2c4.com
2022-07-04soc: bcm: bcm2835-power: Bypass power_on/off() callsNicolas Saenz Julienne1-0/+8
Bypass power_on/power_off() when running on BCM2711 as they are not needed. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20220625113619.15944-12-stefan.wahren@i2se.com
2022-07-04soc: bcm: bcm2835-power: Add support for BCM2711's RPiVid ASBStefan Wahren1-2/+23
In BCM2711 the new RPiVid ASB took over V3D. The old ASB is still present with the ISP and H264 bits, and V3D is in the same place in the new ASB as the old one. Use the fact that 'pm->rpivid_asb' is populated as a hint that we're on BCM2711. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20220625113619.15944-11-stefan.wahren@i2se.com
2022-07-04soc: bcm: bcm2835-power: Resolve ASB register macrosStefan Wahren1-7/+7
The macros in order to access the ASB registers have a hard coded base address. So extending them for other platforms would make them harder to read. As a solution resolve these macros. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20220625113619.15944-10-stefan.wahren@i2se.com
2022-07-04soc: bcm: bcm2835-power: Refactor ASB controlStefan Wahren1-18/+13
The functions to control the async AXI bridges are almost identical. So define a general function to handle it and keep the original ones as wrapper. This should make this driver easier to extend. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20220625113619.15944-9-stefan.wahren@i2se.com
2022-07-04can: mcp251xfd: mcp251xfd_register_get_dev_id(): fix endianness conversionMarc Kleine-Budde1-1/+2
In mcp251xfd_register_get_dev_id() the device ID register is read with handcrafted SPI transfers. As all registers, this register is in little endian. Further it is not naturally aligned in struct mcp251xfd_map_buf_nocrc::data. However after the transfer the register content is converted from big endian to CPU endianness not taking care of being unaligned. Fix the conversion by converting from little endian to CPU endianness taking the unaligned source into account. Side note: So far the register content is 0x0 on all mcp251xfd compatible chips, and is only used for an informative printk. Link: https://lore.kernel.org/all/20220627092859.809042-1-mkl@pengutronix.de Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Reviewed-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04can: mcp251xfd: mcp251xfd_register_get_dev_id(): use correct length to read dev_idMarc Kleine-Budde1-1/+1
The device ID register is 32 bits wide. The driver uses incorrectly the size of a pointer to a u32 to calculate the length of the SPI transfer. This results in a read of 2 registers on 64 bit platforms. This is no problem on the Linux side, as the RX buffer of the SPI transfer is large enough. In the mpc251xfd chip this results in the read of an undocumented register. So far no problems were observed. Fix the length of the SPI transfer to read the device ID register only. Link: https://lore.kernel.org/all/20220616094914.244440-1-mkl@pengutronix.de Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Reported-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04can: mcp251xfd: mcp251xfd_stop(): add missing hrtimer_cancel()Marc Kleine-Budde1-0/+1
In commit 169d00a25658 ("can: mcp251xfd: add TX IRQ coalescing support") software based TX coalescing was added to the driver. The key idea is to keep the TX complete IRQ disabled for some time after processing it and re-enable later by a hrtimer. When bringing the interface down, this timer has to be stopped. Add the missing hrtimer_cancel() of the tx_irq_time hrtimer to mcp251xfd_stop(). Link: https://lore.kernel.org/all/20220620143942.891811-1-mkl@pengutronix.de Fixes: 169d00a25658 ("can: mcp251xfd: add TX IRQ coalescing support") Cc: stable@vger.kernel.org # v5.18 Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04can: mcp251xfd: mcp251xfd_regmap_crc_read(): update workaround broken CRC on TBC registerThomas Kopp1-6/+3
The mcp251xfd compatible chips have an erratum ([1], [2]), where the received CRC doesn't match the calculated CRC. In commit c7eb923c3caf ("can: mcp251xfd: mcp251xfd_regmap_crc_read(): work around broken CRC on TBC register") the following workaround was implementierend. - If a CRC read error on the TBC register is detected and the first byte is 0x00 or 0x80, the most significant bit of the first byte is flipped and the CRC is calculated again. - If the CRC now matches, the _original_ data is passed to the reader. For now we assume transferred data was OK. New investigations and simulations indicate that the CRC send by the device is calculated on correct data, and the data is incorrectly received by the SPI host controller. Use flipped instead of original data and update workaround description in mcp251xfd_regmap_crc_read(). [1] mcp2517fd: DS80000792C: "Incorrect CRC for certain READ_CRC commands" [2] mcp2518fd: DS80000789C: "Incorrect CRC for certain READ_CRC commands" Link: https://lore.kernel.org/all/DM4PR11MB53901D49578FE265B239E55AFB7C9@DM4PR11MB5390.namprd11.prod.outlook.com Fixes: c7eb923c3caf ("can: mcp251xfd: mcp251xfd_regmap_crc_read(): work around broken CRC on TBC register") Cc: stable@vger.kernel.org Signed-off-by: Thomas Kopp <thomas.kopp@microchip.com> [mkl: split into 2 patches, update patch description and documentation] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04can: mcp251xfd: mcp251xfd_regmap_crc_read(): improve workaround handling for mcp2517fdThomas Kopp1-5/+8
The mcp251xfd compatible chips have an erratum ([1], [2]), where the received CRC doesn't match the calculated CRC. In commit c7eb923c3caf ("can: mcp251xfd: mcp251xfd_regmap_crc_read(): work around broken CRC on TBC register") the following workaround was implementierend. - If a CRC read error on the TBC register is detected and the first byte is 0x00 or 0x80, the most significant bit of the first byte is flipped and the CRC is calculated again. - If the CRC now matches, the _original_ data is passed to the reader. For now we assume transferred data was OK. Measurements on the mcp2517fd show that the workaround is applicable not only of the lowest byte is 0x00 or 0x80, but also if 3 least significant bits are set. Update check on 1st data byte and workaround description accordingly. [1] mcp2517fd: DS80000792C: "Incorrect CRC for certain READ_CRC commands" [2] mcp2518fd: DS80000789C: "Incorrect CRC for certain READ_CRC commands" Link: https://lore.kernel.org/all/DM4PR11MB53901D49578FE265B239E55AFB7C9@DM4PR11MB5390.namprd11.prod.outlook.com Fixes: c7eb923c3caf ("can: mcp251xfd: mcp251xfd_regmap_crc_read(): work around broken CRC on TBC register") Cc: stable@vger.kernel.org Reported-by: Pavel Modilaynen <pavel.modilaynen@volvocars.com> Signed-off-by: Thomas Kopp <thomas.kopp@microchip.com> [mkl: split into 2 patches, update patch description and documentation] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04can: kvaser_usb: kvaser_usb_leaf: fix bittiming limitsJimmy Assarsson3-35/+47
Use correct bittiming limits depending on device. For devices based on USBcanII, Leaf M32C or Leaf i.MX28. Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices") Fixes: b4f20130af23 ("can: kvaser_usb: add support for Kvaser Leaf v2 and usb mini PCIe") Fixes: f5d4abea3ce0 ("can: kvaser_usb: Add support for the USBcan-II family") Link: https://lore.kernel.org/all/20220603083820.800246-4-extja@kvaser.com Cc: stable@vger.kernel.org Signed-off-by: Jimmy Assarsson <extja@kvaser.com> [mkl: remove stray netlink.h include] [mkl: keep struct can_bittiming_const kvaser_usb_flexc_bittiming_const in kvaser_usb_hydra.c] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04mfd: bcm2835-pm: Add support for BCM2711Stefan Wahren2-0/+14
In BCM2711 the new RPiVid ASB took over V3D. The old ASB is still present with the ISP and H264 bits, and V3D is in the same place in the new ASB as the old one. As per the devicetree bindings, BCM2711 will provide both the old and new ASB resources, so get both of them and pass them into 'bcm2835-power,' which will take care of selecting which one to use accordingly. Since the RPiVid ASB's resources were being provided prior to formalizing the bindings[1], also support the old DT files that didn't use 'reg-names.' [1] See: 7dbe8c62ceeb ("ARM: dts: Add minimal Raspberry Pi 4 support") Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by: Peter Robinson <pbrobinson@gmail.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20220625113619.15944-8-stefan.wahren@i2se.com
2022-07-04can: kvaser_usb: kvaser_usb_leaf: fix CAN clock frequency regressionJimmy Assarsson3-21/+38
The firmware of M32C based Leaf devices expects bittiming parameters calculated for 16MHz clock. Since we use the actual clock frequency of the device, the device may end up with wrong bittiming parameters, depending on user requested parameters. This regression affects M32C based Leaf devices with non-16MHz clock. Fixes: fb12797ab1fe ("can: kvaser_usb: get CAN clock frequency from device") Link: https://lore.kernel.org/all/20220603083820.800246-3-extja@kvaser.com Cc: stable@vger.kernel.org Signed-off-by: Jimmy Assarsson <extja@kvaser.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04mfd: bcm2835-pm: Use 'reg-names' to get resourcesNicolas Saenz Julienne1-20/+41
If available in firmware, find resources by their 'reg-names' position instead of relying on hardcoded offsets. Care is taken to support old firmware nonetheless. Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Link: https://lore.kernel.org/r/20220625113619.15944-7-stefan.wahren@i2se.com
2022-07-04can: kvaser_usb: replace run-time checks with struct kvaser_usb_driver_infoJimmy Assarsson3-148/+172
Unify and move compile-time known information into new struct kvaser_usb_driver_info, in favor of run-time checks. All Kvaser USBcanII supports listen-only mode and error counter reporting. Link: https://lore.kernel.org/all/20220603083820.800246-2-extja@kvaser.com Suggested-by: Marc Kleine-Budde <mkl@pengutronix.de> Cc: stable@vger.kernel.org Signed-off-by: Jimmy Assarsson <extja@kvaser.com> [mkl: move struct kvaser_usb_driver_info into kvaser_usb_core.c] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04net: hns: Fix spelling mistakes in comments.Zhang Jiaming1-2/+2
Fix spelling of 'waitting' in comments. remove unnecessary space of 'MDIO_COMMAND_REG 's'. Signed-off-by: Zhang Jiaming <jiaming@nfschina.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04ibmvnic: Properly dispose of all skbs during a failover.Rick Lindsley1-0/+9
During a reset, there may have been transmits in flight that are no longer valid and cannot be fulfilled. Resetting and clearing the queues is insufficient; each skb also needs to be explicitly freed so that upper levels are not left waiting for confirmation of a transmit that will never happen. If this happens frequently enough, the apparent backlog will cause TCP to begin "congestion control" unnecessarily, culminating in permanently decreased throughput. Fixes: d7c0ef36bde03 ("ibmvnic: Free and re-allocate scrqs when tx/rx scrqs change") Tested-by: Nick Child <nnac123@linux.ibm.com> Reviewed-by: Brian King <brking@linux.vnet.ibm.com> Signed-off-by: Rick Lindsley <ricklind@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04Merge branch 'nfp-vlan-strip-and-insert'David S. Miller11-40/+187
Simon Horman says: ==================== nfp: support VLAN strip and insert this series adds support to the NFP driver for HW offload of both: * RX VLAN ctag/stag strip * TX VLAN ctag insert ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04nfp: support TX VLAN ctag insertDiana Wang5-19/+45
Add support for TX VLAN ctag insert which may be configured via ethtool. e.g. # ethtool -K $DEV tx-vlan-offload on The NIC supplies VLAN insert information as packet metadata. The fields of this VLAN metadata are gotten from sk_buff, including vlan_proto and vlan tag. Configuration control bit NFP_NET_CFG_CTRL_TXVLAN_V2 is to signal availability of ctag-insert features of the firmware. NFDK is used to communicate via PCIE to NFP-3800 based NICs while NFD3 is used for other NICs supported by the NFP driver. The metadata format on tx side of NFD3 is different from NFDK. This feature is not currently implemented for NFDK. Signed-off-by: Diana Wang <na.wang@corigine.com> Reviewed-by: Louis Peens <louis.peens@corigine.com> Signed-off-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04nfp: support RX VLAN ctag/stag stripDiana Wang11-22/+143
Add support for RX VLAN ctag/stag strip which may be configured via ethtool. e.g. # ethtool -K $DEV rx-vlan-offload on # ethtool -K $DEV rx-vlan-stag-hw-parse on Ctag-stripped and stag-stripped cannot be enabled at the same time because currently the kernel supports only one layer of VLAN stripping. The NIC supplies VLAN strip information as packet metadata. The fields of this VLAN metadata are: * strip flag: 1 for stripped; 0 for unstripped * tci: VLAN TCI ID * tpid: 1 for ETH_P_8021AD; 0 for ETH_P_8021Q Configuration control bits NFP_NET_CFG_CTRL_RXVLAN_V2 and NFP_NET_CFG_CTRL_RXQINQ are to signal availability of ctag-strip and stag-strip features of the firmware. Signed-off-by: Diana Wang <na.wang@corigine.com> Reviewed-by: Louis Peens <louis.peens@corigine.com> Signed-off-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04can: m_can: m_can_{read_fifo,echo_tx_event}(): shift timestamp to full 32 bitsMarc Kleine-Budde1-2/+2
In commit 1be37d3b0414 ("can: m_can: fix periph RX path: use rx-offload to ensure skbs are sent from softirq context") the RX path for peripheral devices was switched to RX-offload. Received CAN frames are pushed to RX-offload together with a timestamp. RX-offload is designed to handle overflows of the timestamp correctly, if 32 bit timestamps are provided. The timestamps of m_can core are only 16 bits wide. So this patch shifts them to full 32 bit before passing them to RX-offload. Link: https://lore.kernel.org/all/20220612211410.4081390-1-mkl@pengutronix.de Fixes: 1be37d3b0414 ("can: m_can: fix periph RX path: use rx-offload to ensure skbs are sent from softirq context") Cc: <stable@vger.kernel.org> # 5.13 Cc: Torin Cooper-Bennun <torin@maxiluxsystems.com> Reviewed-by: Chandrasekar Ramakrishnan <rcsekar@samsung.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04can: m_can: m_can_chip_config(): actually enable internal timestampingMarc Kleine-Budde1-1/+3
In commit df06fd678260 ("can: m_can: m_can_chip_config(): enable and configure internal timestamps") the timestamping in the m_can core should be enabled. In peripheral mode, the RX'ed CAN frames, TX compete frames and error events are sorted by the timestamp. The above mentioned commit however forgot to enable the timestamping. Add the missing bits to enable the timestamp counter to the write of the Timestamp Counter Configuration register. Link: https://lore.kernel.org/all/20220612212708.4081756-1-mkl@pengutronix.de Fixes: df06fd678260 ("can: m_can: m_can_chip_config(): enable and configure internal timestamps") Cc: <stable@vger.kernel.org> # 5.13 Cc: Torin Cooper-Bennun <torin@maxiluxsystems.com> Reviewed-by: Chandrasekar Ramakrishnan <rcsekar@samsung.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04can: grcan: grcan_probe(): remove extra of_node_get()Liang He1-1/+0
In grcan_probe(), of_find_node_by_path() has already increased the refcount. There is no need to call of_node_get() again, so remove it. Link: https://lore.kernel.org/all/20220619070257.4067022-1-windhl@126.com Fixes: 1e93ed26acf0 ("can: grcan: grcan_probe(): fix broken system id check for errata workaround needs") Cc: stable@vger.kernel.org # v5.18 Cc: Andreas Larsson <andreas@gaisler.com> Signed-off-by: Liang He <windhl@126.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04can: gs_usb: gs_usb_open/close(): fix memory leakRhett Aultman1-2/+21
The gs_usb driver appears to suffer from a malady common to many USB CAN adapter drivers in that it performs usb_alloc_coherent() to allocate a number of USB request blocks (URBs) for RX, and then later relies on usb_kill_anchored_urbs() to free them, but this doesn't actually free them. As a result, this may be leaking DMA memory that's been used by the driver. This commit is an adaptation of the techniques found in the esd_usb2 driver where a similar design pattern led to a memory leak. It explicitly frees the RX URBs and their DMA memory via a call to usb_free_coherent(). Since the RX URBs were allocated in the gs_can_open(), we remove them in gs_can_close() rather than in the disconnect function as was done in esd_usb2. For more information, see the 928150fad41b ("can: esd_usb2: fix memory leak"). Link: https://lore.kernel.org/all/alpine.DEB.2.22.394.2206031547001.1630869@thelappy Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Cc: stable@vger.kernel.org Signed-off-by: Rhett Aultman <rhett.aultman@samsara.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04can: rcar_canfd: Fix data transmission failed on R-Car V3UDuy Nguyen1-1/+4
On R-Car V3U, this driver should use suitable register offset instead of other SoCs' one. Otherwise, data transmission failed on R-Car V3U. Fixes: 45721c406dcf ("can: rcar_canfd: Add support for r8a779a0 SoC") Link: https://lore.kernel.org/all/20220704074611.957191-1-yoshihiro.shimoda.uh@renesas.com Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Duy Nguyen <duy.nguyen.rh@renesas.com> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04Merge branch 'smsc95xx-deadlock'David S. Miller1-116/+86
Lukas Wunner says: ==================== Deadlock no more in LAN95xx Second attempt at fixing a runtime resume deadlock in the LAN95xx USB driver: In short, the driver isn't using the "nopm" register accessors in portions of its runtime resume path, causing a deadlock. I'm fixing that by auto-detecting whether nopm accessors shall be used, instead of having to explicitly call them wherever it's necessary. As a byproduct, code size shrinks significantly (see diffstat below). Back in April I submitted a first attempt which was rejected by Alan Stern: https://lore.kernel.org/all/6710d8c18ff54139cdc538763ba544187c5a0cee.1651041411.git.lukas@wunner.de/ That approach only detected whether a PM callback is running concurrently, not whether the access is performed by the PM callback. I've come up with a different approach which should resolve the objection (see patch [1/3]). ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04usbnet: smsc95xx: Clean up unnecessary BUG_ON() upon register accessLukas Wunner1-4/+0
smsc95xx_read_reg() and smsc95xx_write_reg() call BUG_ON() if the struct usbnet pointer passed in is NULL. The functions have just been amended to dereference the pointer on entry. So the kernel now oopses if the pointer is NULL, eliminating the need for an explicit BUG_ON(). Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04usbnet: smsc95xx: Clean up nopm handlingLukas Wunner1-106/+66
The LAN95xx driver has just been amended to auto-detect whether the _nopm variant of usbnet_read_cmd() / usbnet_write_cmd() shall be used. Drop all the now unnecessary open coding of that distinction. Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04usbnet: smsc95xx: Fix deadlock on runtime resumeLukas Wunner1-6/+20
Commit 05b35e7eb9a1 ("smsc95xx: add phylib support") amended smsc95xx_resume() to call phy_init_hw(). That function waits for the device to runtime resume even though it is placed in the runtime resume path, causing a deadlock. The problem is that phy_init_hw() calls down to smsc95xx_mdiobus_read(), which never uses the _nopm variant of usbnet_read_cmd(). Commit b4df480f68ae ("usbnet: smsc95xx: add reset_resume function with reset operation") causes a similar deadlock on resume if the device was already runtime suspended when entering system sleep: That's because the commit introduced smsc95xx_reset_resume(), which calls down to smsc95xx_reset(), which neglects to use _nopm accessors. Fix by auto-detecting whether a device access is performed by the suspend/resume task_struct and use the _nopm variant if so. This works because the PM core guarantees that suspend/resume callbacks are run in task context. Stacktrace for posterity: INFO: task kworker/2:1:49 blocked for more than 122 seconds. Workqueue: usb_hub_wq hub_event schedule rpm_resume __pm_runtime_resume usb_autopm_get_interface usbnet_read_cmd __smsc95xx_read_reg __smsc95xx_phy_wait_not_busy __smsc95xx_mdio_read smsc95xx_mdiobus_read __mdiobus_read mdiobus_read smsc_phy_reset phy_init_hw smsc95xx_resume usb_resume_interface usb_resume_both usb_runtime_resume __rpm_callback rpm_callback rpm_resume __pm_runtime_resume usb_autoresume_device hub_event process_one_work Fixes: b4df480f68ae ("usbnet: smsc95xx: add reset_resume function with reset operation") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org # v3.16+ Cc: Andre Edich <andre.edich@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04net: phy: broadcom: Add support for BCM53128 internal PHYsKurt Kanzenbach2-0/+16
Add support for BCM53128 internal PHYs. These support interrupts as well as statistics. Therefore, enable the Broadcom PHY driver for them. Tested on BCM53128 switch using the mainline b53 DSA driver. Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04dt-bindings: net: dsa: renesas,rzn1-a5psw: add interrupts descriptionClément Léger1-0/+23
Describe the switch interrupts (dlr, switch, prp, hub, pattern) which are connected to the GIC. Signed-off-by: Clément Léger <clement.leger@bootlin.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04selftest: net: bridge mdb add/del entry to port that is downCasper Andersson2-0/+119
Tests that permanent mdb entries can be added/deleted on ports with state down. Signed-off-by: Casper Andersson <casper.casan@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04net: ipconfig: use strscpy to replace strlcpyXueBing Chen1-4/+4
The strlcpy should not be used because it doesn't limit the source length. Preferred is strscpy. Signed-off-by: XueBing Chen <chenxuebing@jari.cn> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04Revert "can: xilinx_can: Limit CANFD brp to 2"Srinivas Neeli1-2/+2
This reverts commit 05ca14fdb6fe65614e0652d03e44b02748d25af7. On early silicon engineering samples observed bit shrinking issue when we use brp as 1. Hence updated brp_min as 2. As in production silicon this issue is fixed, so reverting the patch. Link: https://lore.kernel.org/all/20220609082433.1191060-2-srinivas.neeli@xilinx.com Signed-off-by: Srinivas Neeli <srinivas.neeli@xilinx.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2022-07-04Merge branch 'netdev-docs'David S. Miller1-0/+36
Jakub Kicinski says: ==================== docs: netdev: document more of our rules The patch series length limit and reverse xmas tree are not documented. Add those, and a tl;dr section summarizing how we differ. v2: improve the series length blurb (Andrew) ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04docs: netdev: add a cheat sheet for the rulesJakub Kicinski1-0/+9
Summarize the rules we see broken most often and which may be less familiar to kernel devs who are used to working outside of netdev. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04docs: netdev: document reverse xmas treeJakub Kicinski1-0/+13
Similarly to the 15 patch rule the reverse xmas tree is not documented. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04docs: netdev: document that patch series length limitJakub Kicinski1-0/+14
We had been asking people to avoid massive patch series but it does not appear in the FAQ. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04Merge branch 'mlxsw-unified-bridge-conversion-part-6'David S. Miller11-235/+829
Ido Schimmel says: ==================== mlxsw: Unified bridge conversion - part 6/6 This is the sixth and final part of the conversion of mlxsw to the unified bridge model. It transitions the last bits of functionality that were under firmware's responsibility in the legacy model to the driver. The last patches flip the driver to the unified bridge model and clean up code that was used to make the conversion easier to review. Patchset overview: Patch #1 sets the egress VID for known unicast packets. For multicast packets, the egress VID is configured using the MPE table. See commit 8c2da081c8b8 ("mlxsw: spectrum_fid: Configure egress VID classification for multicast"). Patch #2 configures the VNI to FID classification that is used during decapsulation. Patch #3 configures ingress router interface (RIF) in FID classification records, so that when a packet reaches the router block, its ingress RIF is known. Care is taken to configure this in all the different flows (e.g., RIF set on a FID, {Port, VID} joins a FID that already has a RIF etc.). Patch #4 configures the egress VID for routed packets. For such packets, the egress VID is not set by the MPE table or by an FDB record at the egress bridge, but instead by a dedicated table that maps {Egress RIF, Egress port} to a VID. Patch #5 removes VID configuration from RIF creation as in the unified bridge model firmware no longer needs it. Patch #6 sets the egress FID to use in RIF configuration so that the device knows using which FID to bridge the packet after routing. Patches #7-#9 add a new 802.1Q family and associated VLAN RIFs. In the unified bridge model, we no longer need to emulate 802.1Q FIDs using 802.1D FIDs as VNI can be associated with both. Patches #10-#11 finally flip the driver to the unified bridge model. Patches #12-#13 clean up code that was used to make the conversion easier to review. v2: * Fix build failure [1] in patch #1. [1] https://lore.kernel.org/netdev/20220630201709.6e66a1bb@kernel.org/ ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04mlxsw: spectrum_fid: Remove '_ub_' indication from structures and definesAmit Cohen1-47/+47
Some structures and defines were added with '_ub_' indication, as there were equivalent objects for the legacy model. Now when the legacy model is not used anymore, remove the '_ub_' indication. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04mlxsw: spectrum_fid: Remove flood_index() from FID operation structureAmit Cohen1-9/+1
The flood_index() function is not needed anymore, as in the unified bridge model the flood index is calculated using 'mid_base' and 'fid_offset'. Remove this function. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04mlxsw: Enable unified bridge modelAmit Cohen6-326/+77
After all the preparations for unified bridge model, finally flip mlxsw driver to use the new model. Change config profile, set 'ubridge' to true and remove the configurations that are relevant only for the legacy model. Set 'flood_mode' to 'controlled' as the current mode is not supported with unified bridge model. Remove all the code which is dedicated to the legacy model. Remove 'struct mlxsw_sp.ubridge' variable which was temporarily added to separate configurations between the models. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04mlxsw: Add ubridge to config profileAmit Cohen3-0/+20
The unified bridge model is enabled via the CONFIG_PROFILE command during driver initialization. Add the definition of the relevant fields to the command's payload in preparation for unified bridge enablement. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04mlxsw: Add support for 802.1Q FID familyAmit Cohen2-2/+193
Using the legacy bridge model, there is no VID classification at egress for 802.1Q FIDs, which means that the VID is maintained. This behavior cause the limitation that 802.1Q FIDs cannot work with VXLAN. This limitation stems from the fact that a decapsulated VXLAN packet should not contain a VLAN tag. If such a packet was to egress from a local port using a 802.1Q FID, it would "maintain" its VLAN on egress, which is no VLAN at all. Currently 802.1Q FIDs are emulated in mlxsw driver using 802.1D FIDs. Using unified bridge model, there is a FID->VID mapping, so it is possible to stop emulating 802.1Q FIDs. The main changes are: 1. Use 'SFGC.bridge_type' = 0, to separate between 802.1Q FIDs and 802.1D FIDs. 2. Use VLAN RIF instead of the emulated one (VLAN_EMU which is emulated using FID RIF). 3. Create VID->FID mapping when the FID is created. Then when a new port is mapped to the FID, if it not in virtual mode, no new mapping is needed. Save the new port in 'port_vid_list', to be able to update a RIF in all {Port, VID}->FID mappings in case that the port will be in virtual mode later. 4. Add a dedicated operation function per FID family to update RIF for VID->FID mappings. For 802.1d and rFID families, just return. For 802.1q family, handle the global mapping which is created for new 802.1q FID. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04mlxsw: Add new FID families for unified bridge modelAmit Cohen3-7/+189
In the unified bridge model, mlxsw will no longer emulate 802.1Q FIDs using 802.1D FIDs. The new FID table will look as follows: +---------------+ | 802.1q FIDs | 4K entries | [1..4094] | +---------------+ | 802.1d FIDs | 1K entries | [4095..5118] | +---------------+ | Dummy FIDs | 1 entry | [5119..5119] | +---------------+ | rFIDs | 11K entries | [5120..16383] | +---------------+ In order to make the change easier to review, four new temporary FID families will be added (e.g., MLXSW_SP_FID_TYPE_8021D_UB) and will not be registered with the FID core until mlxsw is flipped to use the unified bridge model. Add .1d, rfid and dummy FID families for unified bridge, the next patch will add .1q family separately as it requires more changes. The following changes are required: 1. Add 'smpe_index_valid' field to 'struct mlxsw_sp_fid_family' and set SFMR.smpe accordingly. SMPE index is reserved for rFIDs, as their flooding is handled by firmware, and always reserved in Spectrum-1, as it is configured as part of PGT table. 2. Add 'ubridge' field to 'struct mlxsw_sp_fid_family'. This field will be removed later, use it in mlxsw_sp_fid_family_{register,unregister}() to skip the registration / unregistration of the new families when the legacy model is used. 3. Indexes - the start and end indexes of each FID family will need to be changed according to the above diagram. 4. Add flood tables for unified bridge model, use 'fid_offset' as table type, as in the new model the access to flood tables will be using 'fid_offset' calculation. 5. FID family operation changes: a. rFID supposed to be created using SFMR, as it is not created by firmware using unified bridge model. b. port_vid_map() should perform SVFA for rFID, as the mapping is not created by firmware using unified bridge model. c. flood_index() is not aligned to the new model, as this function will be removed later. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04mlxsw: Add support for VLAN RIFsAmit Cohen2-0/+120
Router interfaces (RIFs) constructed on top of VLAN-aware bridges are of 'VLAN' type, whereas RIFs constructed on top of VLAN-unaware bridges are of 'FID' type. Currently 802.1Q FIDs are emulated using 802.1D FIDs, therefore VLAN RIFs are emulated using FID RIFs. As part of converting the driver to use unified bridge model, 802.1Q FIDs and VLAN RIFs will be used. The egress FID is required for VLAN RIFs in Spectrum-2 and above, but not in Spectrum-1, as in Spectrum-1 the mapping for VLAN RIFs is VID->FID, while in other ASICs it is FID->FID. The reason for the change is that it is more scalable to reuse the FID->FID entry than creating multiple {Port, VID}->FID entries for the router port. Use the existing operation structure to separate the configuration between different ASICs. Add support for VLAN RIFs, most of the configurations are same to FID RIFs. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04mlxsw: Configure egress FID classification after routingAmit Cohen2-1/+5
After routing, a packet needs to perform an L2 lookup using the DMAC it got from the routing and a FID. In unified bridge model, the egress FID configuration needs to be performed by software. It is configured by RITR for both sub-port RIFs and FID RIFs. Currently FID RIFs already configure eFID. Add eFID configuration for sub-port RIFs. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04mlxsw: spectrum_router: Do not configure VID for sub-port RIFsAmit Cohen1-1/+1
The field 'vid' in RITR is reserved when unified bridge model is used and the RIF's type is sub-port RIF. Instead, ingress VID is configured via SVFA and egress VID is configured via REIV. Set 'vid' to zero in RITR register for sub-port RIF when unified bridge model is used. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-07-04mlxsw: spectrum_fid: Configure layer 3 egress VID classificationAmit Cohen1-5/+137
After routing, the device always consults a table that determines the packet's egress VID based on {egress RIF, egress local port}. In the unified bridge model, it is up to software to maintain this table via REIV register. The table needs to be updated in the following flows: 1. When a RIF is set on a FID, need to iterate over the FID's {Port, VID} list and issue REIV write to map the {RIF, Port} to the given VID. 2. When a {Port, VID} is mapped to a FID and the FID already has a RIF, need to issue REIV write with a single record to map the {RIF, Port} to the given VID. REIV register supports a simultaneous update of 256 ports, so use this capability for the first flow. Handle the two above mentioned flows. Add mlxsw_sp_fid_evid_map() function to handle egress VID classification for both unicast and multicast. Layer 2 multicast configuration is already done in the driver, just move it to the new function. Signed-off-by: Amit Cohen <amcohen@nvidia.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Signed-off-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.