On 25/04/2024 10:30, Bartosz Golaszewski wrote: > 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. I don't have a near plan to describe QCA6390 supplies and pins, so don't worry. I also don't think Qualcomm BT understand what are bindings, so I don't expect patches from them. Best regards, Krzysztof
