On Fri, Apr 27, 2018 at 6:05 PM, Bartosz Golaszewski
<bgolaszewski@xxxxxxxxxxxx> wrote:
> 2018-04-27 16:48 GMT+02:00 Arnd Bergmann <arnd@xxxxxxxx>:
>> On Fri, Apr 27, 2018 at 4:05 PM, Bartosz Golaszewski
>
> So speaking in pseudo-C we basically have two ways for an imaginary
> future timer driver:
>
> int foo_probe(struct platform_device *pdev)
> {
> struct clk *clk;
>
> if (probing_early(pdev)) {
> clk = devm_clk_get(dev, "earlyclock");
>
> /* Do early stuff. */
> return 0;
> }
>
> /* Do late stuff. */
>
> return 0;
> }
>
> --- vs ---
>
> int foo_probe(struct platform_device *pdev)
> {
> /* Do late stuff. */
>
> return 0;
> }
>
> static int foo_init(struct device_node *np)
> {
> struct clk *clk;
> struct device *dev = device_from_device_node(np);
>
> /* Do early stuff. */
> clk = devm_clk_get(dev, "earlyclock");
>
> return 0;
> }
>
> TIMER_OF_DECLARE(foo, "bar,foo", foo_init);
>
> I still believe the first approach is easier to implement and has the
> added benefit of supporting board files.
Right. I still like the second approach better, since it avoids
multiplexing two very different code paths into a single
function, and because it's closer to what everyone is used
to at the moment.
Prototyping both is probably helpful to get a better idea
of the actual complexity this introduces.
> I'll give it a thought and will be back at it next week.
Ok. I'll be on vacation for three weeks so I wont' be able
to reply on the new patches.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
