Hi, On Thu, 8 Jul 2021 at 13:10, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > > - Peter (the email was bouncing) + Peter's kernel.org address > > On Tue, 6 Jul 2021 at 13:55, Mark Brown <broonie@xxxxxxxxxx> wrote: > > > > On Tue, Jul 06, 2021 at 09:54:03AM +0200, Ulf Hansson wrote: > > > On Tue, 22 Jun 2021 at 00:32, Dmitry Baryshkov > > > > > > Qualcomm QCA6390/1 is a family of WiFi + Bluetooth SoCs, with BT part > > > > being controlled through the UART and WiFi being present on PCIe > > > > bus. Both blocks share common power sources. Add device driver handling > > > > power sequencing of QCA6390/1. > > > > > Power sequencing of discoverable buses have been discussed several > > > times before at LKML. The last attempt [1] I am aware of, was in 2017 > > > from Peter Chen. I don't think there is a common solution, yet. > > > > This feels a bit different to the power sequencing problem - it's not > > exposing the individual inputs to the device but rather is a block that > > manages everything but needs a bit of a kick to get things going (I'd > > guess that with ACPI it'd be triggered via AML). It's in the same space > > but it's not quite the same issue I think, something that can handle > > control of the individual resources might still struggle with this. > > Well, to me it looks very similar to those resouses we could manage > with the mmc pwrseq, for SDIO. It's also typically the same kind of > combo-chips that moved from supporting SDIO to PCIe, for improved > performance I guess. More importantly, the same constraint to > pre-power on the device is needed to allow it to be discovered/probed. In our case we'd definitely use pwrseq for PCIe bus and we can also benefit from using pwrseq for serdev and for platform busses also (for the same story of WiFi+BT chips). I can take a look at rewriting pwrseq code to also handle the PCIe bus. Rewriting it to be a generic lib seems like an easy task, plugging it into PCIe code would be more fun. Platform and serdev... Definitely even more fun. > Therefore, I think it would be worth having a common solution for > this, rather than a solution per subsystem or even worse, per device. > > Unfortunately, it looks like Peter's email is bouncing so we can't get > an update from him. Let's see if the kernel.org email will get to him. -- With best wishes Dmitry
