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. Bart
