- 30 May, 2023 40 commits
-
-
Jiri Pirko authored
Use newly introduce devlink port registration function variant and register devlink port passing ops. Signed-off-by:
Jiri Pirko <jiri@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jiri Pirko authored
Use newly introduce devlink port registration function variant and register devlink port passing ops. Signed-off-by:
Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by:
-
Jiri Pirko authored
Move port_type_set() from devlink_ops into newly introduced devlink_port_ops. Signed-off-by:
-
Jiri Pirko authored
Use newly introduce devlink port registration function variant and register devlink port passing ops. Signed-off-by:
-
Jiri Pirko authored
Move port_split/unsplit() from devlink_ops into newly introduced devlink_port_ops. Signed-off-by:
-
Jiri Pirko authored
Use newly introduce devlink port registration function variant and register devlink port passing ops. Signed-off-by:
-
Jiri Pirko authored
Use newly introduce devlink port registration function variant and register devlink port passing ops. Signed-off-by:
Petr Machata <petrm@nvidia.com> Tested-by:
-
Jiri Pirko authored
Use newly introduce devlink port registration function variant and register devlink port passing ops. Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Reviewed-by:
Michal Wilczynski <michal.wilczynski@intel.com> Signed-off-by:
-
Jiri Pirko authored
In devlink, some of the objects have separate ops registered alongside with the object itself. Port however have ops in devlink_ops structure. For drivers what register multiple kinds of ports with different ops this is not convenient. Introduce devlink_port_ops and a set of functions that allow drivers to pass ops pointer during port registration. Signed-off-by:
-
Wei Fang authored
The last_bdp is initialized to bdp, and both last_bdp and bdp are not changed. That is to say that last_bdp and bdp are always equal. So bdp can be used directly. Signed-off-by:
Wei Fang <wei.fang@nxp.com> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Link: https://lore.kernel.org/r/20230529022615.669589-1-wei.fang@nxp.comSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Heiner Kallweit authored
Check whether first PCI read returns 0xffffffff. Currently, if this is the case, the user sees the following misleading message: unknown chip XID fcf, contact r8169 maintainers (see MAINTAINERS file) Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
-
Andy Shevchenko authored
There is no gpiod_export() and gpiod_unexport() looks pretty much stray. The gpiod_export() and gpiod_unexport() shouldn't be used in the code, GPIO sysfs is deprecated. That said, simply drop the stray call. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20230528142531.38602-1-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Christophe JAILLET authored
Use vzalloc() instead of hand writing it with vmalloc()+memset(). This is less verbose. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
-
Paolo Abeni authored
Parthiban Veerasooran says: ==================== microchip_t1s: Update on Microchip 10BASE-T1S PHY driver This patch series contain the below updates, - Fixes on the Microchip LAN8670/1/2 10BASE-T1S PHYs support in the net/phy/microchip_t1s.c driver. - Adds support for the Microchip LAN8650/1 Rev.B0 10BASE-T1S Internal PHYs in the net/phy/microchip_t1s.c driver. ==================== Link: https://lore.kernel.org/r/20230526152348.70781-1-Parthiban.Veerasooran@microchip.comSigned-off-by:
-
Parthiban Veerasooran authored
Add support for the Microchip LAN865x Rev.B0 10BASE-T1S Internal PHYs (LAN8650/1). The LAN865x combines a Media Access Controller (MAC) and an internal 10BASE-T1S Ethernet PHY to access 10BASE‑T1S networks. As LAN867X and LAN865X are using the same function for the read_status, rename the function as lan86xx_read_status. Reviewed-by:
Parthiban Veerasooran <Parthiban.Veerasooran@microchip.com> Reviewed-by:
Ramón Nordin Rodriguez <ramon.nordin.rodriguez@ferroamp.se> Signed-off-by:
-
Parthiban Veerasooran authored
By default, except Reset Complete interrupt in the Interrupt Mask 2 Register all other interrupts are disabled/masked. As Reset Complete status is already handled, it doesn't make sense to disable it. Reviewed-by:
-
Parthiban Veerasooran authored
As per the datasheet DS-LAN8670-1-2-60001573C.pdf, the Reset Complete status bit in the STS2 register has to be checked before proceeding to the initial configuration. Reading STS2 register will also clear the Reset Complete interrupt which is non-maskable. Reviewed-by:
-
Parthiban Veerasooran authored
As per AN1699, the initial configuration in the driver applies to LAN867x Rev.B1 hardware revision. 0x0007C160 (Rev.A0) and 0x0007C161 (Rev.B0) never released to production and hence they don't need to be supported. Reviewed-by:
-
Parthiban Veerasooran authored
Replace read-modify-write code in the lan867x_config_init function to avoid handling data type mismatch and to simplify the code. Reviewed-by:
-
Parthiban Veerasooran authored
Remove LAN867X from the driver description as this driver is common for all the Microchip 10BASE-T1S PHYs. Reviewed-by:
-
Paolo Abeni authored
Oleksij Rempel says: ==================== Microchip DSA Driver Improvements changes v2: - set .max_register = U8_MAX, it should be more readable - clarify in the RMW error handling patch, logging behavior expectation. I'd like to share a set of patches for the Microchip DSA driver. These patches were chosen from a bigger set because they are simpler and should be easier to review. The goal is to make the code easier to read, get rid of unused code, and handle errors better. ==================== Link: https://lore.kernel.org/r/20230526073445.668430-1-o.rempel@pengutronix.deSigned-off-by:
-
Oleksij Rempel authored
This update introduces specific register access boundaries for the KSZ8873 and KSZ8863 chips within the DSA Microchip driver. The outlined ranges target global control registers, port registers, and advanced control registers. Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by:
-
Oleksij Rempel authored
This patch prepares the ksz8863_smi part of ksz8 driver to utilize the regmap register access validation feature. Signed-off-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
Oleksij Rempel authored
The only place where this variable would be set to false is the ksz8_config_cpu_port() function. But it is done in a bogus way: for (i = 0; i < dev->phy_port_cnt; i++) { if (i == dev->phy_port_cnt) <--- will be never executed. break; p->on = 1; So, we never have a situation where p->on = 0. In this case, we can just remove it. Signed-off-by: -
Vladimir Oltean authored
It is not immediately obvious that this driver allocates, via the KSZ_REGMAP_TABLE() macro, 3 regmaps for register access: dev->regmap[0] for 8-bit access, dev->regmap[1] for 16-bit and dev->regmap[2] for 32-bit access. In future changes that add support for reg_fields, each field will have to specify through which of the 3 regmaps it's going to go. Add an enum now, to denote one of the 3 register access widths, and make the code go through some wrapper functions for easier review and further modification. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Oleksij Rempel authored
This patch refines the error handling mechanism for 8-bit register read-modify-write operations. In case of a failure, it now logs an error message detailing the problematic offset. This enhancement aids in debugging by providing more precise information when these operations encounter issues. Furthermore, the ksz_prmw8() function has been updated to return error values rather than void, enabling calling functions to appropriately respond to errors. Additionally, in case of an error that affects both the current and future accesses, the PHY driver will log the errors consistently, akin to the existing behavior in all ksz_read*/ksz_write* helpers. Signed-off-by:
-
Jakub Kicinski authored
Donald Hunter says: ==================== netlink: specs: add ynl spec for ovs_flow Add a ynl specification for ovs_flow. The spec is sufficient to dump ovs flows but some attrs have been left as binary blobs because ynl doesn't support C arrays in struct definitions yet. Patches 1-3 add features for genetlink-legacy specs Patch 4 is the ovs_flow netlink spec ==================== Link: https://lore.kernel.org/r/20230527133107.68161-1-donald.hunter@gmail.comSigned-off-by:
-
Donald Hunter authored
Add a ynl specification for ovs_flow. This spec is sufficient to dump ovs flows. Some attrs are left as binary blobs because ynl doesn't support C arrays in struct definitions yet. Signed-off-by:
Donald Hunter <donald.hunter@gmail.com> Signed-off-by:
-
Donald Hunter authored
Support decoding scalars as enums in struct members for genetlink-legacy specs. Signed-off-by:
-
Donald Hunter authored
This eliminates the need for e.g. --json '{"dp-ifindex":0}' which is not too big a deal for ovs but will get tiresome for fixed header structs that have many members. Signed-off-by: -
Donald Hunter authored
Make it possible to document the meaning of struct member attributes in genetlink-legacy specs. Signed-off-by:
-
Simon Horman authored
Make some minor spelling corrections in comments. Found by inspection. Signed-off-by:
Simon Horman <horms@kernel.org> Reviewed-by:
-
Dan Carpenter authored
The "len" variable needs to be signed for the error handling to work correctly. Fixes: 2e910b95 ("net: Add a function to splice pages into an skbuff for MSG_SPLICE_PAGES") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by:
David Howells <dhowells@redhat.com> Reviewed-by:
-
Russell King (Oracle) authored
Rather than using put_device(&mdiodev->dev), use the proper interface provided to dispose of the mdiodev - that being mdio_device_free(). Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by:
Ioana Ciornei <ioana.ciornei@nxp.com> Tested-by:
-
Jakub Kicinski authored
Russell King says: ==================== net: pcs: add helpers to xpcs and lynx to manage mdiodev This morning, we have had two instances where the destruction of the MDIO device associated with XPCS and Lynx has been wrong. Rather than allowing this pattern of errors to continue, let's make it easier for driver authors to get this right by adding a helper. The changes are essentially: 1. Add two new mdio device helpers to manage the underlying struct device reference count. Note that the existing mdio_device_free() doesn't actually free anything, it merely puts the reference count. 2. Make the existing _create() and _destroy() PCS driver methods increment and decrement this refcount using these helpers. This results in no overall change, although drivers may hang on to the mdio device for a few cycles longer. 3. Add _create_mdiodev() which creates the mdio device before calling the existing _create() method. Once the _create() method has returned, we put the reference count on the mdio device. If _create() was successful, then the reference count taken there will "hold" the mdio device for the lifetime of the PCS (in other words, until _destroy() is called.) However, if _create() failed, then dropping the refcount at this point will free the mdio device. This is the exact behaviour we desire. 4. Convert users that create a mdio device and then call the PCS's _create() method over to the new _create_mdiodev() method, and simplify the cleanup. We also have DPAA2 and fmem_memac that look up their PCS rather than creating it. These could also drop their reference count on the MDIO device immediately after calling lynx_pcs_create(), which would then mean we wouldn't need lynx_get_mdio_device() and the associated complexity to put the device in dpaa2_pcs_destroy() and pcs_put(). Note that DPAA2 bypasses the mdio device's abstractions by calling put_device() directly. ==================== Link: https://lore.kernel.org/r/ZHCGZ8IgAAwr8bla@shell.armlinux.org.ukSigned-off-by:
-
Russell King (Oracle) authored
Use the newly introduced lynx_pcs_create_mdiodev() which simplifies the creation and destruction of the lynx PCS. Signed-off-by:
-
Russell King (Oracle) authored
Use the newly introduced lynx_pcs_create_mdiodev() which simplifies the creation and destruction of the lynx PCS. Signed-off-by:
-
Russell King (Oracle) authored
Add lynx_pcs_create_mdiodev() to simplify the creation of the mdio device associated with lynx PCS. In order to allow lynx_pcs_destroy() to clean this up, we need to arrange for lynx_pcs_create() to take a refcount on the mdiodev, and lynx_pcs_destroy() to put it. Adding the refcounting to lynx_pcs_create()..lynx_pcs_destroy() will be transparent to existing users of these interfaces. Signed-off-by:
-
Russell King (Oracle) authored
Use the new xpcs_create_mdiodev() creator, which simplifies the creation and destruction of the mdio device associated with xpcs. Signed-off-by:
-
Russell King (Oracle) authored
Add xpcs_create_mdiodev() to simplify the creation of the mdio device associated with the XPCS. In order to allow xpcs_destroy() to clean this up, we need to arrange for xpcs_create() to take a refcount on the mdiodev, and xpcs_destroy() to put it. Adding the refcounting to xpcs_create()..xpcs_destroy() will be transparent to existing users of these interfaces. Signed-off-by:
-
