Hi Hans, 2018-06-12 16:56 GMT+09:00 Hans de Goede <hdegoede@xxxxxxxxxx>: > Hi, > > On 12-06-18 08:27, Masahiro Yamada wrote: >> >> Hi Hans, >> >> 2018-06-08 5:57 GMT+09:00 Hans de Goede <hdegoede@xxxxxxxxxx>: >>> >>> Hi All, >>> >>> While testing usb-next on some Intle Bay and Cherry Trail >>> devices I noticed the following new error in my logs: >>> >>> [ 26.187958] dwc3 dwc3.3.auto: Failed to get clk 'ref': -2 >>> >>> This is caused by the new clk_bulk_get() call in >>> drivers/usb/dwc3/core.c >>> >>> If I understand the commit message correctly this is >>> intended to replace (for newer boards / SoCs) the >>> clk handling in dwc3-of-simple.c and this seems to >>> be a devicetree specific patch in general. >>> >>> Now things still work because the new clk code accepts >>> clk_bulk_get() failing and then effectively disables >>> itself. >>> >>> Maybe we should wrap the clk_bulk_get() in an >>> if (device->of_node) conditional to stop this error >>> from getting logged on non DT platforms? >>> >> >> Or, maybe drop the error logging from clk_bulk_get() ? > > > Yes, but that would require all callers to do their > own error logging. There seems to be a pattern in the > kernel where functions like clk_bulk_get (any function > which is expected to normally succeed) do the error > logging themselves so that callers don't have to do this. Right. But, clk_get() emits "ERROR: could not get clock" log in the core. To not disturb optional clocks, there are more conditions to meet for displaying the error message. See this code. https://github.com/torvalds/linux/blob/v4.17/drivers/clk/clkdev.c#L80 So, I suspect that logging is duplicated to some extent between clk_get() and clk_bulk_get(). > Note in the mean time I've prepared a patch making the > clk_bulk_get() call on dev->of_node. If we are in agreement > that that is best fix then I will post it. Fair enough. Go ahead. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
