On 12/08, Tero Kristo wrote: > On 08/12/16 02:13, Stephen Boyd wrote: > >On 10/21, Tero Kristo wrote: > >>diff --git a/drivers/clk/keystone/sci-clk.c b/drivers/clk/keystone/sci-clk.c > >>new file mode 100644 > >>index 0000000..f6af5bd > >>--- /dev/null > >>+++ b/drivers/clk/keystone/sci-clk.c > > > > >>+ > >>+ handle = devm_ti_sci_get_handle(dev); > >>+ if (IS_ERR(handle)) > >>+ return PTR_ERR(handle); > >>+ > >>+ provider = devm_kzalloc(dev, sizeof(*provider), GFP_KERNEL); > >>+ if (!provider) > >>+ return -ENOMEM; > >>+ > >>+ provider->clocks = data; > >>+ > >>+ provider->sci = handle; > >>+ provider->ops = &handle->ops.clk_ops; > >>+ provider->dev = dev; > >>+ > >>+ ti_sci_init_clocks(provider); > > > >And if this fails? > > Yea this is kind of controversial. ti_sci_init_clocks() can fail if > any of the clocks registered will fail. I decided to have it this > way so that at least some clocks might work in failure cause, and > you might have a booting device instead of total lock-up. > > Obviously it could be done so that if any clock fails, we would > de-register all clocks at that point, but personally I think this is > a worse option. > > ti_sci_init_clocks could probably be modified to continue > registering clocks when a single clock fails though. Currently it > aborts at first failure. > That sounds like a better approach if we don't care about failures to register a clock. Returning a value from a function and not using it isn't really a great design. I worry that if we start returning errors from clk_hw_register() that something will go wrong though, so really I don't know why we want to ignore errors at all. Just for debugging a boot hang? Can't we use early console to at least see that this driver is failing to probe and debug that way? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
