- 10 Jan, 2023 16 commits
-
-
Andrew Lunn authored
Now that mdiobus_c45_addr() is only used within the MDIO code during fallback, move the function next to its only users. This function should not be used any more in drivers, the c45 helpers should be used in its place, so hiding it away will prevent any new users from being added. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Michael Walle <michael@walle.cc> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Andrew Lunn authored
When performing a C22 operation, check that the bus driver actually provides the methods, and return -EOPNOTSUPP if not. C45 only busses do exist, and in future their C22 methods will be NULL. Signed-off-by:
-
Andrew Lunn authored
Now that C45 uses its own read/write methods, the validation performed when a bus is registers needs updating. All combinations of C22 and C45 are supported, but both read and write methods must be provided, read only busses are not supported etc. Signed-off-by:
-
Andrew Lunn authored
Convert the PCS-XPCS driver to make use of the C45 MDIO bus API for modify_change(). Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Andrew Lunn authored
Currently C22 and C45 transactions are mixed over a combined API calls which make use of a special bit in the reg address to indicate if a C45 transaction should be performed. This makes it impossible to know if the bus driver actually supports C45. Additionally, many C22 only drivers don't return -EOPNOTSUPP when asked to perform a C45 transaction, they mistaking perform a C22 transaction. This is the first step to cleanly separate C22 from C45. To maintain backwards compatibility until all drivers which are capable of performing C45 are converted to this new API, the helper functions will fall back to the older API if the new API is not supported. Eventually this fallback will be removed. Signed-off-by:
-
Paolo Abeni authored
Michael Walle says: ==================== net: phy: mxl-gpy: broken interrupt fixes The GPY215 has a broken interrupt pin. This patch series tries to workaround that and because in general that is not possible, disables the interrupts by default and falls back to polling mode. There is an opt-in via the devicetree. ==================== Link: https://lore.kernel.org/r/20230109123013.3094144-1-michael@walle.ccSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Michael Walle authored
The interrupts on the GPY215B and GPY215C are broken and the only viable fix is to disable them altogether. There is still the possibilty to opt-in via the device tree. Signed-off-by:
-
Michael Walle authored
Until now, it is not possible for a PHY driver to disable interrupts during runtime. If a driver offers the .config_intr() as well as the .handle_interrupt() ops, it is eligible for interrupt handling. Introduce a new flag for the dev_flags property of struct phy_device, which can be set by PHY driver to skip interrupt setup and fall back to polling mode. At the moment, this is used for the MaxLinear PHY which has broken interrupt handling and there is a need to disable interrupts in some cases. Signed-off-by:
-
Michael Walle authored
Add the device tree bindings for the MaxLinear GPY2xx PHYs, which essentially adds just one flag: maxlinear,use-broken-interrupts. One might argue, that if interrupts are broken, just don't use the interrupt property in the first place. But it needs to be more nuanced. First, this interrupt line is also used to wake up systems by WoL, which has nothing to do with the (broken) PHY interrupt handling. Second and more importantly, there are devicetrees which have this property set. Thus, within the driver we have to switch off interrupt handling by default as a workaround. But OTOH, a systems designer who knows the hardware and knows there are no shared interrupts for example, can use this new property as a hint to the driver that it can enable the interrupt nonetheless. Signed-off-by:
-
Michael Walle authored
MaxLinear is a manufacturer of integrated circuits. https://www.maxlinear.comSigned-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Paolo Abeni authored
Hans J. Schultz says: ==================== mv88e6xxx: Add MAB offload support This patch-set adds MAB [1] offload support in mv88e6xxx. Patch #1: Correct default return value for mv88e6xxx_port_bridge_flags. Patch #2: Shorten the locked section in mv88e6xxx_g1_atu_prob_irq_thread_fn(). Patch #3: The MAB implementation for mv88e6xxx. [1] https://git.kernel.org/netdev/net-next/c/4bf24ad09bc0 ==================== Link: https://lore.kernel.org/r/20230108094849.1789162-1-netdev@kapio-technology.comSigned-off-by: -
Hans J. Schultz authored
This implementation for the Marvell mv88e6xxx chip series is based on handling ATU miss violations occurring when packets ingress on a port that is locked with learning on. This will trigger a SWITCHDEV_FDB_ADD_TO_BRIDGE event, which will result in the bridge module adding a locked FDB entry. This bridge FDB entry will not age out as it has the extern_learn flag set. Userspace daemons can listen to these events and either accept or deny access for the host, by either replacing the locked FDB entry with a simple entry or leave the locked entry. If the host MAC address is already present on another port, a ATU member violation will occur, but to no real effect, and the packet will be dropped in hardware. Statistics on these violations can be shown with the command and example output of interest: ethtool -S ethX NIC statistics: ... atu_member_violation: 5 atu_miss_violation: 23 ... Where ethX is the interface of the MAB enabled port. Furthermore, as added vlan interfaces where the vid is not added to the VTU will cause ATU miss violations reporting the FID as MV88E6XXX_FID_STANDALONE, we need to check and skip the miss violations handling in this case. Signed-off-by:Hans J. Schultz <netdev@kapio-technology.com> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
Hans J. Schultz authored
As only the hardware access functions up til and including mv88e6xxx_g1_atu_mac_read() called under the interrupt handler need to take the chip lock, we release the chip lock after this call. The follow up code that handles the violations can run without the chip lock held. In further patches, the violation handler function will even be incompatible with having the chip lock held. This due to an AB/BA ordering inversion with rtnl_lock(). Signed-off-by:
-
Hans J. Schultz authored
The default return value -EOPNOTSUPP of mv88e6xxx_port_bridge_flags() came from the return value of the DSA method port_egress_floods() in commit 4f85901f ("net: dsa: mv88e6xxx: add support for bridge flags"), but the DSA API was changed in commit a8b659e7 ("net: dsa: act as passthrough for bridge port flags"), resulting in the return value -EOPNOTSUPP not being valid anymore, and sections for new flags will not need to set the return value to zero on success, as with the new mab flag added in a following patch. Signed-off-by:
-
Raju Rangoju authored
Add the necessary changes to support 10 Mbps speed for BaseT and SFP port modes. This is supported in MAC ver >= 30H. Signed-off-by:
Raju Rangoju <Raju.Rangoju@amd.com> Link: https://lore.kernel.org/r/20230109101819.747572-1-Raju.Rangoju@amd.comSigned-off-by:
-
Jamie Gloudon authored
This enables link partner advertised support to show link modes and pause frame use. Signed-off-by:
Jamie Gloudon <jamie.gloudon@gmx.fr> Tested-by:
Naama Meir <naamax.meir@linux.intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com> Reviewed-by:
-
- 09 Jan, 2023 18 commits
-
-
Jakub Kicinski authored
Since commit ce098da1 ("skbuff: Introduce slab_build_skb()") drivers trying to build skb around slab-backed buffers should go via slab_build_skb() rather than passing frag_size = 0 to the main build_skb(). Remove the copy'n'pasted comments about 0 meaning slab. Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Bjørn Mork says: ==================== r8152: allow firmwares with NCM support Some device and firmware combinations with NCM support will end up using the cdc_ncm driver by default. This is sub- optimal for the same reasons we've previously accepted the blacklist hack in cdc_ether. The recent support for subclassing the generic USB device driver allows us to create a very slim driver with the same functionality. This patch set uses that to implement a device specific configuration default which is independent of any USB interface drivers. This means that it works equally whether the device initially ends up in NCM or ECM mode, without depending on any code in the respective class drivers. ==================== Signed-off-by: -
Bjørn Mork authored
The r8152 driver does not need this anymore. Dropping blacklist entries adds optional support for these devices in ECM mode. The 8153 devices are handled by the r8153_ecm driver when in ECM mode, and must still be blacklisted here. Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Bjørn Mork authored
Subclassing the generic USB device driver to override the default configuration selection regardless of matching interface drivers. The r815x family devices expose a vendor specific function which the r8152 interface driver wants to handle. This is the preferred device mode. Additionally one or more USB class functions are usually supported for hosts lacking a vendor specific driver. The choice is USB configuration based, with one alternate function per configuration. Example device with both NCM and ECM alternate cfgs: T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 4 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 3 P: Vendor=0bda ProdID=8156 Rev=31.00 S: Manufacturer=Realtek S: Product=USB 10/100/1G/2.5G LAN S: SerialNumber=001000001 C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=256mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=00 Driver=r8152 E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=83(I) Atr=03(Int.) MxPS= 2 Ivl=128ms C: #Ifs= 2 Cfg#= 2 Atr=a0 MxPwr=256mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0d Prot=00 Driver= E: Ad=83(I) Atr=03(Int.) MxPS= 16 Ivl=128ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=01 Driver= I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=01 Driver= E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms C: #Ifs= 2 Cfg#= 3 Atr=a0 MxPwr=256mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver= E: Ad=83(I) Atr=03(Int.) MxPS= 16 Ivl=128ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=00 Driver= I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver= E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms A problem with this is that Linux will prefer class functions over vendor specific functions. Using the above example, Linux defaults to cfg #2, running the device in a sub-optimal NCM mode. Previously we've attempted to work around the problem by blacklisting the devices in the ECM class driver "cdc_ether", and matching on the ECM class function in the vendor specific interface driver. The latter has been used to switch back to the vendor specific configuration when the driver is probed for a class function. This workaround has several issues; - class driver blacklists is additional maintanence cruft in an unrelated driver - class driver blacklists prevents users from optionally running the devices in class mode - each device needs double match entries in the vendor driver - the initial probing as a class function slows down device discovery Now these issues have become even worse with the introduction of firmware supporting both NCM and ECM, where NCM ends up as the default mode in Linux. To use the same workaround, we now have to blacklist the devices in to two different class drivers and add yet another match entry to the vendor specific driver. This patch implements an alternative workaround strategy - independent of the interface drivers. It avoids adding a blacklist to the cdc_ncm driver and will let us remove the existing blacklist from the cdc_ether driver. As an additional bonus, removing the blacklists allow users to select one of the other device modes if wanted. Signed-off-by:
-
David S. Miller authored
Mat Martineau says: ==================== mptcp: Protocol in-use tracking and code cleanup Here's a collection of commits from the MPTCP tree: Patches 1-4 and 6 contain miscellaneous code cleanup for more consistent use of helper functions, existing local variables, and better naming. Patches 5, 7, and 9 add sock_prot_inuse tracking for MPTCP and an associated self test. Patch 8 modifies the mptcp_connect self test tool to exit on SIGUSR1 when in "slow mode". ==================== Signed-off-by: -
Menglong Dong authored
Add the function chk_msk_inuse() to diag.sh, which is used to check the statistics of mptcp socket in use. As mptcp socket in listen state will be closed randomly after 'accept', we need to get the count of listening mptcp socket through 'ss' command. All tests pass. Acked-by:
Menglong Dong <imagedong@tencent.com> Signed-off-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Signed-off-by:
-
Menglong Dong authored
For now, mptcp_connect won't exit after receiving the 'SIGUSR1' signal if '-r' is set. Fix this by skipping poll and sleep in copyfd_io_poll() if 'quit' is set. Acked-by:
-
Menglong Dong authored
Do the statistics of mptcp socket in use with sock_prot_inuse_add(). Therefore, we can get the count of used mptcp socket from /proc/net/protocols: & cat /proc/net/protocols protocol size sockets memory press maxhdr slab module cl co di ac io in de sh ss gs se re sp bi br ha uh gp em MPTCPv6 2048 0 0 no 0 yes kernel y n y y y y y y y y y y n n n y y y n MPTCP 1896 1 0 no 0 yes kernel y n y y y y y y y y y y n n n y y y n Acked-by:
-
Menglong Dong authored
'ssk' should be more appropriate to be the name of the first argument in mptcp_token_new_connect(). Acked-by:
-
Menglong Dong authored
The 'sk_prot' field in token KUNIT self-tests will be dereferenced in mptcp_token_new_connect(). Therefore, init it with tcp_prot. Acked-by:
-
Menglong Dong authored
'sock->sk' is used frequently in mptcp_listen(). Therefore, we can introduce the 'sk' and replace 'sock->sk' with it. Acked-by:
-
Geliang Tang authored
The local variable 'ssk' has been defined at the beginning of the function mptcp_write_options(), use it instead of getting 'ssk' again. Reviewed-by:
Geliang Tang <geliang.tang@suse.com> Signed-off-by:
-
Geliang Tang authored
Use the local variable 'net' instead of sock_net() in the functions where the variable 'struct net *net' has been defined. Reviewed-by:
-
Geliang Tang authored
The helper msk_owned_by_me() is defined in protocol.h, so use it instead of sock_owned_by_me(). Reviewed-by:
-
Leesoo Ahn authored
The current source pushes skb into dev-done queue by calling skb_dequeue_tail() and then pop it by skb_dequeue() to branch to rx_cleanup state for freeing urb/skb in usbnet_bh(). It takes extra CPU load, 2.21% (skb_queue_tail) as follows, - 11.58% 0.26% swapper [k] usbnet_bh - 11.32% usbnet_bh - 6.43% skb_dequeue 6.34% _raw_spin_unlock_irqrestore - 2.21% skb_queue_tail 2.19% _raw_spin_unlock_irqrestore - 1.68% consume_skb - 0.97% kfree_skbmem 0.80% kmem_cache_free 0.53% skb_release_data To reduce the extra CPU load use return values to call helper function usb_free_skb() to free the resources instead of calling skb_queue_tail() and skb_dequeue() for push and pop respectively. - 7.87% 0.25% swapper [k] usbnet_bh - 7.62% usbnet_bh - 4.81% skb_dequeue 4.74% _raw_spin_unlock_irqrestore - 1.75% consume_skb - 0.98% kfree_skbmem 0.78% kmem_cache_free 0.58% skb_release_data 0.53% smsc95xx_rx_fixup Signed-off-by:Leesoo Ahn <lsahn@ooseel.net> Signed-off-by:
-
David S. Miller authored
Divya Koppera says: ==================== Fixed warnings Fixed warnings related to PTR_ERR and initialization. ==================== Signed-off-by: -
Divya Koppera authored
Handle the NULL pointer case Fixes New smatch warnings: drivers/net/phy/micrel.c:2613 lan8814_ptp_probe_once() warn: passing zero to 'PTR_ERR' vim +/PTR_ERR +2613 drivers/net/phy/micrel.c Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Alexander Duyck <alexanderduyck@fb.com> Signed-off-by:
Divya Koppera <Divya.Koppera@microchip.com> Signed-off-by:
-
Divya Koppera authored
Initialized return variable Fixes Old smatch warnings: drivers/net/phy/micrel.c:1750 ksz886x_cable_test_get_status() error: uninitialized symbol 'ret'. Reported-by:
-
- 07 Jan, 2023 6 commits
-
-
Jakub Kicinski authored
Jiawen Wu says: ==================== net: wangxun: Adjust code structure Remove useless structs 'txgbe_hw' and 'ngbe_hw' make the codes clear. And move the same codes which sets MAC address between txgbe and ngbe to libwx. Further more, rename struct 'wx_hw' to 'wx' and move total adapter members to wx. ==================== Link: https://lore.kernel.org/r/20230106033853.2806007-1-jiawenwu@trustnetic.comSigned-off-by:
-
Mengyuan Lou authored
Move the total private structure to libwx. Signed-off-by:
Mengyuan Lou <mengyuanlou@net-swift.com> Signed-off-by:
-
Jiawen Wu authored
Move the total private structure to libwx. Signed-off-by:
Jiawen Wu <jiawenwu@trustnetic.com> Signed-off-by:
-
Jiawen Wu authored
In order to move the total members in struct adapter to struct wx_hw to keep the code clean, it's a bad name of 'wx_hw' only for hardware. Rename 'wx_hw' to 'wx', and rename the pointers at use. Signed-off-by:
-
Jiawen Wu authored
For setting MAC address, both txgbe and ngbe drivers have the same handling flow with different parameters. Move the same codes to libwx. Signed-off-by:
-
Jiawen Wu authored
Remove ngbe.h, move defines into ngbe_type.h file. Signed-off-by:
-
