Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4349823imm; Mon, 14 May 2018 06:23:39 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqtB3Bgfe6vMTJJFH0xMBa30HA9tdzMv1BmZZrIpIy8hjEwXKHoIOwoVI6NZCFM8mury6Hk X-Received: by 2002:a62:cc08:: with SMTP id a8-v6mr10433689pfg.219.1526304219900; Mon, 14 May 2018 06:23:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526304219; cv=none; d=google.com; s=arc-20160816; b=upoOXyYqam81x6AcJqRlx8lYVdLtYwidjOKp+PI9/XuUp+sP/Qnz0Jyloxezh+kgZe 4sUm7K0IB5azdGwYFwFlMP4cYzqrwA+K+miPlK90ajttSBowoeefBru1jHi3sYZAtZQr JQJzZiO8U+8qHDZdwp1YRerEnidItDygaFVKASWgkBOiQ71PAVfphG3Q8gEeBXNazm15 AcFB1rb7VI85vJACxMPh/bM05b1ip8Ajt6lYWca82AJ0iLRbw7tUANijOO19LPkupdy9 S7uDxa7lRMvmw7wJD0rzgo9o7KkATPtxutqjw2E/oLUaONvve5QLmCiU+sbHIOypVoA+ JDGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=6TvuCjgVBNUhK8wboHZe++crdKKEcU1Fr/2DpmJYhfU=; b=0yTF1ckLnI/dTCq32EGSsoneDqQyApifqN67G15sAYTkX30YHF60Ii4veTtBM7JusF vECwMY+qRKUQosdLPVMgYZexSb+JmjGwiyS/Ds5fyoGVGhDOxvZHFdI3C78sWNA+GznE DtvImCAu/UhF5ByvEXRDTzuzSjoxkL3qAEtUEoVh4C1SNVtc+zOXz8w0nd/wiV9m+mOt qyJL5+TJyfYnoGUk4QRFYLdIVGe8EuT8+JUpL69z7xeAl3nmG6EeKjDLd/ifnrOeXv5Y YuJAGiiCBugCqacHMs8qTAf6VoWKCn8hXKKyszOR+0A2ksJfId+sBg8/9xiPIKE45ffV yzmQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=vMeIBCgK; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v4-v6si9212586pff.281.2018.05.14.06.23.25; Mon, 14 May 2018 06:23:39 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=vMeIBCgK; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753804AbeENNVW (ORCPT + 99 others); Mon, 14 May 2018 09:21:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:44626 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752463AbeENNVT (ORCPT ); Mon, 14 May 2018 09:21:19 -0400 Received: from mail-qt0-f174.google.com (mail-qt0-f174.google.com [209.85.216.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F364221747; Mon, 14 May 2018 13:21:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1526304079; bh=6TvuCjgVBNUhK8wboHZe++crdKKEcU1Fr/2DpmJYhfU=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=vMeIBCgK6u0qDiokN9Lbfa7PVI8QD/soeBfbQjqR4Irwe6GMTE20/38KuXFqF9Bbk gv3OOYeBO6Nh4rkOpAXRXemB2/g6IIFxIHyWGzH1oPRxyk7TR0G8KnS2g3PnmnmF0g p7s4+N5YF8p5LfaV/3LLqPCmxFU1Httj8R4tvEtg= Received: by mail-qt0-f174.google.com with SMTP id d3-v6so15981470qtp.11; Mon, 14 May 2018 06:21:18 -0700 (PDT) X-Gm-Message-State: ALKqPwfOiqJkHgtaNwQHz7gNuI/pOMRpUkYJ/X3RxrSujQY1Yu1LwZIc 3QBzetnLJU/9/MwxvgCigjou64oLl7vxpP/mvA== X-Received: by 2002:a0c:85e6:: with SMTP id o93-v6mr8783606qva.27.1526304077954; Mon, 14 May 2018 06:21:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.155.2 with HTTP; Mon, 14 May 2018 06:20:57 -0700 (PDT) In-Reply-To: References: <20180511162028.20616-1-brgl@bgdev.pl> From: Rob Herring Date: Mon, 14 May 2018 08:20:57 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 00/12] introduce support for early platform drivers To: Bartosz Golaszewski Cc: Sekhar Nori , Kevin Hilman , David Lechner , Michael Turquette , Stephen Boyd , Arnd Bergmann , Greg Kroah-Hartman , Mark Rutland , Yoshinori Sato , Rich Felker , Andy Shevchenko , Marc Zyngier , "Rafael J . Wysocki" , Peter Rosin , Jiri Slaby , Thomas Gleixner , Daniel Lezcano , Geert Uytterhoeven , Magnus Damm , Johan Hovold , Frank Rowand , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , "linux-kernel@vger.kernel.org" , devicetree , "open list:GENERIC INCLUDE/ASM HEADER FILES" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 14, 2018 at 6:38 AM, Bartosz Golaszewski wrote: > 2018-05-11 22:13 GMT+02:00 Rob Herring : >> On Fri, May 11, 2018 at 11:20 AM, Bartosz Golaszewski wrote: >>> This series is a follow-up to the RFC[1] posted a couple days ago. >>> >>> NOTE: this series applies on top of my recent patches[2] that move the previous >>> implementation of early platform devices to arch/sh. >>> >>> Problem: >>> >>> Certain class of devices, such as timers, certain clock drivers and irq chip >>> drivers need to be probed early in the boot sequence. The currently preferred >>> approach is using one of the OF_DECLARE() macros. This however does not create >>> a platform device which has many drawbacks - such as not being able to use >>> devres routines, dev_ log functions or no way of deferring the init OF function >>> if some other resources are missing. >> >> I skimmed though this and it doesn't look horrible (how's that for >> positive feedback? ;) ). But before going into the details, I think >> first there needs to be agreement this is the right direction. >> >> The question does remain though as to whether this class of devices >> should be platform drivers. They can't be modules. They can't be >> hotplugged. Can they be runtime-pm enabled? So the advantage is ... >> > > The main (but not the only) advantage for drivers that can both be > platform drivers and OF_DECLARE drivers is that we get a single entry > point and can reuse code without resorting to checking if (!dev). It > results in more consistent code base. Another big advantage is > consolidation of device tree and machine code for SoC drivers used in > different boards of which some are still using board files and others > are defined in DT (see: DaVinci). > >> I assume that the clock maintainers had some reason to move clocks to >> be platform drivers. It's just not clear to me what that was. >> >>> For drivers that use both platform drivers and OF_DECLARE the situation is even >>> more complicated as the code needs to take into account that there can possibly >>> be no struct device present. For a specific use case that we're having problems >>> with, please refer to the recent DaVinci common-clock conversion patches and >>> the nasty workaround that this problem implies[3]. >> >> So devm_kzalloc will work with this solution? Why did we need >> devm_kzalloc in the first place? The clocks can never be removed and >> cleaning up on error paths is kind of pointless. The system would be >> hosed, right? >> > > It depends - not all clocks are necessary for system to boot. That doesn't matter. You have a single driver for all/most of the clocks, so the driver can't be removed. >>> We also used to have an early platform drivers implementation but they were not >>> integrated with the linux device model at all - they merely used the same data >>> structures. The users could not use devres, defer probe and the early devices >>> never became actual platform devices later on. >>> >>> Proposed solution: >>> >>> This series aims at solving this problem by (re-)introducing the concept of >>> early platform drivers and devices - this time however in a way that seamlessly >>> integrates with the existing platform drivers and also offers device-tree >>> support. >>> >>> The idea is to provide a way for users to probe devices early, while already >>> being able to use devres, devices resources and properties and also deferred >>> probing. >>> >>> New structures are introduced: the early platform driver contains the >>> early_probe callback which has the same signature as regular platform_device >>> probe. This callback is called early on. The user can have both the early and >>> regular probe speficied or only one of them and they both receive the same >>> platform device object as argument. Any device data allocated early will be >>> carried over to the normal probe. >>> >>> The architecture code is responsible for calling early_platform_start() in >>> which the early drivers will be registered and devices populated from DT. >> >> Can we really do this in one spot for different devices (clk, timers, >> irq). The sequence is all very carefully crafted. Platform specific >> hooks is another thing to consider. >> > > This is why I added support for early probe deferral - so that we can > stop caring for the order as long as the drivers are aware of other > resources they need and we call early_platform_start() the moment the > earliest of the early devices is needed. Deferred probe helps for inter-device dependencies, but I am more concerned about timing of trying to register clocksources, irqchips, etc. What happens if we probe drivers before the infrastructure is initialized? Rob