Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752988AbbKXCh0 (ORCPT ); Mon, 23 Nov 2015 21:37:26 -0500 Received: from comal.ext.ti.com ([198.47.26.152]:56553 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752655AbbKXChY (ORCPT ); Mon, 23 Nov 2015 21:37:24 -0500 Subject: Re: [PATCH RESEND 06/16] mfd: add TI LMU driver To: Lee Jones References: <1446441875-1256-1-git-send-email-milo.kim@ti.com> <1446441875-1256-7-git-send-email-milo.kim@ti.com> <20151123103025.GJ3098@x1> CC: , , Jingoo Han , Guenter Roeck , Jean Delvare , Jacek Anaszewski , Mark Brown , , From: "Kim, Milo" Message-ID: <5653CD07.2090602@ti.com> Date: Tue, 24 Nov 2015 11:35:51 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20151123103025.GJ3098@x1> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1699 Lines: 56 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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/