On Wed, Oct 16, 2024 at 5:34 PM Stephan Gerhold <stephan.gerhold@xxxxxxxxxx> wrote: > > On Tue, Oct 15, 2024 at 02:27:56PM +0200, Johan Hovold wrote: > > On Fri, Oct 11, 2024 at 12:11:43PM +0200, Stephan Gerhold wrote: > > > On Thu, Oct 10, 2024 at 11:34:44AM +0200, Johan Hovold wrote: > > > > > > Based on our discussions it seems we do not really need to describe the > > > > internal PMU at all for WCN7850 (as the bluetooth and wlan blocks can be > > > > enabled indepdendently) so perhaps we can just restore the old binding > > > > and drop most of this boilerplate for all boards. > > > > > > > > > > I think there is no clear conclusion on that yet. The old bindings > > > didn't describe any power supplies for WiFi at all. The pwrseq bindings > > > are currently the only way to do that. > > > > > > We could potentially move all the "PMU supplies" to the WiFi/BT nodes > > > and rely on reference counting to handle them. But I think it's better > > > to wait how the M.2/generic PCI power control discussion turns out > > > before investing any time to refactor the current solution. > > > > > > There are existing users of qcom,wcn7850-pmu already in 6.11, so I think > > > it does not hurt to take this patch as-is for now. We can clean them up > > > together later if needed. > > > > Sounds good. > > > > But can you please address the following warning that I see with this > > series: > > > > pwrseq-qcom_wcn wcn7850-pmu: supply vddio1p2 not found, using dummy regulator > > > > Not sure if it's the dtsi that's missing a supply if it's the driver > > that needs fixing. > > > > It's the driver, the DT should be correct. This supply exists on the > WCN7850 chip, but nothing is connected there on the QCP. > > Unfortunately, it's not entirely straightforward to drop the warning > since the pwrseq-qcom-wcn driver uses the bulk regulator APIs and > (AFAIK) there is no good way to make only one of the regulators optional > there. > > @Bartosz: Any thoughts on this? sm8550-qrd and sm8550-hdk are also > missing the vddio1p2-supply, so they probably have the same warning in > latest mainline. > How do others deal with it? I'm asking because I've been seeing these warnings for years on many platforms which makes me think they are not a high priority for anyone. The best approach would be to provide an optional bulk get for the regulator API. Or extend struct regulator_bulk_data with bool optional and take this into account. Mark: Any thoughts on this? Bart
