-
Sean Anderson authored
Currently, clock consumers cannot take any programmatic action based on the return code of a clock function. This is because there is no standardization, and generally no way of separating e.g. "there was a major problem setting the rate for this clock" which usually should not be recovered from, from "this clock doesn't support setting its rate" or "this clock doesn't support *this* rate" which could be absolutely fine depending on the driver. This commit aims to standardize the acceptable codes which may be returned from clock operations. In general, - ENOSYS should be returned when an operation is not supported for a particular clock. - ENOENT may be returned if the clock ID is invalid. However, it is encouraged to move any checks to request() to reduce code duplication. - EINVAL should be returned for logical errors only (such as requesting an invalid rate). Each function has had specific guidance added for when to return each error code. This is just guidance for now; most of the clock subsystem does not yet conform to this standard. However, it is expected that new clock drivers return these error codes. Additionally, this commit adds expected behavior for each of the clock operations. I believe these should be mostly straightforward and correspond to existing behavior. I remember not understanding what the expected invariants were for several clock functions, so hopefully this should help out new driver authors. In the future, some of these invariants could be checked via an optional config option. Signed-off-by: Sean Anderson <seanga2@gmail.com> Link: https://lore.kernel.org/r/20231216193843.2463779-4-seanga2@gmail.com
0bfbb830