On 06/12/2012 01:37 AM, Mohammed, Afzal wrote: > Hi Jon, > > On Tue, Jun 12, 2012 at 00:19:35, Hunter, Jon wrote: > >> What boards have been tested with this change? > > Beagle board, after applying all 5 series of patches, without all > patch series it can't be tested for beagle board as it depended on > bootloader, not this API > >>> + u16 bus_turnaround; >>> + u16 cycle2cycle_delay; >>> + >>> + u16 wait_monitoring; >>> + u16 clk_activation; >>> + >>> /* The following are only on OMAP3430 */ >>> u16 wr_access; /* WRACCESSTIME */ >>> u16 wr_data_mux_bus; /* WRDATAONADMUXBUS */ >> >> In general, I agree with this, but if we apply this today, it seems that >> we *may* be clearing these fields if they have been configured by the >> bootloader and hence this could introduce a regression (potentially). >> >> So we ever need to test boards that this change impacts or at least >> verify that this change would not impact these boards because these >> fields have not been configured. > > Yes, it is the exactly the reason this patch has been splitted out > of gpmc driver conversion series. To find out whether enhancing > existing API cause any regression and if so, then it can be easily > root caused and would not be confused with driver conversion. > > This was the only change required w.r.t old interface, need to make > sure that this won't causes breakage on any of the boards (the boards > which were unknowingly depending on bootloader for these settings). > I have only beagle board & omap3evm (both would not get affected > by this change with existing code) and others can't be validated. > Once this is in lo tree or mainline, this change can be validated > for different boards.
Should you at least warn, if you are going to over-write a value? Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
