On 2013-03-11, at 10:09 PM, Evgeniy Polyakov wrote: > Hi > > On Thu, Mar 07, 2013 at 04:07:03PM -0500, Jean-Francois Dagenais > (jeff.dagen...@gmail.com) wrote: >> De-activating this reading back will effectively half the time required >> for a write to the output register. > > Are you sure you want this to be compile-time option and not module > parameter?
My experience showed that having this kind of check was only useful for HW/SW debug development phases, which usually require debug configs. Later in the development process, when HW and SW are stable, we usually optimize for actual production. Removing un-needed debug features and modules. Assuming that, for historical reasons, implementing this new option as a module parameter would imply initializing it to "true" (i.e. read-back check enabled), then user-space or kernel invocation would have to override this to "false" in order to benefit from the enhancement. I felt that this was an awkward burden to propagate and maintain outside the kernel's config (.config). Especially since usually, the debug and release configs are meant exactly for this kind of stuff. Also, it's not so off from the "Protect DS2433 data with a CRC16" option nearby. We could do the "best of both worlds" and have the Kconfig influence the init value of a new module parameter which controls whether we read-back or not... All that said, kernel style and good practices should win here over my own experiences as the extra run-time "if" check is not an issue really an issue on most platform. Thoughts? /jfd-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
