On Thu, 11 Jun 2009, Sebastian Andrzej Siewior wrote: > * Nicolas Pitre | 2009-06-11 16:36:42 [-0400]: > > >> Adding a revision history is good thing... I could not find the ARM tree > >> but I've rebased this patch against the orion tree [0]. > > > >Actually, I'm leaning towards the removal of such dynamic mappings > >altogether and keep an unconditional static mapping instead, just like > >Kirkwood does. > Oh now I remember: I've been counting the number possible window > mappings and they exceeded the number of availble slots. That's why I've > made it dynamic and board specific. However if this is not an issue than > static is probaly the better way. There is no need for other physical mappings that I can see in the set of boards we currently support. So I'll make it static until there is a real need for dynamic mapping. > >> Since the driver got renamed, I'm going to send a delta if nothing else > >> comes up. > > > >What is your plan for this driver? Submit it now and add incremental > >improvements afterward or wait until it is more functional? > I would like to get it squeezed into this merge window unless there are > any objections and improve it afterwards. > If you thing it is too early I can keep hacking in my own git tree until > I get the dmac_flush_range() hack out or so. I have no problem with you submitting it now. It is not complete yet but what is there is plenty functional. However I'd prefer if you used the API based on sg_copy_buffer() which includes a call to flush_kernel_dcache_page() already for mainline inclusion, so to have good style up front. ( a patch to fix flush_kernel_dcache_page() on ARM is already queued). Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
