phy: exynos5-usbdrd: convert core clocks to clk_bulk
Using the clk_bulk APIs, the clock handling for the core clocks becomes much simpler. No need to check any flags whether or not certain clocks exist or not. Further, we can drop the various handles to the individual clocks in the driver data and instead simply treat them all as one thing. So far, this driver assumes that all platforms have a clock "ref". It also assumes that the clocks "phy_pipe", "phy_utmi", and "itp" exist if the platform data "has_common_clk_gate" is set to true. It then goes and individually tries to acquire and enable and disable all the individual clocks one by one. Rather than relying on these implicit clocks and open-coding the clock handling, we can just explicitly spell out the clock names in the different device data and use that information to populate clk_bulk_data, allowing us to use the clk_bulk APIs for managing the clocks. As a side-effect, this change highlighted the fact that exynos5_usbdrd_phy_power_on() forgot to check the result of the clock enable calls. Using the clk_bulk APIs, the compiler now warns when return values are not checked - therefore add the necessary check instead of silently ignoring failures and continuing as if all is OK when it isn't. For consistency, also change a related dev_err() to dev_err_probe() in exynos5_usbdrd_phy_clk_handle() to get consistent error message formatting. Finally, exynos5_usbdrd_phy_clk_handle() prints an error message in all cases as necessary (except for -ENOMEM). There is no need to print another message in its caller (the probe() function), and printing errors during OOM conditions is usually discouraged. Drop the duplicated message in exynos5_usbdrd_phy_probe(). Signed-off-by: André Draszik <andre.draszik@linaro.org> Tested-by: Will McVicker <willmcvicker@google.com> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Tested-by: Peter Griffin <peter.griffin@linaro.org> Link: https://lore.kernel.org/r/20240617-usb-phy-gs101-v3-3-b66de9ae7424@linaro.orgSigned-off-by: Vinod Koul <vkoul@kernel.org>
Showing
Please register or sign in to comment