aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2013-10-14ath9k_hw: remove direct accesses to channel mode flagsFelix Fietkau9-169/+49
Use wrappers where available. Simplifies code and helps with further improvements to the channel data structure Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2013-10-14ath9k: use a separate data structure for rx buffersFelix Fietkau3-50/+92
There's no shared code for handling both rx and tx buffers, and tx buffers require a lot more metadata than rx buffers. Using a separate data structure for rx reduces memory usage and improves cache footprint. Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2013-10-14wcn36xx: fix coccinelle warningsFengguang Wu1-9/+2
drivers/net/wireless/ath/wcn36xx/debug.c:27:11-31: WARNING opportunity for simple_open, see also structure on line 106 /c/kernel-tests/src/i386/drivers/net/wireless/ath/wcn36xx/debug.c:27:11-31: WARNING opportunity for simple_open, see also structure on line 148 This removes an open coded simple_open() function and replaces file operations references to the function with simple_open() instead. Generated by: coccinelle/api/simple_open.cocci CC: Eugene Krasnikov <[email protected]> CC: John W. Linville <[email protected]> Signed-off-by: Fengguang Wu <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2013-10-14rt2x00: rt73usb: use rt2x00_has_cap_* helpersGabor Juhos1-9/+9
Use the appropriate helper functions instead of directly accessing the rt2x00dev->cap_flags field to check device capability flags. This improves readability of the code a bit. Compile tested only. Signed-off-by: Gabor Juhos <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2013-10-14rt2x00: rt61pci: use rt2x00_has_cap_* helpersGabor Juhos1-10/+10
Use the appropriate helper functions instead of directly accessing the rt2x00dev->cap_flags field to check device capability flags. This improves readability of the code a bit. Compile tested only. Signed-off-by: Gabor Juhos <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2013-10-14rt2x00: rt2800lib: use rt2x00_has_cap_* helpersGabor Juhos1-13/+12
Use the appropriate helper functions instead of directly accessing the rt2x00dev->cap_flags field to check device capability flags. This improves readability of the code a bit. Signed-off-by: Gabor Juhos <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2013-10-14rt2x00: rt2x00lib: use rt2x00_has_cap_* helpersGabor Juhos6-13/+13
Use the appropriate helper functions instead of directly accessing the rt2x00dev->cap_flags field to check device capability flags. This improves readability of the code a bit. Signed-off-by: Gabor Juhos <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2013-10-14rt2x00: add rt2x00_has_cap_* helpersGabor Juhos1-0/+87
The rt2x00 code directly accesses the 'cap_flags' field of 'struct rt2x00_dev' when checking presence of a given capability flag. The direct access needs long expressions which lowers readability of the code. Add a few helper functions which can be used to test device capabilities without directly accessing the cap_flags filed. Signed-off-by: Gabor Juhos <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2013-10-14rt2x00: cleanup indentation in rt2800.hGabor Juhos1-21/+21
Adjust whitespaces to move badly aligned constants to the right column. The patch contains no functional changes. Signed-off-by: Gabor Juhos <[email protected]> Signed-off-by: John W. Linville <[email protected]>
2013-10-14Bluetooth: Fix updating advertising data needlesslyJohan Hedberg1-1/+1
We need to ensure that the advertising data is up-to-date whenever advertising is enabled, but when disabling advertising we do not need to worry about it (since it will eventually get fixed as soon as advertising is enabled again). This patch fixes this in the command complete callback for set_adv_enable. Signed-off-by: Johan Hedberg <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2013-10-14Bluetooth: Move static advertising functions to avoid forward declarationsJohan Hedberg1-28/+28
These functions will soon be used by set_connectable() so move them to a location in mgmt.c that doesn't require forward declarations. Signed-off-by: Johan Hedberg <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2013-10-14Bluetooth: Add missing error handling for Set ConnectableJohan Hedberg1-0/+7
If the HCI commands related to the Set Connectable command fail we will get a non-zero status in the request completion callback. In such a case we must respond with the appropriate command status message to user space. Signed-off-by: Johan Hedberg <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2013-10-14Bluetooth: Move more logic into set_connectable complete callbackJohan Hedberg1-4/+19
This patch moves the responsibility of setting/clearing the HCI_CONNECTABLE flag to the request completion callback of the Set Connectable command. This will allow us to cleanly add support for LE Advertising hooks in later patches. Signed-off-by: Johan Hedberg <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2013-10-14Bluetooth: Reorganize set_connectable HCI command sendingJohan Hedberg1-16/+20
This patch moves all the decisions of which HCI commands to send (or not to send) to the code between hci_req_init() and hci_req_run() this allows us to further extend the request with further commands but still keep the same logic of handling whether to return a direct mgmt response in the case that no HCI commands were sent. Signed-off-by: Johan Hedberg <[email protected]> Signed-off-by: Marcel Holtmann <[email protected]>
2013-10-14Bluetooth: Introduce L2CAP channel callback for resumingMarcel Holtmann3-5/+11
Clearing the BT_SK_SUSPEND socket flag from the L2CAP core is causing a dependency on the socket. So intead of doing that, use a channel callback into the socket handling to resume. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-14Bluetooth: Introduce L2CAP channel flag for defer setupMarcel Holtmann3-10/+13
The L2CAP core should not look into the socket flags to figure out the setting of defer setup. So introduce a L2CAP channel flag that mirrors the socket flag. Since the defer setup option is only set in one place this becomes a really easy thing to do. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-14Bluetooth: Adjust header for proc socket informationMarcel Holtmann1-1/+1
The exposed socket information do not contain source or destination addresses. So adjust the header accordingly. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Increase minor version of core moduleMarcel Holtmann1-1/+1
There have been a lot of changes in the core Bluetooth handling lately. So it is a good idea to increase the module version. The module version is not used anywhere, but it makes debugging a little bit simpler if versions can be distinguished. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Provide msg_name callback for L2CAP connectionless channelsMarcel Holtmann3-1/+20
The L2CAP connectionless channels use SOCK_DGRAM and recvmsg() and need to receive the remote BD_ADDR and PSM information via msg_name from the recvmsg() system call. So in case the L2CAP socket is for connectionless channels, provide a msg_name callback that can update the data. Also store the remote BD_ADDR and PSM in the skb so it can be extracted later on. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Add support for per socket msg_name callbackMarcel Holtmann2-4/+12
This allows to add a per socket msg_name callback that can be used for updating the msg_name information for recvmsg() system calls. This feature is used by another patch to support address information on L2CAP connectionless channels. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Use l2cap_pi(sk) directly where possibleMarcel Holtmann1-8/+7
There are few places where it makes sense to use l2cap_pi(sk) directly instead of assigning it to temporary structure. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Remove src and dst fields from bt_sock structureMarcel Holtmann2-5/+1
Every socket protocol now stores its own address information. So just remove the generic src and dst fields since they are no longer needed. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Store RFCOMM address information in its own socket structureMarcel Holtmann2-13/+17
The address information of RFCOMM sockets should be stored in its own socket structure. Trying to generalize them is not helpful since different transports have different address types. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Store SCO address information in its own socket structureMarcel Holtmann2-18/+20
The address information of SCO sockets should be stored in its own socket structure. Trying to generalize them is not helpful since different transports have different address types. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Use SCO addresses from HCI connection directlyMarcel Holtmann2-15/+8
Instead of storing a pointer to the addresses for the HCI device and HCI connection, use them directly. With the recent changes to address tracking of HCI connections, this becomes simple. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Access BNEP session addresses through L2CAP channelMarcel Holtmann1-12/+6
The L2CAP socket structure does not contain the address information anymore. They need to be accessed through the L2CAP channel. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Access HIDP session addresses through L2CAP channelMarcel Holtmann1-6/+12
The L2CAP socket structure does not contain the address information anymore. They need to be accessed through the L2CAP channel. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Access CMTP session addresses through L2CAP channelMarcel Holtmann1-3/+3
The L2CAP socket structure does not contain the address information anymore. They need to be accessed through the L2CAP channel. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Access RFCOMM session addresses through L2CAP channelMarcel Holtmann1-10/+9
The L2CAP socket structure does not contain the address information anymore. They need to be accessed through the L2CAP channel. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Return the correct address type for L2CAP socketsMarcel Holtmann3-2/+24
The L2CAP sockets can use BR/EDR public, LE public and LE random addresses for various combinations of source and destination devices. So make sure that getsockname(), getpeername() and accept() return the correct address type. For this the address type of the source and destination is stored with the L2CAP channel information. The stored address type is not the one specific for the HCI protocol. It is the address type used for the L2CAP sockets and the management interface. The underlying HCI connections store the HCI address type. If needed, it gets converted to the socket address type. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Store address information in L2CAP channel structureMarcel Holtmann3-40/+29
With the effort of abstracting the L2CAP socket from the underlying L2CAP channel it is important to store the source and destination address information directly in the L2CAP channel structure. Direct access to the HCI connection address information is not possible since they might not be avaiable at L2CAP channel creation time. The address information will be updated when the underlying BR/EDR or LE connection status changes. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Update L2CAP socket source address from HCI connectionMarcel Holtmann1-4/+5
When having LE connections, the source address is not always the public address of the controller. So update the socket address based on the actual used source address of the HCI connection. This also remove the pointless source address pointer and adds a proper lock around the socket structure. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Fix coding style violations in SMP handlingMarcel Holtmann1-18/+17
The SMP source code has a few coding style violations. Fix them up all at once. No actual code has changed. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Fix input address type for SMP C1 functionMarcel Holtmann1-8/+10
The smp_c1() so far always assumed public addresses as input for its operation. However it should provide actually the source address type of the actual connection. Finally the source address type is tracked in hci_conn->src_type and so use that one as input. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Use hci_conn->src address for L2CAP functionsMarcel Holtmann1-10/+7
The source address is now stored in hci_conn->src and so use that one for L2CAP functions. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Use hci_conn->src address for SMP functionsMarcel Holtmann1-7/+5
The source address is now stored in hci_conn->src and so use that one for SMP functions. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Update source address and type for incoming LE connectionsMarcel Holtmann1-0/+11
The incoming LE connections do not have a proper source address and address type set. The connection needs to be set with the same values as used for advertising parameters. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Store source address of HCI connectionsMarcel Holtmann2-2/+6
The source addressed was based on the public address of the HCI device, but with LE connections this not always the case. For example single mode LE-only controllers would use a static random address. And this address is configured by userspace. To not complicate the lookup of what kind of address is in use, store the correct source address for each HCI connection. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Store the source address type of LE connectionsMarcel Holtmann2-4/+8
When establishing LE connections, it is possible to use a public address (if available) or a random address. The type of address is only known when creating connections, so make sure it is stored in hci_conn structure. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Remove pointless bdaddr_to_le() helper functionMarcel Holtmann4-18/+11
The bdaddr_to_le() function tries to convert the internal address type to one that matches the HCI address type for LE. It does not handle any address types not used by LE and in the end just make the code a lot harder to read. So instead of just hiding behind a magic function, just convert the internal address type where it needs to be converted. And it turns out that these are only two cases anyway. One when creating new LE connections and the other when loading the long term keys. In both cases this makes it more clear on what it going on. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Remove l2cap_conn->src and l2cap_conn->dst pointersMarcel Holtmann1-3/+0
The l2cap_conn->src and l2cap_conn->dst pointers are no longer in use and so just remove them. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Remove l2cap_conn->src and l2cap_conn->dst usage from L2CAPMarcel Holtmann1-14/+17
The l2cap_conn->src and l2cap_conn->dst addresses are just a pointers to hci_conn structure. Use hci_conn->hdev->bdaddr and hci_conn->dst directly instead. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Remove l2cap_conn->src and l2cap_conn->dst usage from SMPMarcel Holtmann1-18/+21
The l2cap_conn->src and l2cap_conn->dst addresses are just a pointer to hci_conn->hdev->bdaddr and hci_conn->dst structures. Use the data provided by hci_conn directly. This is done for hci_conn->dst_type already anyway and with this change it makes it a lot clearer were the address information comes from. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-13Bluetooth: Remove l2cap_conn->dst usage from AMP managerMarcel Holtmann2-3/+5
The l2cap_conn->dst address is just a pointer into the hci_conn->dst structure. Use hci_conn->dst directly instead. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-12Bluetooth: Unicast connectionless data reception is supportedMarcel Holtmann1-1/+1
The unicast connectionless data reception feature is actually support and has been supported all along. Mark it as supported in the L2CAP features bitmask. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-12Bluetooth: The L2CAP fixed channel connectionless data is supportedMarcel Holtmann2-1/+2
The implementation actually supports the L2CAP connectionless data channel. So set it as supported in the fixed channels bitmask. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-12Bluetooth: Allow 3D profile to use security mode 4 level 0Marcel Holtmann3-0/+15
The PSM 0x0021 is dedicated to the 3D profile and has permission to use security mode 4 level 0 for L2CAP connectionless unicast data transfers. When establishing a L2CAP connectionless channel on PSM 0x0021, it will no longer force Secure Simple Pairing. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-12Bluetooth: Limit security mode 4 level 0 to connection oriented channelsMarcel Holtmann2-12/+22
The exception for certain PSM channels when it comes to security mode 4 level 0 should only be checked when actually a connection oriented channel is established. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-12Bluetooth: Fix PSM value for L2CAP connectionless data packetsMarcel Holtmann1-2/+3
The put_unaligned() for setting the PSM is missing the (__le16 *) cast. Without this, the PSM information transmitted over the air are bogus. In addition, print the used PSM value in the debug message so this becomes easier to debug in the future. Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
2013-10-12Bluetooth: Fix HCI init for 1st generation BlueFRITZ! devicesMarcel Holtmann1-2/+6
The 1st generation of BlueFRITZ! devices from AVM Berlin pretend to be HCI version 1.2 controllers, but they are not. They are simple Bluetooth 1.1 devices. Since this company never created any newer controllers, it is safe to use the manufacturer ID instead of an USB quirk. < HCI Command: Read Page Scan Activity (0x03|0x001b) plen 0 > HCI Event: Command Complete (0x0e) plen 8 Read Page Scan Activity (0x03|0x001b) ncmd 1 Status: Success (0x00) Interval: 1280.000 msec (0x0800) Window: 21.250 msec (0x0022) < HCI Command: Read Page Scan Type (0x03|0x0046) plen 0 > HCI Event: Command Status (0x0f) plen 4 Read Page Scan Type (0x03|0x0046) ncmd 1 Status: Unknown HCI Command (0x01) Signed-off-by: Marcel Holtmann <[email protected]> Signed-off-by: Johan Hedberg <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.