linux-rtc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Biju Das <biju.das@bp.renesas.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	"linux-rtc@vger.kernel.org" <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 15:49:57 +0000	[thread overview]
Message-ID: <OSBPR01MB2103A13E75634AD81CFD1628B8A90@OSBPR01MB2103.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <CAMuHMdWRz-iutKD54vtmJxnLsb3vtm1juYDw-k1+RFCNUVsjkg@mail.gmail.com>

Hi Geert,

Thanks for the feedback.

> Subject: Re: [PATCH v3 2/4] rtc: pcf85363: Add support for NXP pcf85263 rtc
>
> Hi Biju,
>
> On Thu, Dec 6, 2018 at 4:24 PM Biju Das <biju.das@bp.renesas.com> wrote:
> > > Subject: Re: [PATCH v3 2/4] rtc: pcf85363: Add support for NXP
> > > pcf85263 rtc 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.
>
> > > > --- 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?
> >
> > I doubt we get "bytes==0" because of the checks in "
> drivers/nvmem/core.c"
> > Function " bin_attr_nvmem_read/ bin_attr_nvmem_write".
>
> Depends. There are other functions calling nvmem_reg_{read,write}(), e.g.
> nvmem_device_{read,write}().

OK. In that case, I will return (-EINVAL)  for "bytes !=1"

> >
> > > > +{> +       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.
> >
> > OK. Will use an intermediate integer variable.
> >
> > > > +}
> > > > +
> > > > +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.

Regards,
Biju


[https://www2.renesas.eu/media/email/unicef.jpg]

This Christmas, instead of sending out cards, Renesas Electronics Europe have decided to support Unicef with a donation. For further details click here<https://www.unicef.org/> to find out about the valuable work they do, helping children all over the world.
We would like to take this opportunity to wish you a Merry Christmas and a prosperous New Year.



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

  reply	other threads:[~2018-12-06 15:50 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
2018-12-06 15:24     ` Biju Das
2018-12-06 15:37       ` Geert Uytterhoeven
2018-12-06 15:49         ` Biju Das [this message]
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=OSBPR01MB2103A13E75634AD81CFD1628B8A90@OSBPR01MB2103.jpnprd01.prod.outlook.com \
    --to=biju.das@bp.renesas.com \
    --cc=Chris.Paterson2@renesas.com \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@bootlin.com \
    --cc=fabrizio.castro@bp.renesas.com \
    --cc=geert+renesas@glider.be \
    --cc=geert@linux-m68k.org \
    --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).