On Tue, Apr 09, 2013 at 01:17:46PM -0700, Tony Lindgren wrote: > * Thierry Reding <thierry.reding@xxxxxxxxxxxxxxxxx> [130409 12:45]: > > On Tue, Apr 09, 2013 at 09:40:04AM -0700, Tony Lindgren wrote: > > [...] > > > But then the regulator is not found and the driver should just exit, > > > or do nothing. If this is an optional regulator, then that should be > > > indicated in some platform data flags? > > > > Yes, if the regulator isn't found then the driver fails. However the > > goal was to maintain bisectability. If we apply them in the wrong order > > we can't guarantee that because pwm-backlight will fail to work between > > both patches. > > But it's fixing something that's not working anyways for board-4430sdp.c, > It seems so as these patches just add new features? Not quite. It's adding a dummy regulator to represent hardware where the enable pin is always high. So I think pwm-backlight will work in the current state, but if we make the pwm-backlight driver change without adding the dummy regulator, then pwm-backlight will fail to probe and therefore the PWM won't be enabled either and the display will stay black. > > > The driver parts really must be done in independently from any platform > > > data or .dts changes. The only common part needed should be changes > > > to include/linux/platform_data/*.h files. > > > > We don't even need to touch platform data because the regulators are > > looked up via a global table. And the changes are all done independently > > but as I mentioned above, bisectability isn't maintained, so the > > preferred patch order is the one in which pwm-backlight keeps working at > > each point in the commit history. > > Bisectability is a good point. But in the 4430sdp case I'm sure it's enough > that it builds and boots no matter how the patches get merged :) If you don't mind some intermediary breakage, I will no longer object. Thierry
Attachment:
pgpKIFYHDfEJh.pgp
Description: PGP signature
