On Thu, Feb 04, 2010 at 04:52:26PM +0200, Grazvydas Ignotas wrote: > On Thu, Feb 4, 2010 at 4:24 PM, Mark Brown > > The updates to fix up the boards that need this are fairly > > straightforward and given that it's fairly easy to identify systems > > which are using the driver in mainline so I'd really prefer not to go > > down the route of trying to carry on in the face of error, it papers > > over stuff now but is not robust in the face of future changes. > What about warning and continuing only on ENODEV then? I really don't > want to be responsible for potentially breaking touchscreen on ~30 > boards, where I have no idea about how things are wired up and how the > regulators should be set up. I'm really not terribly enthusiastic about that approach - like I say, it just moves the problem about a bit and postpones the breakage in a potentially more obscure fashion. I'm also thinking that if we were going to go down that route then handling it in the regulator core rather than in each individual driver is going to be a much more sensible approach. Having to conditionalise each and every regulator API call in every single driver to handle this feels like the wrong approach, it'd spread noise through the kernel as a whole and obscure what's going on in cases where there are problems. The bodge I'm thinking of would do something like log an error and substitute in a dummy regulator when regulator_get() would have failed so that the driver sees behaviour equivalent to the stubbed regulator API if the bodge is active. A central thing seems much more sensible here - there's nothing specific to this driver going on here and having the API behave in a consistent manner seems good. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
