Re: [PATCH v8 2/4] misc: Generic on-chip SRAM allocation driver

[Matt Porter <mporter-l0cyMroinI0@public.gmane.org>]

On Tue, Feb 05, 2013 at 12:53:45AM +0900, Paul Mundt wrote:
> On Mon, Feb 04, 2013 at 12:32:16PM +0100, Philipp Zabel wrote:
> > This driver requests and remaps a memory region as configured in the
> > device tree. It serves memory from this region via the genalloc API.
> > It optionally enables the SRAM clock.
> > 
> > Other drivers can retrieve the genalloc pool from a phandle pointing
> > to this drivers' device node in the device tree.
> > 
> > The allocation granularity is hard-coded to 32 bytes for now,
> > to make the SRAM driver useful for the 6502 remoteproc driver.
> > There is overhead for bigger SRAMs, where only a much coarser
> > allocation granularity is needed: At 32 bytes minimum allocation
> > size, a 256 KiB SRAM needs a 1 KiB bitmap to track allocations.
> > 
> > Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> > Reviewed-by: Shawn Guo <shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> 
> How exactly is this "generic" if you have randomly hard-coded an
> allocation granularity that is larger than half of the in-tree SRAM pool
> users today can even support? Did you even bother to look at in-tree SRAM
> pool users other than the one you are working on?
>
> There also doesn't seem to be any real reason for the hard-coding either,
> this information could easily be fetched via platform data or the device
> tree, and the driver in question would simply need to be able to
> determine whether the size is suitable for it or not.

Please see http://thread.gmane.org/gmane.linux.kernel/1377702 for the
original discussion on my patch for configurable allocation granularity.
I believe there was an implied agreement from Grant that it was ok if we
went with a more descriptive name even though it hits the grey area of
not describing hardware.

-Matt