On Fri, 10 May 2024 17:14:28 -0400 Luiz Augusto von Dentz wrote: > The following changes since commit f8beae078c82abde57fed4a5be0bbc3579b59ad0: > > Merge tag 'gtp-24-05-07' of git://git.kernel.org/pub/scm/linux/kernel/git/pablo/gtp Pablo neira Ayuso says: (2024-05-10 13:59:27 +0100) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git tags/for-net-next-2024-05-10 > > for you to fetch changes up to 75f819bdf9cafb0f1458e24c05d24eec17b2f597: > > Bluetooth: btintel: Fix compiler warning for multi_v7_defconfig config (2024-05-10 17:04:15 -0400) > > ---------------------------------------------------------------- > bluetooth-next pull request for net-next: > > - Add support MediaTek MT7921S SDIO > - Various fixes for -Wflex-array-member-not-at-end and -Wfamnae > - Add USB HW IDs for MT7921/MT7922/MT7925 > - Add support for Intel BlazarI and Filmore Peak2 (BE201) > - Add initial support for Intel PCIe driver > - Remove HCI_AMP support > - Add TX timestamping support There is one more warning in the Intel driver: drivers/bluetooth/btintel_pcie.c:673:33: warning: symbol 'causes_list' was not declared. Should it be static? It'd also be great to get an ACK from someone familiar with the socket time stamping (Willem?) I'm not sure there's sufficient detail in the commit message to explain the choices to: - change the definition of SCHED / SEND to mean queued / completed, while for Ethernet they mean queued to qdisc, queued to HW. How does it compare to stamping in the driver in terms of accuracy? - the "experimental" BT_POLL_ERRQUEUE, how does the user space look? What is the "upper layer"? What does it mean for kernel uAPI to be "experimental"? When does the "upper layer" get to run and how does it know that there are time stamps on the error queue? Would be great to get more info and/or second opinion, because it's not sufficiently "obviously right" to me to pull right away :(
