The Broadcom controller on aries S5PV210 boards sends out a couple of
unknown packets after the firmware is loaded.  This will cause
logging of errors such as:
	Bluetooth: hci0: Frame reassembly failed (-84)

This is probably also the case with other boards, as there are related
Android userspace patches for custom ROMs such as
https://review.lineageos.org/#/c/LineageOS/android_system_bt/+/142721/
Since this appears to be intended behaviour, treated them as diagnostic
packets.

Note that this is another variant of commit 01d5e44a
("Bluetooth: hci_bcm: Handle empty packet after firmware loading")
Signed-off-by: NJonathan Bakker <xc-racer2@live.ca>
Signed-off-by: NPaweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

This patch adds the device ID for the BCM 4329 combo module used
in the Samsung Aries based phones (Galaxy S and it's variants).

```
[   11.508980] Bluetooth: hci0: BCM: chip id 41
[   11.518975] Bluetooth: hci0: BCM: features 0x04
[   11.550132] Bluetooth: hci0: BCM4329B1
[   11.557046] Bluetooth: hci0: BCM4329B1 (002.002.023) build 0000
[   13.737071] Bluetooth: hci0: BCM4329B1 (002.002.023) build 0744
```

Output from hciconfig

```
hci0:   Type: Primary  Bus: UART
        BD Address: 43:29:B1:55:00:00  ACL MTU: 1021:6  SCO MTU: 64:1
        UP RUNNING
        RX bytes:1675 acl:0 sco:0 events:145 errors:0
        TX bytes:20426 acl:0 sco:0 commands:146 errors:0
        Features: 0xbf 0xfe 0x8f 0xfe 0x9b 0xff 0x79 0x83
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy: RSWITCH SNIFF
        Link mode: SLAVE ACCEPT
        Name: 'aries'
        Class: 0x000000
        Service Classes: Unspecified
        Device Class: Miscellaneous,
        HCI Version: 2.1 (0x4)  Revision: 0x2e8
        LMP Version: 2.1 (0x4)  Subversion: 0x4217
        Manufacturer: Broadcom Corporation (15)
```
Signed-off-by: NPaweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Include the new USB product ID for Intel Bluetooth device 22260
family(CcPeak)

The /sys/kernel/debug/usb/devices portion for this device is:

T:  Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#=  2 Spd=12   MxCh= 0
D:  Ver= 2.00 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=8087 ProdID=0029 Rev= 0.01
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=1ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:  If#= 1 Alt= 6 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=03(O) Atr=01(Isoc) MxPS=  63 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  63 Ivl=1ms
Signed-off-by: NRaghuram Hegde <raghuram.hegde@intel.com>
Signed-off-by: NChethan T N <chethan.tumkur.narayan@intel.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

On many devices the RTL8723BS device gets reset during suspend/resume,
causing it to lose its firmware and all state.

Testing has shown it drops back to communicating at 115200 bps and sends
sync-request packages, indicating it has been fully reset.

This commit fixes this by queueing a reprobe on resume.

This mirrors how USB RTL BT devices, which have the same problem, are
handled in the btusb driver, there we set the USB_QUIRK_RESET_RESUME for
all RTL devices, which also causes a reprobe on resume. The only difference
is that here we need to do the reprobe ourselves.

Since we are doing a full reprobe on resume now, we can also turn off the
device on suspend to save power while suspended.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Add support for vendor specific suspend / resume callbacks.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Trivial fix to clean up an indentation issue, remove spaces
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Trivial fix to clean up an indentation issue
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

HCI_QUIRK_RESET_ON_CLOSE quirk is required for BT v1.0 based devices,
to send a reset command to the chip during hci device close. Serdev
architecture is used for the latest BT chips, which doesn't require to
send the reset command during close. If still chips required reset
command during close, it would be better enabling it in the vendor
probes or in proto setup.
Signed-off-by: NBalakrishna Godavarthi <bgodavar@codeaurora.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The barriers are redundant because atomic_test_and_clear_bit() already
provides the required full ordering for the cases in question (that is,
when the bit is cleared).
Signed-off-by: NAndrea Parri <andrea.parri@amarulasolutions.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The BCM43430A0 has the default MAC address 43:43:A0:12:1F:AC if none
is given. This address was found when enabling Bluetooth on a bunch of
boards with the AMPAK AP6210 module, all sharing the same address. It
also contains the sequence 4343A0, which is suspicious as that is also
the name the chip identifies itself as.

Add this to the list of default MAC addresses and leave it to the user
to configure a valid one.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The BCM4330 chip is a 802.11 a/b/g/n + Bluetooth 4.0 + HS controller.
This patch adds a compatible string match to the serdev driver for the
Bluetooth part of the chip.
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The BCM20702A1 chip is a single-chip Bluetooth 4.0 controller and
transceiver. It is found in the AMPAK AP6210 WiFi+BT package.
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Tested-by: NOndrej Jirman <megous@megous.com>
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The datasheets for BCM20702 and BCM43438 both have power up time
sequence graphs, however they are slightly different. Both chips
also have an internal power-on-reset, which holds the chip in reset
for a short time after the regulators are enabled.

For the BCM20702, the time period from when the regulators are enabled,
until the chip settles and comes out of sleep state, is 6564 ~ 8171 us.

For the BCM43438, the graph only shows the time period from when the
regulators are enabled until the chip responds by driving the host's
CTS line low, assuming the host has already driven its RTS line low.
This is shown to be 6.5 sleep cycles, with the sleep clock at 32.768
kHz. This is around 2 ms.

Wait a full 10 ms after the regulators are enabled to account for signal
rising times.
Tested-by: NOndrej Jirman <megous@megous.com>
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The Broadcom Bluetooth chips have two power inputs, VBAT and VDDIO.
The former provides overall power for the chip, while the latter powers
the I/O pins and buffers.

Model these two as regulator supplies, and let the driver manage them
in the same way as it does the clock supply.
Tested-by: NOndrej Jirman <megous@megous.com>
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The Broadcom Bluetooth controllers support a secondary LPO clock at
32.768 kHz. This external clock provides low power timing, and also
a way to detect the frequency of the main reference clock. On many
designs without NVRAM and a non-default reference clock, this must
be used or the controller will not function correctly.
Tested-by: NOndrej Jirman <megous@megous.com>
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Originally the device tree binding only specified one clock reference,
with the name "extclk". The driver simply retrieves the clock without
bothering to specify a name.

Since we added a second clock to the binding, we need to fetch the
clocks by name now. First we try the new name "txco", then fall back
to the old name "extclk", and finally try retrieving a clock without
using any name, to cover any instances where a bad device tree or
firmware worked by accident.

In the last case, we should take care that we don't get the same
clock twice when we add support for the "lpo" clock.
Tested-by: NOndrej Jirman <megous@megous.com>
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The driver currently checks the clk pointer for an error condition, as
returned by clk_get, before every invocation of the clk consumer API.
This is redundant if the goal is simply to ignore the errors, thereby
making the clk optional. The clk consumer API already checks if the
pointer is NULL or not.

Simplify the code a bit by assigning NULL to the clk pointer if the
error condition is one we want to ignore, which is every error except
deferred probing.
Tested-by: NOndrej Jirman <megous@megous.com>
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

On some systems that actually have the bluetooth controller wired up
with an extra clock signal, it's possible the bluetooth controller
probes before the clock provider. clk_get would return a defer probe
error, which was not handled by this driver.

Handle this properly, so that these systems can work reliably.
Tested-by: NOndrej Jirman <megous@megous.com>
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The BCM4330 is a 802.11 a/b/g/n WiFi + Bluetooth 4.0 chip from Broadcom.
It is found in the Ampak AP6330 WiFi+BT module. The partiular one I have
identifies as BCM4330B1 for Bluetooth and BCM4330/4 for WiFi.

It is unclear if the AP6330 module uses this revision of the BCM4330, or
if there are multiple revisions. The module does not have revision
markings. This patch elects to use just BCM4330 for the compatible
string.
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The BCM20702A1 is a Bluetooth 4.0 chip from Broadcom. It is found in the
Ampak AP6210 WiFi+BT module, identified from the read verbose config info
command response. However the Bluetooth firmware provided by vendors uses
the name BCM20710. This patch elects to use the chip ID returned by the
chip for the compatible string.
Reviewed-by: NRob Herring <robh@kernel.org>
Tested-by: NOndrej Jirman <megous@megous.com>
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The Broadcom Bluetooth chips have two power inputs, VBAT and VDDIO.
The former provides overall power for the chip, while the latter powers
the I/O pins and buffers.

This patch adds properties for the two so we can describe the power
supply relationships.
Reviewed-by: NRob Herring <robh@kernel.org>
Tested-by: NOndrej Jirman <megous@megous.com>
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

The Broadcom Bluetooth controllers can take up to two external clocks:
an external frequency reference, substituting the main crystal, and a
LPO clock at 32.768 kHz substituting the internal LPO clock.

In particular, the external LPO clock must be used when the controller
does not have NVRAM connected, and the main reference frequency is not
the default 20 MHz. This is described in detail in the datasheet.

The original "extclk" clock name is ambiguous as to which of these it
refers to, and some designs might even require both.

This patch deprecates the existing name, and adds "txco" and "lpo".
Tested-by: NOndrej Jirman <megous@megous.com>
Signed-off-by: NChen-Yu Tsai <wens@csie.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: NYangtao Li <tiny.windzz@gmail.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
Signed-off-by: NYangtao Li <tiny.windzz@gmail.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>

Previously the identifier used for indirect block callback registry and
for block rule cb registry (when done via indirect blocks) was the pointer
to the netdev we were interested in receiving updates on. This worked fine
if a single app existed that registered one callback per netdev of
interest. However, if multiple cards are in place and, in turn, multiple
apps, then each app may register the same callback with the same
identifier to both the netdev's indirect block cb list and to a block's cb
list. This can lead to EEXIST errors and/or incorrect cb deletions.

Prevent this conflict by using the app pointer as the identifier for
netdev indirect block cb registry, allowing each app to register a unique
callback per netdev. For block cb registry, the same app may register
multiple cbs to the same block if using TC shared blocks. Instead of the
app, use the pointer to the allocated cb_priv data as the identifier here.
This means that there can be a unique block callback for each app/netdev
combo.

Fixes: 3166dd07 ("nfp: flower: offload tunnel decap rules via indirect TC blocks")
Reported-by: NEdward Cree <ecree@solarflare.com>
Signed-off-by: NJohn Hurley <john.hurley@netronome.com>
Reviewed-by: NJakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This new firmware contains:
 * New packet traps for discarded packets
 * Secure firmware flash bug fix
 * Fence mechanism bug fix
 * TCAM RMA bug fix
Signed-off-by: NShalom Toledo <shalomt@mellanox.com>
Signed-off-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

mfc6_cache is not needed by ip6mr_forward2 so drop it from the input
argument list.
Signed-off-by: NDavid Ahern <dsahern@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

mfc_cache is not needed by ipmr_queue_xmit so drop it from the input
argument list.
Signed-off-by: NDavid Ahern <dsahern@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit d9fbc7f6 "net: tcp: prefer listeners bound to an address"
removes port-only listener lookups. This caused segfaults in DCCP
lookups because DCCP did not initialize the (addr,port) hashtable.

This patch adds said initialization.

The only non-trivial issue here is the size of the new hashtable.
It seemed reasonable to make it match the size of the port-only
hashtable (= INET_LHTABLE_SIZE) that was used previously. Other
parameters to inet_hashinfo2_init() match those used in TCP.

V2 changes: marked inet_hashinfo2_init as an exported symbol
so that DCCP compiles when configured as a module.

Tested: syzcaller issues fixed; the second patch in the patchset
        tests that DCCP lookups work correctly.

Fixes: d9fbc7f6 "net: tcp: prefer listeners bound to an address"
Reported-by: Nsyzcaller <syzkaller@googlegroups.com>
Signed-off-by: NPeter Oskolkov <posk@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Michael Chan says:

====================
bnxt_en: Updates for net-next.

Two main changes in this seris plus some miscellaneous changes.

1. Improvements and fixes for resource accounting which are required
for enabling SR-IOV and RDMA on the new 57500 chips.  Only SR-IOV
for 57500 chips is enabled in this series.

2. New statistics counters and improvements to keep the basic
counters and port counters during IFDOWN.

3. Msic. small changes for ETS, returning proper error codes
when flashing NVRAM, and a link speed related fix for ethtool
loopback selftest.
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

With autoneg enabled, PHY loopback test fails. To disable autoneg,
driver needs to send a valid forced speed to FW. FW is not sending
async event for invalid speeds. To fix this, query forced speeds
and send the correct speed when disabling autoneg mode.
Signed-off-by: NVasundhara Volam <vasundhara-v.volam@broadcom.com>
Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Port statistics which include RDMA counters are useful even when the
netdevice is down.  Do not free the port statistics DMA buffers
when the netdevice is down.  This is keep the snapshot of the port
statistics and counters will just continue counting when the
netdevice goes back up.

Split the bnxt_free_stats() function into 2 functions.  The port
statistics buffers will only be freed when the netdevice is
removed.
Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

With the current driver, the statistics reported by .ndo_get_stats64()
are reset when the device goes down.  Store a snapshot of the
rtnl_link_stats64 before shutdown.  This snapshot is added to the
current counters in .ndo_get_stats64() so that the counters will not
get reset when the device is down.
Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently firmware specific errors are returned directly in flash_device
and reset ethtool hooks. Modify it to return linux standard errors
to userspace when flashing operations fail.
Signed-off-by: NVasundhara Volam <vasundhara-v.volam@broadcom.com>
Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Currently, the code allows ETS bandwidth weight 0 to be set on unused TCs.
We should not set any DCB parameters on unused TCs at all.
Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Display the CoS counters as additional priority counters by looking up
the priority to CoS queue mapping.  If the TX extended port statistics
block size returned by firmware is big enough to cover the CoS counters,
then we will display the new priority counters.  We call firmware to get
the up-to-date pri2cos mapping to convert the CoS counters to
priority counters.
Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There are some minor differences when assigning VF resources on the
new chips.  The MSIX (NQ) resource has to be assigned and ring group
is not needed on the new chips.
Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When bringing up a device, the code checks to see if the number of
MSIX has changed.  pci_disable_msix() should be called first before
changing the number of reserved NQs/CMPL rings.  This ensures that
the MSIX vectors associated with the NQs/CMPL rings are still
properly mapped when pci_disable_msix() masks the vectors.

This patch will prevent errors when RDMA support is added for the new
57500 chips.  When the RDMA driver shuts down, the number of NQs is
decreased and we must use the new sequence to prevent MSIX errors.
Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

bnxt_en requires same number of stat_ctxs as CP rings but RDMA
requires only 1 stat_ctx.  Also add a new parameter resv_stat_ctxs
to better keep track of stat_ctxs reserved including resources used
by RDMA.  Add a stat_ctxs parameter to all the relevant resource
reservation functions so we can reserve the correct number of
stat_ctxs.

Prior to this patch, we were not reserving the extra stat_ctx for
RDMA and RDMA would not work on the new 57500 chips.
Signed-off-by: NVasundhara Volam <vasundhara-v.volam@broadcom.com>
Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Calling bnxt_set_max_func_stat_ctxs() to modify max stat_ctxs requested
or freed by the RDMA driver is wrong. After introducing reservation of
resources recently, the driver has to keep track of all stat_ctxs
including the ones used by the RDMA driver.  This will provide a better
foundation for accurate accounting of the stat_ctxs.
Signed-off-by: NVasundhara Volam <vasundhara-v.volam@broadcom.com>
Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>