- 13 Sep, 2019 21 commits
-
-
Tsang-Shian Lin authored
Enable 8822C Tx/Rx interrupt migration. In some platforms, performance test may cause heavy cpu loading and get bad results. Interrupt migration can decrease the amount of interrupts, and lower cpu loading. Signed-off-by:
Tsang-Shian Lin <thlin@realtek.com> Signed-off-by:
Yan-Hsuan Chuang <yhchuang@realtek.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org>
-
Chin-Yen Lee authored
update sequence to v13 to reduce power consumption when MAC power off Signed-off-by:
Chin-Yen Lee <timlee@realtek.com> Signed-off-by:
-
Yan-Hsuan Chuang authored
Update PHY hardware parameters to v38. Signed-off-by:
-
Larry Finger authored
rtlwifi: rtl8188ee: rtl8192ce: rtl8192de: rtl8723ae: rtl8821ae: Remove some unused bit manipulation macros Each of these drivers defines some device to host macros that are never used, thus they can be removed. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Larry Finger authored
In this step, the read/write routines for the descriptors are converted to use __le32 quantities, thus a lot of casts can be removed. Callback routines still use the 8-bit arrays, but these are changed within the specified routine. The macro that cleared a descriptor has now been converted into an inline routine. Signed-off-by:
-
Larry Finger authored
As a first step in the conversion, the macros that set the RX and TX descriptors are converted to static inline routines, and the names are changed from upper to lower case. To minimize the changes in a given step, the input descriptor information is left as as a byte array (u8 *), even though it should be a little-endian word array (__le32 *). That will be changed in the next patch. Several places where checkpatch.pl complains about a space after a cast are fixed. Signed-off-by:
-
Larry Finger authored
This driver uses a set of local macros to manipulate the RX and TX descriptors, which are all little-endian quantities. These macros are replaced by the bitfield macros le32p_replace_bits() and le32_get_bits(). In several places, the macros operated on an entire 32-bit word. In these cases, a direct read or replacement is used. Signed-off-by:
-
Larry Finger authored
iAs the first step in converting from macros that get/set information in the RX and TX descriptors, unused macros are being removed. Signed-off-by:
-
Larry Finger authored
In this step, the read/write routines for the descriptors are converted to use __le32 quantities, thus a lot of casts can be removed. Callback routines still use the 8-bit arrays, but these are changed within the specified routine. The macro that cleared a descriptor has now been converted into an inline routine. Signed-off-by:
-
Larry Finger authored
As a first step in the conversion, the macros that set the RX and TX descriptors are converted to static inline routines, and the names are changed from upper to lower case. To minimize the changes in a given step, the input descriptor information is left as as a byte array (u8 *), even though it should be a little-endian word array (__le32 *). That will be changed in the next patch. Several places where checkpatch.pl reports lines too long are fixed. Signed-off-by:
-
Larry Finger authored
This driver uses a set of local macros to manipulate the RX and TX descriptors, which are all little-endian quantities. These macros are replaced by the bitfield macros le32p_replace_bits() and le32_get_bits(). In several places, the macros operated on an entire 32-bit word. In these cases, a direct read or replacement is used. Signed-off-by:
-
Larry Finger authored
As the first step in converting from macros that get/set information in the RX and TX descriptors, unused macros are being removed. Signed-off-by:
-
Lubomir Rintel authored
With the commit e86dc1ca ("Libertas: cfg80211 support") we've lost the ability to actually set the Mesh SSID from userspace. NL80211_CMD_SET_INTERFACE with NL80211_ATTR_MESH_ID sets the mesh point interface's ssid field. Let's use that one for the Libertas Mesh operation Signed-off-by:
Lubomir Rintel <lkundrak@v3.sk> Signed-off-by:
-
Colin Ian King authored
Don't populate the array pwr_info_offset on the stack but instead make it static const. Makes the object code smaller by 207 bytes. Before: text data bss dec hex filename 26066 3000 64 29130 71ca drivers/ssb/pci.o After: text data bss dec hex filename 25763 3096 64 28923 70fb drivers/ssb/pci.o (gcc version 9.2.1, amd64) Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Michael Büsch <m@bues.ch> Signed-off-by:
-
Luis Correia authored
Signed-off-by:
Luis Correia <luisfcorreia@gmail.com> Signed-off-by:
-
zhong jiang authored
The kernel.h macro DIV_ROUND_CLOSEST performs the computation (x + d/2)/d but is perhaps more readable. Signed-off-by:
zhong jiang <zhongjiang@huawei.com> Signed-off-by:
-
Colin Ian King authored
Arrays pwr_info_offset and sprom_sizes can be make static const rather than populating them on the stack. Shrinks object size by 236 bytes. Before: text data bss dec hex filename 11300 1320 64 12684 318c drivers/bcma/sprom.o After: text data bss dec hex filename 10904 1480 64 12448 30a0 drivers/bcma/sprom.o (gcc version 9.2.1, amd64) Signed-off-by:
-
Colin Ian King authored
The array channel_all can be make static const rather than populating it on the stack, this makes the code smaller. Also, variable place is being initialized with a value that is never read, so this assignment is redundant and can be removed. Before: text data bss dec hex filename 118537 9591 0 128128 1f480 realtek/rtlwifi/rtl8821ae/phy.o After: text data bss dec hex filename 118331 9687 0 128018 1f412 realtek/rtlwifi/rtl8821ae/phy.o Saves 110 bytes, (gcc version 9.2.1, amd64) Signed-off-by:
-
Rafał Miłecki authored
Providing a new wiphy on every PCIe reset was confusing and was causing configuration problems for some users (supplicant and authenticators). Sticking to the existing wiphy should make error recovery much simpler and more reliable. Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Acked-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
-
Rafał Miłecki authored
Move code allocating/freeing wiphy out of above functions. This will allow reinitializing the driver (e.g. on some error) without allocating a new wiphy. Signed-off-by:
-
Rafał Miłecki authored
This moves "ops" pointer from "struct brcmf_cfg80211_info" to the "struct brcmf_pub". This movement makes it possible to allocate wiphy without attaching cfg80211 (brcmf_cfg80211_attach()). It's required for later separation of wiphy allocation and driver initialization. While at it fix also an unlikely memory leak in the brcmf_attach(). Signed-off-by:
-
- 12 Sep, 2019 5 commits
-
-
Arkadiusz Drabczyk authored
Fix several spelling typos in comments in t4_hw.c. Signed-off-by:
Arkadiusz Drabczyk <arkadiusz@drabczyk.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
George McCollister says: ==================== add ksz9567 with I2C support to ksz9477 driver Resurrect KSZ9477 I2C driver support patch originally sent to the list by Tristram Ha and resolve outstanding issues. It now works as similarly to the ksz9477 SPI driver as possible, using the same regmap macros. Add support for ksz9567 to the ksz9477 driver (tested on a board with ksz9567 connected via I2C). Remove NET_DSA_TAG_KSZ_COMMON since it's not needed. Changes since v1: Put ksz9477_i2c.c includes in alphabetical order. Added Reviewed-Bys. ==================== Signed-off-by: -
George McCollister authored
Remove the superfluous NET_DSA_TAG_KSZ_COMMON and just use the existing NET_DSA_TAG_KSZ. Update the description to mention the three switch families it supports. No functional change. Signed-off-by:
George McCollister <george.mccollister@gmail.com> Reviewed-by:
Marek Vasut <marex@denx.de> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
George McCollister authored
Add support for the KSZ9567 7-Port Gigabit Ethernet Switch to the ksz9477 driver. The KSZ9567 supports both SPI and I2C. Oddly the ksz9567 is already in the device tree binding documentation. Signed-off-by:
-
Tristram Ha authored
Add KSZ9477 I2C driver support. The code ksz9477.c and ksz_common.c are used together to generate the I2C driver. Signed-off-by:
Tristram Ha <Tristram.Ha@microchip.com> [george.mccollister@gmail.com: bring up to date, use ksz_common regmap macros] Signed-off-by:
-
- 11 Sep, 2019 14 commits
-
-
Dirk van der Merwe authored
The PluDevice register provides the authoritative chip model/revision. Since the model number is purely used for reporting purposes, follow the hardware team convention of subtracting 0x10 from the PluDevice register to obtain the chip model/revision number. Suggested-by:
Francois H. Theron <francois.theron@netronome.com> Signed-off-by:
Dirk van der Merwe <dirk.vandermerwe@netronome.com> Signed-off-by:
Simon Horman <simon.horman@netronome.com> Signed-off-by:
-
Eric Dumazet authored
When tcp sends a TSO packet, adding a PSH flag on it reduces the sojourn time of GRO packet in GRO receivers. This is particularly the case under pressure, since RX queues receive packets for many concurrent flows. A sender can give a hint to GRO engines when it is appropriate to flush a super-packet, especially when pacing is in the picture, since next packet is probably delayed by one ms. Having less packets in GRO engine reduces chance of LRU eviction or inflated RTT, and reduces GRO cost. We found recently that we must not set the PSH flag on individual full-size MSS segments [1] : Under pressure (CWR state), we better let the packet sit for a small delay (depending on NAPI logic) so that the ACK packet is delayed, and thus next packet we send is also delayed a bit. Eventually the bottleneck queue can be drained. DCTCP flows with CWND=1 have demonstrated the issue. This patch allows to slowdown the aggregate traffic without involving high resolution timers on senders and/or receivers. It has been used at Google for about four years, and has been discussed at various networking conferences. [1] segments smaller than MSS already have PSH flag set by tcp_sendmsg() / tcp_mark_push(), unless MSG_MORE has been requested by the user. Signed-off-by:Eric Dumazet <edumazet@google.com> Cc: Soheil Hassas Yeganeh <soheil@google.com> Cc: Neal Cardwell <ncardwell@google.com> Cc: Yuchung Cheng <ycheng@google.com> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Tariq Toukan <tariqt@mellanox.com> Acked-by:
Soheil Hassas Yeganeh <soheil@google.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
-
Stefano Brivio authored
This is the equivalent of commit 2c6b55f4 ("ipv6: fix neighbour resolution with raw socket") for ip6_confirm_neigh(): we can send a packet with MSG_CONFIRM on a raw socket for a connected route, so the gateway would be :: here, and we should pick the next hop using rt6_nexthop() instead. This was found by code review and, to the best of my knowledge, doesn't actually fix a practical issue: the destination address from the packet is not considered while confirming a neighbour, as ip6_confirm_neigh() calls choose_neigh_daddr() without passing the packet, so there are no similar issues as the one fixed by said commit. A possible source of issues with the existing implementation might come from the fact that, if we have a cached dst, we won't consider it, while rt6_nexthop() takes care of that. I might just not be creative enough to find a practical problem here: the only way to affect this with cached routes is to have one coming from an ICMPv6 redirect, but if the next hop is a directly connected host, there should be no topology for which a redirect applies here, and tests with redirected routes show no differences for MSG_CONFIRM (and MSG_PROBE) packets on raw sockets destined to a directly connected host. However, directly using the dst gateway here is not consistent anymore with neighbour resolution, and, in general, as we want the next hop, using rt6_nexthop() looks like the only sane way to fetch it. Reported-by:
Guillaume Nault <gnault@redhat.com> Signed-off-by:
Stefano Brivio <sbrivio@redhat.com> Acked-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by:
-
Jose Abreu authored
Add the support for Synopsys HAPS board that uses GMAC5. Signed-off-by:
Jose Abreu <joabreu@synopsys.com> Signed-off-by:
-
Vitaly Gaiduk authored
This patch adds ability to switch beetween two PHY SGMII modes. Some hardware, for example, FPGA IP designs may use 6-wire mode which enables differential SGMII clock to MAC. Signed-off-by:
Vitaly Gaiduk <vitaly.gaiduk@cloudbear.ru> Signed-off-by:
-
Vitaly Gaiduk authored
Add documentation of ti,sgmii-ref-clock-output-enable which can be used to select SGMII mode type (4 or 6-wire). Signed-off-by:
-
Alexandru Ardelean authored
This change documents the 'mac-mode' property that was introduced in the 'stmmac' driver to support passive mode converters that can sit in-between the MAC & PHY. Signed-off-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by:
-
Alexandru Ardelean authored
In-between the MAC & PHY there can be a mode converter, which converts one mode to another (e.g. GMII-to-RGMII). The converter, can be passive (i.e. no driver or OS/SW information required), so the MAC & PHY need to be configured differently. For the `stmmac` driver, this is implemented via a `mac-mode` property in the device-tree, which configures the MAC into a certain mode, and for the PHY a `phy_interface` field will hold the mode of the PHY. The mode of the PHY will be passed to the PHY and from there-on it work in a different mode. If unspecified, the default `phy-mode` will be used for both. Signed-off-by:
-
David S. Miller authored
Sudarsana Reddy Kalluru says: ==================== qed* Fix series. The patch series addresses couple of issues in the recent commits. Patch (1) populates the actual dump-size of config attribute instead of providing a fixed size value. Patch(2) updates frame format of flash config buffer as required by management FW (MFW). Please consider applying it to net-next. ==================== Signed-off-by: -
Sudarsana Reddy Kalluru authored
MFW associates the entity id to a config attribute instead of assigning one entity id for all the config attributes. This patch incorporates driver changes to link entity id to a config id attribute. Fixes: 0dabbe1b ("qed: Add driver API for flashing the config attributes.") Signed-off-by:
Sudarsana Reddy Kalluru <skalluru@marvell.com> Signed-off-by:
Ariel Elior <aelior@marvell.com> Signed-off-by:
-
Sudarsana Reddy Kalluru authored
Driver currently returns max-buf-size as size of the config attribute. This patch incorporates changes to read this value from MFW (if available) and provide it to the user. Also did a trivial clean up in this path. Fixes: d44a3ced ("qede: Add support for reading the config id attributes.") Signed-off-by:
-
David S. Miller authored
Simon Horman says: ==================== devlink: add unknown 'fw_load_policy' value Dirk says: Recently we added an unknown value for the 'reset_dev_on_drv_probe' devlink parameter. Extend the 'fw_load_policy' parameter in the same way. The only driver that uses this right now is the nfp driver. ==================== Signed-off-by: -
Dirk van der Merwe authored
If the 'app_fw_from_flash' HWinfo key is invalid, set the 'fw_load_policy' devlink parameter value to unknown. Suggested-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
-
Dirk van der Merwe authored
Similar to the 'reset_dev_on_drv_probe' devlink parameter, it is useful to have an unknown value which can be used by drivers to report that the hardware value isn't recognized or is otherwise invalid instead of failing the operation. This is especially useful for u8/enum parameters. Suggested-by:
-
