Hi Lee, Thanks for all your comments. Please see my comments below. On 11/23/2015 7:30 PM, Lee Jones wrote:
+int ti_lmu_read_byte(struct ti_lmu *lmu, u8 reg, u8 *read) >+{ >+ int ret; >+ unsigned int val; >+ >+ ret = regmap_read(lmu->regmap, reg, &val); >+ if (ret < 0) >+ return ret; >+ >+ *read = (u8)val; >+ return 0; >+} >+EXPORT_SYMBOL_GPL(ti_lmu_read_byte);It doesn't get much more simple than this. What's the purpose of abstracting it?>+int ti_lmu_write_byte(struct ti_lmu *lmu, u8 reg, u8 data) >+{ >+ return regmap_write(lmu->regmap, reg, data); >+} >+EXPORT_SYMBOL_GPL(ti_lmu_write_byte); >+ >+int ti_lmu_update_bits(struct ti_lmu *lmu, u8 reg, u8 mask, u8 data) >+{ >+ return regmap_update_bits(lmu->regmap, reg, mask, data); >+} >+EXPORT_SYMBOL_GPL(ti_lmu_update_bits);Okay, I lied, it does get more simple. Seems like abstraction for the sake of abstraction here. Feel free to try and convince me otherwise.
The main reason was that LMU MFD core provides consistent register access among LMU drivers like ti-lmu-backlight, leds-lm3633, lm363x-regulator and ti-lmu-fault-monitor('ti-lmu-hwmon' will be changed to this in the 2nd patch).
However, LMU register helpers are exactly same as regmap interface except using ti_lmu data structure. So let me replace them with regmap functions. Thanks for pointing this out.
Best regards, Milo -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
