On Tuesday 02 September 2008, Felipe Balbi wrote: > > > One thing we might say, Jean Delvare won't accept twl4030 the way it is > > > now. Old style i2c drivers will be dropped soon. We have to get twl4030 > > > properly done otherwise it'll be a pain later. > > > > He's also not keen on growing drivers/i2c/chips ... > > So this driver should probably move to drivers/mfd too. > > Sure... it should really be there since it really is a multifunction > device. In that case it would be merged through Samuel Ortiz, right ? > Most likely Cc:ing i2c@xxxxxxxxxxxxxx so i2c people could comment on the > code as well. Yes. Though considering it's an irq_chip that dispatches through I2C ... maybe an LKML review too, for the core. > > (When it starts moving upstream, I suspect some folk will > > ask why it doesn't support the drivers/regulator calls; > > that's still new, I'd not worry much.) > > Well, but if we have proper APIs for doing stuff, we should really start > using them, don't you think ? That's why I mentioned that. My priority would be getting the existing core code fixed/merged. Then other bits as needed to get widely-available boards (Beagle, soon Overo) working in mainline. (Then the rest.) Being the first "external" user of a new API framework is something to take slowly... IMO it's not worth holding up twl4030 support to do that. > I'll postpone my twl4030-usb patch and try to work on twl4030-core.c. > It'll be a huge task moving all of that to new style i2c driver. Well, it's got obvious increments that are simple. Core first; then the other bits, incrementally. Maybe the core could be pushed upstream without a lot of the other functions exposed. Note that the LED support isn't written yet, so there'd be nothing to convert. :) - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
