[Cbe-oss-dev] [patch 11/13] cell: driver for DDR2 memory on AXON

[Christoph Hellwig]

On Thu, Jul 19, 2007 at 12:48:08AM +0200, Arnd Bergmann wrote:
> On Wednesday 18 July 2007, Andrew Morton wrote:
> > > +/**
> > > + * axon_ram_open - open() method for device
> > > + * @inode, @file: see file_operations method
> > > + */
> > > +static int
> > > +axon_ram_open(struct inode *inode, struct file *file)
> > > +{
> > > +?????inode->i_bdev->bd_block_size = AXON_RAM_BLOCK_SIZE;
> > > +
> > > +?????return 0;
> > > +}
> > 
> > This looks fishy. ?There are a bunch of helpers in fs/block-dev.c which are
> > supposed to set bd_block_size, but here we are open-coding it within a
> > particular blockdev driver.
> > 
> > I note that rd.c does the same thing, which is presumably where this came
> > from. ?Could be that rd.c is simply misbehaving. ?Perhaps Christoph could
> > opine?
> > 
> 
> It's funny: The only two places where bd_block_size is set in the entire
> linux code are in rd.c and dcssblk.c. The only places where we use that
> value are in floppy.c and loop.c, as well as the BLKBSZGET ioctl.
> 
> None of these seems to make any difference whatsoever, except for BLKBSZGET
> returning non-zero on a ramdisk or dcssblk device. I think we'd be best
> off removing bd_block_size from the kernel altogether, and I'll remove
> it from the axon-ram driver now.

Yes, please.  I even have patches that only pass struct gendisk to block
device ->open, so this couldn't work anymore anyway.  And yes, the
ramdisk driver is doing some really odd things.