On Wed, Jun 03, 2009 at 11:03:20AM +0200, Janusz Krzysztofik wrote: > Wednesday 03 June 2009 00:04:33 Jonathan McDowell napisał(a): > > I'm obviously too late as I've seen the "Applied" mail, > > No problem, I'm glad to hear from you. > > > but some > > comments: > > > > * I don't think SW_HEADPHONE_INSERT is appropriate. input guys, is it > > not reasonable to have SW_PHONE_HOOK or similar? > > I do share you point of view. However, I didn't want to start a discussion if > there is a need for another symbol or not before the patch got any > acceptance. > > > * We assume the bootloader does the appropriate GPIO pin setup for us, > > so I don't think your omap_cfg_reg is required but it doesn't hurt in > > the unlikely event we ever replace the Amstrad PBL. > > OK, let it stay there. Do you see a need for replaceing it with a new > ams_delta_hook_switch_init() function call that just calls omap_cfg_reg()? I don't see a need for this; it's always present and not a lot of code to have in the init function as it stands. > > * The commented out code to include the GPIO status in sysfs shouldn't > > be included. > > Yes, I put it there to get a feedback. > > > Does the input layer not provide a way to obtain the > > state of the switch? > > Yes, it does, with EVIOCGSW ioctl()[1]. I personally don't like this way of > getting the switch status and would rather see it available over sysfs. > However, input guys may have their own preferences and gpio-keys driver > belongs to them. I think that's a discussion to have with the input guys rather than putting a hack in the platform file then. So really the only issue with the patch that remains is if it justifies adding a new SW_PHONE_HOOK switch type? J. -- ] http://www.earth.li/~noodles/ [] Purranoia: The fear that your cat [ ] PGP/GPG Key @ the.earth.li [] is up to something. [ ] via keyserver, web or email. [] [ ] RSA: 4096/2DA8B985 [] [ -- 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