linux-rtc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Biju Das <biju.das@bp.renesas.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	linux-rtc@vger.kernel.org, Simon Horman <horms@verge.net.au>,
	Chris Paterson <Chris.Paterson2@renesas.com>,
	Fabrizio Castro <fabrizio.castro@bp.renesas.com>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Subject: Re: [PATCH v3 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc
Date: Thu, 6 Dec 2018 10:39:13 +0100	[thread overview]
Message-ID: <CAMuHMdVv262dM8JGWN4w3h2kq4Y4ftRczn8TF-kM_fecF4GXnw@mail.gmail.com> (raw)
In-Reply-To: <1544086559-47141-3-git-send-email-biju.das@bp.renesas.com>

Hi Biju,

CC nvmem maintainer

On Thu, Dec 6, 2018 at 10:04 AM Biju Das <biju.das@bp.renesas.com> wrote:
> Add support for NXP pcf85263 real-time clock. pcf85263 rtc is compatible
> with pcf85363,except that pcf85363 has additional 64 bytes of RAM.
>
> 1 byte of nvmem is supported and exposed in sysfs (# is the instance
> number,starting with 0): /sys/bus/nvmem/devices/pcf85x63-#/nvmem
>
> Signed-off-by: Biju Das <biju.das@bp.renesas.com>
> ---
> V1-->V2
>         * Incorporated Alexandre and Geert's review comment.
> V2-->V3
>         * Incorporated Geert's review comment.

Thanks for the update!

> --- a/drivers/rtc/rtc-pcf85363.c
> +++ b/drivers/rtc/rtc-pcf85363.c
> @@ -120,6 +120,11 @@ struct pcf85363 {
>         struct regmap           *regmap;
>  };
>
> +struct pcf85x63_config {
> +       struct regmap_config regmap;
> +       unsigned int num_nvram;
> +};
> +
>  static int pcf85363_rtc_read_time(struct device *dev, struct rtc_time *tm)
>  {
>         struct pcf85363 *pcf85363 = dev_get_drvdata(dev);
> @@ -311,25 +316,68 @@ static int pcf85363_nvram_write(void *priv, unsigned int offset, void *val,
>                                  val, bytes);
>  }
>
> -static const struct regmap_config regmap_config = {
> -       .reg_bits = 8,
> -       .val_bits = 8,
> -       .max_register = 0x7f,
> +static int pcf85x63_nvram_read(void *priv, unsigned int offset, void *val,
> +                              size_t bytes)

Given bytes should be 1, val should be a pointer to a single byte...
What if bytes == 0?

> +{> +       struct pcf85363 *pcf85363 = priv;
> +
> +       return regmap_read(pcf85363->regmap, CTRL_RAMBYTE, val);

However, regmap_read() has an unsigned int output parameter!
So it's writing too many bytes, and only writing the actual data byte to the
correct address on little-endian systems.
Hence you need to use an intermediate variable to convert from unsigned
int to byte.

> +}
> +
> +static int pcf85x63_nvram_write(void *priv, unsigned int offset, void *val,
> +                               size_t bytes)
> +{
> +       struct pcf85363 *pcf85363 = priv;
> +
> +       return regmap_write(pcf85363->regmap, CTRL_RAMBYTE,
> +                               *((unsigned int *)val));

Likewise for writing.

> +}

BTW, while the nvmem_device_{read,write}() public API is documented, the
nvmem_device.reg_{read,write}() driver API isn't.
And the behavior might be confusing.

E.g.
 * Return: length of successful bytes read on success and negative
 * error code on error.

The public API seems to assume the driver API returns zero on success,
and replaces the zero by the number of bytes requested.
If the requested number of bytes is too large, a zero success would be
converted to a value that's larger than the actual number of bytes
transferred!
However, the driver API can return a smaller (positive) number, which matches
"standard" read/write() APIs.

> +static const struct pcf85x63_config pcf_85263_config = {
> +       {
> +               .reg_bits = 8,
> +               .val_bits = 8,
> +               .max_register = 0x2f,
> +       },
> +       1

The "1" looks funny. Please use C99 initializers for all struct members.

> +};
> +
> +static const struct pcf85x63_config pcf_85363_config = {
> +       {
> +               .reg_bits = 8,
> +               .val_bits = 8,
> +               .max_register = 0x7f,
> +       },
> +       2

Likewise.

The rest looks good to me, so
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

  reply	other threads:[~2018-12-06  9:39 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-06  8:55 [PATCH v3 0/4] Add NXP pcf85263 real-time clock support Biju Das
2018-12-06  8:55 ` [PATCH v3 1/4] dt-bindings: rtc: pcf85363: Document pcf85263 real-time clock Biju Das
2018-12-06  9:13   ` Geert Uytterhoeven
2018-12-06  8:55 ` [PATCH v3 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc Biju Das
2018-12-06  9:39   ` Geert Uytterhoeven [this message]
2018-12-06 15:24     ` Biju Das
2018-12-06 15:37       ` Geert Uytterhoeven
2018-12-06 15:49         ` Biju Das
2018-12-06 16:52           ` Alexandre Belloni
2018-12-07  9:34             ` Biju Das
2018-12-07  9:45               ` Geert Uytterhoeven
2018-12-07 10:16                 ` Biju Das
2018-12-07 10:18                   ` Geert Uytterhoeven
2018-12-06  8:55 ` [PATCH v3 3/4] ARM: shmobile: Enable NXP pcf85363 rtc in shmobile_defconfig Biju Das
2018-12-06  9:41   ` Geert Uytterhoeven
2018-12-06  8:55 ` [PATCH v3 4/4] ARM: dts: iwg23s-sbc: Enable RTC Biju Das
2018-12-06  9:55   ` Geert Uytterhoeven
2018-12-06 12:40     ` Biju Das
2018-12-06 12:59       ` Geert Uytterhoeven
2018-12-10 11:52         ` Simon Horman
2018-12-10 11:56           ` Geert Uytterhoeven
2018-12-10 12:15             ` Simon Horman

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=CAMuHMdVv262dM8JGWN4w3h2kq4Y4ftRczn8TF-kM_fecF4GXnw@mail.gmail.com \
    --to=geert@linux-m68k.org \
    --cc=Chris.Paterson2@renesas.com \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@bootlin.com \
    --cc=biju.das@bp.renesas.com \
    --cc=fabrizio.castro@bp.renesas.com \
    --cc=geert+renesas@glider.be \
    --cc=horms@verge.net.au \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=srinivas.kandagatla@linaro.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).