On Fri, Sep 30, 2016 at 10:47:38AM +0100, Paul Burton wrote:
On Friday, 30 September 2016 17:53:38 BST Alexandre Courbot wrote:
On 09/30/2016 05:46 PM, Thierry Reding wrote:
From: Thierry Reding treding@nvidia.com
For Tegra186 there are currently no UART clocks wired up in device tree. This exposes a regression introduced in commit 50fce1d5d874 ("serial: ns16550: Support clocks via phandle"), which causes the p2771-0000-500 board (and probably any Tegra186-based board as well) to fail to boot.
The reason is that if no clocks property exists, then clk_get_by_index() returns -ENOENT (via fdtdec_parse_phandle_with_args()) rather than -ENODEV as the above-mentioned commit expects.
Fix this by checking for the right error code.
Tested-by: Alexandre Courbot acourbot@nvidia.com
I sent a similar patch ~10 minutes before this one, but Thierry's commit message is clearer than mine (and his handling of -ENODEV probably more correct as well), so let's go with this version!
Hi Thierry & Alexandre,
Apologies for the breakage!
If a DT contains a clock & the UART node references it by phandle then I believe clk_get_by_index() could return -ENODEV via uclass_get_device_by_of_offset & uclass_find_device_by_of_offset. So we probably need to handle both -ENOENT for the "no clocks property" case & - ENODEV for the "clocks property but no driver" case, as Alexandre's patch does?
Indeed. I thought I had checked all possible return values, but I've obviously been blind. Alex's patch looks more correct, though I'm beginning to wonder if there's a better way to achieve this than keep adding whatever error codes happen to be special cases.
How about we just leave out the else completely? At this point it seems like any failure to obtain a valid clock would best be dealt with by falling back to clock-frequency or the one specified in the config.
Are there even other errors besides -ENODEV, -ENOENT and -ENOSYS that we could get here?
Thierry