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 16:37:13 +0100 [thread overview]
Message-ID: <CAMuHMdWRz-iutKD54vtmJxnLsb3vtm1juYDw-k1+RFCNUVsjkg@mail.gmail.com> (raw)
In-Reply-To: <OSBPR01MB21039D89E5E8852574A18893B8A90@OSBPR01MB2103.jpnprd01.prod.outlook.com>
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}().
>
> > > +{> + 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.
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
next prev parent reply other threads:[~2018-12-06 15:37 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 [this message]
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=CAMuHMdWRz-iutKD54vtmJxnLsb3vtm1juYDw-k1+RFCNUVsjkg@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).