From: "Kim, Milo" <milo.kim@ti.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Jingoo Han <jingoohan1@gmail.com>,
Guenter Roeck <linux@roeck-us.net>,
Jean Delvare <jdelvare@suse.com>,
Jacek Anaszewski <j.anaszewski@samsung.com>,
Mark Brown <broonie@kernel.org>,
lm-sensors@lm-sensors.org, linux-leds@vger.kernel.org
Subject: Re: [PATCH RESEND 06/16] mfd: add TI LMU driver
Date: Tue, 24 Nov 2015 15:39:35 +0900 [thread overview]
Message-ID: <56540627.7010901@ti.com> (raw)
In-Reply-To: <5653CD07.2090602@ti.com>
On 11/24/2015 11:35 AM, Kim, Milo wrote:
> 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.
I just realized LMU MFD core helpers also provide module dependencies by
using EXPORT_SYMBOL_GPL().
# modprobe -D ti-lmu-backlight
insmod /lib/modules/<ver>/kernel/drivers/base/regmap/regmap-i2c.ko
insmod /lib/modules/<ver>/kernel/drivers/mfd/mfd-core.ko
insmod /lib/modules/<ver>/kernel/drivers/mfd/ti-lmu.ko
insmod /lib/modules/<ver>/kernel/drivers/video/backlight/ti-lmu-backlight.ko
# modprobe -D ti-lmu-fault-monitor
insmod /lib/modules/<ver>/kernel/drivers/base/regmap/regmap-i2c.ko
insmod /lib/modules/<ver>/kernel/drivers/mfd/mfd-core.ko
insmod /lib/modules/<ver>/kernel/drivers/mfd/ti-lmu.ko
insmod /lib/modules/<ver>/kernel/drivers/mfd/ti-lmu-fault-monitor.ko
# modprobe -D lm363x-regulator
insmod /lib/modules/<ver>/kernel/drivers/base/regmap/regmap-i2c.ko
insmod /lib/modules/<ver>/kernel/drivers/mfd/mfd-core.ko
insmod /lib/modules/<ver>/kernel/drivers/mfd/ti-lmu.ko
insmod /lib/modules/<ver>/kernel/drivers/regulator/lm363x-regulator.ko
# modprobe -D leds-lm3633
insmod /lib/modules/<ver>/kernel/drivers/base/regmap/regmap-i2c.ko
insmod /lib/modules/<ver>/kernel/drivers/mfd/mfd-core.ko
insmod /lib/modules/<ver>/kernel/drivers/mfd/ti-lmu.ko
insmod /lib/modules/<ver>/kernel/drivers/leds/leds-lm3633.ko
ti-lmu.ko should be loaded first because it has hardware enable pin
control code. Four other drivers have dependency on this module. Without
EXPORT_SYMBOL_GPL(), this dependency will be gone like below.
# modprobe -D ti-lmu-backlight
insmod /lib/modules/<ver>/kernel/drivers/video/backlight/ti-lmu-backlight.ko
# modprobe -D ti-lmu-fault-monitor
insmod /lib/modules/<ver>/kernel/drivers/mfd/ti-lmu-fault-monitor.ko
# modprobe -D lm363x-regulator
insmod /lib/modules/<ver>/kernel/drivers/regulator/lm363x-regulator.ko
# modprobe -D leds-lm3633
insmod /lib/modules/<ver>/kernel/drivers/leds/leds-lm3633.ko
If LMU MFD core module is not loaded and other modules call regmap
helpers, then loaded drivers will not work because hardware is not
enabled yet.
So I'd like to keep LMU MFD helpers for module dependencies.
Additionally, I'll modify 'ti_lmu_read_byte()' as follows.
int ti_lmu_read_byte(struct ti_lmu *lmu, u8 reg, u8 *read)
{
return regmap_read(lmu->regmap, reg, (unsigned int *)read);
}
EXPORT_SYMBOL_GPL(ti_lmu_read_byte);
Please let me know if you have better idea.
Best regards,
Milo
next prev parent reply other threads:[~2015-11-24 6:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1446441875-1256-1-git-send-email-milo.kim@ti.com>
[not found] ` <1446441875-1256-1-git-send-email-milo.kim-l0cyMroinI0@public.gmane.org>
2015-11-02 5:24 ` [PATCH RESEND 04/16] Documentation: dt-bindings: leds: add LM3633 LED binding information Milo Kim
[not found] ` <1446441875-1256-5-git-send-email-milo.kim-l0cyMroinI0@public.gmane.org>
2015-11-03 16:15 ` Jacek Anaszewski
2015-11-10 7:01 ` Kim, Milo
2015-11-02 5:24 ` [PATCH RESEND 06/16] mfd: add TI LMU driver Milo Kim
2015-11-23 10:30 ` Lee Jones
2015-11-24 2:35 ` Kim, Milo
2015-11-24 6:39 ` Kim, Milo [this message]
2015-11-24 8:18 ` Lee Jones
2015-11-25 8:10 ` Kim, Milo
[not found] ` <56556D01.9070804-l0cyMroinI0@public.gmane.org>
2015-11-25 8:15 ` Lee Jones
2015-11-02 5:24 ` [PATCH RESEND 15/16] leds: add LM3633 driver Milo Kim
2015-11-03 16:15 ` Jacek Anaszewski
[not found] ` <5638DD99.9070502-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2015-11-10 7:38 ` Kim, Milo
2015-11-10 13:44 ` Jacek Anaszewski
[not found] ` <5641F4D3.7000800-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2015-11-11 2:16 ` Kim, Milo
2015-11-12 9:04 ` Jacek Anaszewski
2015-11-20 9:22 ` Jacek Anaszewski
2015-11-22 23:40 ` Kim, Milo
[not found] ` <56525262.60308-l0cyMroinI0@public.gmane.org>
2015-11-23 11:17 ` Jacek Anaszewski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56540627.7010901@ti.com \
--to=milo.kim@ti.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=j.anaszewski@samsung.com \
--cc=jdelvare@suse.com \
--cc=jingoohan1@gmail.com \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=lm-sensors@lm-sensors.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).