On Thu, Jan 12, 2017 at 10:29:37AM -0600, Benjamin Herrenschmidt wrote: > So I think the best approach here is: > > - A pair of ioctls to read and write random registers in the > LPC bridge for all the "generally configuration gunk". These have a > filter to ensure that the registers controlling the above mapping > cannot be accessed that way. > > - An ioctl to control the above mapping window. It takes as > arguments the location in LPC space, the window type (flash vs. > memory), for memory, maybe an ID (several windows to chose from), and > the offset& size in the latter. The driver can enforce that the windows > are one of the specially reserved areas of memory etc... > > - An mmap function to map those reserved windows into userspace > so the daemon can communicate appropriately (only needed for the memory > windows, the flash space is accessed via the normal /dev/mtd drivers) > > Greg, does that make sense ? Yes, that makes a lot more sense to me. Thanks for writing it up, hopefully it survives into the next driver submission, otherwise I'll ask the same questions again due to not having a short-term memory at all :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
