- 29 Jun, 2016 15 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== 40GbE Intel Wired LAN Driver Updates 2016-06-27 This series contains updates to i40e and i40evf only. Mitch provides several changes, first adds functions to enable and disable VSI on a VEB, which allows for configuration of limited promiscuous mode specifically for bridging purposes. Sets the RSS Hash Enable registers by default now that VF RSS is configured by the PF driver. Fixed a issue where we could overflow the buffer, by checking the address count and bail out of the loop at the appropriate time. Removed the need for a reset when the device enters limited promiscuous mode, since this was causing heartburn for people who were using VFs and bridging. Catherine adds a call to set the client interface down when we put the VSI down. Fixed an issue where RSS queues was being limited to the number of CPUs, so if a user wants to use more queues than CPUs, we want to trust they know what they are doing and let them. Greg cleans up the driver suspend routine to ensure we are calling synchronize_irq() before freeing IRQ vectors and explicitly free the other causes interrupt resources and shut down the MSIX interrupt. Serey fixes i40e_set_settings() to not fail when a Direct Attach (DA) cable is used. Avinash fixes a supported link bug by removing code which was not allowing 100BaseT to show up in the supported link modes for 10GBaseT PHYs. Shannon adds a bit of information to the error messages to help determine the source of error by adding VSI info to macaddr messages. Tushar Dave fixes error received when turning off TSO on some systems, which was caused by enabling FD_SB without checking availability of MSIx vectors, so add the check. Neerav fixes a possible panic when LLDP/DCBX change happens and the driver tried to notify the client(s) for each of the PF VSIs, which would panic when it reached a VSI that did not have any netdev associated with it. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Philippe Reynes authored
There are two generics functions phy_ethtool_{get|set}_link_ksettings, so we can use them instead of defining the same code in the driver. Signed-off-by:Philippe Reynes <tremyfr@gmail.com> Signed-off-by:
-
Philippe Reynes authored
The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phydev in the private structure, and update the driver to use the one contained in struct net_device. Signed-off-by:
-
Eric Dumazet authored
If skb_unshare() fails, we call qdisc_drop() with a NULL skb, which is no longer supported. Fixes: 520ac30f ("net_sched: drop packets after root qdisc lock is released") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
David S. Miller authored
Sudarsana Reddy Kalluru says: ==================== qed*: Fix the static checker warnings. The patch series addresses the static checker warnings introduced by the earlier patches related to qed/qede coalesce configuration support. ==================== Signed-off-by: -
Sudarsana Reddy Kalluru authored
Static checker warnings: drivers/net/ethernet/qlogic/qede/qede_ethtool.c:435 qede_get_coalesce() warn: passing casted pointer '&coal->rx_coalesce_usecs' to 'edev->ops->common->get_coalesce()' 32 vs 16. The u32 pointer is being typecasted to u16 which may fail for big-endian platforms. Fixes: d552fa84 ("qede: Add support for coalescing config read/update.") Reported-by:
Sudarsana Reddy Kalluru <sudarsana.kalluru@qlogic.com> Signed-off-by:
-
Sudarsana Reddy Kalluru authored
Static checker warnings: drivers/net/ethernet/qlogic/qed/qed_int.c:2450 qed_init_cau_sb_entry() warn: always true condition '(cdev->rx_coalesce_usecs <= 255) => (0-255 <= 255)' drivers/net/ethernet/qlogic/qed/qed_int.c:2511 qed_int_cau_conf_sb() warn: always true condition '(p_hwfn->cdev->rx_coalesce_usecs <= 255) => (0-255 <= 255)' .. The data types for rx/tx_coalesce_usecs should be u16. Fixes: commit 722003ac ("qed: Add support for coalescing config read/update.") Reported-by:
-
Philippe Reynes authored
There are two generics functions phy_ethtool_{get|set}_link_ksettings, so we can use them instead of defining the same code in the driver. Signed-off-by: -
Philippe Reynes authored
The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phydev in the private structure, and update the driver to use the one contained in struct net_device. Signed-off-by:
-
Richard Alpe authored
Context implies that port in struct "udp_media_addr" is referring to a UDP port. Signed-off-by:
Richard Alpe <richard.alpe@ericsson.com> Acked-by:
Jon Maloy <jon.maloy@ericsson.com> Acked-by:
Ying Xue <ying.xue@windriver.com> Signed-off-by:
-
Richard Alpe authored
The UDP msg2addr function tipc_udp_msg2addr() can return -EINVAL which prior to this patch was unhanded in the caller. Signed-off-by:
-
Wei Tang authored
The space is missing before the open parenthesis '(', and this will introduce much more noise when checking patch around. Signed-off-by:Wei Tang <tangwei@cmss.chinamobile.com> Signed-off-by:
-
Arnd Bergmann authored
In some configurations, gcc produces a warning for correct code in this driver: drivers/net/dsa/b53/b53_mmap.c: In function 'b53_mmap_read64': drivers/net/dsa/b53/b53_mmap.c:107:10: error: 'hi' may be used uninitialized in this function [-Werror=maybe-uninitialized] *val = ((u64)hi << 32) | lo; ^~~~~~~ drivers/net/dsa/b53/b53_mmap.c: In function 'b53_mmap_read48': drivers/net/dsa/b53/b53_mmap.c:91:11: error: 'hi' may be used uninitialized in this function [-Werror=maybe-uninitialized] *val = ((u64)hi << 32) | lo; ^~~~~~~ drivers/net/dsa/b53/b53_mmap.c:83:11: error: 'hi' may be used uninitialized in this function [-Werror=maybe-uninitialized] *val = ((u64)hi << 16) | lo; I have seen the warning before and at the time thought I had fixed it with 55e7f6ab ("dsa: b53: fix big-endian register access"), however it now came back in a different randconfig build that happens to have different inlining decisions in the compiler. The mistake that gcc makes here is that it thinks the second call to readl() might fail because the address 'reg + 4' is not a multiple of four despite having knowing that 'reg' itself is a multiple of four. By open-coding the two reads without the redundant alignment check, we can avoid the warning and produce slightly better object code, but get slightly longer source code instead. Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Grygorii Strashko authored
TI CPDMA currently uses a bitmap for tracking descriptors alloactions allocations, but The genalloc already handles the same and can be used as with special memory (SRAM) as with DMA cherent memory chank (dma_alloc_coherent()). Hence, switch to using genalloc and add desc_num property for each channel for limitation of max number of allowed descriptors for each CPDMA channel. This patch do not affect on net throuput. Acked-by:
Mugunthan V N <mugunthanvnm@ti.com> Tested-by:
Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
-
Zhao Qiang authored
Signed-off-by:
Zhao Qiang <qiang.zhao@nxp.com> Signed-off-by:
-
- 28 Jun, 2016 25 commits
-
-
Philippe Reynes authored
There are two generics functions phy_ethtool_{get|set}_link_ksettings, so we can use them instead of defining the same code in the driver. Signed-off-by: -
Philippe Reynes authored
The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phydev in the private structure, and update the driver to use the one contained in struct net_device. Signed-off-by:
-
Philippe Reynes authored
There are two generics functions phy_ethtool_{get|set}_link_ksettings, so we can use them instead of defining the same code in the driver. Signed-off-by: -
Philippe Reynes authored
The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phydev in the private structure, and update the driver to use the one contained in struct net_device. Signed-off-by:
-
Philippe Reynes authored
There are two generics functions phy_ethtool_{get|set}_link_ksettings, so we can use them instead of defining the same code in the driver. Signed-off-by: -
Philippe Reynes authored
The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phydev in the private structure, and update the driver to use the one contained in struct net_device. Signed-off-by:
-
Philippe Reynes authored
There are two generics functions phy_ethtool_{get|set}_link_ksettings, so we can use them instead of defining the same code in the driver. Signed-off-by: -
Philippe Reynes authored
The private structure contain a pointer to phydev, but the structure net_device already contain such pointer. So we can remove the pointer phy in the private structure, and update the driver to use the one contained in struct net_device. Signed-off-by:
-
David S. Miller authored
Grygorii Strashko says: ==================== drivers: net: cpsw: improve runtime pm This series intended to improve runtime PM and allow CPSW to be RPM suspended when all ethX netdevices are down. To achieve above goal it is required to relax runtime PM constraints for Davinci MDIO which blocks CPSW runtime PM now, because Davinci MDIO is always powered on during probe and powered off only when it's going to be removed. - Patches 6-11 implement PM runtime autosuspend for Davinci MDIO, but keep it disabled by default, because Davinci MDIO is integrated in big set of TI devices and not all of them verified to work correctly with RPM autosuspend enabled: expected to work on SoCs where MDIO is defined as part of CPSW in DT (cpsw.c DRA7/am57x, am437x, am335x) The CPSW need to be fixed before RPM suspended can be allowed: - Patches 1-5 ensure that CPSW will not cause L3 errors while it is in RPM suspended state. Davinci MDIO RPM autosuspend can be enabled through sysfs: echo 100 > /sys/devices/../48484000.ethernet/48485000.mdio/power/autosuspend_delay_ms Patches 12 - 15: introduce new compatible string "ti,cpsw-mdio" which is used then to enable RPM for am335x/am437x/dra7 SoCs. Tested on am335x, am437x, am572x and k2g (on k2g with RPM disabled for Davinci MDIO) These changes should not affect on errata i877 implementation on DRA7. Power measurement on am335x GP EVM: Without this series: 547.60 mW total SoC power With this series + "ifconfig eth0 down": 477.32 mW Total Soc Power Changes in v2: - CPSW ethtool interface updated to use .begin()/.complete() callbacks - kbuild failure fixed - davinci_mdio DT updated with proper description of allowed compatible strings combinations Link on v1: https://lkml.org/lkml/2016/6/15/362 ==================== Reviewed-by:
-
Grygorii Strashko authored
Add "ti,cpsw-mdio" for am335x/am437x/dra7 SoCs where MDIO is implemented as part of TI CPSW and, this way, enable PM runtime auto suspend for Davinci MDIO driver on these paltforms. Signed-off-by:
-
Grygorii Strashko authored
Use "ti,cpsw-mdio" to enable PM runtime auto-suspend on supported platforms, where MDIO is implemented as part of TI CPSW. Signed-off-by:
-
Grygorii Strashko authored
Introduce "ti,cpsw-mdio" compatible string for Davinci MDIO, because it's required to distinguish the case when MDIO is part of TI CPSW to enable features supported by TI CPSW (for example, enable PM management). Signed-off-by:
-
Grygorii Strashko authored
Document missed "ti,am4372-mdio" compat string used for TI am437x SoC (am4372.dtsi). Signed-off-by:
-
Grygorii Strashko authored
Davinci MDIO is always used as slave device which services read/write requests from MDIO/PHY core. It doesn't use IRQ also. As result, It's possible to relax PM runtime constraints for Davinci MDIO and enable it on demand, instead of powering it during probe and powering off during removal. Hence, implement PM runtime autosuspend for Davinci MDIO, but keep it disabled by default, because Davinci MDIO is integrated in big set of TI devices and not all of them expected to work corectly with RPM autosuspend enabled: - expected to work on SoCs where MDIO is part of TI CPSW (cpsw.c DRA7/am57x, am437x, am335x, dm814x) - not verified on Keystone 2 and other SoCs where MDIO is used with TI EMAC IP (davinci_emac.c: dm6467-emac, am3517-emac, dm816-emac). Davinci MDIO RPM autosuspend can be enabled through sysfs: echo 100 > /sys/devices/../48484000.ethernet/48485000.mdio/power/autosuspend_delay_ms Signed-off-by:
-
Grygorii Strashko authored
Add PM runtime .runtime_suspend()/.runtime_resume() callbacks and perform Davinci MDIO enabling/disabling from these callbacks. This allows to reuse pm_runtime_force_suspend/resume() APIs during System suspend and required for further implementation of PM runtime autosuspend. Signed-off-by:
-
Grygorii Strashko authored
The Davinci MDIO MDIO_CONTROL.CLKDIV can be calculated only once during probe, hence split __davinci_mdio_reset() on davinci_mdio_init_clk() and davinci_mdio_enable(). Initialize and save CLKDIV in .probe(). Then just use saved value. Signed-off-by:
-
Grygorii Strashko authored
It's not expected Davinci MDIO to be accessible after its suspend callbacks have been called: - all consumers of Davinci MDIO will stop/disconnect phys at Device suspend stage; - all phys are expected to be suspned already by PHY/MDIO core; - MDIO locking is done by MDIO Bus code. Hence, it's safe to drop "suspended" and "lock" fields from mdio_data. Signed-off-by:
-
Grygorii Strashko authored
PM runtime is disabled when Davinci MDIO .suspend_late() and .resume_early() callbacks are called. As result, any PM runtime calls here will be just a nop and can be removed. Signed-off-by:
-
Grygorii Strashko authored
Do PM runtime initialization later in probe - this allows to simplify error handling a bit. Signed-off-by:
-
Grygorii Strashko authored
The CPSW might be suspended by RPM if all ethX interfaces are down, but it still could be accesible through net_device_ops interfce. In this case net_device_ops operations requiring registers access will cause L3 errors and CPSW crash. Hence, fix it by adding RPM get/put calls in net_device_ops callbacks which need to access CPSW registers: .ndo_set_mac_address(), .ndo_vlan_rx_add_vid(), .ndo_vlan_rx_kill_vid(). Signed-off-by:
-
Grygorii Strashko authored
The CPSW might be suspended by RPM if all ethX interfaces are down, but it still could be accesible through ethtool interfce. In this case ethtool operations, requiring registers access, will cause L3 errors and CPSW crash. ethtool callbcaks which need to access CPSW registers now: .set_coalesce(), .get_ethtool_stats(), .set_pauseparam(), .get_regs() Hence, fix it by adding .begin()/.complete() ethtool callbacks, which will be called before/after each ethtool operation runs, and do CPSW RPM handling in these callbacks. That way CPSW will be active while handling ethtool requests. Signed-off-by:
-
Grygorii Strashko authored
PM runtime is properly handled in cpsw_ndo_open/stop(), as result it isn't required to duplicate these calls in .suspend()/.resume() callbacks. Moreover, it might cause unnecessary RPM resume of CPSW during System suspend in the case it's already suspended because all ethX interfaces are down already, before System suspend started. Signed-off-by:
-
Grygorii Strashko authored
Add missed check of return code from PM runtime get() calls. Signed-off-by:
-
Grygorii Strashko authored
The cpsw_suspend() could trigger L3 error and CPSW will stop functioning if System enters suspend when all ethX net-devices are down - in this case CPSW could be already suspended by PM runtime, but cpsw_suspend() will try to call soft_reset_slave() unconditionally and access CPSW registers. Hence, fix it by moving soft_reset_slave() from cpsw_suspend() to cpsw_slave_stop(). This way slave ports will be reset when CPSW is active and will be in proper state during Suspend. Signed-off-by:
-
David S. Miller authored
Giuseppe Cavallaro says: ==================== stmmac: rework and enhance the PCS support The 3.xx and 4.xx synopsys gmacs have a very similar PCS embedded module and they share almost the same registers; for example: AN_Control, AN_Status, AN_Advertisement, AN_Link_Partner_Ability, AN_Expansion, TBI_Extended_Status. Just the RGMII/SMII Control/Status register differs. So these patches aim to reorganize and enhance the PCS support; to do that, some small inline functions have been provided and also some rework to the PCS ISR part has been done. In the end, the SGMII for MAC2MAC connection has been introduced. All patches have been built on top of net-next git and, as for the previous version, not fully tested. ==================== Signed-off-by:
-
