From: Jakub Kicinski <kuba@kernel.org> Date: 2021-11-15 21:53:57
On Mon, 15 Nov 2021 13:40:30 -0800 Luiz Augusto von Dentz wrote:
quoted
quoted
I guess these won't be able to be merged after all, is there a define
process on how/when pull-request shall be sent to net-next, Ive assume
next-next is freezed now the documentation says the the merge window
lasts for approximately two weeks but I guess that is for the Linus
tree not net-next?
I'm not sure what the exact rules are for net-next.
We had some glitches this time around, IMHO. Here is what I have in
mind for the next merge window but note that I haven't had a chance
to discuss it with Dave yet, so it's more of me blabbering at this
point than a plan:
- net-next would not apply patches posted after Linus cuts final;
- make sure all trees feeding net-next submit their changes around
rc6 time so that we don't get a large code dump right as the merge
window opens;
So net-next has a merge window open during the rc phase, until rc6? I
assume if the rc goes further than rc7 it also would extend the merge
window of net-next as well?
Yes, net-next has the inverse rules to Linus's tree basically.
We accumulate the code outside the merge window. And then during
the merge window try to focus on fixes and conflicts introduced
by merging with other -next trees outside networking.
quoted
- any last minute net-next PRs should be ready by Monday night PST;
- we'd give the tree one day to settle, have build issues reported etc
and submit PR on Wednesday.
If we go with a more structured timeline along these lines I'll try
to send reminders.
+1, that would be great to have reminders for the merge window
open/close that way if for some reason if you guys decide to change
your merge window that would be noticed by us.
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Date: 2021-11-15 22:45:00
Hi Jakub,
On Mon, Nov 15, 2021 at 1:09 PM Jakub Kicinski [off-list ref] wrote:
On Mon, 15 Nov 2021 11:53:15 -0800 Luiz Augusto von Dentz wrote:
quoted
quoted
Any chance to get these changes in before the merge window closes?
I guess these won't be able to be merged after all, is there a define
process on how/when pull-request shall be sent to net-next, Ive assume
next-next is freezed now the documentation says the the merge window
lasts for approximately two weeks but I guess that is for the Linus
tree not net-next?
I'm not sure what the exact rules are for net-next.
We had some glitches this time around, IMHO. Here is what I have in
mind for the next merge window but note that I haven't had a chance
to discuss it with Dave yet, so it's more of me blabbering at this
point than a plan:
- net-next would not apply patches posted after Linus cuts final;
- make sure all trees feeding net-next submit their changes around
rc6 time so that we don't get a large code dump right as the merge
window opens;
So net-next has a merge window open during the rc phase, until rc6? I
assume if the rc goes further than rc7 it also would extend the merge
window of net-next as well?
- any last minute net-next PRs should be ready by Monday night PST;
- we'd give the tree one day to settle, have build issues reported etc
and submit PR on Wednesday.
If we go with a more structured timeline along these lines I'll try
to send reminders.
+1, that would be great to have reminders for the merge window
open/close that way if for some reason if you guys decide to change
your merge window that would be noticed by us.
--
Luiz Augusto von Dentz
From: Jakub Kicinski <kuba@kernel.org> Date: 2021-11-16 00:17:32
On Mon, 15 Nov 2021 11:53:15 -0800 Luiz Augusto von Dentz wrote:
quoted
Any chance to get these changes in before the merge window closes?
I guess these won't be able to be merged after all, is there a define
process on how/when pull-request shall be sent to net-next, Ive assume
next-next is freezed now the documentation says the the merge window
lasts for approximately two weeks but I guess that is for the Linus
tree not net-next?
I'm not sure what the exact rules are for net-next.
We had some glitches this time around, IMHO. Here is what I have in
mind for the next merge window but note that I haven't had a chance
to discuss it with Dave yet, so it's more of me blabbering at this
point than a plan:
- net-next would not apply patches posted after Linus cuts final;
- make sure all trees feeding net-next submit their changes around
rc6 time so that we don't get a large code dump right as the merge
window opens;
- any last minute net-next PRs should be ready by Monday night PST;
- we'd give the tree one day to settle, have build issues reported etc
and submit PR on Wednesday.
If we go with a more structured timeline along these lines I'll try
to send reminders.
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com> Date: 2021-11-16 00:22:31
Hi David and Jakub,
On Mon, Nov 8, 2021 at 10:46 AM Luiz Augusto von Dentz
[off-list ref] wrote:
Hi David and Jakub,
On Tue, Nov 2, 2021 at 2:33 PM Luiz Augusto von Dentz
[off-list ref] wrote:
quoted
The following changes since commit d0f1c248b4ff71cada1b9e4ed61a1992cd94c3df:
Merge tag 'for-net-next-2021-10-01' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next (2021-10-05 07:41:16 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git tags/for-net-next-2021-11-02
for you to fetch changes up to 258f56d11bbbf39df5bc5faf0119d28be528f27d:
Bluetooth: aosp: Support AOSP Bluetooth Quality Report (2021-11-02 19:37:52 +0100)
----------------------------------------------------------------
bluetooth-next pull request for net-next:
- Add support for AOSP Bluetooth Quality Report
- Rework of HCI command execution serialization
----------------------------------------------------------------
Archie Pusaka (1):
Bluetooth: Fix removing adv when processing cmd complete
Brian Gix (13):
Bluetooth: hci_sync: Convert MGMT_OP_SET_FAST_CONNECTABLE
Bluetooth: hci_sync: Enable synch'd set_bredr
Bluetooth: hci_sync: Convert MGMT_OP_GET_CONN_INFO
Bluetooth: hci_sync: Convert MGMT_OP_SET_SECURE_CONN
Bluetooth: hci_sync: Convert MGMT_OP_GET_CLOCK_INFO
Bluetooth: hci_sync: Convert MGMT_OP_SET_LE
Bluetooth: hci_sync: Convert MGMT_OP_READ_LOCAL_OOB_DATA
Bluetooth: hci_sync: Convert MGMT_OP_READ_LOCAL_OOB_EXT_DATA
Bluetooth: hci_sync: Convert MGMT_OP_SET_LOCAL_NAME
Bluetooth: hci_sync: Convert MGMT_OP_SET_PHY_CONFIGURATION
Bluetooth: hci_sync: Convert MGMT_OP_SET_ADVERTISING
Bluetooth: hci_sync: Convert adv_expire
Bluetooth: hci_sync: Convert MGMT_OP_SSP
David Yang (1):
Bluetooth: btusb: Fix application of sizeof to pointer
Johan Hovold (1):
Bluetooth: bfusb: fix division by zero in send path
Joseph Hwang (2):
Bluetooth: Add struct of reading AOSP vendor capabilities
Bluetooth: aosp: Support AOSP Bluetooth Quality Report
Kiran K (2):
Bluetooth: Read codec capabilities only if supported
Bluetooth: btintel: Fix bdaddress comparison with garbage value
Kyle Copperfield (1):
Bluetooth: btsdio: Do not bind to non-removable BCM4345 and BCM43455
Luiz Augusto von Dentz (16):
Bluetooth: hci_vhci: Fix calling hci_{suspend,resume}_dev
Bluetooth: Fix handling of SUSPEND_DISCONNECTING
Bluetooth: L2CAP: Fix not initializing sk_peer_pid
Bluetooth: vhci: Add support for setting msft_opcode and aosp_capable
Bluetooth: vhci: Fix checking of msft_opcode
Bluetooth: hci_sync: Make use of hci_cmd_sync_queue set 1
Bluetooth: hci_sync: Make use of hci_cmd_sync_queue set 2
Bluetooth: hci_sync: Make use of hci_cmd_sync_queue set 3
Bluetooth: hci_sync: Enable advertising when LL privacy is enabled
Bluetooth: hci_sync: Rework background scan
Bluetooth: hci_sync: Convert MGMT_SET_POWERED
Bluetooth: hci_sync: Convert MGMT_OP_START_DISCOVERY
Bluetooth: hci_sync: Rework init stages
Bluetooth: hci_sync: Rework hci_suspend_notifier
Bluetooth: hci_sync: Fix missing static warnings
Bluetooth: hci_sync: Fix not setting adv set duration
Marcel Holtmann (1):
Bluetooth: Add helper for serialized HCI command execution
Mark-YW.Chen (1):
Bluetooth: btusb: fix memory leak in btusb_mtk_submit_wmt_recv_urb()
Mark-yw Chen (1):
Bluetooth: btmtksdio: transmit packet according to status TX_EMPTY
Nguyen Dinh Phi (1):
Bluetooth: hci_sock: purge socket queues in the destruct() callback
Paul Cercueil (1):
Bluetooth: hci_bcm: Remove duplicated entry in OF table
Sean Wang (9):
Bluetooth: mediatek: add BT_MTK module
Bluetooth: btmtksido: rely on BT_MTK module
Bluetooth: btmtksdio: add .set_bdaddr support
Bluetooth: btmtksdio: explicitly set WHISR as write-1-clear
Bluetooth: btmtksdio: move interrupt service to work
Bluetooth: btmtksdio: update register CSDIOCSR operation
Bluetooth: btmtksdio: use register CRPLR to read packet length
mmc: add MT7921 SDIO identifiers for MediaTek Bluetooth devices
Bluetooth: btmtksdio: add MT7921s Bluetooth support
Soenke Huster (1):
Bluetooth: virtio_bt: fix memory leak in virtbt_rx_handle()
Tedd Ho-Jeong An (2):
Bluetooth: hci_vhci: Fix to set the force_wakeup value
Bluetooth: mgmt: Fix Experimental Feature Changed event
Tim Jiang (1):
Bluetooth: btusb: Add support using different nvm for variant WCN6855 controller
Wang Hai (1):
Bluetooth: cmtp: fix possible panic when cmtp_init_sockets() fails
Wei Yongjun (2):
Bluetooth: Fix debugfs entry leak in hci_register_dev()
Bluetooth: Fix memory leak of hci device
drivers/bluetooth/Kconfig | 6 +
drivers/bluetooth/Makefile | 1 +
drivers/bluetooth/bfusb.c | 3 +
drivers/bluetooth/btintel.c | 22 +-
drivers/bluetooth/btmtk.c | 289 +++
drivers/bluetooth/btmtk.h | 111 +
drivers/bluetooth/btmtksdio.c | 496 ++--
drivers/bluetooth/btsdio.c | 2 +
drivers/bluetooth/btusb.c | 389 +--
drivers/bluetooth/hci_bcm.c | 1 -
drivers/bluetooth/hci_vhci.c | 120 +-
drivers/bluetooth/virtio_bt.c | 3 +
include/linux/mmc/sdio_ids.h | 1 +
include/net/bluetooth/bluetooth.h | 2 +
include/net/bluetooth/hci_core.h | 22 +-
include/net/bluetooth/hci_sync.h | 97 +
net/bluetooth/Makefile | 2 +-
net/bluetooth/aosp.c | 168 +-
net/bluetooth/aosp.h | 13 +
net/bluetooth/cmtp/core.c | 4 +-
net/bluetooth/hci_codec.c | 18 +-
net/bluetooth/hci_conn.c | 20 +-
net/bluetooth/hci_core.c | 1334 +----------
net/bluetooth/hci_event.c | 159 +-
net/bluetooth/hci_request.c | 338 +--
net/bluetooth/hci_request.h | 10 +
net/bluetooth/hci_sock.c | 11 +-
net/bluetooth/hci_sync.c | 4799 +++++++++++++++++++++++++++++++++++++
net/bluetooth/hci_sysfs.c | 2 +
net/bluetooth/l2cap_sock.c | 19 +
net/bluetooth/mgmt.c | 2086 ++++++++--------
net/bluetooth/mgmt_util.c | 15 +-
net/bluetooth/mgmt_util.h | 4 +
net/bluetooth/msft.c | 511 ++--
net/bluetooth/msft.h | 15 +-
35 files changed, 7472 insertions(+), 3621 deletions(-)
create mode 100644 drivers/bluetooth/btmtk.c
create mode 100644 drivers/bluetooth/btmtk.h
create mode 100644 include/net/bluetooth/hci_sync.h
create mode 100644 net/bluetooth/hci_sync.c
Any chance to get these changes in before the merge window closes?
I guess these won't be able to be merged after all, is there a define
process on how/when pull-request shall be sent to net-next, Ive assume
next-next is freezed now the documentation says the the merge window
lasts for approximately two weeks but I guess that is for the Linus
tree not net-next?
--
Luiz Augusto von Dentz