All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Esteban Blanc <eblanc@baylibre.com>
Cc: linus.walleij@linaro.org, lgirdwood@gmail.com,
	broonie@kernel.org, a.zummo@towertech.it,
	linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
	linux-rtc@vger.kernel.org, jpanis@baylibre.com,
	jneanne@baylibre.com
Subject: Re: [PATCH INTERNAL v1 1/3] rtc: tps6594: add driver for TPS6594 PMIC RTC
Date: Mon, 13 Mar 2023 12:01:58 +0100	[thread overview]
Message-ID: <20230313110158f5c27b63@mail.local> (raw)
In-Reply-To: <CR556BV2M4I4.2L3LLJ8V1I352@burritosblues>

On 13/03/2023 10:18:45+0100, Esteban Blanc wrote:
> On Tue Mar 7, 2023 at 12:08 PM CET, Alexandre Belloni wrote:
> > On 24/02/2023 14:31:27+0100, Esteban Blanc wrote:
> > > +struct tps6594_rtc {
> > > +   struct rtc_device *rtc;
> > > +};
> >
> > Is the struct actually useful?
> 
> Good catch, it's not. I will remove it for V2.
> 
> (...)
> 
> > > +/*
> > > + * Gets current tps6594 RTC time and date parameters.
> > > + *
> > > + * The RTC's time/alarm representation is not what gmtime(3) requires
> > > + * Linux to use:
> > > + *
> > > + *  - Months are 1..12 vs Linux 0-11
> > > + *  - Years are 0..99 vs Linux 1900..N (we assume 21st century)
> > > + */
> >
> > I don't find this comment to be particularly useful.
> 
> Ok. I propose that I add 2 constants for the -1 and +100 in the month and year
> calculation. This way, without the comment the computation would be a
> bit more self explanatory.
> What do you think?

I don't think this is necessary, keep -1 for the month and +100 for the
year, those are very common operations in the subsystem and don't really
need any explanation

> 
> (...)
> 
> > > +static int tps6594_rtc_probe(struct platform_device *pdev)
> > > +{
> > > +   struct tps6594 *tps6594;
> > > +   struct tps6594_rtc *tps_rtc;
> > > +   int irq;
> > > +   int ret;
> > > +
> > > +   tps6594 = dev_get_drvdata(pdev->dev.parent);
> > > +
> > > +   tps_rtc = devm_kzalloc(&pdev->dev, sizeof(struct tps6594_rtc),
> > > +                          GFP_KERNEL);
> > > +   if (!tps_rtc)
> > > +           return -ENOMEM;
> > > +
> > > +   tps_rtc->rtc = devm_rtc_allocate_device(&pdev->dev);
> > > +   if (IS_ERR(tps_rtc->rtc))
> > > +           return PTR_ERR(tps_rtc->rtc);
> > > +
> > > +   /* Enable crystal oscillator */
> > > +   ret = regmap_set_bits(tps6594->regmap, TPS6594_REG_RTC_CTRL_2,
> > > +                         TPS6594_BIT_XTAL_EN);
> > > +   if (ret < 0)
> > > +           return ret;
> > > +
> > > +   /* Start rtc */
> > > +   ret = regmap_set_bits(tps6594->regmap, TPS6594_REG_RTC_CTRL_1,
> > > +                         TPS6594_BIT_STOP_RTC);
> > > +   if (ret < 0)
> > > +           return ret;
> >
> > Do that (XTAL_EN and clearing STOP) only once the time is known to be
> > set to a correct value so read_time doesn't have a chance to return a
> > bogus value.
> >
> 
> (...)
> 
> I understand your point, however I'm not sure of the canonical way to do
> this. Simply calling `tps6594_rtc_set_time` is enough?

Yeah, let userspace set the time and start the rtc at that point.


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

  reply	other threads:[~2023-03-13 11:02 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-24 13:31 [PATCH v1 0/3] TI TPS6594 PMIC support (RTC, pinctrl, regulators, device trees) Esteban Blanc
2023-02-24 13:31 ` [PATCH INTERNAL v1 1/3] rtc: tps6594: add driver for TPS6594 PMIC RTC Esteban Blanc
2023-03-07 11:08   ` Alexandre Belloni
2023-03-13  9:18     ` Esteban Blanc
2023-03-13 11:01       ` Alexandre Belloni [this message]
2023-03-13 12:10         ` Esteban Blanc
2023-03-13 13:38           ` Alexandre Belloni
2023-02-24 13:31 ` [PATCH INTERNAL v1 2/3] pinctrl: tps6594: add for TPS6594 PMIC Esteban Blanc
2023-02-24 18:49   ` kernel test robot
2023-02-25 20:36   ` kernel test robot
2023-03-06 14:10   ` Linus Walleij
2023-03-14 17:30     ` Esteban Blanc
2023-02-24 13:31 ` [PATCH INTERNAL v1 3/3] regulator: tps6594-regulator: Add driver for TI TPS6594 regulators Esteban Blanc
2023-02-24 13:42   ` Mark Brown
2023-03-03 15:02     ` jerome Neanne
2023-03-23  9:12     ` jerome Neanne
2023-03-23 11:38       ` Mark Brown
2023-03-24  8:00         ` jerome Neanne
2023-02-24 14:05   ` Matti Vaittinen
2023-03-03 14:49     ` jerome Neanne
2023-02-24 22:06   ` kernel test robot
2023-03-22  9:10   ` Julien Panis
2023-03-22 13:13     ` Mark Brown
2023-03-22 13:40       ` Julien Panis

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=20230313110158f5c27b63@mail.local \
    --to=alexandre.belloni@bootlin.com \
    --cc=a.zummo@towertech.it \
    --cc=broonie@kernel.org \
    --cc=eblanc@baylibre.com \
    --cc=jneanne@baylibre.com \
    --cc=jpanis@baylibre.com \
    --cc=lgirdwood@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rtc@vger.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.