From: Alexandre Belloni <alexandre.belloni@free-electrons.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: linux-kernel-dev@beckhoff.com, "Shawn Guo" <shawnguo@kernel.org>,
"Sascha Hauer" <kernel@pengutronix.de>,
"Alessandro Zummo" <a.zummo@towertech.it>,
"Mark Rutland" <mark.rutland@arm.com>,
"open list:REAL TIME CLOCK (RTC) SUBSYSTEM"
<linux-rtc@vger.kernel.org>,
"Patrick Bruenn" <p.bruenn@beckhoff.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
"Juergen Borleis" <jbe@pengutronix.de>,
"open list" <linux-kernel@vger.kernel.org>,
"Russell King" <linux@armlinux.org.uk>,
"Noel Vellemans" <Noel.Vellemans@visionbms.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Philippe Ombredanne" <pombredanne@nexb.com>,
"Fabio Estevam" <fabio.estevam@nxp.com>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>,
"Lothar Waßmann" <LW@KARO-electronics.de>
Subject: Re: [PATCH v2 5/5] rtc: add mxc driver for i.MX53 SRTC
Date: Wed, 6 Dec 2017 09:58:25 +0100 [thread overview]
Message-ID: <20171206085825.GM21780@piout.net> (raw)
In-Reply-To: <20171206083618.eea63zqmpgaaazwl@pengutronix.de>
On 06/12/2017 at 09:36:18 +0100, Sascha Hauer wrote:
> > +/*
> > + * This function updates the RTC alarm registers and then clears all the
> > + * interrupt status bits.
> > + * The caller should hold the pdata->lock
> > + *
> > + * @param alrm the new alarm value to be updated in the RTC
> > + *
> > + * @return 0 if successful; non-zero otherwise.
> > + */
> > +static int mxc_rtc_write_alarm_locked(struct mxc_rtc_data *const pdata,
> > + struct rtc_time *alarm_tm)
> > +{
> > + void __iomem *const ioaddr = pdata->ioaddr;
> > + unsigned long time;
> > +
> > + rtc_tm_to_time(alarm_tm, &time);
> > +
> > + if (time > U32_MAX) {
> > + pr_err("Hopefully I am out of service by then :-(\n");
> > + return -EINVAL;
> > + }
>
> This will never happen as on your target hardware unsigned long is a
> 32bit type. Not sure what is best to do here. Maybe you should test
> the return value of rtc_tm_to_time. ATM it returns 0 unconditionally,
> but rtc_tm_to_time could detect when the input time doesn't fit into
> its return type and return an error in this case.
> Also I just realized that it's unsigned and only overflows in the year
> 2106. I'm most likely dead then so I don't care that much ;)
>
One solution is to use the 64bit version instead so it doesn't overflow.
This makes the time > U32_MAX work.
Also, I'll send (hopefully soon) a series adding proper range checking
for the whole RTC subsystem. And yes, it not urgent as I don't think I
will care so much in 2106 too ;)
> > +/*
> > + * This function reads the current RTC time into tm in Gregorian date.
> > + *
> > + * @param tm contains the RTC time value upon return
> > + *
> > + * @return 0 if successful; non-zero otherwise.
> > + */
> > +static int mxc_rtc_read_time(struct device *dev, struct rtc_time *tm)
> > +{
> > + struct mxc_rtc_data *pdata = dev_get_drvdata(dev);
> > + time_t now;
> > + int ret = mxc_rtc_lock(pdata);
> > +
> > + if (ret)
> > + return ret;
> > +
> > + now = readl(pdata->ioaddr + SRTC_LPSCMR);
> > + rtc_time_to_tm(now, tm);
> > + ret = rtc_valid_tm(tm);
This check is useless for two reasons: you know that rtc_time_to_tm will
generate a valid tm and the core always checks the tm anyway.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
WARNING: multiple messages have this Message-ID (diff)
From: alexandre.belloni@free-electrons.com (Alexandre Belloni)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 5/5] rtc: add mxc driver for i.MX53 SRTC
Date: Wed, 6 Dec 2017 09:58:25 +0100 [thread overview]
Message-ID: <20171206085825.GM21780@piout.net> (raw)
In-Reply-To: <20171206083618.eea63zqmpgaaazwl@pengutronix.de>
On 06/12/2017 at 09:36:18 +0100, Sascha Hauer wrote:
> > +/*
> > + * This function updates the RTC alarm registers and then clears all the
> > + * interrupt status bits.
> > + * The caller should hold the pdata->lock
> > + *
> > + * @param alrm the new alarm value to be updated in the RTC
> > + *
> > + * @return 0 if successful; non-zero otherwise.
> > + */
> > +static int mxc_rtc_write_alarm_locked(struct mxc_rtc_data *const pdata,
> > + struct rtc_time *alarm_tm)
> > +{
> > + void __iomem *const ioaddr = pdata->ioaddr;
> > + unsigned long time;
> > +
> > + rtc_tm_to_time(alarm_tm, &time);
> > +
> > + if (time > U32_MAX) {
> > + pr_err("Hopefully I am out of service by then :-(\n");
> > + return -EINVAL;
> > + }
>
> This will never happen as on your target hardware unsigned long is a
> 32bit type. Not sure what is best to do here. Maybe you should test
> the return value of rtc_tm_to_time. ATM it returns 0 unconditionally,
> but rtc_tm_to_time could detect when the input time doesn't fit into
> its return type and return an error in this case.
> Also I just realized that it's unsigned and only overflows in the year
> 2106. I'm most likely dead then so I don't care that much ;)
>
One solution is to use the 64bit version instead so it doesn't overflow.
This makes the time > U32_MAX work.
Also, I'll send (hopefully soon) a series adding proper range checking
for the whole RTC subsystem. And yes, it not urgent as I don't think I
will care so much in 2106 too ;)
> > +/*
> > + * This function reads the current RTC time into tm in Gregorian date.
> > + *
> > + * @param tm contains the RTC time value upon return
> > + *
> > + * @return 0 if successful; non-zero otherwise.
> > + */
> > +static int mxc_rtc_read_time(struct device *dev, struct rtc_time *tm)
> > +{
> > + struct mxc_rtc_data *pdata = dev_get_drvdata(dev);
> > + time_t now;
> > + int ret = mxc_rtc_lock(pdata);
> > +
> > + if (ret)
> > + return ret;
> > +
> > + now = readl(pdata->ioaddr + SRTC_LPSCMR);
> > + rtc_time_to_tm(now, tm);
> > + ret = rtc_valid_tm(tm);
This check is useless for two reasons: you know that rtc_time_to_tm will
generate a valid tm and the core always checks the tm anyway.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
WARNING: multiple messages have this Message-ID (diff)
From: Alexandre Belloni <alexandre.belloni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
To: Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: linux-kernel-dev-QonKdJ6Bx35Wk0Htik3J/w@public.gmane.org,
Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Sascha Hauer <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
Alessandro Zummo
<a.zummo-BfzFCNDTiLLj+vYz1yj4TQ@public.gmane.org>,
Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
"open list:REAL TIME CLOCK (RTC) SUBSYSTEM"
<linux-rtc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Patrick Bruenn <p.bruenn-QonKdJ6Bx35Wk0Htik3J/w@public.gmane.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Juergen Borleis <jbe-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
open list <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Russell King <linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>,
Noel Vellemans
<Noel.Vellemans-8UENEgx6w+makBO8gow8eQ@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Philippe Ombredanne <pombredanne-od1rfyK75/E@public.gmane.org>,
Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH v2 5/5] rtc: add mxc driver for i.MX53 SRTC
Date: Wed, 6 Dec 2017 09:58:25 +0100 [thread overview]
Message-ID: <20171206085825.GM21780@piout.net> (raw)
In-Reply-To: <20171206083618.eea63zqmpgaaazwl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 06/12/2017 at 09:36:18 +0100, Sascha Hauer wrote:
> > +/*
> > + * This function updates the RTC alarm registers and then clears all the
> > + * interrupt status bits.
> > + * The caller should hold the pdata->lock
> > + *
> > + * @param alrm the new alarm value to be updated in the RTC
> > + *
> > + * @return 0 if successful; non-zero otherwise.
> > + */
> > +static int mxc_rtc_write_alarm_locked(struct mxc_rtc_data *const pdata,
> > + struct rtc_time *alarm_tm)
> > +{
> > + void __iomem *const ioaddr = pdata->ioaddr;
> > + unsigned long time;
> > +
> > + rtc_tm_to_time(alarm_tm, &time);
> > +
> > + if (time > U32_MAX) {
> > + pr_err("Hopefully I am out of service by then :-(\n");
> > + return -EINVAL;
> > + }
>
> This will never happen as on your target hardware unsigned long is a
> 32bit type. Not sure what is best to do here. Maybe you should test
> the return value of rtc_tm_to_time. ATM it returns 0 unconditionally,
> but rtc_tm_to_time could detect when the input time doesn't fit into
> its return type and return an error in this case.
> Also I just realized that it's unsigned and only overflows in the year
> 2106. I'm most likely dead then so I don't care that much ;)
>
One solution is to use the 64bit version instead so it doesn't overflow.
This makes the time > U32_MAX work.
Also, I'll send (hopefully soon) a series adding proper range checking
for the whole RTC subsystem. And yes, it not urgent as I don't think I
will care so much in 2106 too ;)
> > +/*
> > + * This function reads the current RTC time into tm in Gregorian date.
> > + *
> > + * @param tm contains the RTC time value upon return
> > + *
> > + * @return 0 if successful; non-zero otherwise.
> > + */
> > +static int mxc_rtc_read_time(struct device *dev, struct rtc_time *tm)
> > +{
> > + struct mxc_rtc_data *pdata = dev_get_drvdata(dev);
> > + time_t now;
> > + int ret = mxc_rtc_lock(pdata);
> > +
> > + if (ret)
> > + return ret;
> > +
> > + now = readl(pdata->ioaddr + SRTC_LPSCMR);
> > + rtc_time_to_tm(now, tm);
> > + ret = rtc_valid_tm(tm);
This check is useless for two reasons: you know that rtc_time_to_tm will
generate a valid tm and the core always checks the tm anyway.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-12-06 8:58 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-05 14:06 [PATCH v2 0/5] add mxc driver for i.MX53 SRTC linux-kernel-dev
2017-12-05 14:06 ` linux-kernel-dev at beckhoff.com
2017-12-05 14:06 ` [PATCH v2 1/5] dt-bindings: rtc: add bindings " linux-kernel-dev
2017-12-05 14:06 ` linux-kernel-dev at beckhoff.com
2017-12-06 21:54 ` Rob Herring
2017-12-06 21:54 ` Rob Herring
2017-12-06 21:54 ` Rob Herring
2017-12-11 7:08 ` Patrick Brünn
2017-12-11 7:08 ` Patrick Brünn
2017-12-11 7:08 ` Patrick Brünn
2017-12-11 23:08 ` Fabio Estevam
2017-12-11 23:08 ` Fabio Estevam
2017-12-11 23:08 ` Fabio Estevam
2017-12-11 23:08 ` Fabio Estevam
2017-12-12 5:05 ` Patrick Brünn
2017-12-12 5:05 ` Patrick Brünn
2017-12-12 5:05 ` Patrick Brünn
2017-12-12 5:05 ` Patrick Brünn
2017-12-15 21:58 ` Rob Herring
2017-12-15 21:58 ` Rob Herring
2017-12-15 21:58 ` Rob Herring
2017-12-05 14:06 ` [PATCH v2 2/5] ARM: dts: imx53: add srtc node linux-kernel-dev
2017-12-05 14:06 ` linux-kernel-dev at beckhoff.com
2017-12-05 14:13 ` Fabio Estevam
2017-12-05 14:13 ` Fabio Estevam
2017-12-05 14:13 ` Fabio Estevam
2017-12-05 14:20 ` Patrick Brünn
2017-12-05 14:20 ` Patrick Brünn
2017-12-05 14:20 ` Patrick Brünn
2017-12-05 14:20 ` Patrick Brünn
2017-12-10 19:03 ` Fabio Estevam
2017-12-10 19:03 ` Fabio Estevam
2017-12-10 19:03 ` Fabio Estevam
2017-12-10 19:03 ` Fabio Estevam
2017-12-05 14:06 ` [PATCH v2 3/5] rtc: mxc_v2: add driver for i.MX53 SRTC linux-kernel-dev
2017-12-05 14:06 ` linux-kernel-dev-QonKdJ6Bx35Wk0Htik3J/w
2017-12-05 14:06 ` linux-kernel-dev at beckhoff.com
2017-12-05 14:12 ` Fabio Estevam
2017-12-05 14:12 ` Fabio Estevam
2017-12-05 14:12 ` Fabio Estevam
2017-12-05 14:06 ` [PATCH v2 4/5] ARM: imx_v4_v5_defconfig: enable RTC_DRV_MXC_V2 linux-kernel-dev
2017-12-05 14:06 ` linux-kernel-dev-QonKdJ6Bx35Wk0Htik3J/w
2017-12-05 14:06 ` linux-kernel-dev at beckhoff.com
2017-12-05 14:10 ` Fabio Estevam
2017-12-05 14:10 ` Fabio Estevam
2017-12-05 14:10 ` Fabio Estevam
2017-12-05 14:06 ` [PATCH v2 5/5] rtc: add mxc driver for i.MX53 SRTC linux-kernel-dev
2017-12-05 14:06 ` linux-kernel-dev at beckhoff.com
2017-12-06 8:36 ` Sascha Hauer
2017-12-06 8:36 ` Sascha Hauer
2017-12-06 8:36 ` Sascha Hauer
2017-12-06 8:58 ` Alexandre Belloni [this message]
2017-12-06 8:58 ` Alexandre Belloni
2017-12-06 8:58 ` Alexandre Belloni
2017-12-06 9:28 ` Patrick Brünn
2017-12-06 9:28 ` Patrick Brünn
2017-12-06 9:28 ` Patrick Brünn
2017-12-06 10:17 ` Patrick Brünn
2017-12-06 10:17 ` Patrick Brünn
2017-12-06 10:17 ` Patrick Brünn
2017-12-06 14:40 ` Sascha Hauer
2017-12-06 14:40 ` Sascha Hauer
2017-12-06 14:40 ` Sascha Hauer
2017-12-06 11:05 ` Alexandre Belloni
2017-12-06 11:05 ` Alexandre Belloni
2017-12-06 11:05 ` Alexandre Belloni
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=20171206085825.GM21780@piout.net \
--to=alexandre.belloni@free-electrons.com \
--cc=LW@KARO-electronics.de \
--cc=Noel.Vellemans@visionbms.com \
--cc=a.zummo@towertech.it \
--cc=devicetree@vger.kernel.org \
--cc=fabio.estevam@nxp.com \
--cc=jbe@pengutronix.de \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel-dev@beckhoff.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rtc@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--cc=p.bruenn@beckhoff.com \
--cc=pombredanne@nexb.com \
--cc=robh+dt@kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.