- 21 Oct, 2019 2 commits
-
-
Stefan Wahren authored
The RPi 4 uses the hardware handshake lines for CYW43455, but the chip doesn't react to HCI requests during DT probe. The reason is the inproper handling of the RTS line during startup. According to the startup signaling sequence in the CYW43455 datasheet, the hosts RTS line must be driven after BT_REG_ON and BT_HOST_WAKE. Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Jeffrey Hugo authored
This reverts commit cde9dde6. The frame reassembly errors were root caused to a transient gpio issue. The missing response was root caused to an issue with properly managing RFR in the uart driver. Addressing those root causes occurs outside of hci_qca and eliminates the need for the 50ms delay, so remove it. Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
- 19 Oct, 2019 1 commit
-
-
Nathan Chancellor authored
When building with Clang and CONFIG_BT_INTEL unset, the following error occurs: In file included from drivers/bluetooth/hci_ldisc.c:34: drivers/bluetooth/btintel.h:188:2: error: void function 'btintel_reset_to_bootloader' should not return a value [-Wreturn-type] return -EOPNOTSUPP; ^ ~~~~~~~~~~~ 1 error generated. Remove the unneeded return statement to fix this. Fixes: b9a2562f ("Bluetooth: btusb: Trigger Intel FW download error recovery") Link: https://github.com/ClangBuiltLinux/linux/issues/743 Reported-by: <ci_notify@linaro.org> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
- 17 Oct, 2019 7 commits
-
-
Bjorn Andersson authored
Split and rename qca_power_setup() in order to simplify each code path and to clarify that it is unrelated to qca_power_off() and qca_power_setup(). Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Bjorn Andersson authored
With the regulator_set_load() and regulator_set_voltage() out of the enable/disable code paths the code can now use the standard regulator bulk enable/disable API. By cloning num_vregs into struct qca_power there's no need to lug around a reference to the struct qca_vreg_data, which further simplifies qca_power_setup(). Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Bjorn Andersson authored
Devices with specific voltage requirements should not request voltage from the driver, but instead rely on the system configuration to define appropriate voltages for each rail. This ensures that PMIC and board variations are accounted for, something that the 0.1V range in the hci_qca driver currently tries to address. But on the Lenovo Yoga C630 (with wcn3990) vddch0 is 3.1V, which means the driver will fail to set the voltage. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Bjorn Andersson authored
Since the introduction of '5451781d ("regulator: core: Only count load for enabled consumers")' in v5.0, the requested load of a regulator consumer is only accounted for when said consumer is voted enabled. So there's no need to vote for load ever time the regulator is enabled or disabled. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Jeffrey Hugo authored
On the msm8998 mtp, the response to the baudrate change command is never received. On the Lenovo Miix 630, the response to the baudrate change command is corrupted - "Frame reassembly failed (-84)". Adding a 50ms delay before re-enabling flow to receive the baudrate change command response from the wcn3990 addesses both issues, and allows bluetooth to become functional. Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Amit K Bag authored
Sometimes during FW data download stage, in case of an error is encountered the controller device could not be recovered. To recover from such failures send Intel hard Reset to re-trigger FW download in following error scenarios: 1. Intel Read version command error 2. Firmware download timeout 3. Failure in Intel Soft Reset for switching to operational FW 4. Boot timeout for switching to operaional FW Signed-off-by: Raghuram Hegde <raghuram.hegde@intel.com> Signed-off-by: Chethan T N <chethan.tumkur.narayan@intel.com> Signed-off-by: Amit K Bag <amit.k.bag@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Mattijs Korpershoek authored
During the setup() stage, HCI device drivers expect the chip to acknowledge its setup() completion via vendor specific frames. If userspace opens() such HCI device in HCI_USER_CHANNEL [1] mode, the vendor specific frames are never tranmitted to the driver, as they are filtered in hci_rx_work(). Allow HCI devices which operate in HCI_USER_CHANNEL mode to receive frames if the HCI device is is HCI_INIT state. [1] https://www.spinics.net/lists/linux-bluetooth/msg37345.html Fixes: 23500189 ("Bluetooth: Introduce new HCI socket channel for user operation") Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
- 16 Oct, 2019 17 commits
-
-
Szymon Janc authored
It appears that some Broadcom controllers (eg BCM20702A0) reject LE Set Advertising Parameters command if advertising intervals provided are not within range for undirected and low duty directed advertising. Workaround this bug by populating min and max intervals with 'valid' values. < HCI Command: LE Set Advertising Parameters (0x08|0x0006) plen 15 Min advertising interval: 0.000 msec (0x0000) Max advertising interval: 0.000 msec (0x0000) Type: Connectable directed - ADV_DIRECT_IND (high duty cycle) (0x01) Own address type: Public (0x00) Direct address type: Random (0x01) Direct address: E2:F0:7B:9F:DC:F4 (Static) Channel map: 37, 38, 39 (0x07) Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00) > HCI Event: Command Complete (0x0e) plen 4 LE Set Advertising Parameters (0x08|0x0006) ncmd 1 Status: Invalid HCI Command Parameters (0x12) Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl> Tested-by: Sören Beye <linux@hypfer.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Sebastian Reichel authored
All users of this driver have been converted to the serdev based hci_ll driver. The unused driver can be safely dropped now. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Ben Dooks (Codethink) authored
It looks like in hci_init4_req() the request is being initialised from cpu-endian data but the packet is specified to be little-endian. This causes an warning from sparse due to __le16 to u16 conversion. Fix this by using cpu_to_le16() on the two fields in the packet. net/bluetooth/hci_core.c:845:27: warning: incorrect type in assignment (different base types) net/bluetooth/hci_core.c:845:27: expected restricted __le16 [usertype] tx_len net/bluetooth/hci_core.c:845:27: got unsigned short [usertype] le_max_tx_len net/bluetooth/hci_core.c:846:28: warning: incorrect type in assignment (different base types) net/bluetooth/hci_core.c:846:28: expected restricted __le16 [usertype] tx_time net/bluetooth/hci_core.c:846:28: got unsigned short [usertype] le_max_tx_time Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Adam Ford authored
As nice as it would be to update firmware faster, that patch broke at least two different boards, an OMAP4+WL1285 based Motorola Droid 4, as reported by Sebasian Reichel and the Logic PD i.MX6Q + WL1837MOD. This reverts commit a2e02f38. Signed-off-by: Adam Ford <aford173@gmail.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Cc: stable@vger.kernel.org Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Marcel Holtmann authored
For the different hardware support options, it is better to use IS_ENABLED check. Let the compiler do the needed optimizations. Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
-
Arnd Bergmann authored
The btusb_rtl_cmd_timeout() function is used inside of an ifdef, leading to a warning when this part is hidden from the compiler: drivers/bluetooth/btusb.c:530:13: error: unused function 'btusb_rtl_cmd_timeout' [-Werror,-Wunused-function] Use an IS_ENABLED() check instead so the compiler can see the code and then discard it silently. Fixes: d7ef0d1e ("Bluetooth: btusb: Use cmd_timeout to reset Realtek device") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Amit K Bag authored
After FW download there is no print to confirm the current FW version. Add print to check FW version incase of FW download. Signed-off-by: Amit K Bag <amit.k.bag@intel.com> Signed-off-by: Yoni Shavit <yshavit@chromium.org> Signed-off-by: Chethan Tumkur Narayan <chethan.tumkur.narayan@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Max Chou authored
It does not need the '-' for PTR_ERR(skb) because PTR_ERR(skb) will return the negative value during errors. Signed-off-by: Max Chou <max.chou@realtek.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Christophe JAILLET authored
'skb_pad()' a few lines above already initializes the "padded" byte to 0. So there is no need to do it twice. All what is needed is to increase the len of the skb. So 'skb_put(..., 1)' is enough here. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
YueHaibing authored
Fixes gcc '-Wunused-but-set-variable' warning: net/bluetooth/smp.c: In function 'smp_irk_matches': net/bluetooth/smp.c:505:18: warning: variable 'smp' set but not used [-Wunused-but-set-variable] net/bluetooth/smp.c: In function 'smp_generate_rpa': net/bluetooth/smp.c:526:18: warning: variable 'smp' set but not used [-Wunused-but-set-variable] It is not used since commit 28a220aa ("bluetooth: switch to AES library") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
-
Florian Fainelli authored
Make sure that we completely quiesce the network device, including its DMA to avoid having it continue to receive packets while there is no software alive to service those. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Doug Berger <opendmb@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Russell King authored
Use more linkmode_* helpers rather than open-coding the bitmap operations. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Roman Mashak authored
Added TDC test cases for Ethernet LAYERED_OP operations: - set single source Ethernet MAC - set single destination Ethernet MAC - set single invalid destination Ethernet MAC - set Ethernet type - invert source/destination/type fields - add operation on Ethernet type field Signed-off-by: Roman Mashak <mrv@mojatatu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Florian Fainelli authored
Instead of having a hard failure and stopping the driver's probe routine, generate a random Ethernet MAC address to keep going. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Acked-by: Doug Berger <opendmb@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
After commit eeb84aa0 ("net_sched: sch_fq: do not assume EDT packets are ordered"), all skbs get a non zero time_to_send in flow_queue_add() This means @time_next_packet variable in fq_dequeue() can no longer be zero. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Alexander Lobakin authored
Commit 323ebb61 ("net: use listified RX for handling GRO_NORMAL skbs") made use of listified skb processing for the users of napi_gro_frags(). The same technique can be used in a way more common napi_gro_receive() to speed up non-merged (GRO_NORMAL) skbs for a wide range of drivers including gro_cells and mac80211 users. This slightly changes the return value in cases where skb is being dropped by the core stack, but it seems to have no impact on related drivers' functionality. gro_normal_batch is left untouched as it's very individual for every single system configuration and might be tuned in manual order to achieve an optimal performance. Signed-off-by: Alexander Lobakin <alobakin@dlink.ru> Acked-by: Edward Cree <ecree@solarflare.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Himadri Pandya authored
Current code assumes PAGE_SIZE (the guest page size) is equal to the page size used to communicate with Hyper-V (which is always 4K). While this assumption is true on x86, it may not be true for Hyper-V on other architectures. For example, Linux on ARM64 may have PAGE_SIZE of 16K or 64K. A new symbol, HV_HYP_PAGE_SIZE, has been previously introduced to use when the Hyper-V page size is intended instead of the guest page size. Make this code work on non-x86 architectures by using the new HV_HYP_PAGE_SIZE symbol instead of PAGE_SIZE, where appropriate. Also replace the now redundant PAGE_SIZE_4K with HV_HYP_PAGE_SIZE. The change has no effect on x86, but lays the groundwork to run on ARM64 and others. Signed-off-by: Himadri Pandya <himadrispandya@gmail.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 15 Oct, 2019 8 commits
-
-
David S. Miller authored
Jiri Pirko says: ==================== mlxsw: Add support for 400Gbps (50Gbps per lane) link modes Add 400Gbps bits to ethtool and introduce support in mlxsw. These modes are supported by the Spectrum-2 switch ASIC. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jiri Pirko authored
Extend speed support with 400Gbps Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jiri Pirko authored
Add support for 400Gbps speed, link modes of 50Gbps per lane Signed-off-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David Ahern authored
Use my kernel.org address for all entries in MAINTAINERS. Signed-off-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Vladimir Oltean says: ==================== Scatter/gather SPI for SJA1105 DSA This is a small series that reduces the stack memory usage for the sja1105 driver. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
This reworks the SPI transfer implementation to make use of more of the SPI core features. The main benefit is to avoid the memcpy in sja1105_xfer_buf(). The memcpy was only needed because the function was transferring a single buffer at a time. So it needed to copy the caller-provided buffer at buf + 4, to store the SPI message header in the "headroom" area. But the SPI core supports scatter-gather messages, comprised of multiple transfers. We can actually use those to break apart every SPI message into 2 transfers: one for the header and one for the actual payload. To keep the behavior the same regarding the chip select signal, it is necessary to tell the SPI core to de-assert the chip select after each chunk. This was not needed before, because each spi_message contained only 1 single transfer. The meaning of the per-transfer cs_change=1 is: - If the transfer is the last one of the message, keep CS asserted - Otherwise, deassert CS We need to deassert CS in the "otherwise" case, which was implicit before. Avoiding the memcpy creates yet another opportunity. The device can't process more than 256 bytes of SPI payload at a time, so the sja1105_xfer_long_buf() function used to exist, to split the larger caller buffer into chunks. But these chunks couldn't be used as scatter/gather buffers for spi_message until now, because of that memcpy (we would have needed more memory for each chunk). So we can now remove the sja1105_xfer_long_buf() function and have a single implementation for long and short buffers. Another benefit is lower usage of stack memory. Previously we had to store 2 SPI buffers for each chunk. Due to the elimination of the memcpy, we can now send pointers to the actual chunks from the caller-supplied buffer to the SPI core. Since the patch merges two functions into a rewritten implementation, the function prototype was also changed, mainly for cosmetic consistency with the structures used within it. Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
This is a cosmetic patch that reduces some boilerplate in the SPI interaction of the driver. Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Colin Ian King authored
The variable reg is being assigned a value that is never read and is being re-assigned in the following for-loop. The assignment is redundant and hence can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 14 Oct, 2019 5 commits
-
-
David S. Miller authored
Vladimir Oltean says: ==================== PTP driver refactoring for SJA1105 DSA This series creates a better separation between the driver core and the PTP portion. Therefore, users who are not interested in PTP can get a simpler and smaller driver by compiling it out. This is in preparation for further patches: SPI transfer timestamping, synchronizing the hardware clock (as opposed to keeping it free-running), PPS input/output, etc. ==================== Acked-by: Richard Cochran <richardcochran@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
The PTP command register contains enable bits for: - Putting the 64-bit PTPCLKVAL register in add/subtract or write mode - Taking timestamps off of the corrected vs free-running clock - Starting/stopping the TTEthernet scheduling - Starting/stopping PPS output - Resetting the switch When a command needs to be issued (e.g. "change the PTPCLKVAL from write mode to add/subtract mode"), one cannot simply write to the command register setting the PTPCLKADD bit to 1, because that would zeroize the other settings. One also cannot do a read-modify-write (that would be too easy for this hardware) because not all bits of the command register are readable over SPI. So this leaves us with the only option of keeping the value of the PTP command register in the driver, and operating on that. Actually there are 2 types of PTP operations now: - Operations that modify the cached PTP command. These operate on ptp_data->cmd as a pointer. - Operations that apply all previously cached PTP settings, but don't otherwise cache what they did themselves. The sja1105_ptp_reset function is such an example. It copies the ptp_data->cmd on stack before modifying and writing it to SPI. This practically means that struct sja1105_ptp_cmd is no longer an implementation detail, since it needs to be stored in full into struct sja1105_ptp_data, and hence in struct sja1105_private. So the (*ptp_cmd) function prototype can change and take struct sja1105_ptp_cmd as second argument now. Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
This is a non-functional change with 2 goals (both for the case when CONFIG_NET_DSA_SJA1105_PTP is not enabled): - Reduce the size of the sja1105_private structure. - Make the PTP code more self-contained. Leaving priv->ptp_data.lock to be initialized in sja1105_main.c is not a leftover: it will be used in a future patch "net: dsa: sja1105: Restore PTP time after switch reset". Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
The new rule (as already started for sja1105_tas.h) is for functions of optional driver components (ones which may be disabled via Kconfig - PTP and TAS) to take struct dsa_switch *ds instead of struct sja1105_private *priv as first argument. This is so that forward-declarations of struct sja1105_private can be avoided. So make sja1105_ptp.h the second user of this rule. Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
We need priv->ptp_caps to hold a structure and not just a pointer, because we use container_of in the various PTP callbacks. Therefore, the sja1105_ptp_caps structure declared in the global memory of the driver serves no further purpose after copying it into priv->ptp_caps. So just populate priv->ptp_caps with the needed operations and remove sja1105_ptp_caps. Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-