- 22 Aug, 2021 13 commits
-
-
Geetha sowjanya authored
Print debug message if any of the RVU hardware blocks reset fails. Signed-off-by:
Geetha sowjanya <gakula@marvell.com> Signed-off-by:
Sunil Goutham <sgoutham@marvell.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Subbaraya Sundeep authored
As per hardware the base channel number configured for programmable channels of a block must be multiple of number of channels of that block. This condition is not met for SDP base channel currently. Hence this patch ensures all the base channel numbers of all blocks are multiple of number of channels present in the blocks. Also instead of hardcoding SDP number of channels the same is read from the NIX_AF_CONST1 register. Fixes: 242da439 ("octeontx2-af: cn10k: Add support for programmable") Signed-off-by:
Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by:
-
Subbaraya Sundeep authored
'bp_ena' in Aura context is NIX block index, setting it zero will always backpressure NIX0 block, even if NIXLF belongs to NIX1. Hence fix this by setting it appropriately based on NIX block address. Signed-off-by:
Hariprasad Kelam <hkelam@marvell.com> Signed-off-by:
-
Rafał Miłecki authored
This helps validating DTS files. Introduced example binding changes: 1. Fixed reg formatting 2. Swapped #address-cells and #size-cells incorrect values 3. Renamed node: s/phy/ethernet-phy/ Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== DSA documentation updates for v5.15 There were some documentation-visible changes made to DSA in the net-next tree for v5.15. There may be more, but these are the ones I am aware of. ==================== Signed-off-by: -
Vladimir Oltean authored
Two new methods have been introduced, add some verbiage about what they do. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Vladimir Oltean authored
This function has disappeared in commit edac6f63 ("Revert "net: dsa: Allow drivers to filter packets they can decode source port from""). Also, since commit 4e500251 ("net: dsa: generalize overhead for taggers that use both headers and trailers"), the next paragraph is no longer true (it is still discouraged to do that, but it is now supported, so no point in mentioning it). Delete. Signed-off-by:
-
Vladimir Oltean authored
Remove the paragraphs that talk about the various modes of traffic support, bridging with foreign interfaces, etc etc. There is nothing that the user needs to know now, it should all work out of the box as expected. Signed-off-by:
-
Vladimir Oltean authored
The sja1105 driver has removed its devlink params, so there is nothing to see here. Signed-off-by:
-
David S. Miller authored
Alex Elder says: ==================== net: ipa: enable automatic suspend At long last, the first patch in this series enables automatic suspend managed by the power management core. The remaining two just rename things to be "power" oriented rather than "clock" oriented. ==================== Signed-off-by: -
Alex Elder authored
Finally, rename "ipa_clock.c" to be "ipa_power.c" and "ipa_clock.h" to be "ipa_power.h". Signed-off-by:
Alex Elder <elder@linaro.org> Signed-off-by:
-
Alex Elder authored
Rename a number of functions to clarify that there is no longer a notion of an "IPA clock," but rather that the functions are more generally related to IPA power management. ipa_clock_enable() -> ipa_power_enable() ipa_clock_disable() -> ipa_power_disable() ipa_clock_rate() -> ipa_core_clock_rate() ipa_clock_init() -> ipa_power_init() ipa_clock_exit() -> ipa_power_exit() Rename the ipa_clock structure to be ipa_power. Rename all variables and fields using that structure type "power" rather than "clock". Rename the ipa_clock_data structure to be ipa_power_data, and more broadly, just substitute "power" for "clock" in places that previously represented things related to the "IPA clock". Update comments throughout. Signed-off-by:
-
Alex Elder authored
Use runtime power management autosuspend. Up until this point, we only suspended the IPA hardware for system suspend; now we'll suspend it aggressively using runtime power management, setting the initial autosuspend delay to half a second of inactivity. Replace pm_runtime_put() calls with pm_runtime_put_autosuspend(), call pm_runtime_mark_last_busy() before each of those. In places where we're shutting things down, or decrementing power references for errors, use pm_runtime_put_noidle() instead. Finally, remove ipa_runtime_idle(), so the ->runtime_suspend callback will occur if idle. Signed-off-by:
-
- 20 Aug, 2021 27 commits
-
-
Jakub Kicinski authored
Merge tag 'mac80211-next-for-net-next-2021-08-20' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== Minor updates: * BSS coloring support * MEI commands for Intel platforms * various fixes/cleanups * tag 'mac80211-next-for-net-next-2021-08-20' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next: cfg80211: fix BSS color notify trace enum confusion mac80211: Fix insufficient headroom issue for AMSDU mac80211: add support for BSS color change nl80211: add support for BSS coloring mac80211: Use flex-array for radiotap header bitmap mac80211: radiotap: Use BIT() instead of shifts mac80211: Remove unnecessary variable and label mac80211: include <linux/rbtree.h> mac80211: Fix monitor MTU limit so that A-MSDUs get through mac80211: remove unnecessary NULL check in ieee80211_register_hw() mac80211: Reject zero MAC address in sta_info_insert_check() nl80211: vendor-cmd: add Intel vendor commands for iwlmei usage ==================== Link: https://lore.kernel.org/r/20210820105329.48674-1-johannes@sipsolutions.netSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
David S. Miller authored
Nikolay Aleksandrov says: ==================== net: bridge: mcast: add support for port/vlan router control This small set adds control over port/vlan mcast router config. Initially I had added host vlan entry router control via vlan's global options but that is really unnecessary and we can use a single per-vlan option to control it both for port/vlan and host/vlan entries. Since it's all still in net-next we can convert BRIDGE_VLANDB_GOPTS_MCAST_ROUTER to BRIDGE_VLANDB_ENTRY_MCAST_ROUTER and use it for both. That makes much more sense and is easier for user-space. Patch 01 prepares the port router function to be used with port mcast context instead of port and then patch 02 converts the global vlan mcast router option to per-vlan mcast router option which directly gives us both host/vlan and port/vlan mcast router control without any additional changes. This way we get the following coherent syntax: [ port/vlan mcast router] $ bridge vlan set vid 100 dev ens20 mcast_router 2 [ bridge/vlan mcast router ] $ bridge vlan set vid 100 dev bridge mcast_router 2 instead of: $ bridge vlan set vid 100 dev bridge mcast_router 1 global The mcast_router should not be regarded as a global option, it controls the port/vlan and bridge/vlan mcast router behaviour. This is the last set needed for the initial per-vlan mcast support. Next patch-sets: - iproute2 support - selftests ==================== Signed-off-by: -
Nikolay Aleksandrov authored
The per-vlan router option controls the port/vlan and host vlan entries' mcast router config. The global option controlled only the host vlan config, but that is unnecessary and incosistent as it's not really a global vlan option, but rather bridge option to control host router config, so convert BRIDGE_VLANDB_GOPTS_MCAST_ROUTER to BRIDGE_VLANDB_ENTRY_MCAST_ROUTER which can be used to control both host vlan and port vlan mcast router config. Signed-off-by:
Nikolay Aleksandrov <nikolay@nvidia.com> Signed-off-by:
-
Nikolay Aleksandrov authored
Change br_multicast_set_port_router to take port multicast context as its first argument so we can later use it to control port/vlan mcast router option. Signed-off-by:
-
Sunil Goutham authored
This patch ensures that mcam flows are allocated before adding or destroying the flows. Signed-off-by:
-
jing yangyang authored
This silences the following coccinelle warning: "WARNING: sum of probable bitmasks, consider |" Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
jing yangyang <jing.yangyang@zte.com.cn> Signed-off-by:
-
David S. Miller authored
Alex Elder says: ==================== net: ipa: kill off ipa_clock_get() This series replaces the remaining uses of ipa_clock_get() with calls to pm_runtime_get_sync() instead. It replaces all calls to ipa_clock_put() with calls to pm_runtime_put(). This completes the preparation for enabling automated suspend under the control of the power management core code. The next patch (in an upcoming series) enables that. Then the "ipa_clock" files and symbols will switch to using an "ipa_power" naming convention instead. Additional info It is possible for pm_runtime_get_sync() to return an error. There are really three cases, identified by return value: - 1, meaning power was already active - 0, meaning power was not previously active, but is now - EACCES, meaning runtime PM is disabled One additional case is EINVAL, meaning a previous suspend or resume (or idle) call returned an error. But we have always assumed this won't happen (we previously didn't even check for an error). But because we use pm_runtime_force_suspend() to implement system suspend, there's a chance we'd get an EACCES error (the first thing that function does is disable runtime suspend). Individual patches explain what happens in that case, but generally we just accept that it could be an unlikely problem (occurring only at startup time). Similarly, pm_runtime_put() could return an error. There too, we ignore EINVAL, assuming the IPA suspend and resume operations won't produce an error. EBUSY and EPERM are not applicable, EAGAIN is not expected (and harmless). We should never get EACCES (runtime suspend disabled), because pm_runtime_put() calls match prior pm_runtime_get_sync() calls, and a system suspend will not be started while a runtime suspend or resume is underway. In summary, the value returned from pm_runtime_put() is not meaningful, so we explicitly ignore it. ==================== Signed-off-by: -
Alex Elder authored
The only remaining user of the ipa_clock_{get,put}() interface is ipa_isr_thread(). Replace calls to ipa_clock_get() there calling pm_runtime_get_sync() instead. And call pm_runtime_put() there rather than ipa_clock_put(). Warn if we ever get an error. With that, we can get rid of ipa_clock_get() and ipa_clock_put(). Signed-off-by: -
Alex Elder authored
When we open or close the modem network device we need to ensure the hardware is powered. Replace the callers of ipa_clock_get() found in ipa_open() and ipa_stop() with calls to pm_runtime_get_sync(). If an error is returned, simply return that error to the caller (without any error or warning message). This could conceivably occur if the function was called while the system was suspended, but that really shouldn't happen. Replace corresponding calls to ipa_clock_put() with pm_runtime_put() also. If the modem crashes we also need to ensure the hardware is powered to recover. If getting power returns an error there's not much we can do, but at least report the error. (Ideally the remoteproc SSR code would ensure the AP was not suspended when it sends the notification, but that is not (yet) the case.) Signed-off-by:
-
Alex Elder authored
Replace the ipa_clock_get() call in ipa_uc_clock() when taking the "proxy" clock reference for the microcontroller with a call to pm_runtime_get_sync(). Replace calls of ipa_clock_put() for the microcontroller with pm_runtime_put() calls instead. There is a chance we get an error when taking the microcontroller power reference. This is an unlikely scenario, where system suspend is initiated just before we learn the modem is booting. For now we'll just accept that this could occur, and report it if it does. Signed-off-by:
-
Alex Elder authored
If the "modem-init" Device Tree property is present for a platform, the modem performs early IPA hardware initialization, and signals this is complete with an "ipa-setup-ready" SMP2P interrupt. This triggers a call to ipa_setup(), which requires the hardware to be powered. Replace the call to ipa_clock_get() in this case with a call to pm_runtime_get_sync(). And replace the corresponding calls to ipa_clock_put() with calls to pm_runtime_put() instead. There is a chance we get an error when taking this power reference. This is an unlikely scenario, where system suspend is initiated just before the modem signals it has finished initializing the IPA hardware. For now we'll just accept that this could occur, and report it if it does. Signed-off-by:
-
Alex Elder authored
We need the hardware to be powered starting at the config stage of initialization when the IPA driver probes. And we need it powered when the driver is removed, at least until the deconfig stage has completed. Replace callers of ipa_clock_get() in ipa_probe() and ipa_exit(), calling pm_runtime_get_sync() instead. Replace the corresponding callers of ipa_clock_put(), calling pm_runtime_put() instead. The only error we expect when getting power would occur when the system is suspended. The ->probe and ->remove driver callbacks won't be called when suspended, so issue a WARN() call if an error is seen getting power. Signed-off-by:
-
Alex Elder authored
Jakub Kicinski pointed out a race condition in ipa_start_xmit() in a recently-accepted series of patches: https://lore.kernel.org/netdev/20210812195035.2816276-1-elder@linaro.org/ We are stopping the modem TX queue in that function if the power state is not active. We restart the TX queue again once hardware resume is complete. TX path Power Management ------- ---------------- pm_runtime_get(); no power Start resume Stop TX queue ... pm_runtime_put() Resume complete return NETDEV_TX_BUSY Start TX queue pm_runtime_get() Power present, transmit pm_runtime_put() (auto-suspend) The issue is that the power management (resume) activity and the network transmit activity can occur concurrently, and there's a chance the queue will be stopped *after* it has been started again. TX path Power Management ------- ---------------- Resume underway pm_runtime_get(); no power ... Resume complete Start TX queue Stop TX queue <-- No more transmits after this pm_runtime_put() return NETDEV_TX_BUSY We address this using a STARTED flag to indicate when the TX queue has been started from the resume path, and a spinlock to make the flag and queue updates happen atomically. TX path Power Management ------- ---------------- Resume underway pm_runtime_get(); no power Resume complete start TX queue \ If STARTED flag is *not* set: > atomic Stop TX queue set STARTED flag / pm_runtime_put() return NETDEV_TX_BUSY A second flag is used to address a different race that involves another path requesting power. TX path Other path Power Management ------- ---------- ---------------- pm_runtime_get_sync() Resume Start TX queue \ atomic Set STARTED flag / (do its thing) pm_runtime_put() (auto-suspend) pm_runtime_get() Mark delayed resume STARTED *is* set, so do *not* stop TX queue <-- Queue should be stopped here pm_runtime_put() return NETDEV_TX_BUSY Suspend done, resume Resume complete pm_runtime_get() Stop TX queue (STARTED is *not* set) Start TX queue \ atomic pm_runtime_put() Set STARTED flag / return NETDEV_TX_BUSY So a STOPPED flag is set in the transmit path when it has stopped the TX queue, and this pair of operations is also protected by the spinlock. The resume path only restarts the TX queue if the STOPPED flag is set. This case isn't a major problem, but it avoids the "non-trivial amount of useless work" done by the networking stack when NETDEV_TX_BUSY is returned. Fixes: 6b51f802 ("net: ipa: ensure hardware has power in ipa_start_xmit()") Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Small ocelot VLAN improvements This small series propagates some VLAN restrictions via netlink extack and creates some helper functions instead of open-coding VLAN table manipulations from multiple places. This is split from the larger "DSA FDB isolation" series, hence the v2 tag: https://patchwork.kernel.org/project/netdevbpf/cover/20210818120150.892647-1-vladimir.oltean@nxp.com/ ==================== Signed-off-by:
-
Vladimir Oltean authored
This is a mostly cosmetic patch that creates some helpers for accessing the VLAN table. These helpers are also a bit more careful in that they do not modify the ocelot->vlan_mask unless the hardware operation succeeded. Not all callers check the return value (the init code doesn't), but anyway. Signed-off-by:
-
Vladimir Oltean authored
We need to transmit more restrictions in future patches, convert this one to netlink extack. Signed-off-by:
-
Vladimir Oltean authored
We need to reject some more configurations in future patches, convert the existing one to netlink extack. Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Ocelot phylink fixes This series addresses a regression reported by Horatiu which introduced by the ocelot conversion to phylink: there are broken device trees in the wild, and the driver fails to probe the entire switch when a port fails to probe, which it previously did not do. Continue probing even when some ports fail to initialize properly. ==================== Signed-off-by: -
Vladimir Oltean authored
The existing ocelot device trees, like ocelot_pcb123.dts for example, have SERDES ports (ports 4 and higher) that do not have status = "disabled"; but on the other hand do not have a phy-handle or a fixed-link either. So from the perspective of phylink, they have broken DT bindings. Since the blamed commit, probing for the entire switch will fail when such a device tree binding is encountered on a port. There used to be this piece of code which skipped ports without a phy-handle: phy_node = of_parse_phandle(portnp, "phy-handle", 0); if (!phy_node) continue; but now it is gone. Anyway, fixed-link setups are a thing which should work out of the box with phylink, so it would not be in the best interest of the driver to add that check back. Instead, let's look at what other drivers do. Since commit 86f8b1c0 ("net: dsa: Do not make user port errors fatal"), DSA continues after a switch port fails to register, and works only with the ports that succeeded. We can achieve the same behavior in ocelot by unregistering the devlink port for ports where ocelot_port_phylink_create() failed (called via ocelot_probe_port), and clear the bit in devlink_ports_registered for that port. This will make the next iteration reconsider the port that failed to probe as an unused port, and re-register a devlink port of type UNUSED for it. No other cleanup should need to be performed, since ocelot_probe_port() should be self-contained when it fails. Fixes: e6e12df6 ("net: mscc: ocelot: convert to phylink") Reported-and-tested-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
-
Horatiu Vultur authored
There are cases where we would like to continue probing the switch even if one port has failed to probe. When that happens, we need to unregister a devlink_port of type DEVLINK_PORT_FLAVOUR_PHYSICAL and re-register it of type DEVLINK_PORT_FLAVOUR_UNUSED. This is fine, except when calling devlink_port_attrs_set on a structure on which devlink_port_register has been previously called, there is a WARN_ON in devlink_port_attrs_set that devlink_port->devlink must be NULL. So don't assume that the memory behind dlp is clean when calling ocelot_port_devlink_init, just zero-initialize it. Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== dpaa2-switch phylink fixes This is fixing two regressions introduced by the recent conversion of the dpaa2-switch driver to phylink. ==================== Signed-off-by: -
Vladimir Oltean authored
Currently when probing returns an error, the netdev is freed but phylink_disconnect is not called. Create a common function between the unbind path and the error path, call it the opposite of dpaa2_switch_probe_port: dpaa2_switch_remove_port, and call it from both the unbind and the error path. Fixes: 84cba729 ("dpaa2-switch: integrate the MAC endpoint support") Signed-off-by:
Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by:
-
Vladimir Oltean authored
There is an ASSERT_RTNL in phylink_disconnect_phy which triggers whenever dpaa2_switch_port_disconnect_mac is called. To follow the pattern established by dpaa2_eth_disconnect_mac, take the rtnl_mutex every time we call dpaa2_switch_port_disconnect_mac. Fixes: 84cba729 ("dpaa2-switch: integrate the MAC endpoint support") Signed-off-by:
-
David S. Miller authored
Gerhard Engleder says: ==================== Add Xilinx GMII2RGMII loopback support The Xilinx GMII2RGMII driver overrides PHY driver functions in order to configure the device according to the link speed of the PHY attached to it. This is implemented for a normal link but not for loopback. Andrew told me to use phy_loopback and this changes make phy_loopback work in combination with Xilinx GMII2RGMII. ==================== Signed-off-by: -
Gerhard Engleder authored
Configure speed if loopback is used. read_status is not called for loopback. Signed-off-by:
Gerhard Engleder <gerhard@engleder-embedded.com> Signed-off-by:
-
Gerhard Engleder authored
struct phy_device contains a pointer to the PHY driver and nearly everywhere this pointer is used to access the PHY driver. Only mdio_bus_phy_may_suspend() is still using to_phy_driver() instead of the PHY driver pointer. Uniform PHY driver access by eliminating to_phy_driver() use in mdio_bus_phy_may_suspend(). Only phy_bus_match() and phy_probe() are still using to_phy_driver(), because PHY driver pointer is not available there. Signed-off-by:
-
Gerhard Engleder authored
phy_read_status and various other PHY functions support PHY specific overriding of driver functions by using a PHY specific pointer to the PHY driver. Add support of PHY specific override to phy_loopback too. Signed-off-by:
-
