- 01 May, 2019 40 commits
-
-
Gustavo A. R. Silva authored
Replace "pass through" with a proper "fall through" annotation in order to fix the following warning: drivers/net/netdevsim/bus.c: In function ‘new_device_store’: drivers/net/netdevsim/bus.c:170:14: warning: this statement may fall through [-Wimplicit-fallthrough=] port_count = 1; ~~~~~~~~~~~^~~ drivers/net/netdevsim/bus.c:172:2: note: here case 2: ^~~~ Warning level 3 was used: -Wimplicit-fallthrough=3 This fix is part of the ongoing efforts to enable -Wimplicit-fallthrough Signed-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. This patch fixes the following warning: drivers/net/ethernet/sfc/mcdi_port.c: In function ‘efx_mcdi_phy_decode_link’: ./include/linux/compiler.h:77:22: warning: this statement may fall through [-Wimplicit-fallthrough=] # define unlikely(x) __builtin_expect(!!(x), 0) ^~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/asm-generic/bug.h:125:2: note: in expansion of macro ‘unlikely’ unlikely(__ret_warn_on); \ ^~~~~~~~ drivers/net/ethernet/sfc/mcdi_port.c:344:3: note: in expansion of macro ‘WARN_ON’ WARN_ON(1); ^~~~~~~ drivers/net/ethernet/sfc/mcdi_port.c:345:2: note: here case MC_CMD_FCNTL_OFF: ^~~~ Warning level 3 was used: -Wimplicit-fallthrough=3 This patch is part of the ongoing efforts to enable -Wimplicit-fallthrough. Signed-off-by:Edward Cree <ecree@solarflare.com> Signed-off-by:
-
Moshe Shemesh authored
The devlink health reporters create/destroy and user commands currently use the devlink->lock as a locking mechanism. Different reporters have different rules in the driver and are being created/destroyed during different stages of driver load/unload/running. So during execution of a reporter recover the flow can go through another reporter's destroy and create. Such flow leads to deadlock trying to lock a mutex already held. With the new locking mechanism the different reporters share mutex lock only to protect access to shared reporters list. Added refcount per reporter, to protect the reporters from destroy while being used. Signed-off-by:
Moshe Shemesh <moshe@mellanox.com> Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Acked-by:
-
David S. Miller authored
Igor Russkikh says: ==================== net: atlantic: Aquantia driver updates 2019-04 This patchset contains various improvements: - Work targeting link up speedups: link interrupt introduced, some other logic changes to imrove this. - FW operations securing with mutex - Counters and statistics logic improved by Dmitry - read out of chip temperature via hwmon interface implemented by Yana and Nikita. v4 changes: - remove drvinfo_exit noop - 64bit stats should be readed out sequentially (lsw, then msw) declare 64bit read ops for that v3 changes: - temp ops renamed to phy_temp ops - mutex commits squashed for better structure v2 changes: - use threaded irq for link state handling - rework hwmon via devm_hwmon_device_register_with_info Extra comments on review from Andrew: - direct device name pointer is used in hwmon registration. This causes hwmon device to derive possible interface name changes - Will consider sanity checks for firmware mutex lock separately. Right now there is no single point exsists where such check could be easily added. - There is no way now to fetch and configure min/max/crit temperatures via FW. Will investigate this separately. ==================== Signed-off-by: -
Nikita Danilov authored
Some device ids were never released and does not exist. Cleanup these. Signed-off-by:
Nikita Danilov <ndanilov@aquantia.com> Signed-off-by:
Igor Russkikh <igor.russkikh@aquantia.com> Signed-off-by:
-
Dmitry Bogdanov authored
DMA counters are 64 bit and we can fetch that to reduce counter overflow, espesially on byte counters. Tested-by:
Dmitry Bogdanov <dmitry.bogdanov@aquantia.com> Signed-off-by:
-
Dmitry Bogdanov authored
aq_nic_update_ndev_stats pushes statistics to ndev->stats from system interface. This is not always good because it counts packets/bytes before any of rx filters (including mac filter). Its better to report the packet/bytes statistics from DMA counters which gives actual values of data transferred over pci. System level stats is still available via ethtool. Signed-off-by:
-
Dmitry Bogdanov authored
This improves ethtool -S usage, where stats are now actual on each request. Before that stats only were updated at service timer period. Tested-by:
-
Igor Russkikh authored
Service timer callback fetches statistics from FW and that may cause a long delay in error cases. We also now need to use fw mutex to prevent concurrent access to FW, thus - extract that logic from timer callback into the job in the separate work queue. Signed-off-by:
-
Nikita Danilov authored
Some of FW operations could be invoked simultaneously, from f.e. ethtool context and from service service activity work. Here we introduce a fw mutex to secure and serialize access to FW logic. Signed-off-by:
-
Igor Russkikh authored
Typo in msi code. No much impact though. Signed-off-by:
-
Igor Russkikh authored
Improve for better readability Signed-off-by:
-
Igor Russkikh authored
Original code detected link only after 1 sec is passed after up. Here we replace this with direct service callback which updates link status immediately Signed-off-by:
-
Igor Russkikh authored
Here we define and request an extra interrupt line, assign it on link isr handler and restructure abit aq_pci code to better support that. We also remove logic for using different timer intervals depending on link state, since thats now useless. Signed-off-by:
-
Nikita Danilov authored
We need this to schedule link interrupt handling and various service tasks. Signed-off-by:
-
Igor Russkikh authored
Define link interrupt handler Signed-off-by:
-
Igor Russkikh authored
Declare macroes and nic fields to support link interrupt handling Signed-off-by:
-
Yana Esina authored
Added support for hwmon api to fetch out chip temperature Signed-off-by:
Yana Esina <yana.esina@aquantia.com> Signed-off-by:
Nikita Danilov <nikita.danilov@aquantia.com> Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Yana Esina authored
Ability to read the chip temperature from memory via hwmon interface Signed-off-by:
-
Heiner Kallweit authored
According to Neil who reported the issue leading to this workaround, the workaround is no longer needed since version 5.0. So let's remove it. This was the bug report leading to the workaround: https://bugzilla.kernel.org/show_bug.cgi?id=201081Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Tested-by:
Neil MacLeod <neil@nmacleod.com> Signed-off-by:
-
David S. Miller authored
Heiner Kallweit says: ==================== r8169: improve eri function handling This series aims at improving and simplifying the eri functions. No functional change intended. ==================== Signed-off-by: -
Heiner Kallweit authored
Fortunately in one place there's a comment explaining what toggling this bit does. So let's create a helper for it. Signed-off-by:
-
Heiner Kallweit authored
Add helpers rtl_eri_set_bits and rtl_eri_clear_bits to improve readability of the code. Signed-off-by:
-
Heiner Kallweit authored
In basically all eri function calls the type argument is ERIAR_EXGMAC. Therefore make it the default. Signed-off-by:
-
David S. Miller authored
Andrew Lunn says: ==================== Convert mv88e6060 to mdio device This patchset builds upon the previous patches to mv88e6060. It adds support for probing the switch as an MDIO device and then removes the legacy probe method. Since this is the last device supporting legacy probe, this allows legacy probe to be removed, originally planned to be removed in 4.17, but took a bit longer. This change to the mv88e6060 is more risky than the previous patchset. Some attempts to test it have been made, by hacking the driver to match on an mv88e6352 so that it probes. These changes are all about probe, so it is a reasonable test. But testing on a real mv88e6060 would be great. ==================== Signed-off-by: -
Andrew Lunn authored
Now that the code to support the legacy binding has been removed, remove the documentation for it. Signed-off-by:
-
Andrew Lunn authored
Now that all drivers can be probed using more traditional methods, remove the legacy probe code. Signed-off-by:
-
Andrew Lunn authored
Now that the driver can be probed as an mdio device, remove the legacy DSA platform device probing. Signed-off-by:
-
Andrew Lunn authored
Probing DSA devices as platform devices has been superseded by using normal bus drivers. Add support for probing the mv88e6060 device as an mdio device. Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Improvements to DSA core VLAN manipulation In preparation of submitting the NXP SJA1105 driver, the Broadcom b53 and Mediatek mt7530 drivers have been found to apply some VLAN workarounds that are needed in the new driver as well. Therefore this patchset is mostly simply promoting the DSA driver workarounds for VLAN to the generic code. The b53 driver was applying a few workarounds in order to convince DSA that its vlan_filtering setting is not really per-port. This is now simply set by the driver via a DSA variable at probe time. The sja1105 driver will be a second user of this. The mt7530 was also keeping track of when the .port_vlan_filtering callback was being called. Remove the kept state from this driver and simplify dealing with vlan_filtering in the generic case. TODO: Find the best way to deal generically with the situation described below (discussion at https://lkml.org/lkml/2019/4/16/1355): > > +Segregating the switch ports in multiple bridges is supported (e.g. 2 + 2), but > > +all bridges should have the same level of VLAN awareness (either both have > > +``vlan_filtering`` 0, or both 1). Also an inevitable limitation of the fact > > +that VLAN awareness is global at the switch level is that once a bridge with > > +``vlan_filtering`` enslaves at least one switch port, the other un-bridged > > +ports are no longer available for standalone traffic termination. > > That is quite a limitation that I don't think I had fully grasped until > reading your different patches. Since enslaving ports into a bridge > comes after the network device was already made available for use, maybe > you should force the carrier down or something along those lines as soon > as a port is enslaved into a bridge with vlan_filtering=1 to make this > more predictable for the user? ==================== Signed-off-by:
-
Vladimir Oltean authored
This hides the need to perform a two-phase transaction and construct a switchdev_obj_port_vlan struct. Call graph (including a function that will be introduced in a follow-up patch) looks like this now (same for the *_vlan_del function): dsa_slave_vlan_rx_add_vid dsa_port_setup_8021q_tagging | | | | | +-------------+ | | v v dsa_port_vid_add dsa_slave_port_obj_add | | +-------+ +-------+ | | v v dsa_port_vlan_add Signed-off-by:Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Vladimir Oltean authored
While possible (and safe) to use the newly introduced dsa_port_is_vlan_filtering helper, fabricating a dsa_port pointer is a bit awkward, so simply retrieve this from the dsa_switch structure. Signed-off-by:
-
Vladimir Oltean authored
Since DSA has recently learned to treat better with drivers that set vlan_filtering_is_global, doing this is no longer required. Signed-off-by:
-
Vladimir Oltean authored
Even if VLAN filtering is global, DSA will call this callback once per each port. Drivers should not have to compare the global state with the requested change. So let DSA do it. Signed-off-by:
-
Vladimir Oltean authored
This was recently introduced, so keeping state inside the driver is no longer necessary. Signed-off-by:
-
Vladimir Oltean authored
Since different types of hardware may or may not support this setting per-port, DSA keeps it either in dsa_switch or in dsa_port. While drivers may know the characteristics of their hardware and retrieve it from the correct place without the need of helpers, it is cumbersone to find out an unambigous answer from generic DSA code. Signed-off-by:
-
Vladimir Oltean authored
The current behavior is not as obvious as one would assume (which is that, if the driver set vlan_filtering_is_global = 1, then checking any dp->vlan_filtering would yield the same result). Only the ports which are actively enslaved into a bridge would have vlan_filtering set. This makes it tricky for drivers to check what the global state is. So fix this and make the struct dsa_switch hold this global setting. Signed-off-by:
-
Vladimir Oltean authored
The driver, recognizing that the .port_vlan_filtering callback was never coming after the port left its parent bridge, decided to take that duty in its own hands. DSA now takes care of this condition, so fix that. Signed-off-by:
-
Vladimir Oltean authored
When ports are standalone (after they left the bridge), they should have no VLAN filtering semantics (they should pass all traffic to the CPU). Currently this is not true for switchdev drivers, because the bridge "forgets" to unset that. Normally one would think that doing this at the bridge layer would be a better idea, i.e. call br_vlan_filter_toggle() from br_del_if(), similar to how nbp_vlan_init() is called from br_add_if(). However what complicates that approach, and makes this one preferable, is the fact that for the bridge core, vlan_filtering is a per-bridge setting, whereas for switchdev/DSA it is per-port. Also there are switches where the setting is per the entire device, and unsetting vlan_filtering one by one, for each leaving port, would not be possible from the bridge core without a certain level of awareness. So do this in DSA and let drivers be unaware of it. Signed-off-by:
-
Vladimir Oltean authored
The DSA core is now able to do this check prior to calling the .port_vlan_filtering callback, so tell it that VLAN filtering is global for this particular hardware. Signed-off-by:
-
