- 23 Mar, 2020 4 commits
-
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200225011415.GA31868@embeddedor
-
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: -
Gustavo A. R. Silva authored
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by:
-
- 18 Mar, 2020 2 commits
-
-
Kalle Valo authored
Merge tag 'iwlwifi-next-for-kalle-2020-03-17' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next First set of iwlwifi patches intended for v5.7 * Refactoring of the device selection algorithms;
-
https://github.com/nbd168/wirelessKalle Valo authored
mt76 patches for 5.7 * MT7663 support for the MT7615 driver * USB fixes * DBDC fixes for MT7615 * MT76x02 watchdog fixes * Injection fix for MT7615 * Sensitivity fix for MT7615 * MCU support code cleanup
-
- 17 Mar, 2020 34 commits
-
-
Luca Coelho authored
Move the AX200 devices to the new table and add the appropriate cfg struct and strings. Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20200309091348.fdfa5f31b8b1.Idfd28829d9f3820de06d3bba8fa66048b8d0d0b0@changeid
-
Luca Coelho authored
These entries are decided at runtime using the new parameters now, so they are not needed in the macro that is reused in the configs. Signed-off-by:
-
Luca Coelho authored
These devices can now also be fully differentiated by using the new parameters. Move them all to the new table format. Signed-off-by:
-
Luca Coelho authored
All the pu devices can now be differentiated using the new parameters, so move them all to the new tables accordingly. This also includes removal of a few deprecated IDs and redundant cfg structs. Signed-off-by:
-
Luca Coelho authored
These devices don't exist anymore, so remove them from the tables. Signed-off-by:
-
Luca Coelho authored
The 9260-1x1 device can be differentiated using the PCI device ID. There is a single occurrence of this device, so continue relying on the device and subsystem device IDs. The name of this device was incorrect, so add a new string specifically for it. Signed-off-by:
-
Luca Coelho authored
TH1 devices can now be fully differentiated by using the device parameters we have (particularly the RF_TYPE). Start using these parameters instead of hardcoding to specific subsystem device IDs. This also fixes the name of one of the TH1 devices that was erroneously using the 9260 struct and renames 9160 to 9162. Signed-off-by:
-
Luca Coelho authored
These devices can be differentiated depending on the RF type and RF ID. Change them to use these instead of relying on the subsystem device IDs. This also fixes some names that were not including 160MHz (as they should). Signed-off-by:
-
Luca Coelho authored
Pu, PnJ and Th devices have different combinations of PCI ID, MAC ID and RF IDs. Use these to differentiate them and choose the correct configuration. This also includes a change from using soc cfg's for 0x2526 devices (PnJ/Th), which was incorrect. Signed-off-by:
-
Luca Coelho authored
Devices that also include a GNSS module have different names, so add a new device option to differentiate them, according to the values we have in the modules section of the subsystem device ID. Additionally, convert the two applicable devices to use this value instead of hardcoded subsystem IDs. Signed-off-by:
-
Luca Coelho authored
Add MAC ID, RF ID and the bit that tells us whether the device can handle 160MHz bandwidth to the device struct. This allows us to chose the correct structure and string depending on these parameters. Do so for all the 0x2526 devices we already moved to the new table. Signed-off-by:
-
Luca Coelho authored
All the 0x2526 devices are now in the new table, so we can start reusing configurations and adding the strings independently to all of them, reusing them when possible. Signed-off-by:
-
Luca Coelho authored
Now that we have the strings separate from the rest, we can move the remaining 0x2526 devices to the new table in preparation to reuse the configs. Signed-off-by:
-
Lorenzo Bianconi authored
Introduce support for mt7663e 802.11ac 2x2:2 chipset to mt7615 driver. Co-developed-by:
Sean Wang <sean.wang@mediatek.com> Signed-off-by:
Ryder Lee <ryder.lee@mediatek.com> Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by:
Felix Fietkau <nbd@nbd.name>
-
Lorenzo Bianconi authored
Sobstitute sta_rec_wtbl data structure with tlv one Signed-off-by:
-
Lorenzo Bianconi authored
Introduce mt7615_mcu_uni_set_ba routine in order to add support for mt7663e driver Co-developed-by:
-
Sean Wang authored
Introduce mt7615_mcu_uni_set_bss, mt7615_mcu_uni_set_dev and mt7615_mcu_uni_set_beacon_offload uni mcu commands. This is a preliminary patch to add mt7663e support Signed-off-by:
-
Lorenzo Bianconi authored
Introduce mt7615_mcu_uni_set_bmc and mt7615_mcu_uni_set_sta routines for mt7663e commands. Co-developed-by:
-
Lorenzo Bianconi authored
Introduce mcu uni command type. Uni commands rely on a stripped verions of mt7615_mcu_txd data strutture. Split mt7615_mcu_txd_common and mt7615_mcu_txd. Uni commands will be use by mt7663e driver Co-developed-by:
-
Lorenzo Bianconi authored
Introduce mt7615_init_mac_chain routine to configure per band mac register since new devices (e.g. mt7663e) do not support dbdc Signed-off-by:
-
Lorenzo Bianconi authored
Introduce mt7615_eeprom_parse_hw_band_cap routine in order to configure supported band for mt7663e and mt7622 devices since they do not rely on eeprom data to enable 2GHz/5GHz bands Signed-off-by:
-
Lorenzo Bianconi authored
Extend mt7615_mcu_set_eeprom routine in order to be reused adding mt7663e support to mt7615 driver Co-developed-by:
-
Lorenzo Bianconi authored
Extend mt7615_driver_own and mt7615_firmware_own in order to reuse them adding mt7663e support to mt7615 driver Co-developed-by:
-
Lorenzo Bianconi authored
Introduce mt7663e support to mt7615_reg_map routine in order to reuse it adding support for mt7663e driver Co-developed-by:
-
Lorenzo Bianconi authored
In order to reuse mt7615 code adding support for mt7663e driver, introduce mt7615e_reg_map since mt7663e and mt7615 rely on a different base registers definitions. Co-developed-by:
-
Lorenzo Bianconi authored
Currently fw commands rely on negative cmds since they need different mcu msg metadata. Extend this approach introducing MCU_FW_PREFIX. This is a preliminary patch to support new mt7663e firmware commands Signed-off-by:
-
Lorenzo Bianconi authored
Move mt7615_mcu_set_beacon_offload, mt7615_mcu_set_dev and mt7615_mcu_set_bss routine in mt7615_mcu_ops data structure. This is a preliminary patch to support mt7663 firmware Signed-off-by:
-
Lorenzo Bianconi authored
Simplify mt7615_mcu_set_bss_info relying on mcu tlv helpers Signed-off-by:
-
Lorenzo Bianconi authored
Rely on skb API and avoid kmalloc the buffer in mt7615_mcu_set_eeprom routine Signed-off-by:
-
Lorenzo Bianconi authored
Move mt7615_mcu_set_sta for fw version 1 and version 2 in mt7615_mcu_ops data structure. This is a preliminary patch to properly support mt7663e firmware. Rework utility routines to rely on skb APIs for msg parsing Signed-off-by:
-
Lorenzo Bianconi authored
Move mt7615_mcu_set_bmc for fw version 1 and version 2 in mt7615_mcu_ops data structure. This is a preliminary patch to properly support mt7663e firmware. Rework utility routines to rely on skb APIs for msg parsing Signed-off-by:
-
Lorenzo Bianconi authored
Introduce mt7615_mcu_ops data structure in order to support multiple mcu ops API. Move mt7615_mcu_set_{tx,rx}_ba to mt7615_mcu_ops differentiating between fw v1 and v2. This is a preliminary patch to properly support mt7663e firmware. Rework utility routines to rely on skb APIs for msg parsing Signed-off-by: -
Lorenzo Bianconi authored
Introduce mt7615_mcu_send_message routine in order to allocate mcu skb out of mcu sending routine. This approach is useful when the mcu message is complicated and it is convenient to rely on skb buffer API Signed-off-by:
-
Lorenzo Bianconi authored
Always initialize to 0 mcu messages since if they are not propely configured they could hang the firmware. Signed-off-by:
-
