aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2022-04-17net: dsa: qca8k: drop port_sts from qca8k_privAnsuel Smith2-11/+13
Port_sts is a thing of the past for this driver. It was something present on the initial implementation of this driver and parts of the original struct were dropped over time. Using an array of int to store if a port is enabled or not to handle PM operation seems overkill. Switch and use a simple u8 to store the port status where each bit correspond to a port. (bit is set port is enabled, bit is not set, port is disabled) Also add some comments to better describe why we need to track port status. Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-17net: dsa: qca8k: drop MTU tracking from qca8k_privAnsuel Smith2-18/+9
DSA set the CPU port based on the largest MTU of all the slave ports. Based on this we can drop the MTU array from qca8k_priv and set the port_change_mtu logic on DSA changing MTU of the CPU port as the switch have a global MTU settingfor each port. Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-04-16Merge tag 'gpio-fixes-for-v5.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linuxLinus Torvalds2-12/+14
Pull gpio fixes from Bartosz Golaszewski: "A single fix for gpio-sim and two patches for GPIO ACPI pulled from Andy: - fix the set/get_multiple() callbacks in gpio-sim - use correct format characters in gpiolib-acpi - use an unsigned type for pins in gpiolib-acpi" * tag 'gpio-fixes-for-v5.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux: gpio: sim: fix setting and getting multiple lines gpiolib: acpi: Convert type for pin to be unsigned gpiolib: acpi: use correct format characters
2022-04-16Merge tag 'soc-fixes-5.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/socLinus Torvalds8-18/+47
Pull ARM SoC fixes from Arnd Bergmann: "There are a number of SoC bugfixes that came in since the merge window, and more of them are already pending. This batch includes: - A boot time regression fix for davinci that triggered on multi_v5_defconfig when booting any platform - Defconfig updates to address removed features, changed symbol names or dependencies, for gemini, ux500, and pxa - Email address changes for Krzysztof Kozlowski - Build warning fixes for ep93xx and iop32x - Devicetree warning fixes across many platforms - Minor bugfixes for the reset controller, memory controller and SCMI firmware subsystems plus the versatile-express board" * tag 'soc-fixes-5.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (34 commits) ARM: config: Update Gemini defconfig arm64: dts: qcom/sdm845-shift-axolotl: Fix boolean properties with values ARM: dts: align SPI NOR node name with dtschema ARM: dts: Fix more boolean properties with values arm/arm64: dts: qcom: Fix boolean properties with values arm64: dts: imx: Fix imx8*-var-som touchscreen property sizes arm: dts: imx: Fix boolean properties with values arm64: dts: tegra: Fix boolean properties with values arm: dts: at91: Fix boolean properties with values arm: configs: imote2: Drop defconfig as board support dropped. ep93xx: clock: Don't use plain integer as NULL pointer ep93xx: clock: Fix UAF in ep93xx_clk_register_gate() ARM: vexpress/spc: Fix all the kernel-doc build warnings ARM: vexpress/spc: Fix kernel-doc build warning for ve_spc_cpu_in_wfi ARM: config: u8500: Re-enable AB8500 battery charging ARM: config: u8500: Add some common hardware memory: fsl_ifc: populate child nodes of buses and mfd devices ARM: config: Refresh U8500 defconfig firmware: arm_scmi: Fix sparse warnings in OPTEE transport driver firmware: arm_scmi: Replace zero-length array with flexible-array member ...
2022-04-16Merge tag 'random-5.18-rc3-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/crng/randomLinus Torvalds1-24/+20
Pull random number generator fixes from Jason Donenfeld: - Per your suggestion, random reads now won't fail if there's a page fault after some non-zero amount of data has been read, which makes the behavior consistent with all other reads in the kernel. - Rather than an inconsistent mix of random_get_entropy() returning an unsigned long or a cycles_t, now it just returns an unsigned long. - A memcpy() was replaced with an memmove(), because the addresses are sometimes overlapping. In practice the destination is always before the source, so not really an issue, but better to be correct than not. * tag 'random-5.18-rc3-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/crng/random: random: use memmove instead of memcpy for remaining 32 bytes random: make random_get_entropy() return an unsigned long random: allow partial reads if later user copies fail
2022-04-16lkdtm: Add CFI_BACKWARD to test ROP mitigationsKees Cook1-0/+134
In order to test various backward-edge control flow integrity methods, add a test that manipulates the return address on the stack. Currently only arm64 Pointer Authentication and Shadow Call Stack is supported. $ echo CFI_BACKWARD | cat >/sys/kernel/debug/provoke-crash/DIRECT Under SCS, successful test of the mitigation is reported as: lkdtm: Performing direct entry CFI_BACKWARD lkdtm: Attempting unchecked stack return address redirection ... lkdtm: ok: redirected stack return address. lkdtm: Attempting checked stack return address redirection ... lkdtm: ok: control flow unchanged. Under PAC, successful test of the mitigation is reported by the PAC exception handler: lkdtm: Performing direct entry CFI_BACKWARD lkdtm: Attempting unchecked stack return address redirection ... lkdtm: ok: redirected stack return address. lkdtm: Attempting checked stack return address redirection ... Unable to handle kernel paging request at virtual address bfffffc0088d0514 Mem abort info: ESR = 0x86000004 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault [bfffffc0088d0514] address between user and kernel address ranges ... If the CONFIGs are missing (or the mitigation isn't working), failure is reported as: lkdtm: Performing direct entry CFI_BACKWARD lkdtm: Attempting unchecked stack return address redirection ... lkdtm: ok: redirected stack return address. lkdtm: Attempting checked stack return address redirection ... lkdtm: FAIL: stack return address was redirected! lkdtm: This is probably expected, since this kernel was built *without* CONFIG_ARM64_PTR_AUTH_KERNEL=y nor CONFIG_SHADOW_CALL_STACK=y Co-developed-by: Dan Li <ashimida@linux.alibaba.com> Signed-off-by: Dan Li <ashimida@linux.alibaba.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/lkml/20220416001103.1524653-1-keescook@chromium.org
2022-04-16Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds9-306/+271
Pull SCSI fixes from James Bottomley: "13 fixes, all in drivers. The most extensive changes are in the iscsi series (affecting drivers qedi, cxgbi and bnx2i), the next most is scsi_debug, but that's just a simple revert and then minor updates to pm80xx" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: iscsi: MAINTAINERS: Add Mike Christie as co-maintainer scsi: qedi: Fix failed disconnect handling scsi: iscsi: Fix NOP handling during conn recovery scsi: iscsi: Merge suspend fields scsi: iscsi: Fix unbound endpoint error handling scsi: iscsi: Fix conn cleanup and stop race during iscsid restart scsi: iscsi: Fix endpoint reuse regression scsi: iscsi: Release endpoint ID when its freed scsi: iscsi: Fix offload conn cleanup when iscsid restarts scsi: iscsi: Move iscsi_ep_disconnect() scsi: pm80xx: Enable upper inbound, outbound queues scsi: pm80xx: Mask and unmask upper interrupt vectors 32-63 Revert "scsi: scsi_debug: Address races following module load"
2022-04-16Merge tag 'intel-gpio-v5.18-2' of gitolite.kernel.org:pub/scm/linux/kernel/git/andy/linux-gpio-intel into gpio/for-currentBartosz Golaszewski1-10/+12
intel-gpio for v5.18-2 * Couple of fixes related to handling unsigned value of the pin from ACPI gpiolib: - acpi: Convert type for pin to be unsigned - acpi: use correct format characters
2022-04-16iio: imu: inv_icm42600: Fix I2C init possible nackFawzi Khaber1-6/+9
This register write to REG_INTF_CONFIG6 enables a spike filter that is impacting the line and can prevent the I2C ACK to be seen by the controller. So we don't test the return value. Fixes: 7297ef1e261672b8 ("iio: imu: inv_icm42600: add I2C driver") Signed-off-by: Fawzi Khaber <fawzi.khaber@tdk.com> Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol@tdk.com> Link: https://lore.kernel.org/r/20220411111533.5826-1-jmaneyrol@invensense.com Cc: <Stable@vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-16iio: dac: ltc2688: fix voltage scale readNuno Sá1-1/+1
Properly set *val2 (and not overwrite *val) to correctly return IIO_VAL_FRACTIONAL_LOG2. Fixes: 832cb9eeb9312 ("iio: dac: add support for ltc2688") Signed-off-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20220412124916.61-1-nuno.sa@analog.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2022-04-16random: use memmove instead of memcpy for remaining 32 bytesJason A. Donenfeld1-1/+1
In order to immediately overwrite the old key on the stack, before servicing a userspace request for bytes, we use the remaining 32 bytes of block 0 as the key. This means moving indices 8,9,a,b,c,d,e,f -> 4,5,6,7,8,9,a,b. Since 4 < 8, for the kernel implementations of memcpy(), this doesn't actually appear to be a problem in practice. But relying on that characteristic seems a bit brittle. So let's change that to a proper memmove(), which is the by-the-books way of handling overlapping memory copies. Reviewed-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
2022-04-15drm/i915/hwconfig: Add DG2 supportRodrigo Vivi1-0/+2
v2: * Jordan: Drop stepping/skew checking as suggested by John. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Tested-by: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331231737.315957-1-jordan.l.justen@intel.com
2022-04-15Merge tag 'for-5.18/dm-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dmLinus Torvalds4-40/+45
Pull device mapper fixes from Mike Snitzer: - Fix memory corruption in DM integrity target when tag_size is less than digest size. - Fix DM multipath's historical-service-time path selector to not use sched_clock() and ktime_get_ns(); only use ktime_get_ns(). - Fix dm_io->orig_bio NULL pointer dereference in dm_zone_map_bio() due to 5.18 changes that overlooked DM zone's use of ->orig_bio - Fix for regression that broke the use of dm_accept_partial_bio() for "abnormal" IO (e.g. WRITE ZEROES) that does not need duplicate bios - Fix DM's issuing of empty flush bio so that it's size is 0. * tag 'for-5.18/dm-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: dm: fix bio length of empty flush dm: allow dm_accept_partial_bio() for dm_io without duplicate bios dm zone: fix NULL pointer dereference in dm_zone_map_bio dm mpath: only use ktime_get_ns() in historical selector dm integrity: fix memory corruption when tag_size is less than digest size
2022-04-15i2c: ismt: Fix undefined behavior due to shift overflowing the constantBorislav Petkov1-2/+2
Fix: drivers/i2c/busses/i2c-ismt.c: In function ‘ismt_hw_init’: drivers/i2c/busses/i2c-ismt.c:770:2: error: case label does not reduce to an integer constant case ISMT_SPGT_SPD_400K: ^~~~ drivers/i2c/busses/i2c-ismt.c:773:2: error: case label does not reduce to an integer constant case ISMT_SPGT_SPD_1M: ^~~~ See https://lore.kernel.org/r/YkwQ6%2BtIH8GQpuct@zn.tnic for the gory details as to why it triggers with older gccs only. Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Seth Heasley <seth.heasley@intel.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-04-15i2c: meson: Use 50% duty cycle for I2C clockLucas Tanure1-10/+60
The duty cycle of 33% is less than the required by the I2C specs for the LOW period of the SCL clock. Move the duty cyle to 50% for 100Khz or lower clocks, and (40% High SCL / 60% Low SCL) duty cycle for clocks above 100Khz. Signed-off-by: Lucas Tanure <tanure@linux.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-04-15i2c: meson: Use _SHIFT and _MASK for register definitionsLucas Tanure1-18/+21
Differentiate between masks and shifts Signed-off-by: Lucas Tanure <tanure@linux.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-04-15drm/i915: Don't show engine information in fdinfo with GuC submissionAshutosh Dixit1-1/+5
At present i915 does not fetch busyness information from GuC, resulting in incorrect busyness values in fdinfo. Because engine information is coupled with busyness in fdinfo, skip showing client engine information in fdinfo with GuC submission till fetching busyness is supported in the i915 GuC submission backend. v2 (Daniele): Make commit title and description more precise Add FIXME with brief description at code change s/intel_guc_submission_is_used/intel_uc_uses_guc_submission/ v3 (Daniele): Drop FIXME in comment Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/5564 Fixes: 055634e4b62f ("drm/i915: Expose client engine utilisation via fdinfo") Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b614c2c61a954de06fbe2c3a7c70d3a91804407e.1649982207.git.ashutosh.dixit@intel.com
2022-04-15i2c: rcar: add support for I2C_M_RECV_LENWolfram Sang1-4/+27
With this feature added, SMBus Block reads and Proc calls are now supported. This patch is the best of two independent developments by Wolfram and Bhuvanesh + Andrew, refactored again by Wolfram. Signed-off-by: Bhuvanesh Surachari <bhuvanesh_surachari@mentor.com> Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Eugeniu Rosca <erosca@de.adit-jv.com> Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-04-15i2c: dev: Force case user pointers in compat_i2cdev_ioctl()Andy Shevchenko1-1/+1
Sparse has warned us about wrong address space for user pointers: i2c-dev.c:561:50: warning: incorrect type in initializer (different address spaces) i2c-dev.c:561:50: expected unsigned char [usertype] *buf i2c-dev.c:561:50: got void [noderef] __user * Force cast the pointer to (__u8 *) that is used by I²C core code. Note, this is an additional fix to the previously addressed similar issue in the I2C_RDWR case in the same function. Fixes: 3265a7e6b41b ("i2c: dev: Add __user annotation") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-04-15net: lan966x: Make sure to release ptp interruptHoratiu Vultur1-0/+3
When the lan966x driver is removed make sure to remove also the ptp_irq IRQ. Fixes: e85a96e48e3309 ("net: lan966x: Add support for ptp interrupts") Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com> Link: https://lore.kernel.org/r/20220413195716.3796467-1-horatiu.vultur@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-04-15net: Handle l3mdev in ip_tunnel_init_flowDavid Ahern1-1/+1
Ido reported that the commit referenced in the Fixes tag broke a gre use case with dummy devices. Add a check to ip_tunnel_init_flow to see if the oif is an l3mdev port and if so set the oif to 0 to avoid the oif comparison in fib_lookup_good_nhc. Fixes: 40867d74c374 ("net: Add l3mdev index to flow struct and avoid oif reset for port devices") Reported-by: Ido Schimmel <idosch@idosch.org> Signed-off-by: David Ahern <dsahern@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-04-15Merge branch '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queueJakub Kicinski4-7/+27
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2022-04-13 This series contains updates to igc and e1000e drivers. Sasha removes waiting for hardware semaphore as it could cause an infinite loop and changes usleep_range() calls done under atomic context to udelay() for igc. For e1000e, he changes some variables from u16 to u32 to prevent possible overflow of values. Vinicius disables PTM when going to suspend as it is causing hang issues on some platforms for igc. * '1GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: e1000e: Fix possible overflow in LTR decoding igc: Fix suspending when PTM is active igc: Fix BUG: scheduling while atomic igc: Fix infinite loop in release_swfw_sync ==================== Link: https://lore.kernel.org/r/20220413170814.2066855-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-04-15i2c: dev: check return value when calling dev_set_name()Andy Shevchenko1-5/+10
If dev_set_name() fails, the dev_name() is null, check the return value of dev_set_name() to avoid the null-ptr-deref. Fixes: 1413ef638aba ("i2c: dev: Fix the race between the release of i2c_dev and cdev") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-04-15i2c: qcom-geni: Use dev_err_probe() for GPI DMA errorBjorn Andersson1-4/+2
The GPI DMA engine driver can be compiled as a module, in which case the likely probe deferral "error" shows up in the kernel log. Switch to using dev_err_probe() to silence this warning and to ensure that "devices_deferred" in debugfs carries this information. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-04-15i2c: imx: Implement errata ERR007805 or e7805 bus frequency limitMarek Vasut1-0/+33
The i.MX8MP Mask Set Errata for Mask 1P33A, Rev. 2.0 has description of errata ERR007805 as below. This errata is found on all MX8M{M,N,P,Q}, MX7{S,D}, MX6{UL{,L,Z},S{,LL,X},S,D,DL,Q,DP,QP} . MX7ULP, MX8Q, MX8X are not affected. MX53 and older status is unknown, as the errata first appears in MX6 errata sheets from 2016 and the latest errata sheet for MX53 is from 2015. Older SoC errata sheets predate the MX53 errata sheet. MX8ULP and MX9 status is unknown as the errata sheet is not available yet. " ERR007805 I2C: When the I2C clock speed is configured for 400 kHz, the SCL low period violates the I2C spec of 1.3 uS min Description: When the I2C module is programmed to operate at the maximum clock speed of 400 kHz (as defined by the I2C spec), the SCL clock low period violates the I2C spec of 1.3 uS min. The user must reduce the clock speed to obtain the SCL low time to meet the 1.3us I2C minimum required. This behavior means the SoC is not compliant to the I2C spec at 400kHz. Workaround: To meet the clock low period requirement in fast speed mode, SCL must be configured to 384KHz or less. " Implement the workaround by matching on the affected SoC specific compatible strings and by limiting the maximum bus frequency in case the SoC is affected. Signed-off-by: Marek Vasut <marex@denx.de> To: linux-i2c@vger.kernel.org Acked-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-04-15i2c: pasemi: Wait for write xfers to finishMartin Povišer1-0/+6
Wait for completion of write transfers before returning from the driver. At first sight it may seem advantageous to leave write transfers queued for the controller to carry out on its own time, but there's a couple of issues with it: * Driver doesn't check for FIFO space. * The queued writes can complete while the driver is in its I2C read transfer path which means it will get confused by the raising of XEN (the 'transaction ended' signal). This can cause a spurious ENODATA error due to premature reading of the MRXFIFO register. Adding the wait fixes some unreliability issues with the driver. There's some efficiency cost to it (especially with pasemi_smb_waitready doing its polling), but that will be alleviated once the driver receives interrupt support. Fixes: beb58aa39e6e ("i2c: PA Semi SMBus driver") Signed-off-by: Martin Povišer <povik+lin@cutebit.org> Reviewed-by: Sven Peter <sven@svenpeter.dev> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-04-15octeon_ep: Remove custom driver versionLeon Romanovsky3-23/+1
In review comment [1] was pointed that new code is not supposed to set driver version and should rely on kernel version instead. As an outcome of that comment all the dance around setting such driver version to FW should be removed too, because in upstream kernel whole driver will have same version so read/write from/to FW will give same result. [1] https://lore.kernel.org/all/YladGTmon1x3dfxI@unreal Fixes: 862cd659a6fb ("octeon_ep: Add driver framework and device initialization") Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Link: https://lore.kernel.org/r/5d76f3116ee795071ec044eabb815d6c2bdc7dbd.1649922731.git.leonro@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-04-15ibmvnic: Allow multiple ltbs in txpool ltb_setSukadev Bhattiprolu2-20/+35
Allow multiple LTBs in the txpool's ltb_set. i.e rather than using a single large LTB, use several smaller LTBs. The first n-1 LTBs will all be of the same size. The size of the last LTB in the set depends on the number of buffers and buffer (mtu) size. This strategy hopefully allows more reuse of the initial LTBs and also reduces the chances of an allocation failure (of the large LTB) when system is low in memory. Suggested-by: Brian King <brking@linux.ibm.com> Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com> Signed-off-by: Dany Madden <drt@linux.ibm.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-04-15ibmvnic: Allow multiple ltbs in rxpool ltb_setSukadev Bhattiprolu2-20/+177
Allow multiple LTBs in the rxpool's ltb_set. The first n-1 LTBs will all be of the same size. The size of the last LTB in the set depends on the number of buffers and buffer (mtu) size. Having a set of LTBs per pool provides a couple of benefits. First, with the current value of IBMVNIC_MAX_LTB_SIZE of 16MB, with an MTU of 9000, we need a LTB (DMA buffer) of that size but the allocation can fail in low memory conditions. With a set of LTBs per pool, we can use several smaller (8MB) LTBs and hopefully have fewer allocation failures. (See also comments in ibmvnic.h on the trade-off with smaller LTBs) Second since the kernel limits the size of the DMA buffer to 16MB (based on MAX_ORDER), with a single DMA buffer per pool, the pool is also limited to 16MB. This in turn limits the number of buffers per pool to 1763 when MTU is 9000. With a set of LTBs per pool, we can have upto the max of 4096 buffers per pool even when MTU is 9000. Suggested-by: Brian King <brking@linux.ibm.com> Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com> Signed-off-by: Dany Madden <drt@linux.ibm.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-04-15ibmvnic: convert rxpool ltb to a set of ltbsSukadev Bhattiprolu2-6/+45
Define and use interfaces that treat the long term buffer (LTB) of an rxpool as a set of LTBs rather than a single LTB. The set only has one LTB for now. Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com> Signed-off-by: Dany Madden <drt@linux.ibm.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-04-15ibmvnic: define map_txpool_buf_to_ltb()Sukadev Bhattiprolu1-4/+25
Define a helper to map a given txpool buffer into its corresponding long term buffer (LTB) and offset. Currently there is just one LTB per txpool so the mapping is trivial. When we add support for multiple LTBs per txpool, this helper will be more useful. Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com> Signed-off-by: Dany Madden <drt@linux.ibm.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-04-15ibmvnic: define map_rxpool_buf_to_ltb()Sukadev Bhattiprolu1-4/+24
Define a helper to map a given rx pool buffer into its corresponding long term buffer (LTB) and offset. Currently there is just one LTB per pool so the mapping is trivial. When we add support for multiple LTBs per pool, this helper will be more useful. Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com> Signed-off-by: Dany Madden <drt@linux.ibm.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-04-15ibmvnic: rename local variable index to bufidxSukadev Bhattiprolu1-22/+22
The local variable 'index' is heavily used in some functions and is confusing with the presence of other "index" fields like pool->index, ->consumer_index, etc. Rename it to bufidx to better reflect that its the index of a buffer in the pool. Signed-off-by: Sukadev Bhattiprolu <sukadev@linux.ibm.com> Signed-off-by: Dany Madden <drt@linux.ibm.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-04-15dm: fix bio length of empty flushShin'ichiro Kawasaki1-0/+1
The commit 92986f6b4c8a ("dm: use bio_clone_fast in alloc_io/alloc_tio") removed bio_clone_fast() call from alloc_tio() when ci->io->tio is available. In this case, ci->bio is not copied to ci->io->tio.clone. This is fine since init_clone_info() sets same values to ci->bio and ci->io->tio.clone. However, when incoming bios have REQ_PREFLUSH flag, __send_empty_flush() prepares a zero length bio on stack and set it to ci->bio. At this time, ci->io->tio.clone still keeps non-zero length. When alloc_tio() chooses this ci->io->tio.clone as the bio to map, it is passed to targets as non-empty flush bio. It causes bio length check failure in dm-zoned and unexpected operation such as dm_accept_partial_bio() call. To avoid the non-empty flush bio, set zero length to ci->io->tio.clone in __send_empty_flush(). Fixes: 92986f6b4c8a ("dm: use bio_clone_fast in alloc_io/alloc_tio") Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com> Signed-off-by: Mike Snitzer <snitzer@kernel.org>
2022-04-15drm/i915/guc/slpc: Use i915_probe_error instead of drm_errVinay Belgaumkar1-21/+21
This will ensure we don't have false positives when we run error injection tests. Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220412224852.21501-1-vinay.belgaumkar@intel.com
2022-04-15soc: ti: knav_dma: Use pm_runtime_resume_and_get instead of pm_runtime_get_syncMinghao Chi1-2/+1
Using pm_runtime_resume_and_get is more appropriate for simplifying code. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com> Link: https://lore.kernel.org/r/20220412082923.2532649-1-chi.minghao@zte.com.cn
2022-04-15reset: ti-sci: Allow building under COMPILE_TESTPhilipp Zabel1-1/+1
Since commit 043cfff99a18 ("firmware: ti_sci: Fix compilation failure when CONFIG_TI_SCI_PROTOCOL is not defined") it is possible to build reset-ti-sci under CONFIG_COMPILE_TEST. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20220404094500.2708816-1-p.zabel@pengutronix.de
2022-04-15soc: ti: ti_sci_pm_domains: Check for null return of devm_kcallocQintaoShen1-0/+2
The allocation funciton devm_kcalloc may fail and return a null pointer, which would cause a null-pointer dereference later. It might be better to check it and directly return -ENOMEM just like the usage of devm_kcalloc in previous code. Signed-off-by: QintaoShen <unSimple1993@163.com> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/1648107843-29077-1-git-send-email-unSimple1993@163.com
2022-04-15soc: ti: omap_prm: Use of_device_get_match_data()Minghao Chi (CGEL ZTE)1-5/+2
Since omap_prm_id_table all have (and expected to have) data entries, use of_device_get_match_data() to simplify the code. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi (CGEL ZTE) <chi.minghao@zte.com.cn> Signed-off-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20220307033736.2075221-1-chi.minghao@zte.com.cn
2022-04-15ice, xsk: Avoid refilling single Rx descriptorsMaciej Fijalkowski1-1/+4
Call alloc Rx routine for ZC driver only when the amount of unallocated descriptors exceeds given threshold. Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20220413153015.453864-14-maciej.fijalkowski@intel.com
2022-04-15stmmac, xsk: Diversify return values from xsk_wakeup call pathsMaciej Fijalkowski1-2/+2
Currently, when debugging AF_XDP workloads, one can correlate the -ENXIO return code as the case that XSK is not in the bound state. Returning same code from ndo_xsk_wakeup can be misleading and simply makes it harder to follow what is going on. Change ENXIOs in stmmac's ndo_xsk_wakeup() implementation to EINVALs, so that when probing it is clear that something is wrong on the driver side, not the xsk_{recv,send}msg. There is a -ENETDOWN that can happen from both kernel/driver sides though, but I don't have a correct replacement for this on one of the sides, so let's keep it that way. Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20220413153015.453864-13-maciej.fijalkowski@intel.com
2022-04-15mlx5, xsk: Diversify return values from xsk_wakeup call pathsMaciej Fijalkowski1-1/+1
Currently, when debugging AF_XDP workloads, one can correlate the -ENXIO return code as the case that XSK is not in the bound state. Returning same code from ndo_xsk_wakeup can be misleading and simply makes it harder to follow what is going on. Change ENXIO in mlx5's ndo_xsk_wakeup() implementation to EINVAL, so that when probing it is clear that something is wrong on the driver side, not the xsk_{recv,send}msg. There is a -ENETDOWN that can happen from both kernel/driver sides though, but I don't have a correct replacement for this on one of the sides, so let's keep it that way. Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20220413153015.453864-12-maciej.fijalkowski@intel.com
2022-04-15ixgbe, xsk: Diversify return values from xsk_wakeup call pathsMaciej Fijalkowski1-3/+3
Currently, when debugging AF_XDP workloads, one can correlate the -ENXIO return code as the case that XSK is not in the bound state. Returning same code from ndo_xsk_wakeup can be misleading and simply makes it harder to follow what is going on. Change ENXIOs in ixgbe's ndo_xsk_wakeup() implementation to EINVALs, so that when probing it is clear that something is wrong on the driver side, not the xsk_{recv,send}msg. There is a -ENETDOWN that can happen from both kernel/driver sides though, but I don't have a correct replacement for this on one of the sides, so let's keep it that way. Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20220413153015.453864-11-maciej.fijalkowski@intel.com
2022-04-15i40e, xsk: Diversify return values from xsk_wakeup call pathsMaciej Fijalkowski1-3/+3
Currently, when debugging AF_XDP workloads, one can correlate the -ENXIO return code as the case that XSK is not in the bound state. Returning same code from ndo_xsk_wakeup can be misleading and simply makes it harder to follow what is going on. Change ENXIOs in i40e's ndo_xsk_wakeup() implementation to EINVALs, so that when probing it is clear that something is wrong on the driver side, not the xsk_{recv,send}msg. There is a -ENETDOWN that can happen from both kernel/driver sides though, but I don't have a correct replacement for this on one of the sides, so let's keep it that way. Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20220413153015.453864-10-maciej.fijalkowski@intel.com
2022-04-15ice, xsk: Diversify return values from xsk_wakeup call pathsMaciej Fijalkowski1-3/+3
Currently, when debugging AF_XDP workloads, one can correlate the -ENXIO return code as the case that XSK is not in the bound state. Returning same code from ndo_xsk_wakeup can be misleading and simply makes it harder to follow what is going on. Change ENXIOs in ice's ndo_xsk_wakeup() implementation to EINVALs, so that when probing it is clear that something is wrong on the driver side, not the xsk_{recv,send}msg. There is a -ENETDOWN that can happen from both kernel/driver sides though, but I don't have a correct replacement for this on one of the sides, so let's keep it that way. Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20220413153015.453864-9-maciej.fijalkowski@intel.com
2022-04-15ixgbe, xsk: Terminate Rx side of NAPI when XSK Rx queue gets fullMaciej Fijalkowski2-9/+19
When XSK pool uses need_wakeup feature, correlate -ENOBUFS that was returned from xdp_do_redirect() with a XSK Rx queue being full. In such case, terminate the Rx processing that is being done on the current HW Rx ring and let the user space consume descriptors from XSK Rx queue so that there is room that driver can use later on. Introduce new internal return code IXGBE_XDP_EXIT that will indicate case described above. Note that it does not affect Tx processing that is bound to the same NAPI context, nor the other Rx rings. Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20220413153015.453864-8-maciej.fijalkowski@intel.com
2022-04-15i40e, xsk: Terminate Rx side of NAPI when XSK Rx queue gets fullMaciej Fijalkowski2-10/+23
When XSK pool uses need_wakeup feature, correlate -ENOBUFS that was returned from xdp_do_redirect() with a XSK Rx queue being full. In such case, terminate the Rx processing that is being done on the current HW Rx ring and let the user space consume descriptors from XSK Rx queue so that there is room that driver can use later on. Introduce new internal return code I40E_XDP_EXIT that will indicate case described above. Note that it does not affect Tx processing that is bound to the same NAPI context, nor the other Rx rings. Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20220413153015.453864-7-maciej.fijalkowski@intel.com
2022-04-15ice, xsk: Terminate Rx side of NAPI when XSK Rx queue gets fullMaciej Fijalkowski2-10/+20
When XSK pool uses need_wakeup feature, correlate -ENOBUFS that was returned from xdp_do_redirect() with a XSK Rx queue being full. In such case, terminate the Rx processing that is being done on the current HW Rx ring and let the user space consume descriptors from XSK Rx queue so that there is room that driver can use later on. Introduce new internal return code ICE_XDP_EXIT that will indicate case described above. Note that it does not affect Tx processing that is bound to the same NAPI context, nor the other Rx rings. Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20220413153015.453864-6-maciej.fijalkowski@intel.com
2022-04-15ixgbe, xsk: Decorate IXGBE_XDP_REDIR with likely()Maciej Fijalkowski1-12/+13
ixgbe_run_xdp_zc() suggests to compiler that XDP_REDIRECT is the most probable action returned from BPF program that AF_XDP has in its pipeline. Let's also bring this suggestion up to the callsite of ixgbe_run_xdp_zc() so that compiler will be able to generate more optimized code which in turn will make branch predictor happy. Suggested-by: Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20220413153015.453864-5-maciej.fijalkowski@intel.com
2022-04-15ice, xsk: Decorate ICE_XDP_REDIR with likely()Maciej Fijalkowski1-10/+11
ice_run_xdp_zc() suggests to compiler that XDP_REDIRECT is the most probable action returned from BPF program that AF_XDP has in its pipeline. Let's also bring this suggestion up to the callsite of ice_run_xdp_zc() so that compiler will be able to generate more optimized code which in turn will make branch predictor happy. Suggested-by: Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20220413153015.453864-4-maciej.fijalkowski@intel.com
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.