- Sep 02, 2020
-
-
Alex Dewar authored
In a number of places in emxx_udc.c, there are variables which are assigned to without that value ever being used. Remove these pointless assignments. Reported-by:
kernel test robot <lkp@intel.com> Fixes: 33aa8d45 ("staging: emxx_udc: Add Emma Mobile USB Gadget driver") Signed-off-by:
Alex Dewar <alex.dewar90@gmail.com> Link: https://lore.kernel.org/r/20200902154628.283453-1-alex.dewar90@gmail.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
YueHaibing authored
The correct format string for a size_t argument should be %zu. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/20200901035722.9324-1-yuehaibing@huawei.com Signed-off-by:
-
YueHaibing authored
We should return error to caller in cfg80211_rtw_leave_ibss(). Signed-off-by:
-
Michael Straube authored
Use __func__ instead of hardcoded function names to clear checkpatch warnings. Signed-off-by:
Michael Straube <straube.linux@gmail.com> Link: https://lore.kernel.org/r/20200830072140.14178-1-straube.linux@gmail.com Signed-off-by:
-
Sebastian Fuentes authored
CHECK: Blank lines aren't necessary before a close brace '}' FILE: drivers/staging/qlge/qlge_mpi.c:121: CHECK: Unbalanced braces around else statement FILE: drivers/staging/qlge/qlge_mpi.c:243: CHECK: braces {} should be used on all arms of this statement FILE: drivers/staging/qlge/qlge_mpi.c:350: CHECK: Unbalanced braces around else statement FILE: drivers/staging/qlge/qlge_mpi.c:352: CHECK: Blank lines aren't necessary before a close brace '}' FILE: drivers/staging/qlge/qlge_mpi.c:360: CHECK: Blank lines aren't necessary after an open brace '{' FILE: drivers/staging/qlge/qlge_mpi.c:408: CHECK: braces {} should be used on all arms of this statement FILE: drivers/staging/qlge/qlge_mpi.c:997: CHECK: Unbalanced braces around else statement FILE: drivers/staging/qlge/qlge_mpi.c:1001: Signed-off-by:Sebastian Fuentes <sefu1789@gmail.com> Link: https://lore.kernel.org/r/20200831014859.GA29362@ubuntu Signed-off-by:
-
- Aug 28, 2020
-
-
Alex Dewar authored
In nbu2ss_eq_queue() memory is allocated with dma_alloc_coherent(), though, strangely, NULL is passed as the struct device* argument. Pass the UDC's device instead. Fix up the corresponding call to dma_free_coherent() in the same way. Build-tested on x86 only. Fixes: 33aa8d45 ("staging: emxx_udc: Add Emma Mobile USB Gadget driver") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Linus Walleij authored
Convert the atomisp LM3554 driver to use GPIO descriptors fully. It was already retrieveing the GPIO lines as descriptors but for some reason converting them back into global GPIO numbers. There is no reason to do this, just deal with the descriptors as-is. Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20200827081445.186882-1-linus.walleij@linaro.org Signed-off-by:
-
Dinghao Liu authored
When devm_clk_get() returns -EPROBE_DEFER, spi_priv should be freed just like when wilc_cfg80211_init() fails. Fixes: 854d66df ("staging: wilc1000: look for rtc_clk clock in spi mode") Signed-off-by:
Dinghao Liu <dinghao.liu@zju.edu.cn> Link: https://lore.kernel.org/r/20200819115426.29852-1-dinghao.liu@zju.edu.cn Signed-off-by:
-
Jérôme Pouiller authored
The host and the device can be connected with a called Wake-Up GPIO. When the host fall down this GPIO, it allows the device to enter in deep sleep and no communication with the device is no more possible (the device wakes up automatically on DTIM and fetch data if necessary). So, before to communicate with the device, the driver have to raise the Wake-up GPIO and then wait for an IRQ from the device. Unfortunately, old firmwares have a race in sleep/wake-up process and the device may never wake up. In this case, the IRQ is not sent and driver complains with "timeout while wake up chip". Then, the driver tries anyway to access the bus and an other error is raised by the bus. Fortunately, when the bug occurs, it is possible to fall down the IRQ and the device will eventually finish the sleep process. Then the driver can wake it up normally. The patch implements that workaround and add a retry limit in case something goes very wrong. Signed-off-by:
Jérôme Pouiller <jerome.pouiller@silabs.com> Link: https://lore.kernel.org/r/20200825085828.399505-12-Jerome.Pouiller@silabs.com Signed-off-by:
-
Jérôme Pouiller authored
The initial developer has feared msecs_to_jiffies() could round down the result. However, the documentation of msecs_to_jiffies() says that the result is rounded upward. So the increment of the result of msecs_to_jiffies() is not necessary. Signed-off-by:
-
Jérôme Pouiller authored
In the old days, ieee80211 powersave has some impact on the Rx speed. These problems are solved for a long time now. There is no more reason to not enabling it. Signed-off-by:
-
Jérôme Pouiller authored
The device is able to scan while running an Access Point. Just declare it. Signed-off-by:
-
Jérôme Pouiller authored
The trace below can appear: [83613.832200] INFO: trying to register non-static key. [83613.837248] the code is fine but needs lockdep annotation. [83613.842808] turning off the locking correctness validator. [83613.848375] CPU: 3 PID: 141 Comm: kworker/3:2H Tainted: G O 5.6.13-silabs15 #2 [83613.857019] Hardware name: BCM2835 [83613.860605] Workqueue: events_highpri bh_work [wfx] [83613.865552] Backtrace: [83613.868041] [<c010f2cc>] (dump_backtrace) from [<c010f7b8>] (show_stack+0x20/0x24) [83613.881463] [<c010f798>] (show_stack) from [<c0d82138>] (dump_stack+0xe8/0x114) [83613.888882] [<c0d82050>] (dump_stack) from [<c01a02ec>] (register_lock_class+0x748/0x768) [83613.905035] [<c019fba4>] (register_lock_class) from [<c019da04>] (__lock_acquire+0x88/0x13dc) [83613.924192] [<c019d97c>] (__lock_acquire) from [<c019f6a4>] (lock_acquire+0xe8/0x274) [83613.942644] [<c019f5bc>] (lock_acquire) from [<c0daa5dc>] (_raw_spin_lock_irqsave+0x58/0x6c) [83613.961714] [<c0daa584>] (_raw_spin_lock_irqsave) from [<c0ab3248>] (skb_dequeue+0x24/0x78) [83613.974967] [<c0ab3224>] (skb_dequeue) from [<bf330db0>] (wfx_tx_queues_get+0x96c/0x1294 [wfx]) [83613.989728] [<bf330444>] (wfx_tx_queues_get [wfx]) from [<bf320454>] (bh_work+0x454/0x26d8 [wfx]) [83614.009337] [<bf320000>] (bh_work [wfx]) from [<c014c920>] (process_one_work+0x23c/0x7ec) [83614.028141] [<c014c6e4>] (process_one_work) from [<c014cf1c>] (worker_thread+0x4c/0x55c) [83614.046861] [<c014ced0>] (worker_thread) from [<c0154c04>] (kthread+0x138/0x168) [83614.064876] [<c0154acc>] (kthread) from [<c01010b4>] (ret_from_fork+0x14/0x20) [83614.072200] Exception stack(0xecad3fb0 to 0xecad3ff8) [83614.077323] 3fa0: 00000000 00000000 00000000 00000000 [83614.085620] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [83614.093914] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 Indeed, the code of wfx_add_interface() shows that the interface is enabled to early. So, the spinlock associated with some skb_queue may not yet initialized when wfx_tx_queues_get() is called. Signed-off-by: -
Jérôme Pouiller authored
When mac80211 debug is enabled, the trace below appears: [60744.340037] wlan0: Rx A-MPDU request on aa:bb:cc:97:60:24 tid 0 result -524 This imply that ___ieee80211_start_rx_ba_session will prematurely exit and frame reordering won't be enabled. Fixes: e5da5fbd ("staging: wfx: fix CCMP/TKIP replay protection") Signed-off-by: -
Jérôme Pouiller authored
The device need to receive a skb with necessary space for the ICV. So, the driver adds this space before to send the frame. Currently, once the frame is sent, the driver restore the original content of the skb. However, this step is useless. Mac80211 don't do it when software encryption is enabled. Once we have removed this step, it appears that it is no more necessary to keep hw_key in tx_priv. Then, it is possible to simplify a bunch of code in the Tx path. Signed-off-by:
-
Jérôme Pouiller authored
When MFP is enabled, the multicast management frames are not protected, in fact. Instead, but they should include an IE containing the MMIC of the frames (i.e. a cryptographic signature). Until now, the driver didn't correctly detect this kind of frames (they are not marked protected but they are associated to a key) and didn't ask to the device to encrypt them. In add, the device is not able to generate the IE itself. Mac80211 has to generate the IE and let the device compute the MMIC. Signed-off-by:
-
Jérôme Pouiller authored
A binary operator should be followed by exactly one space. Signed-off-by:
-
Jérôme Pouiller authored
The protection of the management frames is mainly done by mac80211. However, frames for the management of the BlockAck sessions are directly sent by the device. These frames have to be protected if MFP is in use. So the driver has to pass the MFP configuration to the device. Until now, the driver directly read the RSN IE of the BSS. However, it didn't work when the BSS was MFP capable (ieee80211w=1) and the local device has disabled MFP (ieee80211w=0). This patch read the MFP information directly from the struct ieee80211_sta. This information take into account the MFP negotiated during the association. In addition, the code is far simpler. Signed-off-by:
-
Jérôme Pouiller authored
Until now, hif_map_link() get as argument the raw value for map_link_flags when map_link_flags is defined as a bitfield. It was error prone. Now hif_map_link() takes explicit value for every flags of the struct map_link_flags. Signed-off-by:
-
Jérôme Pouiller authored
The protection of the management frames is mainly done by mac80211. However, frames for the management of the BlockAck sessions are directly sent by the device. These frames have to be protected if MFP is in use. So the driver has to pass the MFP configuration to the device. Until now, the BlockAck management frames were completely unprotected whatever the status of the MFP negotiation. So, some devices dropped these frames. The device has two knobs to control the MFP. One global and one per station. Normally, the driver should always enable global MFP. Then it should enable MFP on every station with which MFP was successfully negotiated. Unfortunately, the older firmwares only provide the global control. So, this patch enable global MFP as it is exposed in the beacon. Then it marks every station with which the MFP is effective. Thus, the support for the old firmwares is not so bad. It may only encounter some difficulties to negotiate BA sessions when the local device (the AP) is MFP capable (ieee80211w=1) but the station is not. The only solution for this case is to upgrade the firmware. Signed-off-by:
-
Steff Richards authored
Indent a number of arguments so that they align with the opening parentheses of the function calls. Issues found by checkpatch. Signed-off-by:
Steff Richards <steff.richards.the.third@gmail.com> Link: https://lore.kernel.org/r/20200824165356.GA5204@steffpad Signed-off-by:
-
Ethan Edwards authored
Fixed various different checkpatch duplicate word warnings, the TODO file said to fix checkpatch warnings. Signed-off-by:
Ethan Edwards <ethancarteredwards@gmail.com> Link: https://lore.kernel.org/r/20200825002955.e3wvtwsoqqbc2cvl@archlaptop.localdomain Signed-off-by:
-
Timo A. Aranjo authored
The word "enought" was changed to read as "enough". In addition to this, there was a missing new-line after varaible declarations within a function. Signed-off-by:
Timo A. Aranjo <timo.aranjo@aol.com> Link: https://lore.kernel.org/r/20200826012101.12162-1-timo.aranjo@aol.com Signed-off-by:
-
Mauro Carvalho Chehab authored
The references inside those files were not assuming that they would end at the staging tree. Signed-off-by:
-
Colin Ian King authored
There is a spelling mistake in the MODULE_ALIAS, fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
-
Colin Ian King authored
There are a couple of duplicated "for" spelling mistakes in dev_err error messages. Fix these. Signed-off-by:
-
- Aug 19, 2020
-
-
Mauro Carvalho Chehab authored
The regulator driver needs it, as otherwise it will produce errors when creating vmlinux. Reported-by:
-
- Aug 18, 2020
-
-
Alex Dewar authored
Currently the module can only be test built on ARM, although it seems to build fine on x86. Change this to allow for broader test coverage. Signed-off-by:
-
Mauro Carvalho Chehab authored
Add an entry for the SPMI, MFD and PMIC parts of the HiSilicon 6421v600 support. Signed-off-by:
-
Mauro Carvalho Chehab authored
Add documentation for the properties needed by the HiSilicon 6421v600 driver, and by the SPMI controller used to access the chipset. Signed-off-by:
-
Mauro Carvalho Chehab authored
It is clear that this driver is for PMIC. So, get rid of it at the compatible. Signed-off-by:
-
Mauro Carvalho Chehab authored
Add the chipset name at the compatible string, as other HiSilicon chipsets with SPMI bus might require something different. Signed-off-by:
-
Mauro Carvalho Chehab authored
Both irqnum and irqarray properties reflect the same thing: the number of bits and bytes for interrupts at this chipset. E. g.: irqnum = 8 x irqarray This can be seen by the way pending interrupts are handled: /* During probe time */ pmic->irqs = devm_kzalloc(dev, pmic->irqnum * sizeof(int), GFP_KERNEL); /* While handling IRQs */ for (i = 0; i < pmic->irqarray; i++) { pending = hi6421_spmi_pmic_read(pmic, (i + pmic->irq_addr)); pending &= 0xff; for_each_set_bit(offset, &pending, 8) generic_handle_irq(pmic->irqs[offset + i * 8]); } Going further, there are some logic at the driver which assumes that irqarray is 2: /* solve powerkey order */ if ((i == HISI_IRQ_KEY_NUM) && ((pending & HISI_IRQ_KEY_VALUE) == HISI_IRQ_KEY_VALUE)) { generic_handle_irq(pmic->irqs[HISI_IRQ_KEY_DOWN]); generic_handle_irq(pmic->irqs[HISI_IRQ_KEY_UP]); pending &= (~HISI_IRQ_KEY_VALUE); } As HISI_IRQ_KEY_DOWN and HISI_IRQ_KEY_UP are fixed values and don't depend on irqnum/irqarray. The IRQ addr and mask addr seem to be also fixed, based on some comments at the OF parsing code. So, get rid of them too, removing the of parsing function completely. Signed-off-by: -
Mauro Carvalho Chehab authored
Both the SPMI controller and the SPMI PMIC driver depends on the SPMI bus support. The dependency for the regulator is also wrong: it should depends on the SPMI version of the HiSilicon 6421, and not on the normal one. Signed-off-by:
-
Mauro Carvalho Chehab authored
Place the things that are needed to be able to move those drivers out of staging. Signed-off-by:
-
Mauro Carvalho Chehab authored
Do some code cleanup in order to make it cleaner for moving it out of staging in the future. Suggested-by:
Jonathan Cameron <Jonathan.Cameron@Huawei.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
Change the binding logic to ensure that the PMIC SPMI driver will run before the regulator code and add it to the building system. Signed-off-by:
-
Mauro Carvalho Chehab authored
Fix the remaining issues complained by checkpatch. Signed-off-by:
-
Mauro Carvalho Chehab authored
Currently, an array is used to store both vsel and enable settings, mixing registers, masks and bit settings. Change it in order to have one separate property for each. This makes easier to understand the contents of the DT file, and to describe it at the Documentation/. Signed-off-by:
-
Mauro Carvalho Chehab authored
Without that, the regulator's core complains with: ldo17: ramp_delay not set For now, use the enable time, as we don't have any datasheets from this device. Signed-off-by:
-
