net/sched: flower: refactor control flag definitions
Redefine the flower control flags as an enum, so they are
included in BTF info.
Make the kernel-side enum a more explicit superset of
TCA_FLOWER_KEY_FLAGS_*, new flags still need to be added to
both enums, but at least the bit position only has to be
defined once.
FLOW_DIS_ENCAPSULATION is never set for mask, so it can't be
exposed to userspace in an unsupported flags mask error message,
so it will be placed one bit position above the last uAPI flag.
Suggested-by: Alexander Lobakin <aleksander.lobakin@intel.com> Suggested-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Asbjørn Sloth Tønnesen <ast@fiberby.net> Reviewed-by: Davide Caratti <dcaratti@redhat.com> Link: https://patch.msgid.link/20240713021911.1631517-2-ast@fiberby.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Mon, 15 Jul 2024 15:27:40 +0000 (08:27 -0700)]
Merge tag 'for-net-next-2024-07-15' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
Luiz Augusto von Dentz says:
====================
bluetooth-next pull request for net-next:
- qca: use the power sequencer for QCA6390
- btusb: mediatek: add ISO data transmission functions
- hci_bcm4377: Add BCM4388 support
- btintel: Add support for BlazarU core
- btintel: Add support for Whale Peak2
- btnxpuart: Add support for AW693 A1 chipset
- btnxpuart: Add support for IW615 chipset
- btusb: Add Realtek RTL8852BE support ID 0x13d3:0x3591
* tag 'for-net-next-2024-07-15' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next: (71 commits)
Bluetooth: btmtk: Mark all stub functions as inline
Bluetooth: hci_qca: Fix build error
Bluetooth: hci_qca: use the power sequencer for wcn7850 and wcn6855
Bluetooth: hci_qca: make pwrseq calls the default if available
Bluetooth: hci_qca: unduplicate calls to hci_uart_register_device()
Bluetooth: hci_qca: schedule a devm action for disabling the clock
dt-bindings: bluetooth: qualcomm: describe the inputs from PMU for wcn7850
Bluetooth: btnxpuart: Fix warnings for suspend and resume functions
Bluetooth: btnxpuart: Add system suspend and resume handlers
Bluetooth: btnxpuart: Add support for IW615 chipset
Bluetooth: btnxpuart: Add support for AW693 A1 chipset
Bluetooth: btintel: Add support for Whale Peak2
Bluetooth: btintel: Add support for BlazarU core
Bluetooth: btusb: mediatek: add ISO data transmission functions
Bluetooth: btmtk: move btusb_recv_acl_mtk to btmtk.c
Bluetooth: btmtk: move btusb_mtk_[setup, shutdown] to btmtk.c
Bluetooth: btmtk: move btusb_mtk_hci_wmt_sync to btmtk.c
Bluetooth: btusb: add callback function in btusb suspend/resume
Bluetooth: btmtk: rename btmediatek_data
Bluetooth: btusb: mediatek: return error for failed reg access
...
====================
In prevision to add new UAPI for hwtstamp we will be limited to the struct
ethtool_ts_info that is currently passed in fixed binary format through the
ETHTOOL_GET_TS_INFO ethtool ioctl. It would be good if new kernel code
already started operating on an extensible kernel variant of that
structure, similar in concept to struct kernel_hwtstamp_config vs struct
hwtstamp_config.
Since struct ethtool_ts_info is in include/uapi/linux/ethtool.h, here
we introduce the kernel-only structure in include/linux/ethtool.h.
The manual copy is then made in the function called by ETHTOOL_GET_TS_INFO.
net: net_tstamp: Add unspec field to hwtstamp_source enumeration
Prepare for future support of saving hwtstamp source in PTP xarray by
introducing HWTSTAMP_SOURCE_UNSPEC to hwtstamp_source enum, setting it
to 0 to match old behavior of no source defined.
net: Change the API of PHY default timestamp to MAC
Change the API to select MAC default time stamping instead of the PHY.
Indeed the PHY is closer to the wire therefore theoretically it has less
delay than the MAC timestamping but the reality is different. Due to lower
time stamping clock frequency, latency in the MDIO bus and no PHC hardware
synchronization between different PHY, the PHY PTP is often less precise
than the MAC. The exception is for PHY designed specially for PTP case but
these devices are not very widespread. For not breaking the compatibility
default_timestamp flag has been introduced in phy_device that is set by
the phy driver to know we are using the old API behavior.
Bluetooth: btmtk: Mark all stub functions as inline
Several recent patches added static stubs to btmtk.h without the inline
keyword, which causes instances of -Wunused-function when those stubs
are not used anywhere in a file that includes the header:
In file included from drivers/bluetooth/btusb.c:28:
drivers/bluetooth/btmtk.h:254:13: warning: 'btmtk_fw_get_filename' defined but not used [-Wunused-function]
254 | static void btmtk_fw_get_filename(char *buf, size_t size, u32 dev_id,
| ^~~~~~~~~~~~~~~~~~~~~
drivers/bluetooth/btmtk.h:249:12: warning: 'btmtk_process_coredump' defined but not used [-Wunused-function]
249 | static int btmtk_process_coredump(struct hci_dev *hdev, struct sk_buff *skb)
| ^~~~~~~~~~~~~~~~~~~~~~
drivers/bluetooth/btmtk.h:243:12: warning: 'btmtk_register_coredump' defined but not used [-Wunused-function]
243 | static int btmtk_register_coredump(struct hci_dev *hdev, const char *name,
| ^~~~~~~~~~~~~~~~~~~~~~~
drivers/bluetooth/btmtk.h:233:12: warning: 'btmtk_setup_firmware' defined but not used [-Wunused-function]
233 | static int btmtk_setup_firmware(struct hci_dev *hdev, const char *fwname,
| ^~~~~~~~~~~~~~~~~~~~
drivers/bluetooth/btmtk.h:227:12: warning: 'btmtk_setup_firmware_79xx' defined but not used [-Wunused-function]
227 | static int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname,
| ^~~~~~~~~~~~~~~~~~~~~~~~~
Add inline to all the stubs in btmtk.h (even ones that do not currently
have any warnings associated with them) to ensure there are never unused
function warnings from these stubs, as is customary for the kernel.
Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Luiz Augusto von Dentz [Thu, 11 Jul 2024 02:30:57 +0000 (22:30 -0400)]
Bluetooth: hci_qca: Fix build error
This fixes the following build error introduced by b80f4e3b8cb8
("Bluetooth: hci_qca: schedule a devm action for disabling the clock"):
drivers/bluetooth/hci_qca.c: In function ‘qca_serdev_remove’:
drivers/bluetooth/hci_qca.c:2501:2: error: label at end of compound statement
2501 | default:
| ^~~~~~~
Fixes: b80f4e3b8cb8 ("Bluetooth: hci_qca: schedule a devm action for disabling the clock") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Bluetooth: hci_qca: use the power sequencer for wcn7850 and wcn6855
In preparation for using the power sequencing subsystem on sm8650 boards
and X13s laptop let's make pwrseq the default for wcn7850 and wcn6855.
Both these models require an enable GPIO so we can safely assume that if
the property is not there, then we should try to get the power
sequencer. Due to how the pwrseq lookup works - checking the provider at
run-time - we cannot really do it the other way around as we'd get stuck
forever on -EPROBE_DEFER.
If the relevant OF node does have the 'enable-gpios' property, we
fallback to the existing code for backward compatibility with older DTs.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Bluetooth: hci_qca: unduplicate calls to hci_uart_register_device()
Now that all three branches of the switch end up doing the same thing,
we can move the call to hci_uart_register_device() past it and unify the
error message.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Bluetooth: hci_qca: schedule a devm action for disabling the clock
In preparation for unduplicating the hci_uart registration code,
schedule a devres action for disabling the SUSCLK rather than doing it
manually.
We cannot really use devm_clk_get_enabled() as we also set the rate
before enabling the clock. While this should in theory work, I don't
want to risk breaking existing users. One solution for the future is to
add devm_clk_get_enabled_with_rate() to the clock framework.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
dt-bindings: bluetooth: qualcomm: describe the inputs from PMU for wcn7850
Drop the inputs from the host and instead expect the Bluetooth node to
consume the outputs of the internal PMU. This model is closer to reality
than how we represent it now.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Bluetooth: btnxpuart: Fix warnings for suspend and resume functions
This fixes the warnings 'nxp_serdev_resume' and 'nxp_serdev_suspend'
defined but not used.
Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202407100518.06Xxq5PK-lkp@intel.com/ Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Chris Lu [Thu, 4 Jul 2024 06:01:16 +0000 (14:01 +0800)]
Bluetooth: btusb: mediatek: add ISO data transmission functions
This patch implements functions for ISO data send and receive in btusb
driver for MediaTek's controller.
MediaTek defines a specific interrupt endpoint for ISO data transmissin
because the characteristics of interrupt endpoint are similar to the
application of ISO data which can support guaranteed transmissin
bandwidth, enough maximum data length and error checking mechanism.
Driver sets up ISO interface and endpoints in btusb_mtk_setup and clears
the setup in btusb_mtk_shutdown. These flow can't move to btmtk.c due to
btusb_driver is only defined in btusb.c when claiming/relaesing interface.
ISO packet anchor stops when driver suspending and resubmit interrupt urb
for ISO data when driver resuming.
Signed-off-by: Chris Lu <chris.lu@mediatek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Chris Lu [Thu, 4 Jul 2024 06:01:15 +0000 (14:01 +0800)]
Bluetooth: btmtk: move btusb_recv_acl_mtk to btmtk.c
Move btusb_recv_acl_mtk from btusb.c to btmtk.c which holds
vendor specific stuff and would make btusb.c clean.
Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Chris Lu <chris.lu@mediatek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Chris Lu [Thu, 4 Jul 2024 06:01:14 +0000 (14:01 +0800)]
Bluetooth: btmtk: move btusb_mtk_[setup, shutdown] to btmtk.c
Move btusb_mtk_[setup, shutdown] and related function from
btusb.c to btmtk.c which holds vendor specific stuff and
would make btusb.c clean.
Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Chris Lu <chris.lu@mediatek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Chris Lu [Thu, 4 Jul 2024 06:01:13 +0000 (14:01 +0800)]
Bluetooth: btmtk: move btusb_mtk_hci_wmt_sync to btmtk.c
Move btusb_mtk_hci_wmt_sync from btusb.c to btmtk.c which holds
vendor specific stuff and would make btusb.c clean.
Add usb.h header to btmtksdio.c/btmtkuart.c for usb related element
defined in btmtk.h
Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Chris Lu <chris.lu@mediatek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Chris Lu [Thu, 4 Jul 2024 06:01:12 +0000 (14:01 +0800)]
Bluetooth: btusb: add callback function in btusb suspend/resume
Add suspend/resum callback function in btusb_data which are reserved
for vendor specific usage during suspend/resume. hdev->suspend will be
added before stop traffic in btusb_suspend and hdev-> resume will be
added after resubmit urb in btusb_resume.
Signed-off-by: Chris Lu <chris.lu@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Chris Lu [Thu, 4 Jul 2024 06:01:11 +0000 (14:01 +0800)]
Bluetooth: btmtk: rename btmediatek_data
Rename btmediatek_data to have a consistent prefix throughout the driver.
Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Chris Lu <chris.lu@mediatek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Chris Lu [Thu, 4 Jul 2024 06:01:10 +0000 (14:01 +0800)]
Bluetooth: btusb: mediatek: return error for failed reg access
Update the code to immediately return an error code if accessing a
related register fails. This ensures that our desired logic for
subsequent register operations is maintained and allows us to promptly
catch any unexpected errors.
Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Chris Lu <chris.lu@mediatek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Chris Lu [Thu, 4 Jul 2024 06:01:09 +0000 (14:01 +0800)]
Bluetooth: btusb: mediatek: remove the unnecessary goto tag
Remove the unnecessary goto tag whether there is an error or not, we have
to free the buffer at the end of the function.
Signed-off-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Chris Lu <chris.lu@mediatek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Rafał Miłecki [Fri, 28 Jun 2024 05:46:35 +0000 (07:46 +0200)]
dt-bindings: net: bluetooth: convert MT7622 Bluetooth to the json-schema
This helps validating DTS files. Introduced changes:
1. Dropped serial details from example
2. Added required example include
Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Luiz Augusto von Dentz [Mon, 1 Jul 2024 16:07:46 +0000 (12:07 -0400)]
Bluetooth: Fix usage of __hci_cmd_sync_status
__hci_cmd_sync_status shall only be used if hci_req_sync_lock is _not_
required which is not the case of hci_dev_cmd so it needs to use
hci_cmd_sync_status which uses hci_req_sync_lock internally.
Fixes: f1a8f402f13f ("Bluetooth: L2CAP: Fix deadlock") Reported-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Dmitry Antipov [Fri, 21 Jun 2024 13:01:55 +0000 (16:01 +0300)]
Bluetooth: hci_core: cleanup struct hci_dev
Remove unused and set but otherwise unused 'discovery_old_state'
and 'sco_last_tx' members of 'struct hci_dev'. The first one is
a leftover after commit 182ee45da083 ("Bluetooth: hci_sync: Rework
hci_suspend_notifier"); the second one is originated from ancient
2.4.19 and I was unable to find any actual use since that.
Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Kiran K [Thu, 27 Jun 2024 13:06:39 +0000 (18:36 +0530)]
Bluetooth: btintel: Fix the sfi name for BlazarU
Use INTEL_HW_VARIANT() instead of CNVi Id to decide to load Intermediate
Loader (IML) image. Fix the driver loading incorrect firmware for
BlazarU product.
Fixes: 164c62f958f8 ("Bluetooth: btintel: Add firmware ID to firmware name") Reported-by: Tsigan, Vladislav <vladislav.tsigan@intel.com> Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Bartosz Golaszewski [Mon, 24 Jun 2024 19:45:18 +0000 (21:45 +0200)]
Bluetooth: qca: don't disable power management for QCA6390
We unnecessarily fallthrough the case for QCA6390 when initializing the
device and hit the condition where - due to the lack of the enable-gpio
- we disable power management despite using the power sequencer. We don't
need to look for clocks on this model so it makes more sense to just
register the hci device and break the switch.
Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Fixes: 9a15ce685706 ("Bluetooth: qca: use the power sequencer for QCA6390") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # RB5 Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Krzysztof Kozlowski [Sun, 23 Jun 2024 17:13:52 +0000 (19:13 +0200)]
Bluetooth: hci: fix build when POWER_SEQUENCING=m
BT_HCIUART_QCA, which is a bool and an HCI UART component, uses now
power sequencing, so we need to be sure BT_HCIUART_QCA=y and
POWER_SEQUENCING=m cannot happen:
/usr/bin/aarch64-linux-gnu-ld: drivers/bluetooth/hci_qca.o: in function `qca_serdev_probe':
drivers/bluetooth/hci_qca.c:2401:(.text+0xc48): undefined reference to `devm_pwrseq_get'
/usr/bin/aarch64-linux-gnu-ld: drivers/bluetooth/hci_qca.o: in function `qca_power_shutdown':
drivers/bluetooth/hci_qca.c:2192:(.text+0x29e8): undefined reference to `pwrseq_power_off'
/usr/bin/aarch64-linux-gnu-ld: drivers/bluetooth/hci_qca.o: in function `qca_power_on':
drivers/bluetooth/hci_qca.c:1808:(.text+0x3390): undefined reference to `pwrseq_power_on'
Fixes: 9a15ce685706 ("Bluetooth: qca: use the power sequencer for QCA6390") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Paul Menzel [Fri, 21 Jun 2024 07:18:57 +0000 (09:18 +0200)]
Bluetooth: btintel: Fix spelling of *intermediate* in comment
Fixes: f3b845e0aea3 ("Bluetooth: btintel: Add support to download intermediate loader") Cc: Kiran K <kiran.k@intel.com> Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Bartosz Golaszewski [Wed, 12 Jun 2024 08:01:49 +0000 (10:01 +0200)]
dt-bindings: net: bluetooth: qualcomm: describe regulators for QCA6390
QCA6390 has a compatible listed in the bindings but is missing the
regulators description. Add the missing supply property and list the
required ones in the allOf section.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Aleksander Jan Bajkowski [Sat, 13 Jul 2024 17:09:20 +0000 (19:09 +0200)]
net: ethernet: lantiq_etop: remove redundant device name setup
The same name is set when allocating the netdevice structure in the
alloc_etherdev_mq()->alloc_etherrdev_mqs() function. Therefore, there
is no need to manually set it.
This fixes CheckPatch warnings:
WARNING: Prefer strscpy over strcpy - see: https://github.com/KSPP/linux/issues/88
strcpy(dev->name, "eth%d");
This patch series is a result of splitting a larger patch series [0],
where some parts was merged before.
The first patch implements port state configuration, which is required
for bridge functionality. STP frames are not forwarded at this moment.
BPDU frames are only forwarded from/to the PI/SI interface.
For more information, see chapter 2.7.1 (CPU Forwarding) in the
datasheet.
Patches 2, 7-9 and 11 provide a basic implementation of tag_8021q
functionality with QinQ support, without VLAN filtering in
the bridge and simple VLAN awareness in VLAN filtering mode.
Patches 3-6 came from Vladimir Oltean. They prepare for making
tag8021q more common. VSC73XX uses very similar tag recognition,
and some code from tag_sja1105 could be moved to tag_8021q for
common use.
Patch 10 is preparation for use tag_8021q bridge functions as generic
implementation of the 'ds->ops->port_bridge_*()'.
Patch 12 is required to avoid problem with learning on standalone ports.
net: dsa: vsc73xx: start treating the BR_LEARNING flag
This patch implements .port_pre_bridge_flags() and .port_bridge_flags(),
which are required for properly treating the BR_LEARNING flag. Also,
.port_stp_state_set() is tweaked and now disables learning for standalone
ports.
Disabling learning for standalone ports is required to avoid situations
where one port sees traffic originating from another, which could cause
packet drops.
This patch adds bridge support for the vsc73xx driver.
The vsc73xx requires minimal operations and ithe generic
dsa_tag_8021q_bridge_* API is sufficient.
The forwarding matrix is managed by vsc73xx_port_stp_state_set() ->
vsc73xx_refresh_fwd_map()i routine, which is called immediately after
.port_bridge_join() and .port_bridge_leave().
net: dsa: prepare 'dsa_tag_8021q_bridge_join' for standalone use
The 'dsa_tag_8021q_bridge_join' could be used as a generic implementation
of the 'ds->ops->port_bridge_join()' function. However, it is necessary
to synchronize their arguments.
This patch also moves the 'tx_fwd_offload' flag configuration line into
'dsa_tag_8021q_bridge_join' body. Currently, every (sja1105) driver sets
it, and the future vsc73xx implementation will also need it for
simplification.
net: dsa: vsc73xx: Implement the tag_8021q VLAN operations
This patch is a simple implementation of 802.1q tagging in the vsc73xx
driver. Currently, devices with DSA_TAG_PROTO_NONE are not functional.
The VSC73XX family doesn't provide any tag support for external Ethernet
ports.
The only option available is VLAN-based tagging, which requires constant
hardware VLAN filtering. While the VSC73XX family supports provider
bridging, it only supports QinQ without full implementation of 802.1AD.
This means it only allows the doubled 0x8100 TPID.
In the simple port mode, QinQ is enabled to preserve forwarding of
VLAN-tagged frames.
net: dsa: vsc73xx: introduce tag 8021q for vsc73xx
This commit introduces a new tagger based on 802.1q tagging.
It's designed for the vsc73xx driver. The VSC73xx family doesn't have
any tag support for the RGMII port, but it could be based on VLANs.
Vladimir Oltean [Sat, 13 Jul 2024 21:16:12 +0000 (23:16 +0200)]
net: dsa: tag_sja1105: refactor skb->dev assignment to dsa_tag_8021q_find_user()
A new tagging protocol implementation based on tag_8021q is on the
horizon, and it appears that it also has to open-code the complicated
logic of finding a source port based on a VLAN header.
Create a single dsa_tag_8021q_find_user() and make sja1105 call it.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20240713211620.1125910-7-paweldembicki@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Vladimir Oltean [Sat, 13 Jul 2024 21:16:11 +0000 (23:16 +0200)]
net: dsa: tag_sja1105: prefer precise source port info on SJA1110 too
Now that dsa_8021q_rcv() handles better the case where we don't
overwrite the precise source information if it comes from an external
(non-tag_8021q) source, we can now unify the call sequence between
sja1105_rcv() and sja1110_rcv().
This is a preparatory change for creating a higher-level wrapper for the
entire sequence which will live in tag_8021q.
Vladimir Oltean [Sat, 13 Jul 2024 21:16:10 +0000 (23:16 +0200)]
net: dsa: tag_sja1105: absorb entire sja1105_vlan_rcv() into dsa_8021q_rcv()
tag_sja1105 has a wrapper over dsa_8021q_rcv(): sja1105_vlan_rcv(),
which determines whether the packet came from a bridge with
vlan_filtering=1 (the case resolved via
dsa_find_designated_bridge_port_by_vid()), or if it contains a tag_8021q
header.
Looking at a new tagger implementation for vsc73xx, based also on
tag_8021q, it is becoming clear that the logic is needed there as well.
So instead of forcing each tagger to wrap around dsa_8021q_rcv(), let's
merge the logic into the core.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Tested-by: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com> Link: https://patch.msgid.link/20240713211620.1125910-5-paweldembicki@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Vladimir Oltean [Sat, 13 Jul 2024 21:16:09 +0000 (23:16 +0200)]
net: dsa: tag_sja1105: absorb logic for not overwriting precise info into dsa_8021q_rcv()
In both sja1105_rcv() and sja1110_rcv(), we may have precise source port
information coming from parallel hardware mechanisms, in addition to the
tag_8021q header.
Only sja1105_rcv() has extra logic to not overwrite that precise info
with what's present in the VLAN tag. This is because sja1110_rcv() gets
by, by having a reversed set of checks when assigning skb->dev. When the
source port is imprecise (vbid >=1), source_port and switch_id will be
set to zeroes by dsa_8021q_rcv(), which might be problematic. But by
checking for vbid >= 1 first, sja1110_rcv() fends that off.
We would like to make more code common between sja1105_rcv() and
sja1110_rcv(), and for that, we need to make sure that sja1110_rcv()
also goes through the precise source port preservation logic.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: Pawel Dembicki <paweldembicki@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Tested-by: Vladimir Oltean <olteanv@gmail.com> Link: https://patch.msgid.link/20240713211620.1125910-4-paweldembicki@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This patch implements VLAN filtering for the vsc73xx driver.
After starting VLAN filtering, the switch is reconfigured from QinQ to
a simple VLAN aware mode. This is required because VSC73XX chips do not
support inner VLAN tag filtering.
net: ti: icssg-prueth: Split out common object into module
icssg_prueth.c and icssg_prueth_sr1.c drivers use multiple common .c
files. These common objects are getting added to multiple modules. As a
result when both drivers are enabled in .config, below warning is seen.
drivers/net/ethernet/ti/Makefile: icssg/icssg_common.o is added to multiple modules: icssg-prueth icssg-prueth-sr1
drivers/net/ethernet/ti/Makefile: icssg/icssg_classifier.o is added to multiple modules: icssg-prueth icssg-prueth-sr1
drivers/net/ethernet/ti/Makefile: icssg/icssg_config.o is added to multiple modules: icssg-prueth icssg-prueth-sr1
drivers/net/ethernet/ti/Makefile: icssg/icssg_mii_cfg.o is added to multiple modules: icssg-prueth icssg-prueth-sr1
drivers/net/ethernet/ti/Makefile: icssg/icssg_stats.o is added to multiple modules: icssg-prueth icssg-prueth-sr1
drivers/net/ethernet/ti/Makefile: icssg/icssg_ethtool.o is added to multiple modules: icssg-prueth icssg-prueth-sr1
Fix this by building a new module (icssg.o) for all the common objects.
Both the driver can then depend on this common module.
Some APIs being exported have emac_ as the prefix which may result into
confusion with other existing APIs with emac_ prefix, to avoid
confusion, rename the APIs being exported with emac_ to icssg_ prefix.
This also fixes below error seen when both drivers are built.
ERROR: modpost: "icssg_queue_pop"
[drivers/net/ethernet/ti/icssg-prueth-sr1.ko] undefined!
ERROR: modpost: "icssg_queue_push"
[drivers/net/ethernet/ti/icssg-prueth-sr1.ko] undefined!
Reported-and-tested-by: Thorsten Leemhuis <linux@leemhuis.info> Closes: https://lore.kernel.org/oe-kbuild-all/202405182038.ncf1mL7Z-lkp@intel.com/ Fixes: 487f7323f39a ("net: ti: icssg-prueth: Add helper functions to configure FDB") Reviewed-by: Roger Quadros <rogerq@kernel.org> Signed-off-by: MD Danish Anwar <danishanwar@ti.com> Reviewed-by: Sai Krishna <saikrishnag@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
The issue arises because virtio is assuming it's running in NAPI context
even when it's not, such as in the netpoll case.
To resolve this, modify virtnet_poll_tx() to only set NAPI when budget
is available. Same for virtnet_poll_cleantx(), which always assumed that
it was in a NAPI context.
Fixes: df133f3f9625 ("virtio_net: bulk free tx skbs") Suggested-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Heng Qi <hengqi@linux.alibaba.com> Link: https://patch.msgid.link/20240712115325.54175-1-leitao@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: phy: bcm-phy-lib: Implement BroadR-Reach link modes
Implement single-pair BroadR-Reach modes on bcm5481x PHY by Broadcom.
Create set of functions alternative to IEEE 802.3 to handle
configuration of these modes on compatible Broadcom PHYs.
There is only subset of capabilities supported because of limited
collection of hardware available for the development.
For BroadR-Reach capable PHYs, the LRE (Long Reach Ethernet)
alternative register set is handled. Only bcm54811 PHY is verified,
for bcm54810, there is some support possible but untested. There
is no auto-negotiation of the link parameters (called LDS in the
Broadcom terminology, Long-Distance Signaling) for bcm54811.
It should be possible to enable LDS for bcm54810.
Signed-off-by: Kamil Horák (2N) <kamilh@axis.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20240712150709.3134474-5-kamilh@axis.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
dt-bindings: ethernet-phy: add optional brr-mode flag
There is a group of PHY chips supporting BroadR-Reach link modes in
a manner allowing for more or less identical register usage as standard
Clause 22 PHY.
These chips support standard Ethernet link modes as well, however, the
circuitry is mutually exclusive and cannot be auto-detected.
The link modes in question are 100Base-T1 as defined in IEEE802.3bw,
based on Broadcom's 1BR-100 link mode, and newly defined 10Base-T1BRR
(1BR-10 in Broadcom documents).
Add optional brr-mode flag to switch the PHY to BroadR-Reach mode.
Signed-off-by: Kamil Horák (2N) <kamilh@axis.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://patch.msgid.link/20240712150709.3134474-4-kamilh@axis.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: phy: bcm54811: New link mode for BroadR-Reach
Introduce a new link mode necessary for 10 MBit single-pair
connection in BroadR-Reach mode on bcm5481x PHY by Broadcom.
This new link mode, 10baseT1BRR, is known as 1BR10 in the Broadcom
terminology. Another link mode to be used is 1BR100 and it is already
present as 100baseT1, because Broadcom's 1BR100 became 100baseT1
(IEEE 802.3bw).
Signed-off-by: Kamil Horák (2N) <kamilh@axis.com> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20240712150709.3134474-2-kamilh@axis.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
XDP socket(AF_XDP) is an excellent bypass kernel network framework. The zero
copy feature of xsk (XDP socket) needs to be supported by the driver. The
performance of zero copy is very good. mlx5 and intel ixgbe already support
this feature, This patch set allows virtio-net to support xsk's zerocopy xmit
feature.
So it is time for Virtio-Net to complete the support for the XDP Socket
Zerocopy.
Virtio-net can not increase the queue num at will, so xsk shares the queue with
kernel.
On the other hand, Virtio-Net does not support generate interrupt from driver
manually, so when we wakeup tx xmit, we used some tips. If the CPU run by TX
NAPI last time is other CPUs, use IPI to wake up NAPI on the remote CPU. If it
is also the local CPU, then we wake up napi directly.
This patch set includes some refactor to the virtio-net to let that to support
AF_XDP.
Because there are too many commits, the work of virtio net supporting af-xdp is
split to rx part and tx part. This patch set is for rx part.
So the flag NETDEV_XDP_ACT_XSK_ZEROCOPY is not added, if someone want to test
for af-xdp rx, the flag needs to be adding locally.
ENV: Qemu with vhost-user(polling mode).
Host CPU: Intel(R) Xeon(R) Platinum 8163 CPU @ 2.50GHz
testpmd> show port stats all
######################## NIC statistics for port 0 ########################
RX-packets: 19531092064 RX-missed: 0 RX-bytes: 1093741155584
RX-errors: 0
RX-nombuf: 0
TX-packets: 5959955552 TX-errors: 0 TX-bytes: 371030645664
Xuan Zhuo [Mon, 8 Jul 2024 11:25:36 +0000 (19:25 +0800)]
virtio_net: xsk: rx: support recv small mode
In the process:
1. We may need to copy data to create skb for XDP_PASS.
2. We may need to call xsk_buff_free() to release the buffer.
3. The handle for xdp_buff is difference from the buffer.
If we pushed this logic into existing receive handle(merge and small),
we would have to maintain code scattered inside merge and small (and big).
So I think it is a good choice for us to put the xsk code into an
independent function.
Xuan Zhuo [Mon, 8 Jul 2024 11:25:32 +0000 (19:25 +0800)]
virtio_net: separate receive_mergeable
This commit separates the function receive_mergeable(),
put the logic of appending frag to the skb as an independent function.
The subsequent commit will reuse it.
Xuan Zhuo [Mon, 8 Jul 2024 11:25:31 +0000 (19:25 +0800)]
virtio_net: separate receive_buf
This commit separates the function receive_buf(), then we wrap the logic
of handling the skb to an independent function virtnet_receive_done().
The subsequent commit will reuse it.
Xuan Zhuo [Mon, 8 Jul 2024 11:25:28 +0000 (19:25 +0800)]
virtio_net: replace VIRTIO_XDP_HEADROOM by XDP_PACKET_HEADROOM
virtio net has VIRTIO_XDP_HEADROOM that is equal to
XDP_PACKET_HEADROOM to calculate the headroom for xdp.
But here we should use the macro XDP_PACKET_HEADROOM from bpf.h to
calculate the headroom for xdp. So here we remove the
VIRTIO_XDP_HEADROOM, and use the XDP_PACKET_HEADROOM to replace it.
====================
Eliminate CONFIG_NR_CPUS dependency in dpaa-eth and enable COMPILE_TEST in fsl_qbman
Breno's previous attempt at enabling COMPILE_TEST for the fsl_qbman
driver (now included here as patch 5/5) triggered compilation warnings
for large CONFIG_NR_CPUS values:
https://lore.kernel.org/all/202406261920.l5pzM1rj-lkp@intel.com/
Patch 1/5 switches two NR_CPUS arrays in the dpaa-eth driver to dynamic
allocation to avoid that warning. There is more NR_CPUS usage in the
fsl-qbman driver, but that looks relatively harmless and I couldn't find
a good reason to change it.
I noticed, while testing, that the driver doesn't actually work properly
with high CONFIG_NR_CPUS values, and patch 2/5 addresses that.
During code analysis, I have identified two places which treat
conditions that can never happen. Patches 3/5 and 4/5 simplify the
probing code - dpaa_fq_setup() - just a little bit.
Finally we have at 5/5 the patch that triggered all of this. There is
an okay from Herbert to take it via netdev, despite it being on soc/qbman:
https://lore.kernel.org/all/Zns%2FeVVBc7pdv0yM@gondor.apana.org.au/
Link to v1:
https://lore.kernel.org/netdev/20240710230025.46487-1-vladimir.oltean@nxp.com/
====================
Vladimir Oltean [Sat, 13 Jul 2024 22:53:35 +0000 (01:53 +0300)]
net: dpaa: no need to make sure all CPUs receive a corresponding Tx queue
dpaa_fq_setup() iterates through the &priv->dpaa_fq_list elements
allocated by dpaa_alloc_all_fqs(). This includes a call to:
if (!dpaa_fq_alloc(dev, 0, dpaa_max_num_txqs(), list, FQ_TYPE_TX))
goto fq_alloc_failed;
which gives us dpaa_max_num_txqs() elements of FQ_TYPE_TX type.
The code block which we are deleting runs after an earlier iteration
through &priv->dpaa_fq_list. So at the end of this iteration (for which
there is no early break), egress_cnt will be unconditionally equal to
dpaa_max_num_txqs().
In other words, dpaa_alloc_all_fqs() has already allocated TX queues for
all possible CPUs and the maximal number of traffic classes, and we've
already iterated once through them all.
Vladimir Oltean [Sat, 13 Jul 2024 22:53:34 +0000 (01:53 +0300)]
net: dpaa: stop ignoring TX queues past the number of CPUs
dpaa_fq_setup() iterates through the queues allocated by dpaa_alloc_all_fqs()
and saved in &priv->dpaa_fq_list.
The allocation for FQ_TYPE_TX looks as follows:
if (!dpaa_fq_alloc(dev, 0, dpaa_max_num_txqs(), list, FQ_TYPE_TX))
goto fq_alloc_failed;
Thus, iterating again through FQ_TYPE_TX queues in dpaa_fq_setup() and
counting them will never yield an egress_cnt larger than the allocated
size, dpaa_max_num_txqs().
The comparison serves no purpose since it is always true; remove it.
Vladimir Oltean [Sat, 13 Jul 2024 22:53:33 +0000 (01:53 +0300)]
net: dpaa: eliminate NR_CPUS dependency in egress_fqs[] and conf_fqs[]
The driver uses the DPAA_TC_TXQ_NUM and DPAA_ETH_TXQ_NUM macros for TX
queue handling, and they depend on CONFIG_NR_CPUS.
In generic .config files, these can go to very large (8096 CPUs) values
for the systems that DPAA1 is integrated in (1-24 CPUs). We allocate a
lot of resources that will never be used. Those are:
- system memory
- QMan FQIDs as managed by qman_alloc_fqid_range(). This is especially
painful since currently, when booting with CONFIG_NR_CPUS=8096, a
LS1046A-RDB system will only manage to probe 3 of its 6 interfaces.
The rest will run out of FQD ("/reserved-memory/qman-fqd" in the
device tree) and fail at the qman_create_fq() stage of the probing
process.
- netdev queues as alloc_etherdev_mq() argument. The high queue indices
are simply hidden from the network stack after the call to
netif_set_real_num_tx_queues().
With just a tiny bit more effort, we can replace the NR_CPUS
compile-time constant with the num_possible_cpus() run-time constant,
and dynamically allocate the egress_fqs[] and conf_fqs[] arrays.
Even on a system with a high CONFIG_NR_CPUS, num_possible_cpus() will
remain equal to the number of available cores on the SoC.
The replacement is as follows:
- DPAA_TC_TXQ_NUM -> dpaa_num_txqs_per_tc()
- DPAA_ETH_TXQ_NUM -> dpaa_max_num_txqs()
Vladimir Oltean [Sat, 13 Jul 2024 22:53:32 +0000 (01:53 +0300)]
net: dpaa: avoid on-stack arrays of NR_CPUS elements
The dpaa-eth driver is written for PowerPC and Arm SoCs which have 1-24
CPUs. It depends on CONFIG_NR_CPUS having a reasonably small value in
Kconfig. Otherwise, there are 2 functions which allocate on-stack arrays
of NR_CPUS elements, and these can quickly explode in size, leading to
warnings such as:
The problem is twofold:
- Reducing the array size to the boot-time num_possible_cpus() (rather
than the compile-time NR_CPUS) creates a variable-length array,
which should be avoided in the Linux kernel.
- Using NR_CPUS as an array size makes the driver blow up in stack
consumption with generic, as opposed to hand-crafted, .config files.
A simple solution is to use dynamic allocation for num_possible_cpus()
elements (aka a small number determined at runtime).
Kiran K [Wed, 19 Jun 2024 10:09:33 +0000 (15:39 +0530)]
Bluetooth: btintel: Add firmware ID to firmware name
From BlazarI onwards, driver shall append the firmware ID (usually
represents transport type) while constructing the firmware name.
Firmware ID is returned on Intel Read Version command.
The new firmware file name for operational image and ddc file shall be,
ibt-<cnvi_top type+cnvi_top step>-<cnvr_top type+cnvr_top step-fw_id>.[sfi|ddc]
After commit 78db544b5d27 ("Bluetooth: hci_core: Remove le_restart_scan
work"), 'scan_start' and 'scan_duration' of 'struct discovery_state'
are still initialized but actually unused. So remove the aforementioned
fields and adjust 'hci_discovery_filter_clear()' and 'le_scan_disable()'
accordingly. Compile tested only.
Fixes: 78db544b5d27 ("Bluetooth: hci_core: Remove le_restart_scan work") Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Iulia Tanasescu [Mon, 17 Jun 2024 08:52:06 +0000 (11:52 +0300)]
Bluetooth: hci_event: Set QoS encryption from BIGInfo report
On a Broadcast Sink, after synchronizing to the PA transimitted by a
Broadcast Source, the BIGInfo advertising reports emitted by the
Controller hold the encryption field, which indicates whether the
Broadcast Source is transmitting encrypted streams.
This updates the PA sync hcon QoS with the encryption value reported
in the BIGInfo report, so that this information is accurate if the
userspace tries to access the QoS struct via getsockopt.
Fixes: 1d11d70d1f6b ("Bluetooth: ISO: Pass BIG encryption info through QoS") Signed-off-by: Iulia Tanasescu <iulia.tanasescu@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Neeraj Sanjay Kale [Fri, 14 Jun 2024 08:23:38 +0000 (13:53 +0530)]
Bluetooth: btnxpuart: Add handling for boot-signature timeout errors
This handles the timeout error codes sent by the chip as part of the
bootloader signatures during firmware download process.
When the bootloader does not receive a response packet from the host
within a specific time, it adds an error code to the bootloader
signature while requesting for the FW chunk from the same offset.
The host is expected to clear this error code with a NAK, and reply to
only those bootloader signatures which have error code 0.
However, the driver was ignoring this error code and replying with the
firmware chunks instead, which is apparently ignored by the chip and the
chip resends the same bootloader signature with the error code again. This
happens in a loop until the error code self clears and firmware download
proceeds ahead, adding a couple of milliseconds to the total firmware
download time.
Commit 689ca16e5232 was an initial implementation which simply printed
the following line during driver debug:
- FW Download received err 0x04 from chip
This commit adds the expected handling to the error codes.
This error handling is valid for data_req bootloader signatures for V3
and future bootloader versions.
Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> Fixes: 689ca16e5232 ("Bluetooth: NXP: Add protocol support for NXP Bluetooth chipsets") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Neeraj Sanjay Kale [Fri, 14 Jun 2024 08:49:41 +0000 (14:19 +0530)]
Bluetooth: btnxpuart: Update firmware names
This updates the firmware names of 3 chipsets: w8987, w8997, w9098.
These changes are been done to standardize chip specific firmware
file names to be in sync with firmware names of newer chipsets.
The naming convention for BT-only files would be as follows:
For dual-radio WiFi+BT chipsets:
- <protocol-BT><chip-name>_bt_v<HW-version>.bin
For tri-radio WiFi+BT+15.4 chipsets:
- <protocol-BT><protocol-15.4><chip-name>_bt_v<HW-version>.bin
To maintain backward compatibility, this commit adds a provision to
request older firmware file name, if new firmware file name not found in
/lib/firmware/nxp/.
A new device tree property has been introduced called firmware-name, to
override the hardcoded firmware names (old and new) in the driver.
Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This adds a new optional device tree property called firware-name.
Signed-off-by: Neeraj Sanjay Kale <neeraj.sanjaykale@nxp.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Hector Martin [Sun, 2 Jun 2024 09:57:05 +0000 (09:57 +0000)]
Bluetooth: hci_bcm4377: Add BCM4388 support
This new variant needs a different core2_window1 and always uses
beamforming.
The BAR2 also has an offset (RAM start, presumably), so add that.
Signed-off-by: Hector Martin <marcan@marcan.st> Reviewed-by: Sven Peter <sven@svenpeter.dev>
[sven: rebased, updated some comments, mentioned 4388 in Kconfig] Signed-off-by: Sven Peter <sven@svenpeter.dev> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Ying Hsu [Wed, 29 May 2024 08:00:00 +0000 (08:00 +0000)]
Bluetooth: Add vendor-specific packet classification for ISO data
When HCI raw sockets are opened, the Bluetooth kernel module doesn't
track CIS/BIS connections. User-space applications have to identify
ISO data by maintaining connection information and look up the mapping
for each ACL data packet received. Besides, btsnoop log captured in
kernel couldn't tell ISO data from ACL data in this case.
To avoid additional lookups, this patch introduces vendor-specific
packet classification for Intel BT controllers to distinguish
ISO data packets from ACL data packets.
Signed-off-by: Ying Hsu <yinghsu@chromium.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Remove memset(0) after dma_alloc_coherent(), which already zeroes out
the memory, and fix the following two Coccinelle/coccicheck warnings
reported by zalloc-simple.cocci:
btintel_pcie.c:837:19-37: WARNING: dma_alloc_coherent used in
/* Allocate full chunk of data buffer for DMA first and do indexing and
* initialization next, so it can be freed easily
*/
rxq->buf_v_addr already zeroes out memory, so memset is not needed
btintel_pcie.c:792:19-37: WARNING: dma_alloc_coherent used in
/* Allocate full chunk of data buffer for DMA first and do indexing and
* initialization next, so it can be freed easily
*/
txq->buf_v_addr already zeroes out memory, so memset is not needed
Fixes: c2b636b3f788 ("Bluetooth: btintel_pcie: Add support for PCIe transport") Signed-off-by: Thorsten Blum <thorsten.blum@toblux.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Erick Archer [Fri, 24 May 2024 17:11:51 +0000 (19:11 +0200)]
Bluetooth: Use sizeof(*pointer) instead of sizeof(type)
It is preferred to use sizeof(*pointer) instead of sizeof(type)
due to the type of the variable can change and one needs not
change the former (unlike the latter). This patch has no effect
on runtime behavior.
Signed-off-by: Erick Archer <erick.archer@outlook.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Dan Carpenter [Fri, 24 May 2024 10:14:02 +0000 (13:14 +0300)]
Bluetooth: MGMT: Uninitialized variable in load_conn_param()
The "update" variable needs to be initialized to false.
Fixes: 0ece498c27d8 ("Bluetooth: MGMT: Make MGMT_OP_LOAD_CONN_PARAM update existing connection") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
projects / nvme.git / log