The common clock and several other clock API implementations allow calling clk_get_rate with a NULL pointer. While not specified as expected behavior of the API, device drivers have come to rely on that, causing them to OOPS when run on a platform with a different clock API implementation. Fix this by making sure all clk_get_rate implementations handle NULL clocks instead of OOPSing. While some custom implementations even allow ERR_PTR()s, I decided against that as IIRC the usual idea is that errors should be handled and not silently carried over. Cc: adi-buildroot-devel@xxxxxxxxxxxxxxxxxxxxx Cc: bcm-kernel-feedback-list@xxxxxxxxxxxx Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx Cc: linux-kernel@xxxxxxxxxxxxxxx Cc: linux-m68k@xxxxxxxxxxxxxxxxxxxx Cc: linux-mips@xxxxxxxxxxxxxx Jonas Gorski (9): ARM: ep93xx: allow NULL clock for clk_get_rate ARM: mmp: allow NULL clock for clk_get_rate blackfin: bf609: allow NULL clock for clk_get_rate m68k: allow NULL clock for clk_get_rate MIPS: AR7: allow NULL clock for clk_get_rate MIPS: BCM63XX: allow NULL clock for clk_get_rate MIPS: Loongson 2F: allow NULL clock for clk_get_rate MIPS: ralink: allow NULL clock for clk_get_rate unicore32: allow NULL clock for clk_get_rate arch/arm/mach-ep93xx/clock.c | 3 +++ arch/arm/mach-mmp/clock.c | 4 +++- arch/blackfin/mach-bf609/clock.c | 2 +- arch/m68k/coldfire/clk.c | 3 +++ arch/mips/ar7/clock.c | 3 +++ arch/mips/bcm63xx/clk.c | 3 +++ arch/mips/loongson64/lemote-2f/clock.c | 3 +++ arch/mips/ralink/clk.c | 3 +++ arch/unicore32/kernel/clock.c | 3 +++ 9 files changed, 25 insertions(+), 2 deletions(-) -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
