On Tue, 25 Jun 2024 at 12:01, Bartosz Golaszewski <brgl@xxxxxxxx> wrote: > > On Tue, Jun 25, 2024 at 10:55 AM Dmitry Baryshkov > <dmitry.baryshkov@xxxxxxxxxx> wrote: > > > > On Tue, 25 Jun 2024 at 11:50, Bartosz Golaszewski <brgl@xxxxxxxx> wrote: > > > > > > On Tue, Jun 25, 2024 at 9:47 AM Dmitry Baryshkov > > > <dmitry.baryshkov@xxxxxxxxxx> wrote: > > > > > > > > On Tue, 25 Jun 2024 at 10:46, Bartosz Golaszewski <brgl@xxxxxxxx> wrote: > > > > > > > > > > On Mon, Jun 24, 2024 at 11:20 PM Dmitry Baryshkov > > > > > <dmitry.baryshkov@xxxxxxxxxx> wrote: > > > > > > > > > > > > > > > > > > > > Neither of these has clocks that need to be driven by linux. The only > > > > > > > user of QCA6390 Bluetooth in mainline is RB5. Bindings didn't exist > > > > > > > before so no commitment was ever made. > > > > > > > > > > > > This might make some laptop users unhappy. > > > > > > > > > > Like I said: without upstreamed DT bindings, we have never made any > > > > > commitment about the device properties. I doubt anyone will complain > > > > > though, I haven't seen any DT with QCA6390 with clock properties yet. > > > > > I wouldn't stress it for now. > > > > > > > > I was thinking about x86 laptops / M.2 cards. I'll see if I can locate one. > > > > > > > > > > I don't get it, how could they ever get the clocks property without it > > > being defined in firmware? > > > > The clock and bt_en are optional. > > > > But you're worrying that the lack of this optional clock for QCA6390 > will break it on some M.2 card? That cannot happen, can it? If it's on > an M.2 card then it would never be described in ACPI. > clk_get_optional() will always return NULL. Ack, thank you for the explanation. -- With best wishes Dmitry
