- 24 Oct, 2019 4 commits
-
-
David S. Miller authored
Tao Ren says: ==================== net: phy: support 1000Base-X auto-negotiation for BCM54616S This patch series aims at supporting auto negotiation when BCM54616S is running in 1000Base-X mode: without the patch series, BCM54616S PHY driver would report incorrect link speed in 1000Base-X mode. Patch #1 (of 3) modifies assignment to OR when dealing with dev_flags in phy_attach_direct function, so that dev_flags updated in BCM54616S PHY's probe callback won't be lost. Patch #2 (of 3) adds several genphy_c37_* functions to support clause 37 1000Base-X auto-negotiation, and these functions are called in BCM54616S PHY driver. Patch #3 (of 3) detects BCM54616S PHY's operation mode and calls according genphy_c37_* functions to configure auto-negotiation and parse link attributes (speed, duplex, and etc.) in 1000Base-X mode. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Tao Ren authored
The BCM54616S PHY cannot work properly in RGMII->1000Base-X mode, mainly because genphy functions are designed for copper links, and 1000Base-X (clause 37) auto negotiation needs to be handled differently. This patch enables 1000Base-X support for BCM54616S by customizing 3 driver callbacks, and it's verified to be working on Facebook CMM BMC platform (RGMII->1000Base-KX): - probe: probe callback detects PHY's operation mode based on INTERF_SEL[1:0] pins and 1000X/100FX selection bit in SerDES 100-FX Control register. - config_aneg: calls genphy_c37_config_aneg when the PHY is running in 1000Base-X mode; otherwise, genphy_config_aneg will be called. - read_status: calls genphy_c37_read_status when the PHY is running in 1000Base-X mode; otherwise, genphy_read_status will be called. Note: BCM54616S PHY can also be configured in RGMII->100Base-FX mode, and 100Base-FX support is not available as of now. Signed-off-by:Tao Ren <taoren@fb.com> Acked-by:
Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Heiner Kallweit authored
This patch adds support for clause 37 1000Base-X auto-negotiation. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
René van Dorst <opensource@vdorst.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Tao Ren authored
Modify the assignment to OR when dealing with phydev->dev_flags in phy_attach_direct function, and this is to make sure dev_flags set in driver's probe callback won't be lost. Suggested-by:
-
- 22 Oct, 2019 36 commits
-
-
Eric Dumazet authored
Since commit 342db221 ("sched: Call skb_get_hash_perturb in sch_fq_codel") we no longer need anything from this file. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com>
-
Jakub Kicinski authored
Vivien Didelot says: ==================== The dsa_switch structure represents the physical switch device itself, and is allocated by the driver. The dsa_switch_tree and dsa_port structures represent the logical switch fabric (eventually composed of multiple switch devices) and its ports, and are allocated by the DSA core. This branch lists the logical ports directly in the fabric which simplifies the iteration over all ports when assigning the default CPU port or configuring the D in DSA in drivers like mv88e6xxx. This also removes the unique dst->cpu_dp pointer and is a first step towards supporting multiple CPU ports and dropping the DSA_MAX_PORTS limitation. Because the dsa_port structures are not tied to the dsa_switch structure anymore, we do not need to provide an helper for the drivers to allocate a switch structure. Like in many other subsystems, drivers can now embed their dsa_switch structure as they wish into their private structure. This will be particularly interesting for the Broadcom drivers which were currently limited by the dynamically allocated array of DSA ports. The series implements the list of dsa_port structures, makes use of it, then drops dst->cpu_dp and the dsa_switch_alloc helper. ==================== Signed-off-by: -
Vivien Didelot authored
Now that ports are dynamically listed in the fabric, there is no need to provide a special helper to allocate the dsa_switch structure. This will give more flexibility to drivers to embed this structure as they wish in their private structure. Signed-off-by:
Vivien Didelot <vivien.didelot@gmail.com> Reviewed-by:
-
Vivien Didelot authored
Allocate the struct dsa_port the first time it is accessed with dsa_port_touch, and remove the static dsa_port array from the dsa_switch structure. Signed-off-by:
-
Vivien Didelot authored
Like the dsa_switch_tree structures, the dsa_port structures will be allocated on switch registration. The SJA1105 driver is the only one accessing the dsa_port structure after the switch allocation and before the switch registration. For that reason, move switch registration prior to assigning the priv member of the dsa_port structures. Signed-off-by:
-
Vivien Didelot authored
Instead of digging into the other dsa_switch structures of the fabric and relying too much on the dsa_to_port helper, use the new list of switch fabric ports to remap the Port VLAN Map of local bridge group members or remap the Port VLAN Table entry of external bridge group members. Signed-off-by:
-
Vivien Didelot authored
Instead of digging into the other dsa_switch structures of the fabric and relying too much on the dsa_to_port helper, use the new list of switch fabric ports to define the mask of the local ports allowed to receive frames from another port of the fabric. Signed-off-by:
-
Vivien Didelot authored
Since mv88e6xxx_pvt_map is a static helper, no need to return -EOPNOTSUPP if the chip has no PVT, simply silently skip the operation. Signed-off-by:
-
Vivien Didelot authored
Use the new ports list instead of iterating over switches and their ports when setting up the default CPU port. Unassign it on teardown. Now that we can iterate over multiple CPU ports, remove dst->cpu_dp. At the same time, provide a better error message for CPU-less tree. Signed-off-by:
-
Vivien Didelot authored
Use the new ports list instead of iterating over switches and their ports when looking up the first CPU port in the tree. Signed-off-by:
-
Vivien Didelot authored
Now that we have a potential list of CPU ports, make use of it instead of only configuring the master device of an unique CPU port. Signed-off-by:
-
Vivien Didelot authored
Use the new ports list instead of iterating over switches and their ports to find a port from a given node. Signed-off-by:
-
Vivien Didelot authored
Use the new ports list instead of accessing the dsa_switch array of ports when iterating over DSA ports of a switch to set up the routing table. Signed-off-by:
-
Vivien Didelot authored
Use the new ports list instead of iterating over switches and their ports when setting up the switches and their ports. At the same time, provide setup states and messages for ports and switches as it is done for the trees. Signed-off-by:
-
Vivien Didelot authored
Use the new ports list instead of iterating over switches and their ports when looking for a slave device from a given master interface. Signed-off-by:
-
Vivien Didelot authored
Use the new ports list instead of accessing the dsa_switch array of ports in the dsa_to_port helper. Signed-off-by:
-
Vivien Didelot authored
Add a list of switch ports within the switch fabric. This will help the lookup of a port inside the whole fabric, and it is the first step towards supporting multiple CPU ports, before deprecating the usage of the unique dst->cpu_dp pointer. In preparation for a future allocation of the dsa_port structures, return -ENOMEM in case no structure is returned, even though this error cannot be reached yet. Signed-off-by:
-
Vivien Didelot authored
Do not let the drivers access the ds->ports static array directly while there is a dsa_to_port helper for this purpose. At the same time, un-const this helper since the SJA1105 driver assigns the priv member of the returned dsa_port structure. Signed-off-by:
-
Jakub Kicinski authored
Heiner Kallweit says: ==================== The attempt to improve performance by changing the PCIe max read request size was added in the vendor driver more than 10 years back and copied to r8169 driver. In the vendor driver this has been removed long ago. Obviously it had no effect, also in my tests I didn't see any difference. Typically the max payload size is less than 512 bytes anyway, and the PCI core takes care that the maximum supported value is set. So let's remove fiddling with PCIe max read request size from r8169 too. This change allows to simplify the driver in the subsequent three patches of this series. ==================== Signed-off-by: -
Heiner Kallweit authored
We can remove rtl_hw_start_8168bef() and use rtl_hw_start_8168b() instead because setting register Config4 is done in rtl_jumbo_config(), being called from rtl_hw_start(). Signed-off-by:
-
Heiner Kallweit authored
We can remove rtl_hw_start_8168dp() because it's the same as rtl_hw_start_8168dp() now. Signed-off-by:
-
Heiner Kallweit authored
r8168b_0_hw_jumbo_enable() and r8168b_0_hw_jumbo_disable() both do the same and just set PCI_EXP_DEVCTL_NOSNOOP_EN. We can simplify the code by moving this setting for RTL8168B to rtl_hw_start_8168(). Signed-off-by:
-
Heiner Kallweit authored
The attempt to improve performance by changing the PCIe max read request size was added in the vendor driver more than 10 years back and copied to r8169 driver. In the vendor driver this has been removed long ago. Obviously it had no effect, also in my tests I didn't see any difference. Typically the max payload size is less than 512 bytes anyway, and the PCI core takes care that the maximum supported value is set. So let's remove fiddling with PCIe max read request size from r8169 too. Signed-off-by:
-
Jakub Kicinski authored
Karsten Graul says: ==================== More patches to address abnormal termination processing of sockets and link groups. ==================== Signed-off-by: -
Ursula Braun authored
With the introduction of the link group termination worker there is no longer a need to postpone smc_close_active_abort() to a worker. To protect socket destruction due to normal and abnormal socket closing, the socket refcount is increased. Signed-off-by:
Ursula Braun <ubraun@linux.ibm.com> Signed-off-by:
Karsten Graul <kgraul@linux.ibm.com> Signed-off-by:
-
Ursula Braun authored
Use a worker for link group termination to guarantee process context. Signed-off-by:
-
Ursula Braun authored
If a link group and its connections must be terminated, * wake up socket waiters * do not enable buffer reuse A linkgroup might be terminated while normal connection closing is running. Avoid buffer reuse and its related LLC DELETE RKEY call, if linkgroup termination has started. And use the earliest indication of linkgroup termination possible, namely the removal from the linkgroup list. Signed-off-by:
-
Ursula Braun authored
There are lots of link group termination scenarios. Most of them still allow to inform the peer of the terminating sockets about aborting. This patch tries to call smc_close_abort() for terminating sockets. And the internal TCP socket is reset with tcp_abort(). Signed-off-by:
-
Ursula Braun authored
Usually link groups are freed delayed to enable quick connection creation for a follow-on SMC socket. Terminated link groups are freed faster. This patch makes sure, fast schedule of link group freeing is not rescheduled by a delayed schedule. And it makes sure link group freeing is not rescheduled, if the real freeing is already running. Signed-off-by:
-
Ursula Braun authored
Locking hierarchy requires that the link group conns_lock can be taken if the socket lock is held, but not vice versa. Nevertheless socket termination during abnormal link group termination should be protected by the socket lock. This patch reduces the time segments the link group conns_lock is held to enable usage of lock_sock in smc_lgr_terminate(). Signed-off-by:
-
Ursula Braun authored
When a link group is to be terminated, it is sufficient to hold the lgr lock when unlinking the link group from its list. Move the lock-protected link group unlinking into smc_lgr_terminate(). Signed-off-by:
-
Ursula Braun authored
The resources for a terminated socket are being cleaned up. This patch makes sure * no more data is received for an actively terminated socket * no more data is sent for an actively or passively terminated socket Signed-off-by:
-
Jakub Kicinski authored
Ido Schimmel says: ==================== Vadim says: This patch set extends the size of QSFP EEPROM for the cable types SSF-8436 and SFF-8636 from 256 bytes to 640 bytes. This allows ethtool to show correct information for these cable types (more details below). Patch #1 adds a macro that computes the EEPROM page number from the provided offset specified in the request. Patch #2 teaches the driver to access the information stored in the upper pages of the QSFP memory map. Details and examples: SFF-8436 specification defines pages 0, 1, 2 and 3. Page 0 contains lower memory page offsets (from 0x00 to 0x7f) and upper page offsets (from 0x80 to 0xfe). Upper pages 1, 2 and 3 are optional and can be empty. Page 1 is provided if upper page 0 byte 0xc3 bit 6 is set. Page 2 is provided if upper page 0 byte 0xc3 bit 7 is set. Page 3 is provided if lower page 0 byte 0x02 bit 2 is cleared. Offset 0xc3 for the upper page is provided as 0x43 = 0xc3 - 0x80. As a result of exposing 256 bytes only, ethtool shows wrong information for pages 1, 2 and 3. In the below hex dump from ethtool for a cable compliant to SFF-8636 specification, it can be seen that EEPROM of this device contains optical diagnostic page (lower page 0 byte 0x02 bit 2 is cleared), but it is not exposed, as the length defined for this type is 256 bytes. $ ethtool -m sfp42 hex on Offset Values ------ ------ 0x0000: 11 07 00 ff 00 ff 00 00 00 55 55 00 00 00 00 00 0x0010: 00 00 00 00 00 00 2a 90 00 00 82 ae 00 00 00 00 0x0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 0x0060: 00 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0080: 11 8c 0c 80 00 00 00 00 00 00 00 05 ff 00 00 23 0x0090: 00 00 32 00 4d 65 6c 6c 61 6e 6f 78 20 20 20 20 0x00a0: 20 20 20 20 00 00 02 c9 4d 4d 41 31 42 30 30 2d 0x00b0: 53 53 31 20 20 20 20 20 41 32 42 68 0b b8 46 05 0x00c0: 02 07 f5 9e 4d 54 31 38 33 34 46 54 30 33 38 34 0x00d0: 36 20 20 20 31 38 30 37 30 33 00 00 0c 10 67 c2 0x00e0: 38 32 36 46 4d 41 32 32 36 49 30 31 31 35 20 20 0x00f0: 00 00 00 00 00 00 00 00 00 00 01 00 0e 00 00 00 After changing the length returned by get_module_info() callback from 256 bytes to 640 bytes, the upper pages 1, 2 and 3 are exposed by ethtool. In the below hex dump from the same cable it can be seen that the optical diagnostic page (page 3, from offset 0x0200) has non-zero data. $ ethtool -m sfp42 hex on Offset Values ------ ------ 0x0000: 11 07 00 ff 00 ff 00 00 00 55 55 00 00 00 00 00 0x0010: 00 00 00 00 00 00 27 79 00 00 82 c5 00 00 00 00 0x0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 0x0060: 00 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0080: 11 8c 0c 80 00 00 00 00 00 00 00 05 ff 00 00 23 0x0090: 00 00 32 00 4d 65 6c 6c 61 6e 6f 78 20 20 20 20 0x00a0: 20 20 20 20 00 00 02 c9 4d 4d 41 31 42 30 30 2d 0x00b0: 53 53 31 20 20 20 20 20 41 32 42 68 0b b8 46 05 0x00c0: 02 07 f5 9e 4d 54 31 38 33 34 46 54 30 33 38 34 0x00d0: 36 20 20 20 31 38 30 37 30 33 00 00 0c 10 67 c2 0x00e0: 38 32 36 46 4d 41 32 32 36 49 30 31 31 35 20 20 0x00f0: 00 00 00 00 00 00 00 00 00 00 01 00 0e 00 00 00 0x0100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x01a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x01b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x01c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x01d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x01e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x01f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0200: 50 00 f6 00 46 00 00 00 00 00 00 00 00 00 00 00 0x0210: 88 b8 79 18 87 5a 7a 76 00 00 00 00 00 00 00 00 0x0220: 00 00 00 00 00 00 00 00 00 00 18 30 0e 61 60 b7 0x0230: 87 71 01 d3 43 e2 03 a5 10 9a 0a ba 0f a0 0b b8 0x0240: 87 71 02 d4 43 e2 05 a5 00 00 00 00 00 00 00 00 0x0250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0260: a7 03 00 00 00 00 00 00 00 00 44 44 22 22 11 11 0x0270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 And 'ethtool -m sfp42' shows the real values for the below fields, while before it exposed zeros for these fields: Laser bias current high alarm threshold : 8.500 mA Laser bias current low alarm threshold : 5.492 mA Laser bias current high warning threshold : 8.000 mA Laser bias current low warning threshold : 6.000 mA Laser output power high alarm threshold : 3.4673 mW / 5.40 dBm Laser output power low alarm threshold : 0.0724 mW / -11.40 dBm Laser output power high warning threshold : 1.7378 mW / 2.40 dBm Laser output power low warning threshold : 0.1445 mW / -8.40 dBm Module temperature high alarm threshold : 80.00 degrees C / 176.00 F Module temperature low alarm threshold : -10.00 degrees C / 14.00 F Module temperature high warning threshold : 70.00 degrees C / 158.00 F Module temperature low warning threshold : 0.00 degrees C / 32.00 F Module voltage high alarm threshold : 3.5000 V Module voltage low alarm threshold : 3.1000 V ==================== Signed-off-by: -
Vadim Pasternak authored
Extend the size of QSFP EEPROM for the cable types SSF8436 and SFF8636 from 256 to 640 bytes in order to expose all the EEPROM pages by ethtool. For SFF-8636 and SFF-8436 specifications, the driver exposes 256 bytes of data for ethtool's get_module_eeprom() callback. This is because the driver uses the below defines to specify SFF module length in ethtool's get_module_info() callback: 'ETH_MODULE_SFF_8636_LEN' and 'ETH_MODULE_SFF_8436_LEN' (both are 256). As a result of exposing 256 bytes only, ethtool shows wrong "zero" info for pages 1, 2, 3. The patch changes the length returned by callback for get_module_info() to the values from the next defines: 'ETH_MODULE_SFF_8636_MAX_LEN' and 'ETH_MODULE_SFF_8436_MAX_LEN' (both are 640) to allow exposing of upper page 1, 2 and 3. Signed-off-by:
Vadim Pasternak <vadimp@mellanox.com> Acked-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Vadim Pasternak authored
Provide a macro for getting QSFP module EEPROM page number from the optional upper page number row offset, specified in request. Signed-off-by:
-
Juergen Gross authored
Do some cleanup of the netback init and deinit code: - add an omnipotent queue deinit function usable from xenvif_disconnect_data() and the error path of xenvif_connect_data() - only install the irq handlers after initializing all relevant items (especially the kthreads related to the queue) - there is no need to use get_task_struct() after creating a kthread and using put_task_struct() again after having stopped it. - use kthread_run() instead of kthread_create() to spare the call of wake_up_process(). Signed-off-by:
Juergen Gross <jgross@suse.com> Reviewed-by:
Paul Durrant <pdurrant@gmail.com> Signed-off-by:
-
