- 01 Sep, 2022 1 commit
-
-
Linus Walleij authored
Functions that work on a pointer to virtual memory such as virt_to_pfn() and users of that function such as virt_to_page() are supposed to pass a pointer to virtual memory, ideally a (void *) or other pointer. However since many architectures implement virt_to_pfn() as a macro, this function becomes polymorphic and accepts both a (unsigned long) and a (void *). If we instead implement a proper virt_to_pfn(void *addr) function the following happens (occurred on arch/arm): net/rds/message.c:357:56: warning: passing argument 1 of 'virt_to_pfn' makes pointer from integer without a cast [-Wint-conversion] Fix this with an explicit cast. Cc: Santosh Shilimkar <santosh.shilimkar@oracle.com> Cc: rds-devel@oss.oracle.com Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20220829132001.114858-1-linus.walleij@linaro.orgSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
- 31 Aug, 2022 39 commits
-
-
Sven van Ashbrook authored
The rtl8152 driver does not disable multicasting when userspace asks it to. For example: $ ifconfig eth0 -multicast -allmulti $ tcpdump -p -i eth0 # will still capture multicast frames Fix by clearing the device multicast filter table when multicast and allmulti are both unset. Tested as follows: - Set multicast on eth0 network interface - verify that multicast packets are coming in: $ tcpdump -p -i eth0 - Clear multicast and allmulti on eth0 network interface - verify that no more multicast packets are coming in: $ tcpdump -p -i eth0 Signed-off-by:
Sven van Ashbrook <svenva@chromium.org> Acked-by:
Hayes Wang <hayeswang@realtek.com> Link: https://lore.kernel.org/r/20220830045923.net-next.v1.1.I4fee0ac057083d4f848caf0fa3a9fd466fc374a0@changeidSigned-off-by:
-
Wolfram Sang authored
Follow the advice of the below link and prefer 'strscpy' in this subsystem. Conversion is 1:1 because the return value is not used. Generated by a coccinelle script. Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Petr Machata <petrm@nvidia.com> # For drivers/net/ethernet/mellanox/mlxsw Acked-by: Geoff Levand <geoff@infradead.org> # For ps3_gelic_net and spider_net_ethtool Acked-by: Tom Lendacky <thomas.lendacky@amd.com> # For drivers/net/ethernet/amd/xgbe/xgbe-ethtool.c Acked-by: Marcin Wojtas <mw@semihalf.com> # For drivers/net/ethernet/marvell/mvpp2 Reviewed-by: Leon Romanovsky <leonro@nvidia.com> # For drivers/net/ethernet/mellanox/mlx{4|5} Reviewed-by: Shay Agroskin <shayagr@amazon.com> # For drivers/net/ethernet/amazon/ena Acked-by: Krzysztof Hałasa <khalasa@piap.pl> # For IXP4xx Ethernet Link: https://lore.kernel.org/r/20220830201457.7984-3-wsa+renesas@sang-engineering.comSigned-off-by:
-
Wolfram Sang authored
Follow the advice of the below link and prefer 'strscpy' in this subsystem. Conversion is 1:1 because the return value is not used. Generated by a coccinelle script. Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/Signed-off-by:
-
Heiner Kallweit authored
Simplify the code by using the device-managed clock API. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/b222be68-ba7e-999d-0a07-eca0ecedf74e@gmail.comSigned-off-by:
-
David S. Miller authored
Guangbin Huang says: ==================== net: hns3: updates for -next This series includes some updates for the HNS3 ethernet driver. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Guangbin Huang authored
For some new devices, the FEC mode can not be set to OFF in speed 200G. In order to flexibly adapt to all types of devices, driver queries fec ability from firmware to decide whether OFF mode can be supported. Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by:
-
Hao Lan authored
This patch supports llrs fec mode in speed 200G for some new devices, and suppoprts querying llrs fec ability from firmware. Signed-off-by:
Hao Lan <lanhao@huawei.com> Signed-off-by:
-
Guangbin Huang authored
For some new devices, driver can queries fec ability from firmware to decide which FEC mode can be supported. If devices of old version which not support querying fec ability, driver sets fixed ability according to current speed. Signed-off-by:
-
Guangbin Huang authored
As some new devices may not support GRO offload and flow table director, to support these devices, driver needs to querying capabilities of GRO offload and flow table director from firmware. Whether the driver supports these two features depends on capabilities. For old device of version HNAE3_DEVICE_VERSION_V2, driver sets their capabilities of these two features to fixed value. Setting default features of netdev and debugfs also need to identify whether support these two features. Signed-off-by:
-
David S. Miller authored
Mika Westerberg says: ==================== thunderbolt: net: Enable full end-to-end flow control Thunderbolt/USB4 host controllers support full end-to-end flow control that prevents dropping packets if there are not enough hardware receive buffers. So far it has not been enabled for the networking driver yet but this series changes that. There is one snag though: the second generation (Intel Falcon Ridge) had a bug that needs special quirk to get it working. We had that in the early stages of the Thunderbolt/USB4 driver but it got dropped because it was not needed at the time. Now we add it back as a quirk for the host controller (NHI). The first patch of this series is a bugfix that I'm planning to push for v6.0-rc. Rest are v6.1 material. This also includes a patch that shows the XDomain link type in sysfs the same way we do for USB4 routers and updates the networking driver module description. ==================== Signed-off-by: -
Mika Westerberg authored
It is Thunderbolt/USB4 now so reflect that in the module description too to avoid any confusion. No functional changes. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Mika Westerberg authored
USB4NET protocol allows the networking drivers to take advantage of end-to-end flow control supported by the USB4 host interface. This should prevent the receiving side from dropping network packets. In adddition add a module parameter that can be used to turn this off just in case it causes problems. Signed-off-by:
-
Mika Westerberg authored
As we are now enabling full end-to-end flow control to the Thunderbolt networking driver, in order for it to work properly on second generation Thunderbolt hardware (Falcon Ridge), we need to add back the workaround that was removed with commit 53f13319 ("thunderbolt: Get rid of E2E workaround"). However, this time we only apply it for Falcon Ridge controllers as a form of an additional quirk. For non-Falcon Ridge this does nothing. While there fix a typo 'reqister' -> 'register' in the comment. Signed-off-by:
-
Mika Westerberg authored
Following what we do for routers already, extend this to XDomain connections as well. This will show in sysfs whether the link is in USB4 or Thunderbolt mode. Signed-off-by:
-
Mika Westerberg authored
If the other host starts sending packets early on it is possible that we are still in the middle of populating the initial Rx ring packets to the ring. This causes the tbnet_poll() to mess over the queue and causes list corruption. This happens specifically when connected with macOS as it seems start sending various IP discovery packets as soon as its side of the paths are configured. To prevent this we move the DMA path enabling to happen after we have primed the Rx ring. This makes sure no incoming packets can arrive before we are ready to handle them. Fixes: e69b6c02 ("net: Add support for networking over Thunderbolt cable") Cc: stable@vger.kernel.org Signed-off-by:
-
Maxime Chevallier authored
Makes so that the serdes driver also takes QUSGMII in consideration. It's configured exactly as QSGMII as far as the serdes driver is concerned. Signed-off-by:
Maxime Chevallier <maxime.chevallier@bootlin.com> Signed-off-by:
-
David S. Miller authored
Oleksij Rempel says: ==================== net: dsa: microchip: add error handling and register access validation changes v4: - add Reviewed-by: Vladimir Oltean <olteanv@gmail.com> to all patches - fix checkpatch warnings. changes v3: - fix build error in the middle of the patch stack. changes v2: - add regmap_ranges for KSZ9477 - drop output clock devicetree in driver validation patches. DTs need some more refactoring and can be done in a separate patch set. - remove some unused variables. This patch series adds error handling for the PHY read/write path and optional register access validation. After adding regmap_ranges for KSZ8563 some bugs was detected, so critical bug fixes are sorted before ragmap_range patch. Potentially this bug fixes can be ported to stable kernels, but need to be reworked. ==================== Signed-off-by: -
Oleksij Rempel authored
Use chip_id as other places of this code do it Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by:
Vladimir Oltean <olteanv@gmail.com> Signed-off-by:
-
Oleksij Rempel authored
This variable is not used. So, remove it. Signed-off-by:
-
Oleksij Rempel authored
This variable is not used on ksz9477 side. Remove it. Signed-off-by:
-
Oleksij Rempel authored
This variable is unused. So, drop it. Signed-off-by:
-
Oleksij Rempel authored
With code refactoring was introduced new variable internal_phy. Let's use it. Signed-off-by:
-
Oleksij Rempel authored
Add register validation for KSZ9477 Signed-off-by:
-
Oleksij Rempel authored
The reason why PHYlib may access MII_CTRL1000 on the chip without GBit support is only if chip provides wrong information about extended caps register. This issue is now handled by ksz9477_r_phy_quirks() With proper regmap_ranges provided for all chips we will be able to catch this kind of bugs any way. So, remove this sanity check. Signed-off-by:
-
Oleksij Rempel authored
Add register validation for KSZ8563. Signed-off-by:
-
Oleksij Rempel authored
This is complex driver with support for different chips with different layouts. To detect at least some bugs earlier, we should validate register accesses by using regmap_access_table support. Signed-off-by:
-
Oleksij Rempel authored
This issue was detected after adding regmap register access validation. KSZ9893 compatible chips do not have "Output Clock Control Register 0x0103". So, avoid writing to it. Signed-off-by:
-
Oleksij Rempel authored
Now ksz_pread/ksz_pwrite can return error value. So, make use of it. Signed-off-by:
-
Oleksij Rempel authored
Now ksz_pread/ksz_pwrite can return error value. So, make use of it. Signed-off-by:
-
Oleksij Rempel authored
ksz_read*/ksz_write* are able to return errors, so forward it. Signed-off-by:
-
Oleksij Rempel authored
PHY access may end with errors on different levels. So, allow to forward return values where possible. Signed-off-by:
-
Oleksij Rempel authored
This issue was detected after adding support of regmap_ranges for KSZ8563R chip. This chip is reporting extended registers support without having actual extended registers. This made PHYlib request not existing registers. Signed-off-by:
-
Oleksij Rempel authored
KSZ8563 has two 100Mbit PHYs and CPU port with RGMII support. Since 1000Mbit configuration for the RGMII capable MAC is present, we should use per port validation. As main part of migration to per-port validation we need to rework ksz9477_switch_init() function. Which is using undocumented REG_GLOBAL_OPTIONS register to detect per-chip Gbit support. So, it is related to some sort of risk for regressions. To reduce this risk I compared the code with publicly available documentations. This function will executed on following currently supported chips: struct ksz_chip_data OF compatible KSZ9477 KSZ9477 KSZ9897 KSZ9897 KSZ9893 KSZ9893, KSZ9563 KSZ8563 KSZ8563 KSZ9567 KSZ9567 Only KSZ9893, KSZ9563, KSZ8563 document existence of 0xf == REG_GLOBAL_OPTIONS register with bit field description "SKU ID": KSZ9893 0x0C KSZ9563 0x1C KSZ8563 0x3C The existence of hidden flags is not documented. KSZ9477, KSZ9897, KSZ9567 do not document this register at all. Only KSZ8563 is documented as non Gbit chip: 100Mbit PHYs and RGMII CPU port. So, this change should not introduce a regression for configurations with properly used OF compatibles. Signed-off-by:
-
Oleksij Rempel authored
Add separate entry for the KSZ8563 chip. According to the documentation it can support Gbit only on RGMII port. So, we will need to be able to describe in the followup patch. Signed-off-by:
-
Xin Gao authored
'unsigned int' is better than 'unsigned'. Signed-off-by:
Xin Gao <gaoxin@cdjrlc.com> Signed-off-by:
-
Vlad Buslov authored
This reverts commit 6005a8ae. The assertion was intentionally removed in commit 043b8413 ("net: devlink: remove redundant rtnl lock assert") and, contrary what is described in the commit message, the comment reflects that: "Caller must hold RTNL mutex or reference to dev...". Signed-off-by:
Vlad Buslov <vladbu@nvidia.com> Tested-by:
Leon Romanovsky <leonro@nvidia.com> Link: https://lore.kernel.org/r/20220829121324.3980376-1-vladbu@nvidia.comSigned-off-by:
-
Jakub Kicinski authored
Petr Machata says: ==================== mlxsw: Configure max LAG ID for Spectrum-4 Amit Cohen writes: In the device, LAG identifiers are stored in the port group table (PGT). During initialization, firmware reserves a certain amount of entries at the beginning of this table for LAG identifiers. In Spectrum-4, the size of the PGT table did not increase, but the maximum number of LAG identifiers was doubled, leaving less room for others entries (e.g., flood entries) that also reside in the PGT. Therefore, in order to avoid a regression and as long as there is no explicit requirement to support 256 LAGs, configure the firmware to allocate the same amount of LAG entries (128) as in Spectrum-{2,3}. This can be done via the 'max_lag' field in CONFIG_PROFILE command. Patch set overview: Patch #1 edits the comment of the existing 'max_lag' field. Patch #2 adds support for configuring 'max_lag' field via CONFIG_PROFILE command. Patch #3 adds an helper function to get the actual 'max_lag' in the device. Patch #4 adjusts Spectrum-4 to configure 'max_lag' field. ==================== Link: https://lore.kernel.org/r/cover.1661527928.git.petrm@nvidia.comSigned-off-by: -
Amit Cohen authored
Starting from Spectrum-4, the maximum number of LAG IDs can be configured by software via CONFIG_PROFILE command during driver initialization. Add a dedicated instance of 'struct mlxsw_config_profile' for Spectrum-4 and set the 'max_lag' field to 128, which is the same amount of LAG entries as in Spectrum-{2,3}. Without this configuration, firmware reserves 256 (the value of 'cap_max_lag' resource) entries at beginning of PGT table for LAG identifiers, which means that less entries in PGT will be available. Signed-off-by:Amit Cohen <amcohen@nvidia.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
-
Amit Cohen authored
Currently the driver queries the maximum supported LAG ID from firmware. This will not be accurate anymore once the driver will configure 'max_lag' via CONFIG_PROFILE command. For resource query, firmware returns the maximum LAG ID which is supported by hardware. Software can configure firmware to do not allocate entries for all the supported LAGs, and to limit LAG IDs. In this case, the resource query will not return the actual maximum LAG ID. Add a helper function for getting this value. In case that 'max_lag' field was set during initialization, return the value which was used, otherwise, query firmware for the maximum supported ID. Signed-off-by:
-
