On Thu, Feb 23, 2017 at 07:23:36PM -0500, Pedro Giffuni wrote: > Hi; > > > Il giorno 23 feb 2017, alle ore 19:05, Ian Lepore <i...@freebsd.org> ha > > scritto: > > > > On Thu, 2017-02-23 at 23:48 +0000, Pedro F. Giffuni wrote: > >> Author: pfg > >> Date: Thu Feb 23 23:48:44 2017 > >> New Revision: 314186 > >> URL: https://svnweb.freebsd.org/changeset/base/314186 > >> > >> Log: > >> at91: double assignment. > >> > >> Found with: coccinelle (da.cocci) > >> Suggested by: cognet > >> > >> Modified: > >> head/sys/arm/at91/at91sam9260.c > >> > >> Modified: head/sys/arm/at91/at91sam9260.c > >> ===================================================================== > >> ========= > >> --- head/sys/arm/at91/at91sam9260.c Thu Feb 23 22:46:01 2017 > >> (r314185) > >> +++ head/sys/arm/at91/at91sam9260.c Thu Feb 23 23:48:44 2017 > >> (r314186) > >> @@ -193,7 +193,6 @@ at91_clock_init(void) > >> */ > >> clk = at91_pmc_clock_ref("pllb"); > >> clk->pll_min_in = SAM9260_PLL_B_MIN_IN_FREQ; > >> /* 1 MHz */ > >> - clk->pll_max_in = SAM9260_PLL_B_MAX_IN_FREQ; > >> /* 5 MHz */ > >> clk->pll_max_in = 2999999; > >> /* ~3 MHz */ > >> clk->pll_min_out = SAM9260_PLL_B_MIN_OUT_FREQ; /* > >> 70 MHz */ > >> clk->pll_max_out = SAM9260_PLL_B_MAX_OUT_FREQ; /* > >> 130 MHz */ > >> > > > > Just looking at this by eye (but without digging out the at91 manuals) > > I'd say this looks like fallout from a mismerge and the correct line to > > keep would be the named constant. Keeping the one that has actually > > been in effect all this time isn't the same as keeping the right one, > > and this deletion may remove the only clue someone might find when they > > eventually get around to debugging this (if ever, the sam9260 is a > > pretty old chip). > > > > -- ian > > > > > > According to SVN annotations it is not a mismerge:. The first line looks more > technical but cognet@ stated from the second one is correct and matches the > (long) initial comment. > > It???s also what is in effective use now, so I wouldn???t change it unless > someone with the hardware confirms first. >
As Pedro says, there's a large comment that says : * Fudge MAX pll in frequence down below 3.0 MHz to ensure * PMC alogrithm choose the divisor that causes the input clock * to be near the optimal 2 MHz per datasheet. We know * we are going to be using this for the USB * clock at 96 MHz. * Causes no extra frequency deviation for all recommended crystal * values. See Note 1, table 40-16 SAM9260 doc. So I just assumed it was OK. (And it's been that way since the code was first submitted). Olivier _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"