On 24-10-22, Krzysztof Kozlowski wrote:
> On 21/10/2024 12:25, Marco Felsch wrote:
> > On 24-10-21, Krzysztof Kozlowski wrote:
> >> On 21/10/2024 08:41, Marco Felsch wrote:
> >>> On 24-10-07, Krzysztof Kozlowski wrote:
...
> >>>> Based on earlier message:
> >>>>
> >>>> "For NXP WIFI/BT chip, WIFI and BT share the one PDn pin, which means
> >>>> that both wifi and BT controller will be powered on and off at the same
> >>>> time."
> >>>>
> >>>> but maybe that's not needed. No clue, I don't know the hardware. But be
> >>>> carefully what you write in the bindings, because then it will be ABI.
> >>>
> >>> We noticed the new power-sequencing infrastructure which is part of 6.11
> >>> too but I don't think that this patch is wrong. The DT ABI won't break
> >>> if we switch to the power-sequencing later on since the "reset-gpios"
> >>> are not marked as required. So it is up to the driver to handle it
> >>> either via a separate power-sequence driver or via "power-supply" and
> >>> "reset-gpios" directly.
> >>
> >> That's not the point. We expect correct hardware description. If you say
> >> now it has "reset-gpios" but later say "actually no, because it has
> >> PMU", I respond: no. Describe the hardware, not current Linux.
> >
> > I know that DT abstracts the HW. That said I don't see the problem with
> > this patch. The HW is abstracted just fine:
> >
> > shared PDn -> reset-gpios
> > shared power-supply -> vcc-supply
> >
> > Right now the DT ABI for the BT part is incomplete since it assume a
> > running WLAN part or some hog-gpios to pull the device out-of-reset
> > which is addressed by this patchset.
> >
> > Making use of the new power-sequencing fw is a Linux detail and I don't
> > see why the DT can't be extended later on. We always extend the DT if
> > something is missing or if we found a better way to handle devices.
>
> Sure, although I am not really confident that you understand the
> implications - you will not be able to switch to proper power-sequencing
> with above bindings, because it will not be just possible without
> breaking the ABI or changing hardware description (which you say it is
> "fine", so complete/done). I am fine with it, just mind the implications.
Sorry can you please share your concerns? I don't get the point yet why
we do break the DT ABI if we are going from
bt {
reset-gpios = <&gpio 4 0>;
vcc-supply = <&supply>;
};
to
bt {
vcc-supply = <&pmu_supply>;
};
or:
bt {
pmu = <&pmu>;
};
Of course the driver need to support all 2/3 cases due to backward
compatibility but from DT pov I don't see any breakage since we already
need to define the power handling properties (gpio & supply) as
optional.
That beeing said I don't see the need for a PMU driver for this WLAN/BT
combi chip which is way simpler than the Qualcomm one from Bartosz. Also
there is physically no PMU device which powers the chip unlike the
Qualcomm one. I'm not sure if you would accept virtual PMU devices.
Regards,
Marco
> Best regards,
> Krzysztof
>
>
