summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Bluetooth: Implement the Remove Advertising commandArman Uguray2015-03-241-0/+103
| | | | | | | This patch implements the "Remove Advertising" mgmt command. Signed-off-by: Arman Uguray <armansito@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Implement the Add Advertising commandArman Uguray2015-03-241-10/+273
| | | | | | | | | | | | This patch adds the most basic implementation for the "Add Advertisement" command. All state updates between the various HCI settings (POWERED, ADVERTISING, ADVERTISING_INSTANCE, and LE_ENABLED) has been implemented. The command currently supports only setting the advertising data fields, with no flags and no scan response data. Signed-off-by: Arman Uguray <armansito@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add data structure for advertising instanceArman Uguray2015-03-242-0/+17
| | | | | | | | | | | This patch introduces a new data structure to represent advertising instances that were added using the "Add Advertising" mgmt command. Initially an hci_dev structure will support only one of these instances at a time, so the current instance is simply stored as a direct member of hci_dev. Signed-off-by: Arman Uguray <armansito@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Introduce HCI_ADVERTISING_INSTANCE setting and add AD flagsArman Uguray2015-03-241-0/+2
| | | | | | | | | | This patch introduces the HCI_ADVERTISING_INSTANCE setting, which is set when an at least one advertising instance has been added using the "Add Advertising" mgmt command. This patch also adds a macro definition for the EIR_APPEARANCE field type. Signed-off-by: Arman Uguray <armansito@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add definitions for Add/Remove Advertising APIArman Uguray2015-03-241-0/+34
| | | | | | | | This patch adds definitions for the Add Advertising and Remove Advertising MGMT commands and events. Signed-off-by: Arman Uguray <armansito@chromium.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Read Broadcom chip info for Apple Bluetooth devicesMarcel Holtmann2015-03-231-1/+37
| | | | | | | | | For the Apple Bluetooth devices that are Broadcom based, it makes sense to read the chip information. It is a single HCI command and might help gathering more information about these devices. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Fix memory leak in le_scan_disable_work_complete()Johan Hedberg2015-03-221-8/+9
| | | | | | | | | | | The hci_request in le_scan_disable_work_complete() was being initialized in a general context but only used in a specific branch in the function (when simultaneous discovery is not supported). This patch moves the usage to be limited to the branch where hci_req_run() is actually called. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Read Verbose Config Version Info for Broadcom devicesMarcel Holtmann2015-03-211-0/+19
| | | | | | | | | | | The Broadcom devices expose their chip id via Read Verbose Config Version Info command. While this information is not used at the moment, it might be useful for debugging purposes and so read it before patching the firmware. This makes it show up in dmesg and HCI traces taken for the system. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Expose quirks through debugfsJakub Pawlowski2015-03-201-0/+60
| | | | | | | | | | This patch expose controller quirks through debugfs. It would be useful for BlueZ tests using vhci. Currently there is no way to test quirk dependent behaviour. It might be also useful for manual testing. Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Use HCI_MAX_AD_LENGTH constant instead hardcoded valueMarcel Holtmann2015-03-201-2/+2
| | | | | | | | Using the HCI_MAX_AD_LENGTH for the max advertising data and max scan response data length makes more sense than hardcoding the value. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Gracefully response to enabling LE on LE only devicesMarcel Holtmann2015-03-201-2/+14
| | | | | | | | | | Currently the enabling of LE on LE only devices causes an error. This is a bit difference from other commands where trying to set the same existing settings causes a positive response. Fix this behavior for this single corner case. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* mac802154: fix typo in header guardNicolas Iooss2015-03-191-2/+2
| | | | | | | Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org> Fixes: b6eea9ca354a ("mac802154: introduce driver-ops header") Acked-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* cc2520: Add support for CC2591 amplifier.Brad Campbell2015-03-183-8/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | The TI CC2521 is an RF power amplifier that is designed to interface with the CC2520. Conveniently, it directly interfaces with the CC2520 and does not require any pins to be connected to a microcontroller/processor. Adding a CC2591 increases the CC2520's range, which is useful for border router and other wall-powered applications. Using the CC2591 with the CC2520 requires configuring the CC2520 GPIOs that are connected to the CC2591 to correctly set the CC2591 into TX and RX modes. Further, TI recommends that the CC2520_TXPOWER and CC2520_AGCCTRL1 registers are set differently to maximize the CC2591's performance. These settings are covered in TI Application Note AN065. This patch adds an optional `amplified` field to the cc2520 entry in the device tree. If present, the CC2520 will be configured to operate with a CC2591. The expected pin mapping is: CC2520 GPIO0 --> CC2591 EN CC2520 GPIO5 --> CC2591 PAEN Signed-off-by: Brad Campbell <bradjc5@gmail.com> Acked-by: Varka Bhadram <varkabhadram@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* cc2520: Do not store platform_data in spi_deviceBrad Campbell2015-03-181-49/+46Star
| | | | | | | | | | | | | | | Storing the `platform_data` struct inside of the SPI struct when using the device tree allows for a later function to edit the content of that struct. This patch refactors the `cc2520_get_platformat_data` function to accept a pointer to a `cc2520_platform_data` struct and populates the fields inside of it. This change mirrors commit aaa1c4d226e4cd730075d3dac99a6d599a0190c7 ("at86rf230: copy pdata to driver allocated space"). Signed-off-by: Brad Campbell <bradjc5@gmail.com> Acked-by: Varka Bhadram <varkabhadram@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix potential NULL dereference in SMP channel setupMarcel Holtmann2015-03-181-3/+5
| | | | | | | | | | When the allocation of the L2CAP channel for the BR/EDR security manager fails, then the smp variable might be NULL. In that case do not try to free the non-existing crypto contexts Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Add workaround for broken OS X legacy SMP pairingJohan Hedberg2015-03-171-8/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OS X version 10.10.2 (and possibly older versions) doesn't support LE Secure Connections but incorrectly copies all authentication request bits from a Security Request to its Pairing Request. The result is that an SC capable initiator (such as BlueZ) will think OS X intends to do SC when in fact it's incapable of it: < ACL Data TX: Handle 3585 flags 0x00 dlen 6 SMP: Security Request (0x0b) len 1 Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09) > ACL Data RX: Handle 3585 flags 0x02 dlen 11 SMP: Pairing Request (0x01) len 6 IO capability: KeyboardDisplay (0x04) OOB data: Authentication data not present (0x00) Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09) Max encryption key size: 16 Initiator key distribution: EncKey (0x01) Responder key distribution: EncKey IdKey Sign (0x07) < ACL Data TX: Handle 3585 flags 0x00 dlen 11 SMP: Pairing Response (0x02) len 6 IO capability: NoInputNoOutput (0x03) OOB data: Authentication data not present (0x00) Authentication requirement: Bonding, No MITM, SC, No Keypresses (0x09) Max encryption key size: 16 Initiator key distribution: EncKey (0x01) Responder key distribution: EncKey Sign (0x05) The pairing eventually fails when we get an unexpected Pairing Confirm PDU instead of a Public Key PDU: > ACL Data RX: Handle 3585 flags 0x02 dlen 21 SMP: Pairing Confirm (0x03) len 16 Confim value: bcc3bed31b8f313a78ec3cce32685faf It is only at this point that we can speculate that the remote doesn't really support SC. This patch creates a workaround for the just-works model, however the MITM case is unsolvable because the OS X user has already been requested to enter a PIN which we're now expected to randomly generate and show the user (i.e. a chicken-and-egg problem). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Move generic mgmt command dispatcher to hci_sock.cJohan Hedberg2015-03-173-115/+115
| | | | | | | | | | | The mgmt.c file should be reserved purely for HCI_CHANNEL_CONTROL. The mgmt_control() function in it is already completely generic and has a single user in hci_sock.c. This patch moves the function there and renames it a bit more appropriately to hci_mgmt_cmd() (as it's a command dispatcher). Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add hdev_init callback for HCI channelsJohan Hedberg2015-03-172-2/+4
| | | | | | | | | | In order to make the mgmt command handling more generic we can't have a direct call to mgmt_init_hdev() from mgmt_control(). This patch adds a new callback to struct hci_mgmt_chan. And sets it to point to the mgmt_init_hdev() function for the HCI_CHANNEL_CONTROL instance. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add generic mgmt helper APIJohan Hedberg2015-03-174-197/+265
| | | | | | | | | | There are several mgmt protocol features that will be needed by more than just the current HCI_CHANNEL_CONTROL. These include sending generic events as well as handling pending commands. This patch moves these functions out from mgmt.c to a new mgmt_util.c file. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add channel parameter to mgmt_pending_find() APIJohan Hedberg2015-03-171-46/+62
| | | | | | | | | | | | | | To be able to have pending commands for different HCI channels we need to be able to distinguish for which channel a command was sent to. The channel information is already part of the socket data and can be fetched using the recently added hci_sock_get_channel() function. To not require all mgmt.c code to pass an extra channel parameter this patch also adds a helper pending_find() & pending_find_data() functions which act as a wrapper to the new mgmt_pending_find() & mgmt_pending_find_data() APIs. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Add helper to get HCI channel of a socketJohan Hedberg2015-03-172-0/+6
| | | | | | | | | We'll need to have access to which HCI channel a socket is bound to, in order to manage pending mgmt commands in clean way. This patch adds a helper for the purpose. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Set HCI_QUIRK_SIMULTANEOUS_DISCOVERY for BTUSB_CSRJakub Pawlowski2015-03-171-0/+2
| | | | | | | CSR controllers can do both LE scan and BR/EDR inquiry at once. Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Set HCI_QUIRK_SIMULTANEOUS_DISCOVERY for BTUSB_INTELJakub Pawlowski2015-03-171-0/+1
| | | | | | | Intel controllers can do both LE scan and BR/EDR inquiry at once. Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Set HCI_QUIRK_SIMULTANEOUS_DISCOVERY for BTUSB_ATH3012Jakub Pawlowski2015-03-171-0/+1
| | | | | | | Atheros controllers can do both LE scan and BR/EDR inquiry at once. Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Add simultaneous dual mode scanJakub Pawlowski2015-03-173-10/+70
| | | | | | | | | | | | When doing scan through mgmt api, some controllers can do both le and classic scan at same time. They can be distinguished by HCI_QUIRK_SIMULTANEOUS_DISCOVERY set. This patch enables them to use this feature when doing dual mode scan. Instead of doing le, then classic scan, both scans are run at once. Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Refactor BR/EDR inquiry and LE scan triggering.Jakub Pawlowski2015-03-171-65/+85
| | | | | | | | This patch refactor BR/EDR inquiry and LE scan triggering logic into separate methods. Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Introduce HCI_QUIRK_SIMULTANEOUS_DISCOVERYJakub Pawlowski2015-03-171-0/+8
| | | | | | | | | | | | | Some controllers allow both LE scan and BR/EDR inquiry to run at the same time, while others allow only one, LE SCAN or BR/EDR inquiry at given time. Since this is specific to each controller, add a new quirk setting that allows drivers to tell the core wether given controller can do both LE scan and BR/EDR inquiry at same time. Signed-off-by: Jakub Pawlowski <jpawlowski@google.com> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* at86rf230: fix at86rf230_read_subreg succeed handlingAlexander Aring2015-03-171-1/+1
| | | | | | | | | | | | | | This patch fix an issue when at86rf230_read_subreg was successful. The function at86rf230_read_subreg will directly call regmap_read which returns zero on successful. Nobody figured out issues yet because it was only necessary to evaluate dvdd state while probing. This could make trouble because the stack variable could have an random value. The function is also used by reset the irq line before requesting irq, but the value isn't evaluated afterwards. Signed-off-by: Alexander Aring <alex.aring@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: btusb: Fix minor whitespace issue in QCA ROME device entriesMarcel Holtmann2015-03-171-2/+2
| | | | | Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Add support for Local OOB Extended Data Update eventsMarcel Holtmann2015-03-173-0/+24
| | | | | | | | | | When a different user requests a new set of local out-of-band data, then inform all previous users that the data has been updated. To limit the scope of users, the updates are limited to previous users. If a user has never requested out-of-band data, it will also not see the update. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Fix length for Read Local OOB Extended Data respone packetMarcel Holtmann2015-03-171-1/+1
| | | | | | | | | | The length of the respone packet for Read Local OOB Extended Data command has a calculation error. In case LE Secure Connections support is not enabled, the actual response is shorter. Keep this in mind and update the value accordingly. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Do not include LE SC out-of-band data if not enabledMarcel Holtmann2015-03-161-8/+13
| | | | | | | | | | | In case LE Secure Connections is not enabled, then the command for returning local out-of-band data should not include the confirmation and random value for LE SC pairing. All other fields are still valid, but these two need to be left out. In that case it is also no needed to generate the public/private key pair for out-of-band pairing. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: The P-256 randomizer is 16 octets long and not 19 octetsMarcel Holtmann2015-03-161-1/+1
| | | | | | | | This seems to be a simple typo in the debugfs entry for the remote out-of-band data entries. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Rename smp->local_rr into smp->local_randMarcel Holtmann2015-03-161-5/+5
| | | | | | | | | The variable for the out-of-band random number was badly named and with that confusing. Just rename it to local_rand so it is clear what value it represents. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Add extra SMP_DBG statement for remote OOB dataMarcel Holtmann2015-03-161-0/+2
| | | | | | | | Just for pure debugging purposes print the remote out-of-band data that has been received and is going to be used. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Use smp->remote_pk + 32 instead of &smp->remote_pk[32]Marcel Holtmann2015-03-161-1/+1
| | | | | Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Add clarifying comment when setting local OOB flagJohan Hedberg2015-03-161-0/+8
| | | | | | | | | | It might be a bit counterintuitive to set a 'local' flag based on remote data. This patch adds a clarifying comment to the pairing req/rsp handlers when setting the LOCAL_OOB flag based on the PDU received from the remote side. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Don't send public key if OOB data verification failsJohan Hedberg2015-03-161-10/+10
| | | | | | | | | | When we receive the remote public key, if we have remote OOB data there's no point in sending our public key to the remote if the OOB data doesn't match. This patch moves the test for this higher up in the smp_cmd_public_key() function. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix verifying confirm value when lacking remote OOB dataJohan Hedberg2015-03-161-1/+3
| | | | | | | | | | If we haven't received remote OOB data we cannot perform any special checks on the confirm value. This patch updates the check after having received the public key to only perform the verification if we have remote OOB data present. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Set local OOB data flag if remote has our OOB dataJohan Hedberg2015-03-161-0/+6
| | | | | | | | | If the SMP Pairing Request or Response PDU received from the remote device indicates that it has received our OOB data we should set the SMP_FLAG_LOCAL_OOB flag. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Track local vs remote OOB data availabilityJohan Hedberg2015-03-161-4/+6
| | | | | | | | | | There are several decisions in the SMP logic that depend not only on whether we're doing SMP or not, but also whether local and/or remote OOB data is present. This patch splits the existing SMP_FLAG_OOB into two new flags to track local and remote OOB data respectively. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Fix local OOB data handling for SMPJohan Hedberg2015-03-161-2/+5
| | | | | | | | | | We need to store the local ra/rb value in order to verify the Check value received from the remote. This patch adds a new 'lr' for the local ra/rb value and makes sure it gets used when verifying the DHKey Check PDU received from the remote. Signed-off-by: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
* Bluetooth: Use smp->local_pk + 32 instead of &smp->local_pk[32]Marcel Holtmann2015-03-161-1/+1
| | | | | Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Use OOB key pair for LE SC pairing with OOB methodMarcel Holtmann2015-03-161-0/+20
| | | | | | | | | The OOB public and secret key pair is different from the non-OOB pairing procedure. SO when OOB method is in use, then use this key pair instead of generating a new one. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Return LE SC confirm and random values for out-of-band dataMarcel Holtmann2015-03-161-2/+18
| | | | | | | | | | Then the local out-of-band data for LE SC pairing is requested via Read Local OOB Extended Data command, then fill in the values generated by the smp_generate_oob function. Every call of this command will overwrite previously generated values. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Add function for generating LE SC out-of-band dataMarcel Holtmann2015-03-162-0/+54
| | | | | | | | | This patch adds a smp_generate_oob function that allows to create local out-of-band data that can be used for pairing and also provides the confirmation and random value. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Add support for AES-CMAC hash for security manager deviceMarcel Holtmann2015-03-161-0/+14
| | | | | | | | | The security manager device will require the use of AES-CMAC hash for out-of-band data generation. This patch makes sure it is correctly set up and available. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Add constants for LE SC Confirmation and Random valuesMarcel Holtmann2015-03-161-0/+2
| | | | | | | | | The LE Secure Connections Confirmation Value and LE Secure Connections Random Value contants are required for the out-of-band data and so just define them. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Create SMP device structure for local crypto contextMarcel Holtmann2015-03-161-16/+31
| | | | | | | | | | | | Every Bluetooth Low Energy controller requires a local crypto context to handle the resolvable private addresses. At the moment this is just a single crypto context, but for out-of-band data generation it will require an additional. To facility this, create a struct smp_dev that will hold all the extra information. This patch is just the refactoring in preparation for future changes. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
* Bluetooth: Use kzfree instead of kfree in security managerMarcel Holtmann2015-03-161-8/+8
| | | | | | | | | Within the security manager, it makes sense to use kzfree instead of kfree for all data structures. This ensures that no key material leaks by accident. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-10 21:20:39 +0200