- 20 Nov, 2019 40 commits
-
-
YueHaibing authored
[ Upstream commit f03508ce ] The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, so make sure the implementation in this driver has returns 'netdev_tx_t' value, and change the function return type to netdev_tx_t. Found by coccinelle. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Antoine Tenart authored
[ Upstream commit 70afb58e ] The Marvell PPv2.2 engine only has 8 Rx queues per CPU, while PPv2.1 has 16 of them. This patch updates the code so that the Rx queues mask width is selected given the version of the network controller used. Signed-off-by:
Antoine Tenart <antoine.tenart@bootlin.com> Signed-off-by:
-
Andreas Kemnade authored
[ Upstream commit 079cdff3 ] This avoids getting woken up from suspend after power interruptions when the bci wrongly thinks the battery is full just because of input current going low because of low input power Signed-off-by:
Andreas Kemnade <andreas@kemnade.info> Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
-
Andreas Kemnade authored
[ Upstream commit 8314c212 ] the charging current uses unsigned int variables, if we step back if the current is still low, we would run into negative which means setting the target to a huge value. Better add checks here. Signed-off-by:
-
Rob Herring authored
[ Upstream commit 53dd9dce ] The next update of libfdt has a new dependency on INT_MAX. Update the instances of libfdt_env.h in the kernel to either include the necessary header with the definition or define it locally. Cc: Russell King <linux@armlinux.org.uk> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linux-arm-kernel@lists.infradead.org Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Rob Herring authored
[ Upstream commit 62287dce ] dtc has new checks for I2C buses. Fix the warnings in unit-addresses in the unittests. drivers/of/unittest-data/testcases.dtb: Warning (i2c_bus_reg): /testcase-data/overlay-node/test-bus/i2c-test-bus/test-unittest14/i2c@0/test-mux-dev: I2C bus unit address format error, expected "20" drivers/of/unittest-data/overlay_15.dtb: Warning (i2c_bus_reg): /fragment@0/__overlay__/test-unittest15/i2c@0/test-mux-dev: I2C bus unit address format error, expected "20" Cc: Frank Rowand <frowand.list@gmail.com> Signed-off-by:
-
Viresh Kumar authored
[ Upstream commit 3d255699 ] The dev_list needs to be protected with a lock, else we may have simultaneous access (addition/removal) to it and that would be racy. Extend scope of the opp_table lock to protect dev_list as well. Tested-by:
Niklas Cassel <niklas.cassel@linaro.org> Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Rob Herring authored
[ Upstream commit c890ecdb ] dtc has new checks for I2C and SPI buses. Fix the warnings in node names and unit-addresses. arch/arm/boot/dts/at91-dvk_som60.dtb: Warning (i2c_bus_reg): /ahb/apb/i2c@f0018000/eeprom@87: I2C bus unit address format error, expected "57" arch/arm/boot/dts/at91-dvk_som60.dtb: Warning (i2c_bus_reg): /ahb/apb/i2c@f0018000/ft5426@56: I2C bus unit address format error, expected "38" arch/arm/boot/dts/at91-vinco.dtb: Warning (i2c_bus_reg): /ahb/apb/i2c@f8024000/rtc@64: I2C bus unit address format error, expected "32" arch/arm/boot/dts/at91sam9260ek.dtb: Warning (spi_bus_reg): /ahb/apb/spi@fffc8000/mtd_dataflash@0: SPI bus unit address format error, expected "1" arch/arm/boot/dts/at91sam9g20ek_2mmc.dtb: Warning (spi_bus_reg): /ahb/apb/spi@fffc8000/mtd_dataflash@0: SPI bus unit address format error, expected "1" arch/arm/boot/dts/at91sam9g20ek.dtb: Warning (spi_bus_reg): /ahb/apb/spi@fffc8000/mtd_dataflash@0: SPI bus unit address format error, expected "1" arch/arm/boot/dts/at91sam9261ek.dtb: Warning (spi_bus_reg): /ahb/apb/spi@fffc8000/tsc2046@0: SPI bus unit address format error, expected "2" Signed-off-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
-
Håkon Bugge authored
[ Upstream commit 802fa45c ] Commit f27b4746 ("i40iw: add connection management code") uses an incorrect rcu iterator, whilst holding the rtnl_lock. Since the critical region invokes i40iw_manage_qhash(), which is a sleeping function, the rcu locking and traversal cannot be used. Signed-off-by:
Håkon Bugge <haakon.bugge@oracle.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Anton Blanchard authored
[ Upstream commit e00d93ac ] This re-applies commit b91c1e3e ("powerpc: Fix duplicate const clang warning in user access code") (Jun 2015) which was undone in commits: f2ca8090 ("powerpc/sparse: Constify the address pointer in __get_user_nosleep()") (Feb 2017) d466f6c5 ("powerpc/sparse: Constify the address pointer in __get_user_nocheck()") (Feb 2017) f84ed59a ("powerpc/sparse: Constify the address pointer in __get_user_check()") (Feb 2017) We see a large number of duplicate const errors in the user access code when building with llvm/clang: include/linux/pagemap.h:576:8: warning: duplicate 'const' declaration specifier [-Wduplicate-decl-specifier] ret = __get_user(c, uaddr); The problem is we are doing const __typeof__(*(ptr)), which will hit the warning if ptr is marked const. Removing const does not seem to have any effect on GCC code generation. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Joel Stanley <joel@jms.id.au> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Nathan Fontenot authored
[ Upstream commit 85a88cab ] When performing partition migrations all present CPUs must be online as all present CPUs must make the H_JOIN call as part of the migration process. Once all present CPUs make the H_JOIN call, one CPU is returned to make the rtas call to perform the migration to the destination system. During testing of migration and changing the SMT state we have found instances where CPUs are offlined, as part of the SMT state change, before they make the H_JOIN call. This results in a hung system where every CPU is either in H_JOIN or offline. To prevent this this patch disables CPU hotplug during the migration process. Signed-off-by:
Nathan Fontenot <nfont@linux.vnet.ibm.com> Reviewed-by:
Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Signed-off-by:
-
Nathan Fontenot authored
[ Upstream commit 063b8b12 ] The updates to powerpc numa and memory hotplug code now use the in-kernel LMB array instead of the device tree. This change allows the pseries memory DLPAR code to only update the device tree once after successfully handling a DLPAR request. Prior to the in-kernel LMB array, the numa code looked up the affinity for memory being added in the device tree, the code now looks this up in the LMB array. This change means the memory hotplug code can just update the affinity for an LMB in the LMB array instead of updating the device tree. This also provides a savings in kernel memory. When updating the device tree old properties are never free'ed since there is no usecount on properties. This behavior leads to a new copy of the property being allocated every time a LMB is added or removed (i.e. a request to add 100 LMBs creates 100 new copies of the property). With this update only a single new property is created when a DLPAR request completes successfully. Signed-off-by:
-
Nicholas Piggin authored
[ Upstream commit 09b4438d ] This causes SLB alloation to start 1 beyond the start of the SLB. There is no real problem because after it wraps it stats behaving properly, it's just surprisig to see when looking at SLB traces. Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> Signed-off-by:
-
Breno Leitao authored
[ Upstream commit 44d947ef ] There are cases where the test is not expecting to have the transaction aborted, but, the test process might have been rescheduled, either in the OS level or by KVM (if it is running on a KVM guest machine). The process reschedule will cause a treclaim/recheckpoint which will cause the transaction to doom, aborting the transaction as soon as the process is rescheduled back to the CPU. This might cause the test to fail, but this is not a failure in essence. If that is the case, TEXASR[FC] is indicated with either TM_CAUSE_RESCHEDULE or TM_CAUSE_KVM_RESCHEDULE for KVM interruptions. In this scenario, ignore these two failures and avoid the whole test to return failure. Signed-off-by:
Breno Leitao <leitao@debian.org> Reviewed-by:
Gustavo Romero <gromero@linux.ibm.com> Signed-off-by:
-
Breno Leitao authored
[ Upstream commit 984ecdd6 ] The tbl pointer is being derefenced by IOMMU_PAGE_SIZE prior the check if it is not NULL. Just moving the dereference code to after the check, where there will be guarantee that 'tbl' will not be NULL. Signed-off-by:
-
YueHaibing authored
[ Upstream commit 94b2bb28 ] The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, so make sure the implementation in this driver has returns 'netdev_tx_t' value, and change the function return type to netdev_tx_t. Found by coccinelle. Signed-off-by:
-
YueHaibing authored
[ Upstream commit ac1172de ] The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, so make sure the implementation in this driver has returns 'netdev_tx_t' value, and change the function return type to netdev_tx_t. Found by coccinelle. Signed-off-by:
-
YueHaibing authored
[ Upstream commit c9c39411 ] The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', which is a typedef for an enum type, also the implementation in this driver has returns 'netdev_tx_t' value, so just change the function return type to netdev_tx_t. Found by coccinelle. Signed-off-by:
-
YueHaibing authored
[ Upstream commit 060e8fb5 ] Fixes gcc '-Wunused-but-set-variable' warning: drivers/char/ipmi/ipmi_msghandler.c: In function 'ipmi_set_my_LUN': drivers/char/ipmi/ipmi_msghandler.c:1335:13: warning: variable 'rv' set but not used [-Wunused-but-set-variable] int index, rv = 0; 'rv' should be the correct return value. Fixes: 048f7c3e ("ipmi: Properly release srcu locks on error conditions") Signed-off-by:
Corey Minyard <cminyard@mvista.com> Signed-off-by:
-
Corey Minyard authored
[ Upstream commit 1574608f ] Looking at logs from systems all over the place, it looks like tons of broken systems exist that set the base address to zero. I can only guess that is some sort of non-standard idea to mark the interface as not being present. It can't be zero, anyway, so just complain and ignore it. Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 97a103e6 ] Shifting unsigned char b by an int type can lead to sign-extension overflow. For example, if b is 0xff and the shift is 24, then top bit is sign-extended so the final value passed to writeq has all the upper 32 bits set. Fix this by casting b to a 64 bit unsigned before the shift. Detected by CoverityScan, CID#1465246 ("Unintended sign extension") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Meelis Roos authored
[ Upstream commit 01508d9e ] I noticed that 4.17.0 logs the follwing during ipmi_si setup: ipmi_si 0000:01:04.6: probing via PCI (NULL device *): Could not setup I/O space ipmi_si 0000:01:04.6: [mem 0xf5ef0000-0xf5ef00ff] regsize 1 spacing 1 irq 21 Fix the "NULL device *) by moving io.dev assignment before its potential use by ipmi_pci_probe_regspacing(). Result: ipmi_si 0000:01:04.6: probing via PCI ipmi_si 0000:01:04.6: Could not setup I/O space ipmi_si 0000:01:04.6: [mem 0xf5ef0000-0xf5ef00ff] regsize 1 spacing 1 irq 21 Signed-off-by:
Meelis Roos <mroos@linux.ee> Signed-off-by:
-
Shuming Fan authored
[ Upstream commit 28b20dde ] This patch fixed the boost volume at the begining of playback while DAC volume set to lower level. Signed-off-by:
Shuming Fan <shumingf@realtek.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Peter Shih authored
[ Upstream commit 00bca73b ] Mediatek SPI driver modifies some fields (tx_buf, rx_buf, len, tx_dma, rx_dma) of the spi_transfer* passed in when doing transfer_one and in interrupt handler. This is somewhat unexpected, and there are some caller (e.g. Cr50 spi driver) that reuse the spi_transfer for multiple messages. Add a field to record how many bytes have been transferred, and calculate the right len / buffer based on it instead. Signed-off-by:
Pi-Hsun Shih <pihsun@chromium.org> Change-Id: I23e218cd964f16c0b2b26127d4a5ca6529867673 Signed-off-by:
-
Jonas Gorski authored
[ Upstream commit 0fd85869 ] If the pll clock needs to be enabled to get its rate, it will also need to be enabled to provide it. So ensure it is kept enabled through the lifetime of the device. Fixes: 0d7412ed ("spi/bcm63xx-hspi: Enable the clock before calling clk_get_rate().") Signed-off-by:
Jonas Gorski <jonas.gorski@gmail.com> Signed-off-by:
-
Yonghong Song authored
[ Upstream commit 534e0e52 ] samples/bpf build failed with the following errors: $ make samples/bpf/ ... HOSTCC samples/bpf/sockex3_user.o /data/users/yhs/work/net-next/samples/bpf/sockex3_user.c:16:8: error: redefinition of ‘struct bpf_flow_keys’ struct bpf_flow_keys { ^ In file included from /data/users/yhs/work/net-next/samples/bpf/sockex3_user.c:4:0: ./usr/include/linux/bpf.h:2338:9: note: originally defined here struct bpf_flow_keys *flow_keys; ^ make[3]: *** [samples/bpf/sockex3_user.o] Error 1 Commit d58e468b ("flow_dissector: implements flow dissector BPF hook") introduced struct bpf_flow_keys in include/uapi/linux/bpf.h and hence caused the naming conflict with samples/bpf/sockex3_user.c. The fix is to rename struct bpf_flow_keys in samples/bpf/sockex3_user.c to flow_keys to avoid the conflict. Signed-off-by:
Yonghong Song <yhs@fb.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Kishon Vijay Abraham I authored
[ Upstream commit 3bc15720 ] AM65 has two PCIe controllers and each PCIe controller has '2' address spaces one within the 4GB address space of the SoC and the other above the 4GB address space of the SoC (cbass_main) in addition to the register space. The size of the address space above the 4GB SoC address space is 4GB. These address ranges will be used by CPU/DMA to access the PCIe address space. In order to represent the address space above the 4GB SoC address space and to represent the size of this address space as 4GB, change address-cells and size-cells of interconnect to 2. Since OSPI has similar need in MCU Domain Memory Map, change address-cells and size-cells of cbass_mcu interconnect also to 2. Fixes: ea47eed3 ("arm64: dts: ti: Add Support for AM654 SoC") Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Acked-by:
Tony Lindgren <tony@atomide.com> Acked-by:
Vignesh R <vigneshr@ti.com> Acked-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Tero Kristo <t-kristo@ti.com> Signed-off-by:
-
Douglas Anderson authored
[ Upstream commit c362272b ] If you've got the "console" serial port setup to use just as a UART (AKA there is no "console=ttyMSMX" on the kernel command line) then certain initialization is skipped. When userspace later tries to do something with the port then things go boom (specifically, on my system, some sort of exception hit that caused the system to reboot itself w/ no error messages). Let's cleanup / refactor the init so that we always run the same init code regardless of whether we're using the console. To make this work, we make rely on qcom_geni_serial_pm doing its job to turn resources on. For the record, here is a trace of the order of things (after this patch) when console= is specified on the command line and we have an agetty on the port: qcom_geni_serial_pm: 4 (undefined) => 0 (on) qcom_geni_console_setup qcom_geni_serial_port_setup qcom_geni_serial_console_write qcom_geni_serial_startup qcom_geni_serial_start_tx ...and here is the order of things (after this patch) when console= is _NOT_ specified on the command line and we have an agetty port: qcom_geni_serial_pm: 4 => 0 qcom_geni_serial_pm: 0 => 3 qcom_geni_serial_pm: 3 => 0 qcom_geni_serial_startup qcom_geni_serial_port_setup qcom_geni_serial_pm: 0 => 3 qcom_geni_serial_pm: 3 => 0 qcom_geni_serial_startup qcom_geni_serial_start_tx Fixes: c4f52879 ("tty: serial: msm_geni_serial: Add serial driver support for GENI based QUP") Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Matthias Kaehlcke <mka@chromium.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Anton Vasilyev authored
[ Upstream commit 5963e8a3 ] On the error path of mxs_auart_request_gpio_irq() is performed backward iterating with index i of enum type. Underline enum type may be unsigned char. In this case check (--i >= 0) will be always true and error handling goes into infinite loop. The patch changes the check so that it is valid for signed and unsigned types. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Anton Vasilyev <vasilyev@ispras.ru> Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Marek Szyprowski authored
[ Upstream commit 1ff3652b ] Ensure that the baud clock is also enabled for UART register writes in driver resume. On Exynos5433 SoC this is needed to avoid external abort issue. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Nava kishore Manne authored
[ Upstream commit 4b9d33c6 ] The driver's suspend/resume functions were buggy. If UART node contains any child node in the DT and the child is established a communication path with the parent UART. The relevant /dev/ttyPS* node will be not available for other operations. If the driver is trying to do any operations like suspend/resume without checking the tty->dev status it leads to the kernel crash/hang. This patch fix this issue by call the device_may_wake() with the generic parameter of type struct device. in the uart suspend and resume paths. It also fixes a race condition in the uart suspend path(i.e uart_suspend_port() should be called at the end of cdns_uart_suspend API this path updates the same) Signed-off-by:
Nava kishore Manne <navam@xilinx.com> Signed-off-by:
Michal Simek <michal.simek@xilinx.com> Signed-off-by:
-
Rob Herring authored
[ Upstream commit f5054cee ] dtc has new checks for I2C and SPI buses. Fix the warnings in node names and unit-addresses. arch/arm/boot/dts/zynq-zc702.dtb: Warning (i2c_bus_reg): /amba/i2c@e0004000/i2c-mux@74/i2c@7/hwmon@52: I2C bus unit address format error, expected "34" arch/arm/boot/dts/zynq-zc702.dtb: Warning (i2c_bus_reg): /amba/i2c@e0004000/i2c-mux@74/i2c@7/hwmon@53: I2C bus unit address format error, expected "35" arch/arm/boot/dts/zynq-zc702.dtb: Warning (i2c_bus_reg): /amba/i2c@e0004000/i2c-mux@74/i2c@7/hwmon@54: I2C bus unit address format error, expected "36" arch/arm/boot/dts/zynq-zc770-xm013.dtb: Warning (spi_bus_reg): /amba/spi@e0006000/eeprom@0: SPI bus unit address format error, expected "2" arch/arm/boot/dts/zynq-zc770-xm010.dtb: Warning (spi_bus_reg): /amba/spi@e0007000/flash@0: SPI bus unit address format error, expected "1" Cc: Michal Simek <michal.simek@xilinx.com> Signed-off-by:
-
Gustavo A. R. Silva authored
[ Upstream commit 17a0a1e5 ] Check return value of devm_pci_remap_iospace(). Addresses-Coverity-ID: 1471965 ("Unchecked return value") Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by:
Honghui Zhang <honghui.zhang@mediatek.com> Signed-off-by:
-
Jia-Ju Bai authored
[ Upstream commit 0020f5c8 ] The driver may sleep with holding a spinlock. The function call paths (from bottom to top) in Linux-4.17 are: [FUNC] usleep_range drivers/net/ethernet/socionext/sni_ave.c, 892: usleep_range in ave_rxfifo_reset drivers/net/ethernet/socionext/sni_ave.c, 932: ave_rxfifo_reset in ave_irq_handler [FUNC] usleep_range drivers/net/ethernet/socionext/sni_ave.c, 888: usleep_range in ave_rxfifo_reset drivers/net/ethernet/socionext/sni_ave.c, 932: ave_rxfifo_reset in ave_irq_handler To fix these bugs, usleep_range() is replaced with udelay(). These bugs are found by my static analysis tool DSAC. Signed-off-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by:
-
Sinan Kaya authored
[ Upstream commit 1ad61b61 ] If _OSC execution fails today for platforms without an _OSC entry, code is printing a misleading message saying disabling ASPM as follows: acpi PNP0A03:00: _OSC failed (AE_NOT_FOUND); disabling ASPM We need to ensure that platform supports ASPM to begin with. Reported-by:
Michael Kelley <mikelley@microsoft.com> Signed-off-by:
Sinan Kaya <okaya@kernel.org> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Javier Martinez Canillas authored
[ Upstream commit b7a41762 ] The driver registers the v4l2 subdevice before attempting to power on the chip and checking its ID. This means that a media device driver that it's waiting for this subdevice to be bound, will prematurely expose its media device node to userspace because if something goes wrong the media entity will be cleaned up again on the ov2680 probe function. This also simplifies the probe function error path since no initialization is made before attempting to enable the resources or checking the chip ID. Fixes: 3ee47cad ("media: ov2680: Add Omnivision OV2680 sensor driver") Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Koji Matsuoka authored
[ Upstream commit 9b2798d5 ] YCbCr planar formats can have different pitch values for the luma and chroma planes. This isn't taken into account in the driver. Fix it. Based on a BSP patch from Koji Matsuoka <koji.matsuoka.xm@renesas.com>. Fixes: 7863ac50 ("drm: rcar-du: Add tri-planar memory formats support") [Updated documentation of the struct vsp1_du_atomic_config pitch field] Signed-off-by:
Koji Matsuoka <koji.matsuoka.xm@renesas.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
Laurent Pinchart authored
[ Upstream commit 5eea860a ] All source files of the vsp1 driver are licensed under the GPLv2+ except for vsp1_regs.h which is licensed under GPLv2. This is caused by a bad copy&paste that dates back from the initial version of the driver. Fix it. Acked-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Acked-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Acked-by:
Nobuhiro Iwamatsu <iwamatsu@nigauri.org> Signed-off-by:
-
Julian Wiedmann authored
[ Upstream commit 4d19db77 ] Calling napi_schedule() from process context does not ensure that the NET_RX softirq is run in a timely fashion. So trigger it manually. This is no big issue with current code. A call to ndo_open() is usually followed by a ndo_set_rx_mode() call, and for qeth this contains a spin_unlock_bh(). Except for OSN, where qeth_l2_set_rx_mode() bails out early. Nevertheless it's best to not depend on this behaviour, and just fix the issue at its source like all other drivers do. For instance see commit 83a0c6e5 ("i40e: Invoke softirqs after napi_reschedule"). Fixes: a1c3ed4c ("qeth: NAPI support for l2 and l3 discipline") Signed-off-by:
Julian Wiedmann <jwi@linux.ibm.com> Signed-off-by:
-
Julian Wiedmann authored
[ Upstream commit 121ca39a ] When setting up, qeth installs its IRQ handler on the ccw devices. But the IRQ handler is not cleared on removal - so even after qeth yields control of the ccw devices, spurious interrupts would still be presented to us. Make (de-)installation of the IRQ handler part of the ccw channel setup/removal helpers, and while at it also add the appropriate locking. Shift around qeth_setup_channel() to avoid a forward declaration for qeth_irq(). Signed-off-by:
-
