Hi Marcel, > -----Original Message----- > From: Marcel Holtmann <marcel@xxxxxxxxxxxx> > Sent: Wednesday, April 28, 2021 8:20 PM > To: K, Kiran <kiran.k@xxxxxxxxx> > Cc: linux-bluetooth@xxxxxxxxxxxxxxx; Tumkur Narayan, Chethan > <chethan.tumkur.narayan@xxxxxxxxx>; Srivatsa, Ravishankar > <ravishankar.srivatsa@xxxxxxxxx> > Subject: Re: [PATCH v3 3/3] Bluetooth: cache local supported codec > capabilities > > Hi Kiran, > > >>> +int hci_codec_list_add(struct list_head *list, struct > >> hci_rp_read_local_codec_caps *rp, > >>> + __u32 len, > >>> + struct hci_op_read_local_codec_caps *sent); > >> > >> I think you need to redo the whole patch series, since 1/3 should > >> have hci_codec_list_add in that it adds the codec id from reading the > codec list. > >> > > Ack > > > >> And then reading the capabilities just updates the codec. > >> > > With async calls converted to sync, can we add codec details to the list on > reading codec caps as same codec can be supported on multiple transport > types ? > > > >> Our problem is that the whole init phase is rather async than sync in > >> it procedure. And the reason for that is purely historic from the > >> times when Linus had no work queues and we had to process everything > >> in tasklets or spawn kthreads. > >> > >> Frankly if we moved the whole init procedure to use __hci_cmd_sync we > >> could fold the complete init{1-4} phases into one. And there is no > >> reason we don’t do that. However one problem at a time. > >> > > Ack. I will define init5 for reading codecs and codec caps using > __hci_cmd_sync calls. > > I think this is too early. I only looked at the intermingling of > hci_update_background_scan. I have not gotten the whole init handling. I > suspect some looking issues that would have to be cleaned up first. In my test, I didn't see any issue. In that case, let me know how to proceed further. I am happy to amend as per your comments. Thanks, Kiran