[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-i2c
Subject:    [i2c] [patch/rfc 2.6.19-rc6 3/3] convert OMAP OSK to "new
From:       david-b () pacbell ! net (David Brownell)
Date:       2006-11-18 18:44:45
Message-ID: 200611181044.45700.david-b () pacbell ! net
[Download RAW message or body]

On Saturday 18 November 2006 1:33 am, Greg KH wrote:
> On Thu, Nov 16, 2006 at 11:27:53AM -0800, David Brownell wrote:
> > Partial conversion of one board to use new style I2C driver binding:
> > 
> > ...
> > 
> > Most of the tps65010 changes (by volume) are just adjusting to the fact that
> > this driver no longer allocates the i2c_client structure.  But it's also
> > about 10% smaller (with debugfs, probably 20% smaller otherwise) mostly
> > because the I2C_CLIENT_INSMOD data is gone.

Hmm, no comment on that 10-20% shrinkage in driver size?  :)


> > @@ -179,6 +180,34 @@ static struct platform_device *osk5912_d
> >  	&osk5912_mcbsp1_device,
> >  };
> >  
> > +static struct i2c_board_info __initdata osk_i2c_board_info[] = { {
> > +	.modalias	= "tps65010",
> 
> Can't we automagically set this to THIS_MODULE->name if it's a module so
> that people don't type this wrong somehow?

Not in that file -- that's the board-specific init code!  Not only must
that not be modular; but if it could be, its module name would be wrong.

Assuming you meant to be asking about _driver_ source files ... what does
THIS_MODULE work out to be when drivers are statically linked?  And how
would all the board-specific declarations get updated if someone changes
the driver module's name?  There will be a lot more of the latter.

I've thought about automating that sort of thing before, since platform
(and SPI) driver hotplug might work a bit more smoothly that way, but
it hasn't actually caused much trouble.


> > +	.platform_data	= "tps65010",
> > +	.dev_addr	= 0x48,
> > +	.bus_num	= 0,
> > +	.irq		= OMAP_GPIO_IRQ(OMAP_MPUIO(1)),
> 
> This whole initializer is just crying out for a macro :)

Maybe once the approach gets fully accepted.  Not every chip is going to
want platform data or an IRQ, but device addressing has a better case for
wanting a macro.

- Dave


[prev in list] [next in list] [prev in thread] [next in thread]