From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5AC63C43334 for ; Tue, 28 Jun 2022 13:41:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346417AbiF1Nls (ORCPT ); Tue, 28 Jun 2022 09:41:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45176 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231733AbiF1Nlp (ORCPT ); Tue, 28 Jun 2022 09:41:45 -0400 Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 94AD32A738 for ; Tue, 28 Jun 2022 06:41:43 -0700 (PDT) Received: by mail-yb1-xb2b.google.com with SMTP id r3so22290121ybr.6 for ; Tue, 28 Jun 2022 06:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l0lBZBoRWVZwKeLsg5bhh62sfkY43Fuz7vbWyvz07jo=; b=hGw9T6CarZQ/NMBim5LFKd5YTY/o2ySRURtSkju9ltnp+I2dfsm1E743dkEP7vIdI2 EF0DRNKbp1NoePxE8d03JMmSXIQyxTYmcA6StyWwY4r+YQPVJD8cCVXjq4KFryi4BOBX R1mZO/ER1L2SAM2BBGv6AMAXI5Jfk4vSpWXci5dnkjMyWFiBRxV+lukWKp040ydV0UYw pi8tg+vw420tIDHBWpl4HD2i87IuVJPBeZxJfEHlBvY0Am4KybIx85T311V7Sc3PDZDd 4o1lrjtE8IrlXi97SmhrBQzUpnLpRq4Op7bcrYUqg0s8X0We4xxPIjbi6qZfZCCR6FAX 0Wjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l0lBZBoRWVZwKeLsg5bhh62sfkY43Fuz7vbWyvz07jo=; b=1fP5YgppQexJAucuHsWF5bctCltfSgCYyOLpUuj21p9oHQSVddYvfa1Z+XuRKhP8Fx mdUvqy8PHKYJyozNTBIzuvoSXgqA95wDOyY3MCn6sur+oyIJ0PcCtTYvPCUd32GRO52B Q+CD6GuOrOX7gYSWagkHjWACxPivIjGCkoZbcat6ApudseVYNOITx9WquqOWCpGqPPNr bCmxFoNJXYsh+qAiUgVhpGliZVOMADJc21dNNpbtsTKA2n8jSuhEJ8tltqwKWAgK3Y9e nY1vEt2n0d7HOQCD8GG0Dp94Yea7oijMS5mJv1/5h/e96PgxkXSzTMM1PyDmlceuYJNN bXyw== X-Gm-Message-State: AJIora/m7mr12mfn0L1WzWK31flLnpSueLwiSeoHWDqEHlf1tFDCFqXW O3S5gS1WggODNKkJzGOpzZ1MQYO4A7+mA0DCJn3mdQ== X-Google-Smtp-Source: AGRyM1vMJc6mshbdVpv82z3JrgHLSlBVD5A4IKCtkqq06YBNSTzatN88O/XMo49PG0TuIqgDUg33Srr26PKhV2f0pQk= X-Received: by 2002:a25:1f57:0:b0:669:b6fa:167e with SMTP id f84-20020a251f57000000b00669b6fa167emr20917137ybf.295.1656423702377; Tue, 28 Jun 2022 06:41:42 -0700 (PDT) MIME-Version: 1.0 References: <20220623080344.783549-1-saravanak@google.com> <20220623080344.783549-3-saravanak@google.com> <20220623100421.GY1615@pengutronix.de> In-Reply-To: <20220623100421.GY1615@pengutronix.de> From: Linus Walleij Date: Tue, 28 Jun 2022 15:41:30 +0200 Message-ID: Subject: Re: [PATCH v2 2/2] of: base: Avoid console probe delay when fw_devlink.strict=1 To: sascha hauer Cc: Saravana Kannan , Greg Kroah-Hartman , "Rafael J. Wysocki" , Rob Herring , Frank Rowand , Andy Shevchenko , Daniel Scally , Heikki Krogerus , Sakari Ailus , Len Brown , peng fan , kevin hilman , ulf hansson , len brown , pavel machek , joerg roedel , will deacon , andrew lunn , heiner kallweit , russell king , "david s. miller" , eric dumazet , jakub kicinski , paolo abeni , hideaki yoshifuji , david ahern , kernel-team@android.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, iommu@lists.linux-foundation.org, netdev@vger.kernel.org, linux-gpio@vger.kernel.org, kernel@pengutronix.de, devicetree@vger.kernel.org, linux-acpi@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jun 23, 2022 at 12:05 PM sascha hauer wrote: > Also consider SoCs in early upstreaming phases > when the device tree is merged with "dmas" or "hwlock" properties, > but the corresponding drivers are not yet upstreamed. It's not nice > to defer probing of all these devices for a long time. Actually this drives a truck through the entire approach in a way. It is perfectly legal to have a device tree with dmas specified but leave them unused in the operating system. DT just describes what hardware is there, it does not mandate that the OS implement drivers for all of it. This approach really needs that the resolution mechanism is aware of whether: 1. a driver exist for the resource at all so it will eventually resolve 2. if that driver is compiled in or module at all (IS_ENABLED()) 3. If the resource should be grabbed early or optionally later such as dmas for console UART Only then can the mechanism work in the generic case. Yours, Linus Walleij