All of lore.kernel.org
 help / color / mirror / Atom feed
From: Saravana Kannan <saravanak@google.com>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Android Kernel Team <kernel-team@android.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Paul Cercueil <paul@crapouillou.net>
Subject: Re: [PATCH v1] clocksource: Avoid creating dead devices
Date: Mon, 16 Mar 2020 11:15:45 -0700	[thread overview]
Message-ID: <CAGETcx-UAjWhtDMoTaLX-2HwXWq-3aAi9FcwszEJ1-YKcekqmQ@mail.gmail.com> (raw)
In-Reply-To: <73509a5b-7bb2-fae5-9bd1-cb809a5b67e8@linaro.org>

On Mon, Mar 16, 2020 at 11:07 AM Daniel Lezcano
<daniel.lezcano@linaro.org> wrote:
>
> On 16/03/2020 18:49, Saravana Kannan wrote:
> > On Mon, Mar 16, 2020 at 7:57 AM Daniel Lezcano
> > <daniel.lezcano@linaro.org> wrote:
> >>
> >> On 08/03/2020 06:53, Saravana Kannan wrote:
> >>> On Wed, Mar 4, 2020 at 11:56 AM Daniel Lezcano
> >>> <daniel.lezcano@linaro.org> wrote:
> >>>>
> >>>> On 04/03/2020 20:30, Saravana Kannan wrote:
> >>>>> On Thu, Feb 27, 2020 at 1:22 PM Saravana Kannan <saravanak@google.com> wrote:
> >>>>>>
> >>>>>> On Thu, Feb 27, 2020 at 1:06 AM Daniel Lezcano
> >>>>>> <daniel.lezcano@linaro.org> wrote:
> >>>>>>>
> >>>>>>> On 11/01/2020 06:21, Saravana Kannan wrote:
> >>>>>>>> Timer initialization is done during early boot way before the driver
> >>>>>>>> core starts processing devices and drivers. Timers initialized during
> >>>>>>>> this early boot period don't really need or use a struct device.
> >>>>>>>>
> >>>>>>>> However, for timers represented as device tree nodes, the struct devices
> >>>>>>>> are still created and sit around unused and wasting memory. This change
> >>>>>>>> avoid this by marking the device tree nodes as "populated" if the
> >>>>>>>> corresponding timer is successfully initialized.
> >>>>
> >>>> TBH, I'm missing the rational with the explanation and the code. Can you
> >>>> elaborate or rephrase it?
> >>>
> >>> Ok, let me start from the top.
> >>>
> >>> When the kernel boots, timer_probe() is called (via time_init()) way
> >>> before any of the initcalls are called in do_initcalls().
> >>>
> >>> In systems with CONFIG_OF, of_platform_default_populate_init() gets
> >>> called at arch_initcall_sync() level.
> >>> of_platform_default_populate_init() is what kicks off creating
> >>> platform devices from device nodes in DT. However, if the struct
> >>> device_node that corresponds to a device node in DT has OF_POPULATED
> >>> flag set, a platform device is NOT created for it (because it's
> >>> considered already "populated"/taken care of).
> >>>
> >>> When a timer driver registers using TIMER_OF_DECLARE(), the driver's
> >>> init code is called from timer_probe() on the struct device_node that
> >>> corresponds to the timer device node. At this point the timer is
> >>> already "probed". If you don't mark this device node with
> >>> OF_POPULATED, at arch_initcall_sync() it's going to have a pointless
> >>> struct platform_device created that's just using up memory and
> >>> pointless.
> >>>
> >>> So my patch sets the OF_POPULATED flag for all timer device_node's
> >>> that are successfully probed from timer_probe().
> >>>
> >>> If a timer driver doesn't use TIMER_OF_DECLARE() and just registers as
> >>> a platform device, the driver init function won't be called from
> >>> timer_probe() and it's corresponding devices won't have OF_POPULATED
> >>> set in their device_node. So platform_devices will be created for them
> >>> and they'll probe as normal platform devices. This is why my change
> >>> doesn't break drivers/clocksource/ingenic-timer.c.
> >>>
> >>> Btw, this is no different from what irqchip does with IRQCHIP_DECLARE.
> >>>
> >>> Hope that clears it up.
> >>
> >> Yes, thanks for the explanation.
> >>
> >> Why not just set the OF_POPULATED if the probe succeeds?
> >>
> >> Like:
> >>
> >> diff --git a/drivers/clocksource/timer-probe.c
> >> b/drivers/clocksource/timer-probe.c
> >> index ee9574da53c0..f290639ff824 100644
> >> --- a/drivers/clocksource/timer-probe.c
> >> +++ b/drivers/clocksource/timer-probe.c
> >> @@ -35,6 +35,7 @@ void __init timer_probe(void)
> >>                         continue;
> >>                 }
> >>
> >> +               of_node_set_flag(np, OF_POPULATED);
> >>                 timers++;
> >>         }
> >>
> >> instead of setting the flag and clearing it in case of failure?
> >
> > Looking at IRQ framework which first did it the way you suggested and
> > then changed it to the way I did it, it looks like it allows for
> > drivers that need to split the initialization between early init (not
> > just error out, but init partly) and later driver probe. See [1].
> >
> > Also, most of the other frameworks that set OF_POPULATED, set it
> > before calling the initialization function for the device. Maybe it's
> > to make sure the device node data "looks the same" whether a device is
> > initialized during early init or during normal device probe (since the
> > OF_POPULATED is set before the probe is called) -- i.e. have
> > OF_POPULATED  set before the device initialization code is actually
> > run?
> >
> > Honestly I don't have a strong opinion either way, but I lean towards
> > following what IRQ does.
>
> Thanks for the pointer. Indeed it is to catch situation where the driver
> is clearing the flag like:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clocksource/ingenic-timer.c#n245
>
> But I'm not able to figure out why it is cleared here :/

I think I know what's going on. He wants to implement PM support for
this timer. But PM support is tied to devices. So, clearing out the
flag allows creating the device which then hooks into PM ops.

Although, it looks like the driver assumes the timer framework was
setting the OF_POPULATED flag.

-Saravana

>
> Paul?
>
>
> --
>  <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>

  reply	other threads:[~2020-03-16 18:16 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-11  5:21 [PATCH v1] clocksource: Avoid creating dead devices Saravana Kannan
2020-02-19  2:20 ` Saravana Kannan
2020-02-27  9:06 ` Daniel Lezcano
2020-02-27 21:22   ` Saravana Kannan
2020-03-04 19:30     ` Saravana Kannan
2020-03-04 19:56       ` Daniel Lezcano
2020-03-08  5:53         ` Saravana Kannan
2020-03-16 14:57           ` Daniel Lezcano
2020-03-16 17:49             ` Saravana Kannan
2020-03-16 18:07               ` Daniel Lezcano
2020-03-16 18:15                 ` Saravana Kannan [this message]
     [not found]                   ` <5e70b653.1c69fb81.b03d8.d2bbSMTPIN_ADDED_MISSING@mx.google.com>
2020-03-17 18:08                     ` Saravana Kannan
2020-03-17 18:18                       ` Daniel Lezcano
2020-03-19  8:47 ` [tip: timers/core] clocksource/drivers/timer-probe: " tip-bot2 for Saravana Kannan
2020-03-24 17:59   ` Ionela Voinescu
2020-03-24 18:34     ` Saravana Kannan
2020-03-24 19:56       ` Saravana Kannan
2020-03-25 21:47         ` Thomas Gleixner
2020-03-25 22:56           ` Saravana Kannan
2020-03-25 23:06             ` Saravana Kannan
2020-03-26 10:17             ` Daniel Lezcano
2020-03-26 17:35               ` Saravana Kannan
2020-03-26 10:33             ` Thomas Gleixner
2020-03-26 15:02               ` Rob Herring
2020-03-26 18:08                 ` Saravana Kannan
2020-03-28  2:23                   ` Rob Herring
     [not found]     ` <20200324175955.GA16972-5wv7dgnIgG8@public.gmane.org>
2020-03-25 21:29       ` Jon Hunter
2020-03-25 21:29         ` Jon Hunter
     [not found]         ` <e75ae529-264c-9aa6-f711-2afe28ceec36-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2020-03-26  1:21           ` Dmitry Osipenko
2020-03-26  1:21             ` Dmitry Osipenko
2020-03-28 10:30     ` [tip: timers/core] Revert "clocksource/drivers/timer-probe: Avoid creating dead devices" tip-bot2 for Thomas Gleixner

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=CAGETcx-UAjWhtDMoTaLX-2HwXWq-3aAi9FcwszEJ1-YKcekqmQ@mail.gmail.com \
    --to=saravanak@google.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul@crapouillou.net \
    --cc=tglx@linutronix.de \
    /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.