- 15 Mar, 2015 14 commits
-
-
Marcel Holtmann authored
The flags for the management command table used manual encoding of bits in the form of (1 << n). It is however preferred to use BIT(n) macro instead. Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com>
-
Marcel Holtmann authored
Changes to the global configuration updates like settings, class of device, name etc. can be received by every user. They are allowed to read them in the first place so provide the updates via events as well. Otherwise untrusted users start polling for updates and that is not a desired behavior. Signed-off-by:
-
Marcel Holtmann authored
Until now the management interface was restricted to CAP_NET_ADMIN. With this change every user can open the management socket. However the list of commands is heavily restricted to getting basic information about the attached controllers. No access for configuration or other operation is provided. The events are also limited. This is done so that no keys can leak or untrusted users can mess with the Bluetooth configuration. Signed-off-by:
-
Marcel Holtmann authored
Check the required trust level of each management command with the trust level of the management socket. If it does not match up, then return the newly introduced permission denied error. Signed-off-by:
-
Marcel Holtmann authored
The flags field for the management command table will be always initialized to zero and thus no need to do that manually. Signed-off-by:
-
Marcel Holtmann authored
Some management commands are safe to be accessed from any user without special permissions. First step for allowing access to any of these commands from untrusted application is to mark them accordingly. Signed-off-by:
-
Marcel Holtmann authored
The management interface will need access to the socket flags and so provide a helper function for checking them. Signed-off-by:
-
Marcel Holtmann authored
With the introduction of trusted socket flag for control and monitor channels, it is now possible to use a single function for sending packets to these sockets. And with that consolidate the handling. Signed-off-by:
-
Marcel Holtmann authored
Providing a global trusted flag for management control sockets provides an easy way for identifying sockets and imposing restriction on it. For now all management sockets are trusted since they require CAP_NET_ADMIN. Signed-off-by:
-
Marcel Holtmann authored
The Read Extended Contoller Index List command can be used for retrieving the complete list of local available controllers. This included configured, unconfigured and also AMP controllers. Signed-off-by:
-
Marcel Holtmann authored
This introduces support for using Extended Index Added and Extended Index Removed events. These events contain the controller type and also the hardware bus information from the driver. Signed-off-by:
-
Marcel Holtmann authored
For sending Index Added, Index Removed, Unconfigured Index Added and Unconfigured Index Removed managment events the new helper functions allows taking into account if these events are enabled for a certain management socket or not. Signed-off-by:
-
Marcel Holtmann authored
The hci_send_to_flagged_channel helper function can be used to send packets to all channels that have a certain HCI socket flag set. This is especially useful for managment events that are limited to sockets that have first enabled certain functionality. This allows for filtering of events without confusing existing users. Signed-off-by:
-
Marcel Holtmann authored
To filter out certain actions for certain HCI sockets introcuce a flags field that allows to configure specific settings on individual sockets. Since the hci_pinfo structure is private in hci_sock.c, provide helper functions for setting and clearing a given flag. Signed-off-by:
-
- 14 Mar, 2015 24 commits
-
-
Florian Fainelli authored
Commit cd28a1a9 ("net: dsa: fully divert PHY reads/writes if requested") introduced a check for particular PHYs that need to be accessed using the slave MII bus created by DSA, but this check was too inclusive. This would prevent fixed PHYs from being successfully registered because those should not go through the slave MII bus created by DSA. Make sure we check that the PHY is not a fixed PHY to prevent that from happening. Fixes: cd28a1a9 ("net: dsa: fully divert PHY reads/writes if requested") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queueDavid S. Miller authored
Jeff Kirsher says: ==================== Intel Wired LAN Driver Updates 2015-03-13 This series contains updates to ixgbe and ixgbevf. Don adds additional support for X550 MAC types, which require additional steps around enabling and disabling Rx. Also cleans up variable type inconsistency. I provide a patch to allow relaxed ordering to be enabled on SPARC architectures. Also cleans up ixgbevf whitespace and code comments to align the driver with networking coding standard. Lastly cleaned up uses of memcpy() where ether_addr_copy() could have been used. Alex removes some dead code in the ixgbe cleanup patch. ==================== Signed-off-by: -
David S. Miller authored
Eric Dumazet says: ==================== inet: tcp listener refactoring, part 9 This preliminary work pushes socket convergence a bit more: 1) request sock ir_iif is universally set 2) inet_diag can use common helpers to reduce LOC ==================== Signed-off-by: -
Eric Dumazet authored
Now the three type of sockets share a common base, we can factorize code in inet_diag_msg_common_fill(). inet_diag_entry no longer requires saddr_storage & daddr_storage and the extra copies. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Eric Dumazet authored
inet_sk_diag_fill() only copes with non timewait and non request socks Signed-off-by:
-
Eric Dumazet authored
Once request socks will be in ehash table, they will need to have a valid ir_iff field. This is currently true only for IPv6. This patch extends support for IPv4 as well. This means inet_diag_fill_req() can now properly use ir_iif, which is better for IPv6 link locals anyway, as request sockets and established sockets will propagate consistent netlink idiag_if. Signed-off-by:
-
David S. Miller authored
Jon Maloy says: ==================== tipc: some optimizations and impovements The commits in this series contain some relatively simple changes that lead to better throughput across TIPC connections. We also make changes to the implementation of link transmission queueing and priority handling, in order to make the code more comprehensible and maintainable. v2: Commit #2: Redesigned tipc_msg_validate() to use pskb_may_pull(), as per feedback from David Miller. Commit #3: Some cosmetic changes to tipc_msg_extract(). I tried to replace the unconditional skb_linearize() with calls to pskb_may_pull() at selected locations, but I gave up. First, skb_trim() requires a fully linearized buffer. Second, it doesn't make much sense; the whole buffer will end up linearized, one way or another. ==================== Signed-off-by: -
Jon Paul Maloy authored
Messages transferred by TIPC are assigned an "importance priority", -an integer value indicating how to treat the message when there is link or destination socket congestion. There is no separate header field for this value. Instead, the message user values have been chosen in ascending order according to perceived importance, so that the message user field can be used for this. This is not a good solution. First, we have many more users than the needed priority levels, so we end up with treating more priority levels than necessary. Second, the user field cannot always accurately reflect the priority of the message. E.g., a message fragment packet should really have the priority of the enveloped user data message, and not the priority of the MSG_FRAGMENTER user. Until now, we have been working around this problem in different ways, but it is now time to implement a consistent way of handling such priorities, although still within the constraint that we cannot allocate any more bits in the regular data message header for this. In this commit, we define a new priority level, TIPC_SYSTEM_IMPORTANCE, that will be the only one used apart from the four (lower) user data levels. All non-data messages map down to this priority. Furthermore, we take some free bits from the MSG_FRAGMENTER header and allocate them to store the priority of the enveloped message. We then adjust the functions msg_importance()/msg_set_importance() so that they read/set the correct header fields depending on user type. This small protocol change is fully compatible, because the code at the receiving end of a link currently reads the importance level only from user data messages, where there is no change. Reviewed-by:
Erik Hugne <erik.hugne@ericsson.com> Signed-off-by:
Jon Maloy <jon.maloy@ericsson.com> Signed-off-by:
-
Jon Paul Maloy authored
struct tipc_link contains one single queue for outgoing packets, where both transmitted and waiting packets are queued. This infrastructure is hard to maintain, because we need to keep a number of fields to keep track of which packets are sent or unsent, and the number of packets in each category. A lot of code becomes simpler if we split this queue into a transmission queue, where sent/unacknowledged packets are kept, and a backlog queue, where we keep the not yet sent packets. In this commit we do this separation. Reviewed-by:
Ying Xue <ying.xue@windriver.com> Signed-off-by:
-
Jon Paul Maloy authored
The unicast packet header contains a broadcast acknowledge sequence number, that may need to be conveyed to the broadcast link for proper treatment. Currently, the function tipc_rcv(), which is on the most critical data path, calls the function tipc_bclink_acknowledge() to have this done. This call is made for each received packet, and results in the unconditional grabbing of the broadcast link spinlock. This is unnecessary, since we can see directly from tipc_rcv() if the acknowledged number differs from what has been previously acked from the node in question. In the vast majority of cases the numbers won't differ, and there is nothing to update. We now make the call to tipc_bclink_acknowledge() conditional to that the two ack values differ. Reviewed-by:
-
Jon Paul Maloy authored
When we currently extract a bundled buffer from a message bundle in the function tipc_msg_extract(), we allocate a new buffer and explicitly copy the linear data area. This is unnecessary, since we can just clone the buffer and do skb_pull() on the clone to move the data pointer to the correct position. This is what we do in this commit. Reviewed-by:
-
Jon Paul Maloy authored
Currently, TIPC linearizes all incoming buffers directly at reception before passing them upwards in the stack. This is clearly a waste of CPU resources, and must be avoided. In this commit, we eliminate this unnecessary linearization. We still ensure that at least the message header is linear, and that the buffer is linearized where this is still needed, i.e. when unbundling and when reversing messages. In addition, we ensure that fragmented messages are validated after reassembly before delivering them upwards in the stack. Reviewed-by:
-
Jon Paul Maloy authored
The function link_buf_validate() is in reality re-entrant and context independent, and will in later commits be called from several locations. Therefore, we move it to msg.c, make it outline and rename the it to tipc_msg_validate(). We also redesign the function to make proper use of pskb_may_pull() Signed-off-by:
-
Jon Paul Maloy authored
The TIPC protocol spec has defined a 13 bit capability bitmap in the neighbor discovery header, as a means to maintain compatibility between different code and protocol generations. Until now this field has been unused. We now introduce the basic framework for exchanging capabilities between nodes at first contact. After exchange, a peer node's capabilities are stored as a 16 bit bitmap in struct tipc_node. Reviewed-by:
-
David S. Miller authored
Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next Johan Hedberg says: ==================== Here's another set of Bluetooth & ieee802154 patches intended for 4.1: - Added support for QCA ROME chipset family in the btusb driver - at86rf230 driver fixes & cleanups - ieee802154 cleanups - Refactoring of Bluetooth mgmt API to allow new users - New setting for static Bluetooth address exposed to user space - Refactoring of hci_dev flags to remove limit of 32 - Remove unnecessary fast-connectable setting usage restrictions - Fix behavior to be consistent when trying to pair already paired device - Service discovery corner-case fixes Please let me know if there are any issues pulling. Thanks. ==================== Signed-off-by:
-
Julia Lawall authored
The semantic patch that fixes this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ type T; identifier f; @@ static T f (...) { ... } @@ identifier r.f; declarer name EXPORT_SYMBOL; @@ -EXPORT_SYMBOL(f); // </smpl> Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Acked-by:
Alexander Aring <alex.aring@gmail.com> Signed-off-by:
-
Alexander Aring authored
These registers are also changed by transceiver and should be volatile for right accessing via regmap debugfs. Signed-off-by:
-
Alexander Aring authored
This patch adds a handling for calibration if we are 5 minutes in PLL state. I first tried to implement the calibration functionality in TX_ON state via register values CF_START and DCU_START, but this occurs a one second delay at each calibration time. An another solution to start a calibration is to switch from TRX_OFF state into TX_ON, then a calibration is done automatically by transceiver. This method will be used in this patch, after each transmit of a frame we check with jiffies if the PLL is set 5 minutes without doing a TRX_OFF->(TX_ON || RX_AACK_ON) or channel switch. The worst case would be a transceiver in receiving mode only, but this is under normal operation very unlikely. Signed-off-by:
-
Alexander Aring authored
This patch replace the state change timing relevant sleeps with hrtimers. Currently the sleeps are done in the complete handler of spi_async. The relation of doing the state change timing sleep with a timer will get the sleep functionality out of spi_async complete handler context. Signed-off-by:
-
Alexander Aring authored
This patch initialize xtal_trim value to zero. The xtal_trim property is an optional device tree value. Currently if no xtal_trim property is given the xtal_trim value can be contain random data, because it's a stack variable. This patch init the xtal_trim value to zero which is also the default value after reset for at86rf230 transceivers. Signed-off-by:
-
Alexander Aring authored
This patch fix the max sifs size correction when the IEEE802154_HW_TX_OMIT_CKSUM flag is set. With this flag the sk_buff doesn't contain the CRC, because the transceiver will add the CRC while transmit. Also add some defines for the max sifs frame size value and frame check sequence according to 802.15.4 standard. Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Alexander Aring authored
It's only necessary to offer the name and index, others value are available over netlink. Signed-off-by:
-
Alexander Aring authored
Currently the wpan_phy under /sys/class/ieee802154/ is named as "wpan-phy#", this patch will change the name to phy. This will introduce the same naming convention like wireless. Note: wpan-tools users will not type "wpan-phy#" anymore, just a simple "phy#" is enough. Signed-off-by: -
Alexander Aring authored
Currently there exists two interface types with ARPHRD_IEEE802154. These are the 802.15.4 interfaces and 802.15.4 6LoWPAN interfaces. This is more a bug because some userspace applications checks on this value like wireshark. This occurs that wireshark will always try to parse a lowpan interface as 802.15.4 frames. With ARPHRD_6LOWPAN wireshark will parse it as IPv6 frames which is correct. Much applications checks on this value to readout the EUI64 mac address which should be the same for ARPHRD_6LOWPAN. BTLE 6LoWPAN and ieee802154 6LoWPAN will share now the same ARPHRD. Signed-off-by:
-
- 13 Mar, 2015 2 commits
-
-
Jeff Kirsher authored
Use the macro to copy the Ethernet address instead of memcpy(). Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Tested-by:
Phil Schmitt <phillip.j.schmitt@intel.com>
-
Jeff Kirsher authored
Fix the code comments to align with drivers/net/ code commenting style, as well as whitespace issues. The whitespace issues resolve checkpatch errors, like lines exceeding 80 chars (except for strings) and the use of tabs where possible. CC: <kernel-team@fb.com> Signed-off-by:
-
