- 24 Oct, 2019 20 commits
-
-
Dmitry Bezrukov authored
Depending on FW configuration we can manage from 0 to 3 PINs for periodic output and from 0 to 1 ext ts PIN for getting TS for external event. Ext TS PIN functionality is implemented via periodic timestamps polling directly from PHY, because right now there is now way to receive the PIN trigger interrupt from phy. The polling interval is 15 milliseconds. Co-developed-by:
Egor Pomozov <epomozov@marvell.com> Signed-off-by:
Pavel Belous <pavel.belous@aquantia.com> Signed-off-by:
Dmitry Bezrukov <dmitry.bezrukov@aquantia.com> Signed-off-by:
Igor Russkikh <igor.russkikh@aquantia.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Dmitry Bezrukov authored
GPIO PIN control and access is done by direct phy manipulation. Here we add an aq_phy module which is able to access phy registers via MDIO access mailbox. Access is controlled via HW semaphore. Co-developed-by:
Nikita Danilov <nikita.danilov@aquantia.com> Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Egor Pomozov authored
Ethtool callback with basic information on what PTP features are supported by the device. Signed-off-by:
Sergey Samoilenko <sergey.samoilenko@aquantia.com> Signed-off-by:
-
Egor Pomozov authored
Here we add support for PTP specific IOCTLs of HW timestamp get/set. These will use filters to configure flows onto the required queue ids. Co-developed-by:
-
Dmitry Bezrukov authored
We implement HW filter reservation for PTP traffic. Special location in filters table is marked as reserved, because incoming ptp traffic should be directed only to PTP designated queue. This way HW will do PTP timestamping and proper processing. Co-developed-by:
-
Egor Pomozov authored
Here we do alloc/free IRQs for PTP rings. We also implement processing of PTP packets on TX and RX sides. Signed-off-by:
-
Dmitry Bezrukov authored
Checkpatch and styling fixes on parts of code touched by ptp Signed-off-by:
-
Egor Pomozov authored
Add implementations of PTP rings alloc/free. PTP desing on this device uses two separate rings on a separate traffic class for traffic rx/tx. Third ring (hwts) is not a traffic ring, but is used only to receive timestamps of the transmitted packets. Signed-off-by:
-
Egor Pomozov authored
Basic HW functions implemented for adjusting frequency, adjusting time, getting and setting time. With these callbacks we now do register ptp clock in the system. Firmware interface parts are defined for PTP requests and interactions. Enable/disable PTP counters in HW on clock register/unregister. Signed-off-by:
-
Dmitry Bezrukov authored
Make some other bit-enums more clear about positioning, this helps on debugging and development Signed-off-by:
-
Egor Pomozov authored
Here we add basic function for PTP clock register/unregister. We also declare FW/HW capability bits used to control PTP feature on device. PTP device is created if network card has appropriate FW that has PTP enabled in config. HW supports timestamping for PTPv2 802.AS1 and PTPv2 IPv4 UDP packets. It also supports basic PTP callbacks for getting/setting time, adjusting frequency and time as well. Signed-off-by:
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/usb/lan78xx.c:3995:6: warning: variable event set but not used [-Wunused-but-set-variable] It is never used, so can be removed. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
-
David S. Miller authored
Ido Schimmel says: ==================== mlxsw: Update main pool computation and pool size limits Petr says: In Spectrum ASICs, the shared buffer is an area of memory where packets are kept until they can be transmitted. There are two resources associated with shared buffer size: cap_total_buffer_size and cap_guaranteed_shared_buffer. So far, mlxsw has been using the former as a limit when validating shared buffer pool size configuration. However, the total size also includes headrooms and reserved space, which really cannot be used for shared buffer pools. Patch #1 mends this and has mlxsw use the guaranteed size. To configure default pool sizes, mlxsw has historically hard-coded one or two smallish pools, and one "main" pool that took most of the shared buffer (that would be pool 0 on ingress and pool 4 on egress). During the development of Spectrum-2, it became clear that the shared buffer size keeps shrinking as bugs are identified and worked around. In order to prevent having to tweak the size of pools 0 and 4 to catch up with updates to values reported by the FW, patch #2 changes the way these pools are set. Instead of hard-coding a fixed value, the main pool now takes whatever is left from the guaranteed size after the smaller pool(s) are taken into account. ==================== Signed-off-by: -
Petr Machata authored
Instead of hard-coding the size of the largest pool, calculate it from the reported guaranteed shared buffer size and sizes of other pools (currently only the CPU port pool). Signed-off-by:
Petr Machata <petrm@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Petr Machata authored
There are two resources associated with shared buffer size: cap_total_buffer_size, and cap_guaranteed_shared_buffer. So far, mlxsw has been using the former as a limit to determine how large a pool size is allowed to be. However, the total size also includes headrooms and reserved space, which really cannot be used for shared buffer pools. Therefore convert mlxsw to use the latter resource as a limit. Adjust hard-coded pool sizes to be the guaranteed size minus 256000 bytes for CPU port pool. On Spectrum-1 that actually leads to an increase. A follow-up patch will have this size calculated automatically. Signed-off-by:
-
Heiner Kallweit authored
Setting PCI_EXP_DEVCTL_NOSNOOP_EN for certain chip versions had been added to the vendor driver more than 10 years ago, and copied from there to r8169. It has been removed from the vendor driver meanwhile and I think we can safely remove this too. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
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: -
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:
René van Dorst <opensource@vdorst.com> Reviewed-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 20 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:
-
