On Thu, 25 Apr 2024 at 08:30, Wren Turkal <wt@xxxxxxxxxxxxxxxx> wrote: > > On 4/24/24 11:05 PM, Krzysztof Kozlowski wrote: > > On 25/04/2024 00:01, Wren Turkal wrote: > >>>> > >>>> 3) only care about the case property enable-gpios is not configured, > >>>> the original BT driver design logic indeed matches with binging spec's > >>>> requirements before bartosz's wrong change > >>> > >>> What? There is no such case according to bindings. I told you already > >>> two times: Either change bindings or this is not valid. > >> > >> @krzysztof, I'm curious. There is no entry in the binding specifically > >> for qca6390. Should there be? > > > > qca6390 is documented in the bindings, but you are right that it lacks > > if:then: entry narrowing/choosing specific supplies and pins. It should > > have one, indeed. > > Would creating an entry for the qca6390 hardware fix the issue you are > worried about? > > Again, sorry for all the, what I assume are, basic questions. I am so > far out of my depth here. I am just trying to figure out how to move > forward. I really do appreciate your guidance here. > Wren, Krzysztof: I cannot stop you from doing this but I'm afraid this will complicate the power sequencing work unnecessarily. The QCA6390 PMU bindings I'm proposing[1] are consumers of the BT enable GPIOs. In my series I also create an entry for QCA6390 Bluetooth[2] but without enable-gpios and with the inputs from the PMU, not host. Please consider that if you decide to go with this. Bartosz [1] https://lore.kernel.org/linux-arm-kernel/20240410124628.171783-2-brgl@xxxxxxxx/ [2] https://lore.kernel.org/linux-arm-kernel/20240410124628.171783-4-brgl@xxxxxxxx/
