- 16 Aug, 2017 1 commit
-
-
Sukumar Ghorai authored
BT-Controller connected as platform non-root-hub device and usb-driver initialize such device with wakeup disabled, Ref. usb_new_device(). At present wakeup-capability get enabled by hid-input device from usb function driver(e.g. BT HID device) at runtime. Again some functional driver does not set usb-wakeup capability(e.g LE HID device implement as HID-over-GATT), and can't wakeup the host on USB. Most of the device operation (such as mass storage) initiated from host (except HID) and USB wakeup aligned with host resume procedure. For BT device, usb-wakeup capability need to enable form btusc driver as a generic solution for multiple profile use case and required for USB remote wakeup (in-bus wakeup) while host is suspended. Also usb-wakeup feature need to enable/disable with HCI interface up and down. Signed-off-by:
Sukumar Ghorai <sukumar.ghorai@intel.com> Signed-off-by:
Amit K Bag <amit.k.bag@intel.com> Acked-by:
Oliver Neukum <oneukum@suse.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org>
-
- 15 Aug, 2017 1 commit
-
-
Marcel Holtmann authored
The GPD Pocket is shipping with a BCM2045 USB HCI with its vendor and product information set to 0000:0000 and also has its interface class set to 255 (Vendor Specific Class). Luckily it does advertise usable manufacturer and product strings. T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0000 ProdID=0000 Rev= 1.12 S: Manufacturer=Broadcom Corp S: Product=BCM2045A0 S: SerialNumber=AC83F30677CB C:* #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=84(I) Atr=02(Bulk) MxPS= 32 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 32 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none) Reported-by:
Christopher Williamson <home@chrisaw.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com>
-
- 11 Aug, 2017 1 commit
-
-
Colin Ian King authored
While the kfree of dhkey_a is of the same address of tmp, it probably is clearer and more human readable if tmp is kfree'd rather than dhkey_a. Detected by CoverityScan, CID#1448650 ("Free of address-of expression") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
- 08 Aug, 2017 2 commits
-
-
Pavel Machek authored
Kernel config options should include useful help text; I had to look up the terms on wikipedia. Signed-off-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
-
Dmitry Tunin authored
T: Bus=02 Lev=01 Prnt=01 Port=03 Cnt=03 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=13d3 ProdID=3494 Rev= 2.00 S: Manufacturer=Realtek S: Product=Bluetooth Radio S: SerialNumber=00e04c000001 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by:
Dmitry Tunin <hanipouspilot@gmail.com> Signed-off-by:
-
- 07 Aug, 2017 35 commits
-
-
Ondrej Zary authored
Currently the activity LED is solid on during continuous activity. Blink the LED during continuous activity to match Windows driver behavior. Cards with activity LED: power LED = solid on when up, off when down activity LED = blinking during activity, off when idle Cards without activity LED: power LED = solid on when up, off when down, blinking during activity (don't have such a card so I don't know if Windows driver does the same thing) Signed-off-by:
Ondrej Zary <linux@rainbow-software.org> Signed-off-by:
-
Ondrej Zary authored
Keep power LED on during activity. LED timer races with power LED disabling in hci_close(), resulting in power LED left on after closing. Stop LED timer before disabling power LED. BTW. On cards without an activity LED, the behavior is a bit weird: The LED is on after hci_open() but only until the first data transfer. Then it's off in idle and on during activity. It could be improved by keeping the LED on in idle and flashing during activity. Signed-off-by:
-
Ondrej Zary authored
Anycom CF-300 (HP C8249A) has both power and activity LEDs. However the id read in bluecard_open() is 0x73 so the driver does not enable the LEDs. Remove the CARD_HAS_PCCARD_ID check to enable LEDs. Signed-off-by:
-
David S. Miller authored
Xin Long says: ==================== sctp: remove typedefs from structures part 5 As we know, typedef is suggested not to use in kernel, even checkpatch.pl also gives warnings about it. Now sctp is using it for many structures. All this kind of typedef's using should be removed. This patchset is the part 5 to remove all typedefs in include/net/sctp/constants.h. Just as the part 1-4, No any code's logic would be changed in these patches, only cleaning up. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
Xin Long authored
This patch is to remove the typedef sctp_subtype_t, and replace with union sctp_subtype in the places where it's using this typedef. Note that it doesn't fix many indents although it should, as sctp_disposition_t's removal would mess them up again. So better to fix them when removing sctp_disposition_t in later patch. Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
-
Xin Long authored
This patch is to remove the typedef sctp_event_t, and replace with enum sctp_event in the places where it's using this typedef. Signed-off-by:
-
Xin Long authored
This patch is to remove the typedef sctp_event_timeout_t, and replace with enum sctp_event_timeout in the places where it's using this typedef. Signed-off-by:
-
Xin Long authored
This patch is to remove the typedef sctp_event_other_t, and replace with enum sctp_event_other in the places where it's using this typedef. Signed-off-by:
-
Xin Long authored
This patch is to remove the typedef sctp_event_primitive_t, and replace with enum sctp_event_primitive in the places where it's using this typedef. Signed-off-by:
-
Xin Long authored
This patch is to remove the typedef sctp_state_t, and replace with enum sctp_state in the places where it's using this typedef. Signed-off-by:
-
Xin Long authored
This patch is to remove the typedef sctp_ierror_t, and replace with enum sctp_ierror in the places where it's using this typedef. Signed-off-by:
-
Xin Long authored
This patch is to remove the typedef sctp_xmit_t, and replace with enum sctp_xmit in the places where it's using this typedef. Signed-off-by:
-
Xin Long authored
This patch is to remove the typedef sctp_sock_state_t, and replace with enum sctp_sock_state in the places where it's using this typedef. Signed-off-by:
-
Xin Long authored
This patch is to remove the typedef sctp_transport_cmd_t, and replace with enum sctp_transport_cmd in the places where it's using this typedef. Signed-off-by:
-
Xin Long authored
This patch is to remove the typedef sctp_scope_t, and replace with enum sctp_scope in the places where it's using this typedef. Signed-off-by:
-
Xin Long authored
This patch is to remove the typedef sctp_scope_policy_t and keep it's members as an anonymous enum. It is also to define SCTP_SCOPE_POLICY_MAX to replace the num 3 in sysctl.c to make codes clear. Signed-off-by:
-
Xin Long authored
This patch is to remove the typedef sctp_retransmit_reason_t, and replace with enum sctp_retransmit_reason in the places where it's using this typedef. Signed-off-by:
-
Xin Long authored
This patch is to remove the typedef sctp_lower_cwnd_t, and replace with enum sctp_lower_cwnd in the places where it's using this typedef. Signed-off-by:
-
Alexandru Gagniuc authored
Signed-off-by:
Alexandru Gagniuc <alex.g@adaptrum.com> Signed-off-by:
-
Alexandru Gagniuc authored
Before the GMAC on the Anarion chip can be used, the PHY interface selection must be configured with the DWMAC block in reset. This layer covers a block containing only two registers. Although it is possible to model this as a reset controller and use the "resets" property of stmmac, it's much more intuitive to include this in the glue layer instead. At this time only RGMII is supported, because it is the only mode which has been validated hardware-wise. Signed-off-by:
-
stephen hemminger authored
With new transparent VF support, it is possible to get a deadlock when some of the deferred work is running and the unregister_vf is trying to cancel the work element. The solution is to use trylock and reschedule (similar to bonding and team device). Reported-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Fixes: 0c195567 ("netvsc: transparent VF management") Signed-off-by:
Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by:
-
Florian Fainelli authored
During testing with a background iperf pushing 1Gbit/sec worth of traffic and having both ifconfig and ethtool collect statistics, we could see quite frequent deadlocks. Convert the often accessed DSA slave network devices statistics to per-cpu 64-bit statistics to remove these deadlocks and provide fast efficient statistics updates. Fixes: f613ed66 ("net: dsa: Add support for 64-bit statistics") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
David S. Miller authored
Yuchung Cheng says: ==================== tcp cwnd undo refactor This patch series consolidate similar cwnd undo functions implemented by various congestion control by using existing tcp socket state variable. The first patch fixes a corner case in of cwnd undo in Reno and HTCP. Since the bug has existed for many years and is very minor, we consider this patch set more suitable for net-next as the major change is the refactor itself. - v1->v2 Fix trivial compile errors ==================== Signed-off-by: -
Yuchung Cheng authored
Most TCP congestion controls are using identical logic to undo cwnd except BBR. This patch consolidates these similar functions to the one used currently by Reno and others. Suggested-by:
Neal Cardwell <ncardwell@google.com> Signed-off-by:
Yuchung Cheng <ycheng@google.com> Signed-off-by:
-
Yuchung Cheng authored
Using ssthresh to revert cwnd is less reliable when ssthresh is bounded to 2 packets. This patch uses an existing variable in TCP "prior_cwnd" that snapshots the cwnd right before entering fast recovery and RTO recovery in Reno. This fixes the issue discussed in netdev thread: "A buggy behavior for Linux TCP Reno and HTCP" https://www.spinics.net/lists/netdev/msg444955.htmlSuggested-by:
Wei Sun <unlcsewsun@gmail.com> Signed-off-by:
-
kiki good authored
When using Broadcom Systemport device in 32bit Platform, ifconfig can only report up to 4G tx,rx status, which will be wrapped to 0 when the number of incoming or outgoing packets exceeds 4G, only taking around 2 hours in busy network environment (such as streaming). Therefore, it makes hard for network diagnostic tool to get reliable statistical result, so the patch is used to add 64bit support for Broadcom Systemport device in 32bit Platform. This patch provides 64bit statistics capability on both ethtool and ifconfig. Signed-off-by:
Jianming.qiao <kiki-good@hotmail.com> Signed-off-by:
-
Intiyaz Basha authored
Moving PF module param console_bitmask to lio_main.c for consistency. Signed-off-by:
Intiyaz Basha <intiyaz.basha@cavium.com> Signed-off-by:
Felix Manlunas <felix.manlunas@cavium.com> Signed-off-by:
-
Intiyaz Basha authored
There's supposed to be a one-to-one correspondence between the 18 macros that #define the OCT_DEV states (in octeon_device.h) and the strings in the oct_dev_state_str array, but there are only 14 strings in the array. Add the missing strings (so they become 18 in total), and also revise some incorrect/outdated text of existing strings. Signed-off-by:
-
David S. Miller authored
Russell King says: ==================== phylink and sfp support This patch series introduces generic support for SFP sockets found on various Marvell based platforms. The idea here is to provide common SFP socket support which can be re-used by network drivers as appropriate, rather than each network driver having to re-implement SFP socket support. SFP sockets typically use other system resources, eg, I2C buses to read identifying information, and GPIOs to monitor socket state and control the socket. Meanwhile, some network drivers drive multiple ethernet ports from one instantiation of the driver. It is not desirable to block the initialisation of a network driver (thus denying other ports from being operational) if the resources for the SFP socket are not yet available. This means that an element of independence between the SFP support code and the driver is required. More than that, SFP modules effectively bring hotplug PHYs to networking - SFP copper modules normally contain a standard PHY accessed over the I2C bus, and it is desirable to read their state so network drivers can be appropriately configured. To add to the complexity, SFP modules can be connected in at least two places: 1. Directly to the serdes output of a MAC with no intervening PHY. For example: mvneta ----> SFP socket 2. To a PHY, for example: mvpp2 ---> PHY ---> copper | `-----> SFP socket This code supports both setups, although it's not fully implemented with scenario (2). Moreover, the link presented by the SFP module can be one of the 10Gbase-R family (for SFP+ sockets), SGMII or 1000base-X (for SFP sockets) depending on the module, and network drivers need to reconfigure themselves accordingly for the link to come up. For example, if the MAC is configured for SGMII and a fibre module is plugged in, the link won't come up until the MAC is reconfigured for 1000base-X mode. The SFP code manages the SFP socket - detecting the module, reading the identifying information, and managing the control and status signals. Importantly, it disables the SFP module transmitter when the MAC is down, so that the laser is turned off (but that is not a guarantee.) phylink provides the mechanisms necessary to manage the link modes, based on the SFP module type, and supports hot-plugging of the PHY without needing the MAC driver to be brought up and down on transitions. phylink also supports the classical static PHY and fixed-link modes. I currently (but not included in this series) have code to convert mvneta to use phylink, and the out of tree mvpp2x driver. I have nothing for the mvpp2 driver at present as that driver is only recently becoming functional on 10G hardware, and is missing a lot of features that are necessary to make things work correctly. ==================== Signed-off-by: -
Russell King authored
Add support for SFP hotpluggable modules via sfp-bus and phylink. This supports both copper and optical SFP modules, which require different Serdes modes in order to properly negotiate the link. Optical SFP modules typically require the Serdes link to be talking 1000BaseX mode - this is the gigabit ethernet mode defined by the 802.3 standard. Copper SFP modules typically integrate a PHY in the module to convert from Serdes to copper, and the PHY will be configured by the vendor to either present a 1000BaseX Serdes link (for fixed 1000BaseT) or a SGMII Serdes link. However, this is vendor defined, so we instead detect the PHY, switch the link to SGMII mode, and use traditional PHY based negotiation. Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Russell King authored
Add in-band autonegotation support for 10GBase-KR mode. Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Russell King authored
Add support for reading and writing the clause 45 MII registers. Signed-off-by:
-
Russell King authored
Add support for reading module EEPROMs through phylink. Reviewed-by:
-
Russell King authored
Signed-off-by:
-
Russell King authored
The link between the ethernet MAC and its PHY has become more complex as the interface evolves. This is especially true with serdes links, where the part of the PHY is effectively integrated into the MAC. Serdes links can be connected to a variety of devices, including SFF modules soldered down onto the board with the MAC, a SFP cage with a hotpluggable SFP module which may contain a PHY or directly modulate the serdes signals onto optical media with or without a PHY, or even a classical PHY connection. Moreover, the negotiation information on serdes links comes in two varieties - SGMII mode, where the PHY provides its speed/duplex/flow control information to the MAC, and 1000base-X mode where both ends exchange their abilities and each resolve the link capabilities. This means we need a more flexible means to support these arrangements, particularly with the hotpluggable nature of SFP, where the PHY can be attached or detached after the network device has been brought up. Ethtool information can come from multiple sources: - we may have a PHY operating in either SGMII or 1000base-X mode, in which case we take ethtool/mii data directly from the PHY. - we may have a optical SFP module without a PHY, with the MAC operating in 1000base-X mode - the ethtool/mii data needs to come from the MAC. - we may have a copper SFP module with a PHY whic can't be accessed, which means we need to take ethtool/mii data from the MAC. Phylink aims to solve this by providing an intermediary between the MAC and PHY, providing a safe way for PHYs to be hotplugged, and allowing a SFP driver to reconfigure the serdes connection. Phylink also takes over support of fixed link connections, where the speed/duplex/flow control are fixed, but link status may be controlled by a GPIO signal. By avoiding the fixed-phy implementation, phylink can provide a faster response to link events: fixed-phy has to wait for phylib to operate its state machine, which can take several seconds. In comparison, phylink takes milliseconds. Signed-off-by:
-
