Quoting Matti Vaittinen (2018-12-03 23:13:15)

On Mon, Dec 03, 2018 at 03:35:10PM -0800, Stephen Boyd wrote:

quoted

If the DT doesn't have the #clock-cells property in the node being
registered then calling clk_get() will fail for any consumer devices
that point to the node with a phandle and clock specifier. I don't
expect us to get very far into development if that's the case.

Makes sense. So only potential thing to break is if someone out there
has broken DT/driver - where they currently see this failure. Eg. they
use node w/o #clock-cells as provider and where they try and fail
controlling this clock - but ignore the error (and system just "works"
with HW defaults). After this change they may actually succeed in
controlling - but do control wrong clock.

Not likely scenario (sure happens somewhere) - and it involves already
broken design. So I agree with you. Besides, you are the maintainer for
clk framework and thus get the most of the rain if **** hits the fan =D

Yes, exactly.

quoted

Of course, we don't fail in of_clk_add_provider() if there isn't a
#clock-cells property in the node, we just happily add the node to the
provider list and carry on. I doubt anyone is failing to specify the DT
property, but maybe they are, in which case we could keep not failing
and just add the node of whatever we're called with originally if
neither the parent or the passed node have the #clock-cells property. I
wouldn't try to go any higher than one node above the current node and
look for a #clock-cells though.

I think we should use parent device's node, not the paren node in DT,
right? But I agree, we should only look "one level up in the chain".

Are these two things different? I'm suggesting looking at
device_node::parent and trying to find a #clock-cells property.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel