kernel.git/drivers/net/ethernet/pensando/ionic, branch linux-5.12.y

ionic: linearize tso skb with too many frags

2021-03-17T18:27:30Z

We were linearizing non-TSO skbs that had too many frags, but we weren't checking number of frags on TSO skbs. This could lead to a bad page reference when we received a TSO skb with more frags than the Tx descriptor could support. v2: use gso_segs rather than yet another division don't rework the check on the nr_frags Fixes: 0f3154e6bcb3 ("ionic: Add Tx and Rx handling") Signed-off-by: Shannon Nelson Signed-off-by: David S. Miller

ionic: Remove unused function pointer typedef ionic_reset_cb

2021-02-16T21:43:58Z

Remove the 'ionic_reset_cb' typedef as it is not used. Signed-off-by: Chen Lin Acked-by: Shannon Nelson Signed-off-by: David S. Miller

net: add inline function skb_csum_is_sctp

2021-01-19T22:31:25Z

This patch is to define a inline function skb_csum_is_sctp(), and also replace all places where it checks if it's a SCTP CSUM skb. This function would be used later in many networking drivers in the following patches. Suggested-by: Alexander Duyck Signed-off-by: Xin Long Reviewed-by: Alexander Duyck Signed-off-by: Jakub Kicinski

ionic: account for vlan tag len in rx buffer len

2020-12-22T01:32:14Z

Let the FW know we have enough receive buffer space for the vlan tag if it isn't stripped. Fixes: 0f3154e6bcb3 ("ionic: Add Tx and Rx handling") Signed-off-by: Shannon Nelson Link: https://lore.kernel.org/r/20201218215001.64696-1-snelson@pensando.io Signed-off-by: Jakub Kicinski

drivers: net: ionic: simplify the return expression of ionic_set_rxfh()

2020-12-09T00:22:54Z

Simplify the return expression. Signed-off-by: Zheng Yongjun Signed-off-by: David S. Miller

ionic: change mtu after queues are stopped

2020-12-02T01:14:23Z

Order of operations is slightly more correct in the driver to change the netdev->mtu after the queues have been stopped rather than before. Signed-off-by: Shannon Nelson Signed-off-by: Jakub Kicinski

ionic: remove some unnecessary oom messages

2020-12-02T01:14:23Z

Remove memory allocation fail messages where the OOM stack trace will make it obvious which allocation request failed. Signed-off-by: Shannon Nelson Signed-off-by: Jakub Kicinski

net: don't include ethtool.h from netdevice.h

2020-11-24T01:27:04Z

linux/netdevice.h is included in very many places, touching any of its dependecies causes large incremental builds. Drop the linux/ethtool.h include, linux/netdevice.h just needs a forward declaration of struct ethtool_ops. Fix all the places which made use of this implicit include. Acked-by: Johannes Berg Acked-by: Shannon Nelson Reviewed-by: Jesse Brandeburg Link: https://lore.kernel.org/r/20201120225052.1427503-1-kuba@kernel.org Signed-off-by: Jakub Kicinski

devlink: move flash end and begin to core devlink

2020-11-20T05:41:02Z

When performing a flash update via devlink, device drivers may inform user space of status updates via devlink_flash_update_(begin|end|timeout|status)_notify functions. It is expected that drivers do not send any status notifications unless they send a begin and end message. If a driver sends a status notification without sending the appropriate end notification upon finishing (regardless of success or failure), the current implementation of the devlink userspace program can get stuck endlessly waiting for the end notification that will never come. The current ice driver implementation may send such a status message without the appropriate end notification in rare cases. Fixing the ice driver is relatively simple: we just need to send the begin_notify at the start of the function and always send an end_notify no matter how the function exits. Rather than assuming driver authors will always get this right in the future, lets just fix the API so that it is not possible to get wrong. Make devlink_flash_update_begin_notify and devlink_flash_update_end_notify static, and call them in devlink.c core code. Always send the begin_notify just before calling the driver's flash_update routine. Always send the end_notify just after the routine returns regardless of success or failure. Doing this makes the status notification easier to use from the driver, as it no longer needs to worry about catching failures and cleaning up by calling devlink_flash_update_end_notify. It is now no longer possible to do the wrong thing in this regard. We also save a couple of lines of code in each driver. Signed-off-by: Jacob Keller Acked-by: Vasundhara Volam Reviewed-by: Jiri Pirko Signed-off-by: Jakub Kicinski

devlink: move request_firmware out of driver

2020-11-20T05:40:57Z

All drivers which implement the devlink flash update support, with the exception of netdevsim, use either request_firmware or request_firmware_direct to locate the firmware file. Rather than having each driver do this separately as part of its .flash_update implementation, perform the request_firmware within net/core/devlink.c Replace the file_name parameter in the struct devlink_flash_update_params with a pointer to the fw object. Use request_firmware rather than request_firmware_direct. Although most Linux distributions today do not have the fallback mechanism implemented, only about half the drivers used the _direct request, as compared to the generic request_firmware. In the event that a distribution does support the fallback mechanism, the devlink flash update ought to be able to use it to provide the firmware contents. For distributions which do not support the fallback userspace mechanism, there should be essentially no difference between request_firmware and request_firmware_direct. Signed-off-by: Jacob Keller Acked-by: Shannon Nelson Acked-by: Vasundhara Volam Reviewed-by: Jiri Pirko Signed-off-by: Jakub Kicinski