[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACRpkdY+MfDHGw4QrFy=A64y7dSrno26vuKbt_AnFbVm9y_hoQ@mail.gmail.com>
Date: Tue, 28 Jun 2022 15:41:30 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: sascha hauer <sha@...gutronix.de>
Cc: Saravana Kannan <saravanak@...gle.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Frank Rowand <frowand.list@...il.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Daniel Scally <djrscally@...il.com>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
Len Brown <lenb@...nel.org>, peng fan <peng.fan@....com>,
kevin hilman <khilman@...nel.org>,
ulf hansson <ulf.hansson@...aro.org>,
len brown <len.brown@...el.com>, pavel machek <pavel@....cz>,
joerg roedel <joro@...tes.org>, will deacon <will@...nel.org>,
andrew lunn <andrew@...n.ch>,
heiner kallweit <hkallweit1@...il.com>,
russell king <linux@...linux.org.uk>,
"david s. miller" <davem@...emloft.net>,
eric dumazet <edumazet@...gle.com>,
jakub kicinski <kuba@...nel.org>,
paolo abeni <pabeni@...hat.com>,
hideaki yoshifuji <yoshfuji@...ux-ipv6.org>,
david ahern <dsahern@...nel.org>, kernel-team@...roid.com,
linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
iommu@...ts.linux-foundation.org, netdev@...r.kernel.org,
linux-gpio@...r.kernel.org, kernel@...gutronix.de,
devicetree@...r.kernel.org, linux-acpi@...r.kernel.org
Subject: Re: [PATCH v2 2/2] of: base: Avoid console probe delay when fw_devlink.strict=1
On Thu, Jun 23, 2022 at 12:05 PM sascha hauer <sha@...gutronix.de> 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
Powered by blists - more mailing lists