[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9acdc0af-4be9-91cb-ffed-25133bba73c3@gmail.com>
Date: Mon, 4 Jun 2018 18:25:18 +0200
From: Marek Vasut <marek.vasut@...il.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>,
Steve Twiss <stwiss.opensource@...semi.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Marek Vasut <marek.vasut+renesas@...il.com>,
Geert Uytterhoeven <geert+renesas@...der.be>,
Lee Jones <lee.jones@...aro.org>,
Mark Brown <broonie@...nel.org>,
Wolfram Sang <wsa+renesas@...g-engineering.com>,
Linux-Renesas <linux-renesas-soc@...r.kernel.org>
Subject: Re: [PATCH v3 06/10] mfd: da9063: Add custom regmap for DA9063L
On 06/04/2018 09:39 AM, Geert Uytterhoeven wrote:
> Hi Marek, Steve,
>
> On Sat, Jun 2, 2018 at 12:11 PM, Marek Vasut <marek.vasut@...il.com> wrote:
>> While the datasheet for DA9063L (2v1, 23-Mar-2017) lists the RTC register
>> block, the DA9063L does not have an RTC. Add custom regmap for DA9063L to
>> prevent access into that register block.
>>
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@...il.com>
>
> Thanks for your patch!
>
>> --- a/drivers/mfd/da9063-i2c.c
>> +++ b/drivers/mfd/da9063-i2c.c
>> @@ -254,6 +341,10 @@ static int da9063_i2c_probe(struct i2c_client *i2c,
>
> Note that the line above doesn't check da9063->type, but da9063->variant_code...
>
>> da9063_regmap_config.rd_table = &da9063_ad_readable_table;
>> da9063_regmap_config.wr_table = &da9063_ad_writeable_table;
>> da9063_regmap_config.volatile_table = &da9063_ad_volatile_table;
>> + } else if (da9063->type == PMIC_TYPE_DA9063L) {
>
> ... so this may be slightly confusing.
I know.
>> + da9063_regmap_config.rd_table = &da9063l_bb_readable_table;
>> + da9063_regmap_config.wr_table = &da9063l_bb_writeable_table;
>> + da9063_regmap_config.volatile_table = &da9063l_bb_volatile_table;
>> } else {
>> da9063_regmap_config.rd_table = &da9063_bb_readable_table;
>> da9063_regmap_config.wr_table = &da9063_bb_writeable_table;
>
> However, da9063->variant_code doesn't seem to have been filled in at this
> point yet (the call to da9063_device_init() doing so is below, at the end
> of the probe function!), so commit 9cb42e2a8ed06e91 ("mfd: da9063: Add
> support for AD silicon variant") never actually handled the AD silicon variant
> correctly? Or am I missing something?
Ha, that is a good point.
--
Best regards,
Marek Vasut
Powered by blists - more mailing lists