lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 13 May 2024 14:26:41 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Luiz Augusto von Dentz <luiz.dentz@...il.com>, Willem de Bruijn
 <willemdebruijn.kernel@...il.com>
Cc: davem@...emloft.net, linux-bluetooth@...r.kernel.org,
 netdev@...r.kernel.org
Subject: Re: pull request: bluetooth-next 2024-05-10

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 :(

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ