On Tue, Jan 23, 2024 at 4:09 PM Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> wrote: > > On 23/01/2024 11:04, Bartosz Golaszewski wrote: > > On Tue, Jan 23, 2024 at 9:30 AM Krzysztof Kozlowski > > <krzysztof.kozlowski@xxxxxxxxxx> wrote: > >> > >> On 22/01/2024 19:21, Bartosz Golaszewski wrote: > >>> From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> > >>> > >>> I'm limiting the audience of this compared to the PCI power sequencing > >>> series as I wanted to run the DT part by the maintainers before I commit > >>> to a doomed effort. > >>> > >>> Here is the DT representation of the QCA6390's PMU with its inputs and > >>> outputs. If I were to implement the pwrseq framework that would be able > >>> to assign the relevant pwrseq data to the consumer based on the actual > >>> regulators and not abstract bt-pwrseq or wlan-pwrseq properties - would > >>> that fly with you? > >>> > >>> We'd need to deprecate the existing BT bindings but unfortunately they > >>> are already described as consuming the host PMIC regulators in bindings. > >>> > >>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> > >> > >> Please provide lore link to the binding. > >> > >> Best regards, > >> Krzysztof > >> > > > > This is the one: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/net/bluetooth/qualcomm-bluetooth.yaml > > This does not describe your PMU node. Maybe lack of the binding was > intentional? In such case I missed it from commit msg... > Ah, I thought you were asking about the existing bluetooth binding. Yes, I intentionally didn't include any new bindings as my question is: does this device-tree source change make sense? If so, then I'll include it in my series and build the bindings and C code around it. Bartosz
