- 08 Apr, 2021 27 commits
-
-
Jiaran Zhang authored
The flr_prepare/flr_done functions are not only used in the FLR scenario, but also used in the suspend/resume. Change the function names to prepare_for_reset/rebuild_for_reset, change the flr_prepare/flr_done to reset_prepare/reset_done in hnae3_ae_ops. Signed-off-by:
Jiaran Zhang <zhangjiaran@huawei.com> Signed-off-by:
Huazhong Tan <tanhuazhong@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Shannon Nelson says: ==================== ionic: hwstamp tweaks A few little changes after review comments and additional internal testing. ==================== Signed-off-by: -
Shannon Nelson authored
Make sure the configuration is locked before operating on it for the replay. Signed-off-by:
Shannon Nelson <snelson@pensando.io> Signed-off-by:
-
Shannon Nelson authored
Split the call into ionic_lif_hwstamp_set() to have two separate interfaces, one from the ioctl() for changing the configuration and one for replaying the current configuration after a FW RESET. Signed-off-by:
-
Shannon Nelson authored
When starting the queues in the link-check, don't go into the BROKEN state if the return was EBUSY. Signed-off-by:
-
Shannon Nelson authored
When returning after a firmware reset, re-start the PTP after we've restarted the general queues. Signed-off-by:
-
Shannon Nelson authored
Set the SKBTX_IN_PROGRESS when offloading the Tx timestamp. Signed-off-by:
-
Shannon Nelson authored
Make sure the device is in a Tx offload mode before calling the hwstamp offload xmit. Signed-off-by:
-
Shannon Nelson authored
We don't need to look for HAVE_HWSTAMP_TX_ONESTEP_P2P in the upstream kernel. Signed-off-by:
-
Shannon Nelson authored
Clean up variable declarations. Signed-off-by:
-
David S. Miller authored
Marek Behún says: ==================== net: phy: marvell10g updates Here are some updates for marvell10g PHY driver. I am still working on some more changes for this driver, but I would like to have at least something reviewed / applied. Changes since v3: - added Andrew's Reviewed-by tags - removed patches adding variadic-macro library and bitmap initialization macro - it causes warning that we are not currently able to fix easily. Instead the supported_interfaces bitmap is now initialized via a chip specific method - added explanation of mactype initialization to commit message of patch 07/16 - fixed repeated word in commit message of second to last patch Changes since v2: - code refactored to use an additional structure mv3310_chip describing mv3310 specific properties / operations for PHYs supported by this driver - added separate phy_driver structures for 88X3340 and 88E2111 - removed 88E2180 specific code (dual-port and quad-port SXGMII modes are ignored for now) Changes since v1: - added various MACTYPEs support also for 88E21XX - differentiate between specific models with same PHY_ID - better check for compatible interface - print exact model ==================== Signed-off-by: -
Marek Behún authored
Add myself as maintainer of the marvell10g ethernet PHY driver, in addition to Russell King. Signed-off-by:
Marek Behún <kabel@kernel.org> Signed-off-by:
-
Marek Behún authored
This module supports not only Alaska X, but also Alaska M. Change module description appropriately. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Marek Behún authored
88E2111 is a variant of 88E2110 which does not support 5 gigabit speeds. Differentiate these variants via the match_phy_device() method, since they have the same PHY ID. Signed-off-by:
-
Marek Behún authored
Add constants for 2.5G and 5G speed in PCS speed register into mdio.h. Signed-off-by:
-
Marek Behún authored
The driver name "mv88x2110" should be instead "mv88e2110". Signed-off-by:
-
Marek Behún authored
The 88X3340 contains 4 cores similar to 88X3310, but there is a difference: it does not support xaui host mode. Instead the corresponding MACTYPE means rxaui / 5gbase-r / 2500base-x / sgmii without AN Signed-off-by:
-
Marek Behún authored
Currently the only "changing" MACTYPE we support is when the PHY changes between 10gbase-r / 5gbase-r / 2500base-x / sgmii Add support for usxgmii xaui / 5gbase-r / 2500base-x / sgmii rxaui / 5gbase-r / 2500base-x / sgmii and also 5gbase-r / 2500base-x / sgmii for 88E2110. Signed-off-by:
-
Marek Behún authored
Now that we have a chip structure, we can store the temperature reading method in this structure (OOP style). Signed-off-by:
-
Marek Behún authored
The 88E2110 does not support xaui nor rxaui modes. Check for correct interface mode for different chips. Signed-off-by:
-
Marek Behún authored
Add support for all rate matching modes for 88X3310 (currently only 10gbase-r is supported, but xaui and rxaui can also be used). Add support for rate matching for 88E2110 (on 88E2110 the MACTYPE register is at a different place). Currently rate matching mode is selected by strapping pins (by setting the MACTYPE register). There is work in progress to enable this driver to deduce the best MACTYPE from the knowledge of which interface modes are supported by the host, but this work is not finished yet. Signed-off-by:
-
Marek Behún authored
Add all MACTYPE definitions for 88E2110, 88E2180, 88E2111 and 88E2181. Signed-off-by:
-
Marek Behún authored
Add all MACTYPE definitions for 88X3310, 88X3310P, 88X3340 and 88X3340P. In order to have consistent naming, rename MV_V2_33X0_PORT_CTRL_MACTYPE_RATE_MATCH to MV_V2_33X0_PORT_CTRL_MACTYPE_10GBASER_RATE_MATCH. Signed-off-by:
-
Marek Behún authored
Rename port control registers to indicate that they are valid only for 88X33x0, not for 88E21x0. Signed-off-by:
-
Marek Behún authored
These modes are also supported by these PHYs. Signed-off-by:
-
Marek Behún authored
This space should be a tab instead. Signed-off-by:
-
Marek Behún authored
The MV_V2_PORT_MAC_TYPE_* is part of the CTRL register. Rename to MV_V2_PORT_CTRL_MACTYPE_*. Signed-off-by:
-
- 07 Apr, 2021 13 commits
-
-
Wei Yongjun authored
Use the module_pci_driver() macro to make the code simpler by eliminating module_init and module_exit calls. Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
Wei Yongjun authored
Use the module_pci_driver() macro to make the code simpler by eliminating module_init and module_exit calls. Signed-off-by:
-
Wei Yongjun authored
Use the module_pci_driver() macro to make the code simpler by eliminating module_init and module_exit calls. Signed-off-by:
-
Wei Yongjun authored
Use the module_pci_driver() macro to make the code simpler by eliminating module_init and module_exit calls. Signed-off-by:
-
Wei Yongjun authored
Use the module_pci_driver() macro to make the code simpler by eliminating module_init and module_exit calls. Signed-off-by:
-
Wei Yongjun authored
Use the module_pci_driver() macro to make the code simpler by eliminating module_init and module_exit calls. Signed-off-by:
-
Wei Yongjun authored
module_spi_driver() makes the code simpler by eliminating boilerplate code. Signed-off-by:
-
Johan Hovold authored
According to the changelog, asynchronous mode was dropped sometime before v2.2. Let's get rid of the unused driver-specific async state as well so that it doesn't show up when doing tree-wide tty work. Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Colin Ian King authored
The macro CN23XX_PEM_BAR1_INDEX_REG is being used to shift oct->pcie_port (a u16) left 24 places. There are two subtle issues here, first the shift gets promoted to an signed int and then sign extended to a u64. If oct->pcie_port is 0x80 or more then the upper bits get sign extended to 1. Secondly shfiting a u16 24 bits will lead to an overflow so it needs to be cast to a u64 for all the bits to not overflow. It is entirely possible that the u16 port value is never large enough for this to fail, but it is useful to fix unintended overflows such as this. Fix this by casting the port parameter to the macro to a u64 before the shift. Addresses-Coverity: ("Unintended sign extension") Fixes: 5bc67f58 ("liquidio: CN23XX register definitions") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Colin Ian King authored
The error check on err is always false as err is always 0 at the port_found label. The code is redundant and can be removed. Addresses-Coverity: ("Logically dead code") Signed-off-by: -
David S. Miller authored
Merge tag 'linux-can-next-for-5.13-20210407' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2021-04-07 this is a pull request of 6 patches for net-next/master. The first patch targets the CAN driver infrastructure, it improves the alloc_can{,fd}_skb() function to set the pointer to the CAN frame to NULL if skb allocation fails. The next patch adds missing error handling to the m_can driver's RX path (the code was introduced in -next, no need to backport). In the next patch an unused constant is removed from an enum in the c_can driver. The last 3 patches target the mcp251xfd driver. They add BQL support and try to work around a sometimes broken CRC when reading the TBC register. ==================== Signed-off-by:
-
Andrei Vagin authored
Here is only one place where we want to specify new_ifindex. In all other cases, callers pass 0 as new_ifindex. It looks reasonable to add a low-level function with new_ifindex and to convert dev_change_net_namespace to a static inline wrapper. Fixes: eeb85a14 ("net: Allow to specify ifindex when device is moved to another namespace") Suggested-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Andrei Vagin <avagin@gmail.com> Acked-by:
-
Andrei Vagin authored
In this case, we don't need to check that new_ifindex is positive in validate_linkmsg. Fixes: eeb85a14 ("net: Allow to specify ifindex when device is moved to another namespace") Suggested-by:
-
