[i2c] [patch 2.6.18-rc] constify i2c_algorithm

David Brownell david-b at pacbell.net
Sun Sep 3 19:36:30 CEST 2006


> Please Cc the i2c list when sending i2c patches (added.)

Sorry.

> > Let drivers constify I2C algorithm method operations tables,
> > moving them from ".data" to ".rodata".
> > 
> > Signed-off-by: David Brownell <dbrownell at users.sourceforge.net>
> > 
> > Index: at91/include/linux/i2c.h
> > ===================================================================
> > --- at91.orig/include/linux/i2c.h	2006-08-05 12:14:27.000000000 -0700
> > +++ at91/include/linux/i2c.h	2006-09-03 05:24:43.000000000 -0700
> > @@ -220,7 +220,7 @@ struct i2c_adapter {
> >  	struct module *owner;
> >  	unsigned int id;
> >  	unsigned int class;
> > -	struct i2c_algorithm *algo;/* the algorithm to access the bus	*/
> > +	const struct i2c_algorithm *algo;/* the algorithm to access the bus	*/
> >  	void *algo_data;
> >  
> >  	/* --- administration stuff. */
>
> Looks good. Is there any performance benefit in marking a driver's
> struct i2c_algorithm const?

I'm not sure I'd expect anything measurable with just one driver.

At kernel init time, it's less ".data" to copy, so XIP startup gets
marginally quicker if you're running out of NOR flash (and you have
marginally more of your RAM available for Real Use).  Folk generally
prefer smaller ".data" sections for that and other reasons.

At runtime, I suspect ".rodata" doesn't have any better referencing
locality than ".data".  ".rodata" is less likely to be clobbered by
stray pointers though.


> I've applied your patch, I also added a fix to one occurence in the
> documentation. I'll push two patches on top of that, one adding const
> to all i2c algorithm drivers and one adding const to all i2c bus
> drivers (where possible, of course.)

Ok good; I didn't check docs, and was being lazy about updating the
drivers.  :)

- Dave




More information about the i2c mailing list