- 04 Feb, 2021 1 commit
-
-
Dorota Czaplejewicz authored
-
- 03 Feb, 2021 8 commits
-
-
-
-
-
-
-
-
-
Martin Kepplinger authored
-
- 01 Feb, 2021 31 commits
-
-
Sebastian Krzyszkowiak authoredThis reverts commit 206778f7. When the OF bit is set, we want to ignore the stored value until it's overwritten by a new one because it's known to be invalid. The OF bit is being cleared in m41t80_rtc_set_time already, so once the kernel stores a valid value into RTC it can get read on next boot without issues. Closes #258
-
Martin Kepplinger authored
Signed-off-by:
Martin Kepplinger <martin.kepplinger@puri.sm> -
Martin Kepplinger authored
-
Martin Kepplinger authored
-
Martin Kepplinger authored
-
Martin Kepplinger authored
-
Martin Kepplinger authored
-
The interrupt handling of the RS911x is particularly heavy. For each RX packet, the card does three SDIO transactions, one to read interrupt status register, one to RX buffer length, one to read the RX packet(s). This translates to ~330 uS per one cycle of interrupt handler. In case there is more incoming traffic, this will be more. The drivers/mmc/core/sdio_irq.c has the following comment, quote "Just like traditional hard IRQ handlers, we expect SDIO IRQ handlers to be quick and to the point, so that the holding of the host lock does not cover too much work that doesn't require that lock to be held." The RS911x interrupt handler does not fit that. This patch therefore changes it such that the entire IRQ handler is moved to the RX thread instead, and the interrupt handler only wakes the RX thread. This is OK, because the interrupt handler only does things which can also be done in the RX thread, that is, it checks for firmware loading error(s), it checks buffer status, it checks whether a packet arrived and if so, reads out the packet and passes it to network stack. Moreover, this change permits removal of a code which allocated an skbuff only to get 4-byte-aligned buffer, read up to 8kiB of data into the skbuff, queue this skbuff into local private queue, then in RX thread, this buffer is dequeued, the data in the skbuff as passed to the RSI driver core, and the skbuff is deallocated. All this is replaced by directly calling the RSI driver core with local buffer. Signed-off-by:Marek Vasut <marex@denx.de>
-
Martin Kepplinger authored
-
Martin Kepplinger authored
-
This is not an ERR print so move it to the INFO zone Signed-off-by: -
When power save mode is enabled it generates a lot of noise in dmesg. Storing all this noise in the system journal is unlikely to be power efficient.
-
This seems to fix/workaround issues with WiFi connection being dropped after enabling power_save mode with some networks.
-
Martin Kepplinger authored
at least in the mainline rsi driver, this is the implemented logic.
-
Martin Kepplinger authored
-
Martin Kepplinger authored
-
Imported patch from Redpine, see: https://source.puri.sm/Librem5/linux-next/issues/69#note_73932
-
Read the version number from the flash module Signed-off-by: -
Refer to line 2308 in https://git.kernel.org/pub/scm/linux/kernel/git/jberg/iw.git/tree/scan.c Signed-off-by:
-
refer to Librem5/linux-emcraft#3 for discussions of this issue. Signed-off-by:
-
We need to rename the exported rsi_ functions so they don't conflict with the mainline driver. Signed-off-by: -
Spoof low power mode as it interferes with thoughput Signed-off-by: -
To enable the diversity set the module parameter antenna_diversity=1 insmod rsi_91x.ko rsi_zone_enabled=1 dev_oper_mode=13 antenna_diversity=1 Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
Signed-off-by: -
Add the Redpine driver for RS9116 module Signed-off-by: -
Allow network tools to specify MAC addresses other than the HW address for scanning. Fixes https://source.puri.sm/Librem5/linux-next/issues/157 Signed-off-by:
-
Add a module parameter to set the redpine logging level, Signed-off-by: -
The purism redpine module loads the firmware from the onboard flash Signed-off-by: -
This avoids [ 0.962538] spi_imx 30820000.spi: bitbang start failed with -517 durig driver probe. Fixes: 8197f489 ("spi: imx: Fix failure path leak on GPIO request error correctly") Signed-off-by:
Guido Günther <agx@sigxcpu.org>
Reviewed-by:
-
