Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.If I understand correctly, the recommendation is to return -EPROBE_DEFER on !of_node systems when the driver fails to read the clock-frequency property. Kindly confirm.
Hi Sakari,
On Tue, Jun 24, 2025 at 11:46:27AM +0000, Sakari Ailus wrote:
[...]
I'm in favour of the latter but both should be workable.
Speaking of return values, devm_clk_get_optional() may also return
-EPROBE_DEFER. That needs to be handled.
Ack.
And further on -EPROBE_DEFER, I think the helper should return
-EPROBE_DEFER if the "clock-frequency" property doesn't exist on non-OF
nodes. That signals the required software nodes required on Intel Windows
definitions/ipu-bridge or AMD systems aren't in place yet so really probing
should be deferred. This would allow removing the hacks that return
-EPROBE_DEFER in sensor drivers when no graph endpoint is found.
device_property_read_u32() returns the following:
* Return: number of values if @val was %NULL,
* %0 if the property was found (success),
* %-EINVAL if given arguments are not valid,
* %-ENODATA if the property does not have a value,
* %-EPROTO if the property is not an array of numbers,
* %-EOVERFLOW if the size of the property is not as expected.
* %-ENXIO if no suitable firmware interface is present.
Do you mean something like this in the helper:
if (ret == -ENODATA && !of_node)
return ERR_PTR(-EPROBE_DEFER);
--
Kind Regards
Mehdi Djait