Hi, On 12 January 2015 at 18:51, Joonyoung Shim <[email protected]> wrote: > Hi, > > On 01/13/2015 11:47 AM, Simon Glass wrote: >> Hi, >> >> On 12 January 2015 at 18:36, Joonyoung Shim <[email protected]> wrote: >>> Hi, >>> >>> On 01/13/2015 11:27 AM, Simon Glass wrote: >>>> Hi, >>>> >>>> On 12 January 2015 at 18:24, Joonyoung Shim <[email protected]> >>>> wrote: >>>>> Hi, >>>>> >>>>> I found below compile warnings, >>>>> >>>>> CC arch/arm/cpu/armv7/exynos/clock.o >>>>> arch/arm/cpu/armv7/exynos/clock.c: In function ‘clock_get_periph_rate’: >>>>> arch/arm/cpu/armv7/exynos/clock.c:265:47: warning: array subscript is >>>>> above array bounds [-Warray-bounds] >>>>> struct clk_bit_info *bit_info = &clk_bit_info[peripheral]; >>>>> ^ >>>>> arch/arm/cpu/armv7/exynos/clock.c:265:47: warning: array subscript is >>>>> above array bounds [-Warray-bounds] >>>>> >>>>> ... >>>>>> static unsigned long exynos5_get_periph_rate(int peripheral) >>>>>> { >>>>>> struct clk_bit_info *bit_info = &clk_bit_info[peripheral]; >>>>>> >>>>> >>>>> This can access out of bounds of clk_bit_info[] array from >>>>> exynos5_get_periph_rate(). The peripheral value comes from >>>>> enum periph_id but it gets out of count clk_bit_info[] array. >>>>> >>>>> So, i don't think exynos5_get_periph_rate is working correctly. >>>>> Currently, exynos5_get_periph_rate is used by clock_get_periph_rate only >>>>> from get_pwm_clk. >>>>> >>>>> Is it ongoing to work for generic api to get the clk freq? If not, >>>>> let's remove exynos5_get_periph_rate and clock_get_periph_rate. >>>> >>>> That's going in the wrong direction - these functions make the code >>>> much easier to follow and refactor. We should remove get_pwm_clk(), >>>> get_mmc_clk() etc. and use generic functions instead. >>>> >>> >>> I know, but current codes are wrong, so first i want to correct it even >>> if it is old way because it's really easy. And then we can go to generic >>> functions. >> >> So not remove the generic functions? >> >> Is it this line which is broken? >> >> clock_get_periph_rate(PERIPH_ID_PWM0); >> >> If so, it seems like everything else uses its own function. It should >> all move easily to the generic function I think. >> > > The basic problem is the generic function is wrong.
Oh dear, does it not work for anything? Regards, Simon _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
