- 09 Feb, 2019 36 commits
-
-
Andrew Lunn authored
Add support for runtime determination of what the PHY supports, by adding a new function to the phy driver. The get_features call should set the phydev->supported member with the features the PHY supports. It is only called if phydrv->features is NULL. This requires minor changes to pause. The PHY driver should not set pause abilities, except for when it has odd cause capabilities, e.g. pause cannot be disabled. With this change, phydev->supported already contains the drivers abilities, including pause. So rather than considering phydrv->features, look at the phydev->supported, and enable pause if neither of the pause bits are already set. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> [hkallweit1@gmail.com: fixed small checkpatch complaint in one comment] Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Andrew Lunn authored
We will soon support asking the PHY at runtime to determine what features it supports, rather than forcing it to be compile time. But we should probe the PHY first. So probe the phy driver earlier. Signed-off-by:
-
Heiner Kallweit authored
PHY registers are only 16 bits wide, therefore, if the read was successful, there's no need to mask out the higher 16 bits. Signed-off-by:
-
Vakul Garg authored
Function tls_sw_recvmsg() dequeues multiple records from stream parser and decrypts them. In case the decryption is done by async accelerator, the records may get submitted for decryption while the previous ones may not have been decryted yet. For tls1.3, the record type is known only after decryption. Therefore, for tls1.3, tls_sw_recvmsg() may submit records for decryption even if it gets 'handshake' records after 'data' records. These intermediate 'handshake' records may do a key updation. By the time new keys are given to ktls by userspace, it is possible that ktls has already submitted some records i(which are encrypted with new keys) for decryption using old keys. This would lead to decrypt failure. Therefore, async decryption of records should be disabled for tls1.3. Fixes: 130b392c ("net: tls: Add tls 1.3 support") Signed-off-by:
Vakul Garg <vakul.garg@nxp.com> Signed-off-by:
-
Heiner Kallweit authored
Bit 0 in register 1.5 doesn't represent a device but is a flag that Clause 22 registers are present. Therefore disregard this bit when populating the device list. If code needs this information it should read register 1.5 directly instead of accessing the device list. Because this bit doesn't represent a device don't define a MDIO_MMD_XYZ constant, just define a MDIO_DEVS_XYZ constant for the flag in the device list bitmap. v2: - make masking of bit 0 more explicit - improve commit message Signed-off-by:
-
David S. Miller authored
Russell King says: ==================== mvpp2 phylink fixes Having spent a while debugging issues with Sven Auhagen, it appears that the mvpp2 network driver's phylink support isn't quite correct. This series fixes that up, but, despite being tested locally, by Sven, and by Antoine, I would prefer it to be applied to net-next so that there is time for more people to test before it hits -rc or stable backports. The symptoms were that although PHYs would come up, the GMAC never reported that the link was up, or in some cases it did report link up but packets would not flow. Various approaches were tried to work around that, such as switching to in-band negotiation from PHY mode, but ultimately the problem was in the way mvpp2 was being programmed. This series addresses that by, essentially, making mvpp2 follow the same implementation pattern as mvneta: we configure the GMAC in three stages: 1) the PHY interface mode 2) the negotiation advert 3) the negotiation style Another issue is that mvpp2 was always taking the link down each time its mac_config method was called: this is disruptive when the link is already up, and we're just updating settings such as flow control. There are some circumstances where we make the call despite there being no changes (eg, when phylink is polling a GPIO or using a custom link state function.) This series depends on two previous patches already sent for net-next: net: marvell: mvpp2: fix lack of link interrupts net: marvell: mvpp2: use phy_interface_mode_is_8023z() helper There is one last patch which deals with link status interrupts, which I'll send separately because I think there's other considerations, but that should not hold up this series of patches. ==================== Signed-off-by: -
Russell King authored
phylink already limits which interface modes are able to call the MACs AN restart function, but in any case, the commentry seems incorrect: the AN restart bit does not automatically clear when set. This has been found via manual setting using devmem2, and we can observe that the AN does indeed restart and complete, yet the AN restart bit remains set. Explicitly clear the AN restart bit. Tested-by:
Sven Auhagen <sven.auhagen@voleatech.de> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Russell King authored
When reading the pause bits in mac_link_state, mvpp2 was reporting the state of the "active pause" bits, which are set when the MAC is in pause mode. This is not what phylink wants - we want the negotiated pause state. Fix the definition so we read the correct bits. Tested-by:
-
Russell King authored
mac_config() can be called at any point, and the expected behaviour from MAC drivers is to only reprogram when necessary - and certainly avoid taking the link down on every call. Unfortunately, mvpp2 does exactly that - it takes the link down, and reprograms everything, and then releases the forced-link down. This is bad, it can cause the link to bounce: - SFP detects signal, disables LOS indication. - SFP code calls into phylink, calling phylink_sfp_link_up() which triggers a resolve. - phylink_resolve() calls phylink_get_mac_state() and finds the MAC reporting link up. - phylink wants to configure the pause mode on the MAC, so calls phylink_mac_config() - mvpp2 takes the link down temporarily, generating a MAC link down event followed by another MAC link event. - phylink calls mac_link_up() and then processes the MAC link down event. - phylink_resolve() gets called again, registers the link down, and calls mach_link_down() before re-running itself. - phylink_resolve() starts again at step 3 above. This sequence repeats. GMAC versions prior to mvpp2 do not require the link to be taken down except when certain link properties (eg, switching between SGMII and 1000base-X mode, or enabling/disabling in-band negotiation) are changed. Implement this for mvpp2. Tested-by:
-
Russell King authored
It appears that the mvpp22 can get stuck with SGMII negotiation. The symptoms are that in-band negotiation never completes and the partner (eg, PHY) never reports SGMII link up, or if it supports negotiation bypass, goes into negotiation bypass mode (which will happen when the PHY sees that the MAC is alive but gets no response.) Triggering the PHY end of the link to re-negotiate results in the bypass bit clearing on the PHY, and then re-setting - indicating that the problem is at the mvpp22 GMAC end. Asserting the GMAC reset and de-asserting it resolves the issue. Arrange to assert the GMAC reset at probe time, and deassert it only after we have configured the GMAC for the appropriate mode. This resolves the issue. Tested-by:
-
Russell King authored
Sven Auhagen reported issues with negotiation on a couple of his platforms using a mixture of SFP and PHYs in various different modes. Debugging to root cause proved difficult, but essentially the problem comes down to the mvpp2 phylink implementation being slightly at odds with what is expected. phylink operates in three modes: phy, fixed-link, and in-band mode. In the first two modes, the expected behaviour from a MAC driver is that phylink resolves the operating mode and passes the mode to the MAC driver for it to program, including when the link should be brought up or taken down. This is basically the same as the libphy approach. This does not negate the requirement to advertise a correct control word for interface modes that have control words where that can be reasonably controlled. The second mode is in-band mode, where the MAC is expected to use the in-band control word to determine the operating mode. The mvneta driver implements the correct pattern required to support this: configure the port interface type separately from the in-band mode(s). This is now specified in the phylink documentation patches. mvpp2 was programming in-band mode for SGMII and the 802.3z modes no what, and avoided forcing the link up in fixed/phy modes. This caused a problem with some boards where the PHY is by default programmed to enter AN bypass mode, the PHY would report that the link was up, but the mvpp2 never completed the exchange of control word. Another issue that mvpp2 has is it sets SGMII AN format control word for both SGMII and 802.3z modes. The format of the control word is defined by MVPP2_GMAC_INBAND_AN_MASK, which should be set for SGMII and clear for 802.3z. Available Marvell documentation for earlier GMAC implementations does not make this clear, but this has been ascertained via extensive testing on earlier GMAC implementations, and then confirmed with a Macchiatobin Single Shot connected to a Clearfog: when MVPP2_GMAC_INBAND_AN_MASK is set, the clearfog does not receive the advertised pause mode settings. Lastly, there is no flow control in the in-band control word in Cisco SGMII, setting the flow control autonegotiation bit even with a PHY that has the Marvell extension to send this information does not result in the flow control being enabled at the MAC. We need to do this manually using the information provided via phylink. Re-code mvpp2's mac_config() and mac_link_up() to follow this pattern. This allows Sven Auhagen's board and Macchiatobin to reliably bring the link up with the 88e1512 PHY with phylink operating in PHY mode with COMPHY built as a module but the rest of the networking built-in, and u-boot having brought up the interface. in-band mode requires an additional patch to resolve another problem. Tested-by:
-
Nathan Chancellor authored
net/core/ethtool.c:3023:19: warning: address of array 'ext_m_spec->h_dest' will always evaluate to 'true' [-Wpointer-bool-conversion] if (ext_m_spec->h_dest) { ~~ ~~~~~~~~~~~~^~~~~~ h_dest is an array, it can't be null so remove this check. Fixes: eca4205f ("ethtool: add ethtool_rx_flow_spec to flow_rule structure translator") Link: https://github.com/ClangBuiltLinux/linux/issues/353Signed-off-by:Nathan Chancellor <natechancellor@gmail.com> Acked-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; size = sizeof(struct foo) + count * sizeof(struct boo); instance = kzalloc(size, GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL); Notice that, in this case, variable size is not necessary, hence it is removed. This code was detected with the help of Coccinelle. Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
-
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; size = sizeof(struct foo) + count * sizeof(struct boo); instance = kzalloc(size, GFP_KERNEL) Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL) Notice that, in this case, variable size is not necessary, hence it is removed. This code was detected with the help of Coccinelle. Signed-off-by: -
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; size = sizeof(struct foo) + count * sizeof(struct boo); instance = alloc(size, GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: size = struct_size(instance, entry, count); This code was detected with the help of Coccinelle. Signed-off-by: -
Heiner Kallweit authored
The link status register latches link-down events. Therefore, if link is reported as being up, there's no need for a second read. Signed-off-by:
-
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; size = sizeof(struct foo) + count * sizeof(struct boo); instance = kzalloc(size, GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL); Notice that, in this case, variable size is not necessary, hence it is removed. This code was detected with the help of Coccinelle. Signed-off-by: -
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; void *entry[]; }; size = sizeof(struct foo) + count * sizeof(void *); instance = alloc(size, GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = alloc(struct_size(instance, entry, count), GFP_KERNEL); Notice that, in this case, variable size is not necessary, hence it is removed. This code was detected with the help of Coccinelle. Signed-off-by:Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
-
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; size = sizeof(struct foo) + count * sizeof(struct boo); instance = kzalloc(size, GFP_KERNEL) Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL) Notice that, in this case, variable alloc_size is not necessary, hence it is removed. This code was detected with the help of Coccinelle. Signed-off-by:Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; size = sizeof(struct foo) + count * sizeof(struct boo); instance = kzalloc(size, GFP_KERNEL) Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL) Notice that, in this case, variable fsz is not necessary, hence it is removed. This code was detected with the help of Coccinelle. Signed-off-by: -
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; void *entry[]; }; size = sizeof(struct foo) + count * sizeof(void *); instance = alloc(size, GFP_KERNEL); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: size = struct_size(instance, entry, count); This code was detected with the help of Coccinelle. Signed-off-by: -
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; size = sizeof(struct foo) + count * sizeof(struct boo); instance = alloc(size, GFP_KERNEL) Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = alloc(struct_size(instance, entry, count), GFP_KERNEL) Notice that, in this case, variable alloc_size is not necessary, hence it is removed. This code was detected with the help of Coccinelle. Signed-off-by: -
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; void *entry[]; }; instance = alloc(sizeof(struct foo) + count * sizeof(void *)); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = alloc(struct_size(instance, entry, count)); This code was detected with the help of Coccinelle. Signed-off-by: -
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; size = sizeof(struct foo) + count * sizeof(struct boo); instance = alloc(size, GFP_KERNEL) Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = alloc(struct_size(instance, entry, count), GFP_KERNEL) Notice that, in this case, variable size is not necessary, hence it is removed. This code was detected with the help of Coccinelle. Signed-off-by:Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by:
-
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; instance = alloc(sizeof(struct foo) + count * sizeof(struct boo)); Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: instance = alloc(struct_size(instance, entry, count)); This code was detected with the help of Coccinelle. Signed-off-by: -
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; size = sizeof(struct foo) + count * sizeof(struct boo); instance = alloc(size, GFP_KERNEL) Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: size = struct_size(instance, entry, count); instance = alloc(size, GFP_KERNEL) This code was detected with the help of Coccinelle. Signed-off-by: -
Gustavo A. R. Silva authored
One of the more common cases of allocation size calculations is finding the size of a structure that has a zero-sized array at the end, along with memory for some number of elements for that array. For example: struct foo { int stuff; struct boo entry[]; }; size = sizeof(struct foo) + count * sizeof(struct boo); instance = alloc(size, GFP_KERNEL) Instead of leaving these open-coded and prone to type mistakes, we can now use the new struct_size() helper: size = struct_size(instance, entry, count); This code was detected with the help of Coccinelle. Signed-off-by: -
David S. Miller authored
Sudarsana Reddy Kalluru says: ==================== qed*: SmartAN query support SmartAN feature detects the peer/cable capabilities and establishes the link in the best possible configuration. The patch series adds support for querying the capability. Please consider applying it net-next. ==================== Signed-off-by: -
Sudarsana Reddy Kalluru authored
The patch adds driver support to query SmartAN capability via ethtool. Signed-off-by:
Sudarsana Reddy Kalluru <skalluru@marvell.com> Signed-off-by:
Ariel Elior <aelior@marvell.com> Signed-off-by:
Michal Kalderon <mkalderon@marvell.com> Signed-off-by:
-
Sudarsana Reddy Kalluru authored
The patch adds driver interface to read the SmartAN capability from management firmware. Signed-off-by:
-
David S. Miller authored
Florian Fainelli says: ==================== net: dsa: bcm_sf2: Add support for CFP statistics The Broadcom SF2 switch has a Compact Field Processor (CFP) which not only can perform matching + action, but also counts the number of times a rule has been hit. This is invaluable while debugging when/if rules are not matched. ==================== Signed-off-by: -
Florian Fainelli authored
When the source and destination port of a CFP rule match, we must set the loopback bit enable to allow that, otherwise the frame is discarded. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Florian Fainelli authored
Return CFP policer statistics (Green, Yellow or Red) as part of the standard ethtool statistics. This helps debug when CFP rules may not be hit (0 counter). Signed-off-by:
-
Florian Fainelli authored
In preparation for adding CFP statistics, we will need to overlay the standard B53 statistics, so create specific bcm_sf2_sw_* functions to call into their b53_common.c counterpart. Signed-off-by:
-
Florian Fainelli authored
We no longer need a dedicated statistics mutex since we leverage b53_common for statistics now. Signed-off-by:
-
Heiner Kallweit authored
The link status value latches link-down events. To get the current status we read the register twice in genphy_update_link(). There's a potential risk that we miss a link-down event in polling mode. This may cause issues if the user e.g. connects his machine to a different network. On the other hand reading the latched value may cause issues in interrupt mode. Following scenario: - After boot link goes up - phy_start() is called triggering an aneg restart, hence link goes down and link-down info is latched. - After aneg has finished link goes up and triggers an interrupt. Interrupt handler reads link status, means it reads the latched "link is down" info. But there won't be another interrupt as long as link stays up, therefore phylib will never recognize that link is up. Deal with both scenarios by reading the register twice in interrupt mode only. Signed-off-by:
-
- 08 Feb, 2019 4 commits
-
-
Nicolas Ferre authored
Add a new compatibility string for this product. It's using at91sam9260-macb layout but has a newer hardware revision: it's safer to use its own string. Signed-off-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
-
Nicolas Ferre authored
Add the compatibility sting documentation for sam9x60 10/100 interface. Signed-off-by:
-
Nicolas Ferre authored
This removes a line left while adding the correct compatibility string for sama5d3 10/100 interface. Now use the "atmel,sama5d3-macb" string. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Implement periodic ERP rehash Currently, an ERP set is created for each region according to rules inserted and order of their insertion. However that might lead to suboptimal ERP sets and possible unnecessary spillage into C-TCAM. This patchset aims to fix this problem and introduces periodical checking of used ERP sets and in case a better ERP set is possible for the given set of rules, it rehashes the region to use the better ERP set. Patch 1 prepares devlink params infra in order to fix the init/fini sequences. Patch 2 implements hints infra in objagg library. Patch 3 fixes a typo Patch 4 adds number of root objects directly into objagg stats. Patches 5-7 do split of multiple structs in Spectrum TCAM code. Patch 8 introduces initial implementation of ERP rehash logic, according to objagg hints. Patch 9 adds hints priv passing trought the layers. Patch 10 adds multi field into PAGT reg. (new patch) Patch 11 implements actual region rules migration in TCAM code. Patch 12 adds a devlink param so user is able to control rehash interval. Patch 13 adds couple of tracepoints in order to track rehash procedures. Patch 14 adds a simple selftest to test region rehash. ==================== Signed-off-by:
-
