Messages in this thread | | | Subject | Re: [PATCH 2/4] arm64: dts: ti: k3-j721e*: Cleanup disabled nodes at SoC dtsi level | From | Peter Ujfalusi <> | Date | Mon, 9 Nov 2020 09:49:26 +0200 |
| |
On 06/11/2020 23.46, Nishanth Menon wrote: > On 13:32-20201106, Peter Ujfalusi wrote: > [...] >>> >>>> >>>>> default power management functionality etc >>>> >>>> Right, so how does that helps with devices present in the SoC, but no >>>> node at all? First thing which comes to mind is AASRC, we don't have >>>> Linux driver for it (and no DT binding document), but that does not mean >>>> that it is not present. How PM would take that into account? >>> >>> I think we are mixing topics here -> I was stating the motivation why >>> devicetree chose such as default. >> >> I don't question the fact that 'okay' is the default status if it is not >> explicitly present. There is no better default than that. > > ^^ -> Alright, that is all we are trying to do here: defaults in the > SoC.dtsi and specific cleanups (firmware reserved / board unused > disables) be done in a common board.dtsi (for now, there is no such > specific need, I guess).
The default is what it is: default choice which suits most of the nodes.
If the node is not complete in it's present form then it is not in it's default state. imho.
>>> Alright - what do we suggest we do? >> >> Not sure, I'm 'whatever' after [1] makes it to mainline or next. > [....] >> [1] >> https://lore.kernel.org/alsa-devel/20201106072551.689-1-peter.ujfalusi@ti.com/ > > > I don't see the relationship between the series.. I think this series > brings no change in dtb, hence with OR without your driver cleanup > series, there is no practical regressions.
This series opens up the possibility of nodes leaking to dtb with known broken state and the driver should have a better strategy than 'works by luck' to handle it ;)
>> >>> Tony, Rob - I need some guidance here. >> >> I'm fine whatever way we take, but I think it is up to you to make the >> call as the maintainer of the TI dts files... ;) > > Yep - I have'nt seen a reason yet that must cause us to change from the > Device tree default approach in our debates.
Imho 'disabled' is the default for nodes like McASP as it is: "Indicates that the device is not presently operational, but it might become operational in the future" (for example, needed properties added to the node).
>>>> There is no such a tag, but: >>>> whatever-by: Peter Ujfalusi <peter.ujfalusi@ti.com> >>> >>> OK - I have no idea how B4 or patchworks pick that one as :D >> >> If we take this road, than I'm okay with it, but I'm going to take >> silent protest (not sending acked-by or revired-by). >> That should not stop you doing what you believe is best for the future! > > OK - thanks for your review and the discussions, always appreciate > getting our views out there. > > if there are no other comments, I will try and post a v2 over the > weekend.
OK
- Péter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
| |