- 30 Oct, 2015 23 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-nextDavid S. Miller authored
Samuel Ortiz says: ==================== NFC 4.4 pull request This is the NFC pull request for 4.4. It's a bit bigger than usual, the 3 main culprits being: - A new driver for Intel's Fields Peak NCI chipset. In order to support this chipset we had to export a few NCI routines and extend the driver NCI ops to not only support proprietary commands but also core ones. - Support for vendor commands for both STM drivers, st-nci and st21nfca. Those vendor commands allow to run factory tests through the NFC netlink interface. - New i2c and SPI support for the Marvell driver, together with firmware download support for this driver's core. Besides that we also have: - A few file renames in the STM drivers, to keep the naming consistent between drivers. - Some improvements and fixes on the NCI HCI layer, mostly to properly reach a secure element over a legacy HCI link. - A few fixes for the s3fwrn5 and trf7970a drivers. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Johan Hedberg says: ==================== pull request: bluetooth-next 2015-10-28 Here are a some more Bluetooth patches for 4.4 which collected up during the past week. The most important ones are from Kuba Pawlak for fixing locking issues with SCO sockets. There's also a fix from Alexander Aring for 6lowpan, a memleak fix from Julia Lawall for the btmrvl driver and some cleanup patches from Marcel. Please let me know if there are any issues pulling. Thanks. ==================== Signed-off-by:
-
Alexander Duyck authored
This change makes it so that we reinitialize the interface if the MTU is increased back above IPV6_MIN_MTU and the interface is up. Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
Alexander Duyck <aduyck@mirantis.com> Signed-off-by:
-
David S. Miller authored
Jiri Pirko says: ==================== mlxsw: driver update This driver update mainly brings support for user to be able to setup flooding on specified port, via bridge flag. Also, there is a fix in ageing time conversion. The rest is just cosmetics. ==================== Signed-off-by: -
Jiri Pirko authored
Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Or Gerlitz authored
Fix a place where checkpatch complains that braces should be used on all arms of this statement. Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Or Gerlitz authored
Fixes those places where checkpatch complains that comparisons should place the constant on the right side of the test. Signed-off-by:
-
Jiri Pirko authored
The value passed through switchdev attr set is not in jiffies, but in clock_t, so fix the convert. Reported-by:
Sagi Rotem <sagir@mellanox.com> Fixes: 56ade8fe ("mlxsw: spectrum: Add initial support for Spectrum ASIC") Signed-off-by:
-
Jiri Pirko authored
Signed-off-by:
-
Jiri Pirko authored
Fix copy-paste errors. Signed-off-by:
-
Jiri Pirko authored
The original description was for LAG, so fix it. Signed-off-by:
-
Ido Schimmel authored
Add or remove a bridged port from the flooding domain of unknown unicast packets according to user configuration. Signed-off-by:
-
Ido Schimmel authored
When enabling a range of VLANs on a bridged port we can configure flooding for these VLANs by one register access instead of calling the same register for each VLAN. This is accomplished by using the 'range' field of the Switch Flooding Table Register (SFTR). Signed-off-by:
-
Jiri Pirko authored
It is a flag anyway, so move it to existing u8 flag and don't waste mem. Fix the flags to be in single u8 on the way. Signed-off-by:
-
Ido Schimmel authored
In certain use cases it is not always desirable for the switch device to flood traffic to CPU port. Instead, only certain packet types (e.g. STP, LACP) should be trapped to it. Signed-off-by:
-
Ido Schimmel authored
Allow devices supporting this feature to control the flooding of unknown unicast traffic, by making switchdev infrastructure propagate this setting to the switch driver. Signed-off-by:
-
David S. Miller authored
Iyappan Subramanian says: ==================== drivers: xgene: Add support RGMII TX/RX delay configuration X-Gene RGMII ethernet controller has a RGMII bridge that performs the task of converting the RGMII signal {RX_CLK,RX_CTL, RX_DATA[3:0]} from PHY to GMII signal {RX_DV,RX_ER,RX_DATA[7:0]} and vice versa. This RGMII bridge has a provision to internally delay the input RX_CLK and the output TX_CLK using configuration registers. This will help in maintain the CLK-CTL delay relationship in various operating conditions. This patch adds support RGMII TX/RX delay configuration. ==================== Signed-off-by:Iyappan Subramanian <isubramanian@apm.com> Signed-off-by:
-
Iyappan Subramanian authored
Signed-off-by:
-
Iyappan Subramanian authored
Add RGMII TX/RX delay configuration support. RGMII standard requires 2ns delay to help the RGMII bridge receiver to sample data correctly. If the default value does not provide proper centering of the data sample, the TX/RX delay parameters can be used to adjust accordingly. Signed-off-by:
-
Roopa Prabhu authored
Problem Description: We can add fdbs pointing to the bridge with NULL ->dst but that has a few race conditions because br_fdb_insert() is used which first creates the fdb and then, after the fdb has been published/linked, sets "is_local" to 1 and in that time frame if a packet arrives for that fdb it may see it as non-local and either do a NULL ptr dereference in br_forward() or attach the fdb to the port where it arrived, and later br_fdb_insert() will make it local thus getting a wrong fdb entry. Call chain br_handle_frame_finish() -> br_forward(): But in br_handle_frame_finish() in order to call br_forward() the dst should not be local i.e. skb != NULL, whenever the dst is found to be local skb is set to NULL so we can't forward it, and here comes the problem since it's running only with RCU when forwarding packets it can see the entry before "is_local" is set to 1 and actually try to dereference NULL. The main issue is that if someone sends a packet to the switch while it's adding the entry which points to the bridge device, it may dereference NULL ptr. This is needed now after we can add fdbs pointing to the bridge. This poses a problem for br_fdb_update() as well, while someone's adding a bridge fdb, but before it has is_local == 1, it might get moved to a port if it comes as a source mac and then it may get its "is_local" set to 1 This patch changes fdb_create to take is_local and is_static as arguments to set these values in the fdb entry before it is added to the hash. Also adds null check for port in br_forward. Fixes: 3741873b ("bridge: allow adding of fdb entries pointing to the bridge device") Reported-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
Roopa Prabhu <roopa@cumulusnetworks.com> Reviewed-by:
Stephen Hemminger <stephen@networkplumber.org> Signed-off-by:
-
John W. Linville authored
Signed-off-by:
John W. Linville <linville@tuxdriver.com> Reviewed-by:
Jesse Gross <jesse@nicira.com> Signed-off-by:
-
John W. Linville authored
Other callers of udp_tunnel6_xmit_skb just pass 0 for the prio argument. Jesse Gross <jesse@nicira.com> suggested that prio is really the same as IPv4's tos and should be handled the same, so this is my interpretation of that suggestion. Signed-off-by:
-
John W. Linville authored
NOTE: Link-local IPv6 addresses for remote endpoints are not supported, since the driver currently has no capacity for binding a geneve interface to a specific link. Signed-off-by:
-
- 28 Oct, 2015 17 commits
-
-
Robert Dolca authored
This fixes a build error that seems to be toochain dependent (Not seen with gcc v5.1): In file included from net/nfc/nci/rsp.c:36:0: net/nfc/nci/rsp.c: In function ‘nci_rsp_packet’: include/net/nfc/nci_core.h:355:12: error: inlining failed in call to always_inline ‘nci_prop_rsp_packet’: function body not available inline int nci_prop_rsp_packet(struct nci_dev *ndev, __u16 opcode, Signed-off-by:
Robert Dolca <robert.dolca@intel.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com>
-
yankejian authored
updates the bindings documents and dtsi file according to the review comments[https://lkml.org/lkml/2015/9/21/670] from Rob Herring <robh@kernel.org> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
yankejian <yankejian@huawei.com> Signed-off-by:
huangdaode <huangdaode@hisilicon.com> Signed-off-by:
-
Li Peng authored
delete action of ETHTOOL_ID_ON/ETHTOOL_ID_OFF in XGE ethtool -p, so Hardware control the LED state instead of software. Signed-off-by:
Li Peng <lipeng321@huawei.com> Signed-off-by:
Yisen Zhuang <yisen.zhuang@huawei.com> Signed-off-by:
-
Abhimanyu authored
Increased TX_TIMEOUT to 5HZ to accommodate worst case situation for traffic and CPU intensive use cases Signed-off-by:
Priyanka Jain <Priyanka.Jain@freescale.com> Signed-off-by:
Abhimanyu <abhimanyu@freescale.com> Acked-by:
Claudiu Manoil <claudiu.manoil@freescale.com> Signed-off-by:
-
David S. Miller authored
Merge tag 'wireless-drivers-next-for-davem-2015-10-27' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next Kalle Valo says: ==================== here's a bigger pull request for 4.4. The diffstat looks scary as we created a new directory realtek for all realtek drivers. In the future I'm planning to create similar directories for all vendors, currently we just have ath, mediatek and realtek. This change has been in linux-next for a couple of weeks so it should be safe, but of course you never know. There's also a new driver rtl8xxxu for few realtek USB devices. This just made it to the last linux-next build. Otherwise there's nothing really special, more info below. If time permits, and it's ok for you, I'm hoping to send you a one more pull request this week. brcmfmac * using netdev carrier state * add and rework some cfg80211 callbacks mainly for AP mode * use devcoredump when triggered by firmware event realtek * create new directory drivers/net/wireless/realtek/ for all realtek drivers, not visible to users (no kconfig changes etc) * add rtl8xxxu, a new mac80211 driver for RTL8723AU, RTL8188CU, RTL8188RU, RTL8191CU, RTL8192CU and hopefully more in the future ath10k * add board 2 API support for automatically choosing correct board file * data path optimisations * disable PCI power save for qca988x and QCA99x0 due to interop reasons wil6210 * BlockAckReq support * firmware crashdump using devcoredump * capture all frames with sniffer ==================== Signed-off-by:
-
Tycho Andersen authored
This patch adds support for dumping a process' (classic BPF) seccomp filters via ptrace. PTRACE_SECCOMP_GET_FILTER allows the tracer to dump the user's classic BPF seccomp filters. addr should be an integer which represents the ith seccomp filter (0 is the most recently installed filter). data should be a struct sock_filter * with enough room for the ith filter, or NULL, in which case the filter is not saved. The return value for this command is the number of BPF instructions the program represents, or negative in the case of errors. Command specific errors are ENOENT: which indicates that there is no ith filter in this seccomp tree, and EMEDIUMTYPE, which indicates that the ith filter was not installed as a classic BPF filter. A caveat with this approach is that there is no way to get explicitly at the heirarchy of seccomp filters, and users need to memcmp() filters to decide which are inherited. This means that a task which installs two of the same filter can potentially confuse users of this interface. v2: * make save_orig const * check that the orig_prog exists (not necessary right now, but when grows eBPF support it will be) * s/n/filter_off and make it an unsigned long to match ptrace * count "down" the tree instead of "up" when passing a filter offset v3: * don't take the current task's lock for inspecting its seccomp mode * use a 0x42** constant for the ptrace command value v4: * don't copy to userspace while holding spinlocks v5: * add another condition to WARN_ON v6: * rebase on net-next Signed-off-by:Tycho Andersen <tycho.andersen@canonical.com> Acked-by:
Kees Cook <keescook@chromium.org> CC: Will Drewry <wad@chromium.org> Reviewed-by:
Oleg Nesterov <oleg@redhat.com> CC: Andy Lutomirski <luto@amacapital.net> CC: Pavel Emelyanov <xemul@parallels.com> CC: Serge E. Hallyn <serge.hallyn@ubuntu.com> CC: Alexei Starovoitov <ast@kernel.org> CC: Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
David S. Miller authored
Robert Shearman says: ==================== mpls: mulipath improvements Two improvements to the recently added mpls multipath support. The first is a fix for missing initialisation the nexthop address length for the v4 and v6 explicit null label routes, and the second is to reduce the amount of memory used by mpls routes by changing the way the via addresses are stored. ==================== Signed-off-by: -
Robert Shearman authored
Nexthops for MPLS routes have a via address field sized for the largest via address that is expected, which is 32 bytes. This means that in the most common case of having ipv4 via addresses, 28 bytes of memory more than required are used per nexthop. In the other common case of an ipv6 nexthop then 16 bytes more than required are used. With large numbers of MPLS routes this extra memory usage could start to become significant. To avoid allocating memory for a maximum length via address when not all of it is required and to allow for ease of iterating over nexthops, then the via addresses are changed to be stored in the same memory block as the route and nexthops, but in an array after the end of the array of nexthops. New accessors are provided to retrieve a pointer to the via address. To allow for O(1) access without having to store a pointer or offset per nh, the via address for each nexthop is sized according to the maximum via address for any nexthop in the route, which is stored in a new route field, rt_max_alen, but this is in an existing hole in struct mpls_route so it doesn't increase the size of the structure. Each via address is ensured to be aligned to VIA_ALEN_ALIGN to account for architectures that don't allow unaligned accesses. Signed-off-by:
Robert Shearman <rshearma@brocade.com> Signed-off-by:
-
Robert Shearman authored
Fill in the via address length for the predefined IPv4 and IPv6 explicit-null label routes. Fixes: f8efb73c ("mpls: multipath route support") Signed-off-by:
-
Bert Kenward authored
This patch reduces the overhead of locking for busy poll. Previously the state was protected by a lock, whereas now it's manipulated solely with atomic operations. Signed-off-by:
Shradha Shah <sshah@solarflare.com> Signed-off-by:
-
Hannes Frederic Sowa authored
netstamp_needed is toggled for all socket families if they request timestamping. But some protocols don't need the lower-layer timestamping code at all. This patch starts disabling it for af-unix. E.g. systemd enables timestamping during boot-up on the journald af-unix sockets, thus causing the system to globally enable timestamping in the lower networking stack. Still, it is very probable that timestamping gets activated, by e.g. dhclient or various NTP implementations. Reported-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
David S. Miller authored
Ariel Elior says: ==================== Add new drivers: qed & qede This series implements the driver set for Qlogic's new QL4xxx series. These are 10/20/25/40/50/100 Gig capable converged nics, supporting ethernet (obviously), iscsi, fcoe, roce and iwarp protocols. The overall driver design includes a common module ('qed') and protocol specific dependent modules for ethernet ('qede'), fcoe ('qedf'), iscsi ('qedi') and roce ('qedr'). The common module contains all of the common logic, e.g. initialization, cleanup, infrastructure for interrupt handling, link management, slowpath etc. as well as protocol agnostic features, and supplying an abstraction layer for other modules. The protocol specific modules can be compiled and operated independently of each other, with the exception of the rdma modules which are dependent on the ethernet module, in accordance with the kernel rdma stack design. This series only adds the core and ethernet modules, with basic L2 capabilities. Future series will add the rest of the modules and enhance the L2 functionality. Ths patch series is constructed of the following patches: qed: Add module with basic common support qed: Add basic L2 interface qede: Add basic Network driver qed: Add slowpath L2 support qede: Add basic network device support qede: Add classification configuration qed: Add link support qede: Add support for link qed: Add statistics support qede: Add basic ethtool support This project is a team effort, thanks go to Yuval Mintz, Dmitry Kravkov, Michal Kalderon, Tomer Tayar, Manish Chopra, Sudarsana Kalluru, Rajesh Borundia, Sony Chacko, Artum Zolotushko, Harish Patil, Rasesh Mody, Sergey Ukhterov and Elad Manela, as well as former team members, Eilon Greenstein and Shmulik Ravid. Changes from previos version: ----------------------------- From Version 7: - Various small fixes according to Dave's suggestions; Largest change [code-wise] - don't use tabs for indenting function arguments. From Version 6: - Reduced the number of arguments for functions with exceptionally high number of parameters. From Version 5: - Style change and fixes [mostly in 1, 4 and 7]. Thanks go to Francois Romieu, a mere mortal. ;-) From Version 4: - Drop dependency for x86_64. From Version 3: - Limit support of initial submission to x86_64. - Fix endian problems appearing via sparse [although no BE support yet]. - Fix small issues suggested by the kbuild test robot. From Version 2: - Removed U64_{HI,LO}; Using {upper,lower}_32_bits instead. - Use regular napi weight definition. - [We still use the __le variants for variables, since we didn't get a reply regarding the change into non-user API types]. From Version 1: - Removed private license file; Instead revised comments at source headers. ==================== Signed-off-by: -
Sudarsana Kalluru authored
This adds basic ethtool operations to the qed driver, allowing support in: - Statistics gathering [ethtool -S] - Setting of debug level [ethtool -s <interface> msglvl] - Getting basic information [ethtool, ethtool -i] In addition it adds the ability to change the MTU. Signed-off-by:
Sudarsana Kalluru <Sudarsana.Kalluru@qlogic.com> Signed-off-by:
Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by:
Ariel Elior <Ariel.Elior@qlogic.com> Signed-off-by:
-
Manish Chopra authored
Device statistics can be gathered on-demand. This adds the qed support for reading the statistics [both function and port] from the device, and adds to the public API a method for requesting the current statistics. Signed-off-by:
Manish Chopra <Manish.Chopra@qlogic.com> Signed-off-by:
-
Sudarsana Kalluru authored
This adds basic link functionality to qede - driver still doesn't provide users with an API to change any link property, but it does request qed to initialize the link using default configuration, and registers a callback that allows it to get link notifications. This patch adds the ability of the driver to set the carrier as active and to enable traffic as a result of async. link notifications. Following this patch, driver should be capable of running traffic. Signed-off-by:
-
Yuval Mintz authored
Physical link is handled by the management Firmware. This patch lays the infrastructure for attention handling in the driver, as link change notifications arrive via async. attentions, as well the handling of such notifications. This patch also extends the API with the protocol drivers by adding registered callbacks which the protocol driver passes to qed in order to be notified of async. events originating from the FW/HW. Signed-off-by:
-
Sudarsana Kalluru authored
Add the ability to configure basic classification in driver by implementing ndo_set_mac_address() and ndo_set_rx_mode(). Signed-off-by:
-
