On Mon, Mar 10, 2014 at 11:45:50PM +0100, Courtney Cavin wrote: > On Mon, Mar 10, 2014 at 11:33:06PM +0100, Christopher Heiny wrote: > > On 03/10/2014 07:46 AM, Courtney Cavin wrote: > > > On Sat, Mar 08, 2014 at 03:29:51AM +0100, Christopher Heiny wrote: > > >> Signed-off-by: Christopher Heiny <[email protected]> > > >> Cc: Dmitry Torokhov <[email protected]> > > >> Cc: Benjamin Tissoires <[email protected]> > > >> Cc: Linux Walleij <[email protected]> > > >> Cc: David Herrmann <[email protected]> > > >> Cc: Jiri Kosina <[email protected]> > > >> > > >> --- > > >> > > >> drivers/input/rmi4/rmi_f01.c | 96 > > >> ++----------------------------------- > > >> drivers/input/rmi4/rmi_f01.h | 110 > > >> +++++++++++++++++++++++++++++++++++++++++++ > > >> 2 files changed, 114 insertions(+), 92 deletions(-) > [...] > > > > > > I might be missing something, but these seem like the only defines used > > > in the flash code. Why not keep these in the f01 driver, and export > > > a couple more functions, like rmi_f01_reset() and > > > rmi_f01_set_sleep_mode() ? > > > > It seems better to me to have the information defined in a single place, > > rather than scattered hither and yon through the source files. > > Uh. Exactly? This is why I'm suggesting that you keep this information > isolated in the driver to which is directly related. > > Perhaps what you mean is that the regs/bits for the entire chip > functionality should be exposed in header files, so one can read/write > it from anywhere? That seems backwards to the idea of separating these > 'functions' out into drivers.
Ah. Wait. I think there was some mis-communication on my part. What I should have said: Why not keep all of the defines in the driver, and export a couple more functions? My point is exactly yours. Keep the defines with the code. Expose what's needed. -Courtney -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
