Re: [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers

On Wed, Oct 30, 2019 at 8:54 AM Will Deacon wrote: > > Hi Robin, > > On Wed, Oct 30, 2019 at 03:35:55PM +, Robin Murphy wrote: > > On 30/10/2019 14:51, Will Deacon wrote: > > > As part of the work to enable a "Generic Kernel Image" across multiple > > > Android devices, there is a need to sepe

Re: [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers

On Thu, Oct 31, 2019 at 12:38 PM Jean-Philippe Brucker wrote: > > Hi Saravana, Will, > > On Wed, Oct 30, 2019 at 05:57:44PM -0700, Saravana Kannan via iommu wrote: > > > > > Obviously you need to be careful about using IOMMU drivers as modules, > > > > &g

Re: [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers

On Fri, Nov 1, 2019 at 3:28 AM John Garry wrote: > > On 31/10/2019 23:34, Saravana Kannan via iommu wrote: > > I looked into the iommu-map property and it shouldn't be too hard to > > add support for it. Looks like we can simply hold off on probing the > > root brid

Re: [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers

On Fri, Nov 1, 2019 at 5:28 AM Lorenzo Pieralisi wrote: > > On Fri, Nov 01, 2019 at 12:41:48PM +0100, Jean-Philippe Brucker wrote: > > [...] > > > > > I'm also wondering about ACPI support. > > > > > > I'd love to add ACPI support too, but I have zero knowledge of ACPI. > > > I'd be happy to help

Re: [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers

On Mon, Nov 4, 2019 at 3:43 AM Lorenzo Pieralisi wrote: > > On Fri, Nov 01, 2019 at 02:26:05PM -0700, Saravana Kannan wrote: > > On Fri, Nov 1, 2019 at 5:28 AM Lorenzo Pieralisi > > wrote: > > > > > > On Fri, Nov 01, 2019 at 12:41:48PM +0100, Jean-Philippe Brucker wrote: > > > > > > [...] > > > >

Re: [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers

On Mon, Nov 4, 2019 at 4:16 AM John Garry wrote: > > On 01/11/2019 21:13, Saravana Kannan wrote: > > On Fri, Nov 1, 2019 at 3:28 AM John Garry wrote: > >> > >> On 31/10/2019 23:34, Saravana Kannan via iommu wrote: > >>> I looked into the iommu-ma

Re: [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers

On Mon, Nov 4, 2019 at 5:29 AM Robin Murphy wrote: > > On 04/11/2019 12:16, John Garry wrote: > > On 01/11/2019 21:13, Saravana Kannan wrote: > >> On Fri, Nov 1, 2019 at 3:28 AM John Garry wrote: > >>> > >>> On 31/10/2019 23:34, Saravana Kannan via io

Re: [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers

On Wed, Oct 30, 2019 at 5:57 PM Saravana Kannan wrote: > > On Wed, Oct 30, 2019 at 8:54 AM Will Deacon wrote: > > > > Hi Robin, > > > > On Wed, Oct 30, 2019 at 03:35:55PM +, Robin Murphy wrote: > > > On 30/10/2019 14:51, Will Deacon wrote: > > > > As part of the work to enable a "Generic Kern

Re: [PATCH] of: property: Add device link support for "iommu-map"

On Wed, Nov 20, 2019 at 11:00 AM Will Deacon wrote: > > Commit 8e12257dead7 ("of: property: Add device link support for iommus, > mboxes and io-channels") added device link support for IOMMU linkages > described using the "iommus" property. For PCI devices, this property > is not present and inste

Re: [PATCH v3 09/14] iommu/arm-smmu: Prevent forced unbinding of Arm SMMU drivers

On Tue, Nov 26, 2019 at 1:13 AM John Garry wrote: > > On 21/11/2019 11:49, Will Deacon wrote: > > Forcefully unbinding the Arm SMMU drivers is a pretty dangerous operation, > > since it will likely lead to catastrophic failure for any DMA devices > > mastering through the SMMU being unbound. When

Re: [RFC 0/2] iommu: arm-smmu: Add support for early direct mappings

Hi Thierry, I happened upon this thread while looking into another thread [1]. > From: Thierry Reding > > On some platforms, the firmware will setup hardware to read from a given > region of memory. One such example is a display controller that is > scanning out a splash screen from physical me

Re: [RFC 0/2] iommu: arm-smmu: Add support for early direct mappings

I added everyone from the other thread, but somehow managed to miss the Bjorn who sent the emails! Fixing that now. On Mon, Jan 13, 2020 at 6:07 AM Thierry Reding wrote: > > On Fri, Jan 10, 2020 at 08:56:39PM -0800, Saravana Kannan wrote: > > Hi Thierry, > > > > I happened upon this thread while

Re: [PATCH v2 5/7] driver core: Add device location to "struct device" and expose it in sysfs

On Mon, Jun 29, 2020 at 9:49 PM Rajat Jain wrote: > > Add a new (optional) field to denote the physical location of a device > in the system, and expose it in sysfs. This was discussed here: > https://lore.kernel.org/linux-acpi/20200618184621.ga446...@kroah.com/ > > (The primary choice for attribu

[PATCH v1] driver core: Extend deferred probe timeout on driver registration

The deferred probe timer that's used for this currently starts at late_initcall and runs for driver_deferred_probe_timeout seconds. The assumption being that all available drivers would be loaded and registered before the timer expires. This means, the driver_deferred_probe_timeout has to be pretty

Re: [PATCH v1] driver core: Extend deferred probe timeout on driver registration

On Fri, May 13, 2022 at 6:58 AM Rob Herring wrote: > > On Fri, Apr 29, 2022 at 5:09 PM Saravana Kannan wrote: > > > > The deferred probe timer that's used for this currently starts at > > late_initcall and runs for driver_deferred_probe_timeout seconds. The > > assumption being that all available

Re: [PATCH v1] driver core: Extend deferred probe timeout on driver registration

On Fri, May 20, 2022 at 4:30 PM Nathan Chancellor wrote: > > Hi Saravana, > > On Fri, Apr 29, 2022 at 03:09:32PM -0700, Saravana Kannan wrote: > > The deferred probe timer that's used for this currently starts at > > late_initcall and runs for driver_deferred_probe_timeout seconds. The > > assumpt

Re: [PATCH v1] driver core: Extend deferred probe timeout on driver registration

On Fri, May 20, 2022 at 5:04 PM Nathan Chancellor wrote: > > On Fri, May 20, 2022 at 04:49:48PM -0700, Saravana Kannan wrote: > > On Fri, May 20, 2022 at 4:30 PM Nathan Chancellor wrote: > > > > > > Hi Saravana, > > > > > > On Fri, Apr 29, 2022 at 03:09:32PM -0700, Saravana Kannan wrote: > > > >

Re: [PATCH v1] driver core: Extend deferred probe timeout on driver registration

On Mon, May 23, 2022 at 8:17 AM Nathan Chancellor wrote: > > On Fri, May 20, 2022 at 05:15:55PM -0700, Saravana Kannan wrote: > > On Fri, May 20, 2022 at 5:04 PM Nathan Chancellor wrote: > > > > > > On Fri, May 20, 2022 at 04:49:48PM -0700, Saravana Kannan wrote: > > > > On Fri, May 20, 2022 at 4

Re: [PATCH v1] driver core: Extend deferred probe timeout on driver registration

On Mon, May 23, 2022 at 3:14 PM Nathan Chancellor wrote: > > On Mon, May 23, 2022 at 01:04:03PM -0700, Saravana Kannan wrote: > > On Mon, May 23, 2022 at 8:17 AM Nathan Chancellor wrote: > > > > > > On Fri, May 20, 2022 at 05:15:55PM -0700, Saravana Kannan wrote: > > > > On Fri, May 20, 2022 at 5

Re: [PATCH v1] driver core: Extend deferred probe timeout on driver registration

On Tue, May 24, 2022 at 9:41 AM Sebastian Andrzej Siewior wrote: > > On 2022-05-23 20:43:06 [-0700], Saravana Kannan wrote: > … > > Thanks for all the help. I think I know what's going on. > > I, too got here because my boot recently was extended by 10 seconds and > bisected to that commit in ques

Re: [PATCH v1] driver core: Extend deferred probe timeout on driver registration

On Wed, May 25, 2022 at 12:12 AM Sebastian Andrzej Siewior wrote: > > On 2022-05-24 10:46:49 [-0700], Saravana Kannan wrote: > > > Removing probe_timeout_waitqueue (as suggested) or setting the timeout > > > to 0 avoids the delay. > > > > In your case, I think it might be working as intended? Curi

[RFC PATCH v1 0/9] deferred_probe_timeout logic clean up

This series is based on linux-next + these 2 small patches applies on top: https://lore.kernel.org/lkml/20220526034609.480766-1-sarava...@google.com/ A lot of the deferred_probe_timeout logic is redundant with fw_devlink=on. Also, enabling deferred_probe_timeout by default breaks a few cases. Th

[RFC PATCH v1 2/9] pinctrl: devicetree: Delete usage of driver_deferred_probe_check_state()

Now that fw_devlink=on by default and fw_devlink supports "pinctrl-[0-8]" property, the execution will never get to the point where driver_deferred_probe_check_state() is called before the supplier has probed successfully or before deferred probe timeout has expired. So, delete the call and replac

[RFC PATCH v1 4/9] Revert "driver core: Set default deferred_probe_timeout back to 0."

This reverts commit 11f7e7ef553b6b93ac1aa74a3c2011b9cc8aeb61. Let's take another shot at getting deferred_probe_timeout=10 to work. Signed-off-by: Saravana Kannan --- drivers/base/dd.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/base/dd.c b/drivers/base/dd.c index 11b0fb641

[RFC PATCH v1 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

Now that fw_devlink=on by default and fw_devlink supports "power-domains" property, the execution will never get to the point where driver_deferred_probe_check_state() is called before the supplier has probed successfully or before deferred probe timeout has expired. So, delete the call and replac

[RFC PATCH v1 3/9] net: mdio: Delete usage of driver_deferred_probe_check_state()

Now that fw_devlink=on by default and fw_devlink supports interrupt properties, the execution will never get to the point where driver_deferred_probe_check_state() is called before the supplier has probed successfully or before deferred probe timeout has expired. So, delete the call and replace it

[RFC PATCH v1 5/9] driver core: Set fw_devlink.strict=1 by default

Now that deferred_probe_timeout is non-zero by default, fw_devlink will never permanently block the probing of devices. It'll try its best to probe the devices in the right order and then finally let devices probe even if their suppliers don't have any drivers. Signed-off-by: Saravana Kannan ---

[RFC PATCH v1 6/9] iommu/of: Delete usage of driver_deferred_probe_check_state()

Now that fw_devlink=on and fw_devlink.strict=1 by default and fw_devlink supports iommu DT properties, the execution will never get to the point where driver_deferred_probe_check_state() is called before the supplier has probed successfully or before deferred probe timeout has expired. So, delete

[RFC PATCH v1 7/9] driver core: Add fw_devlink_unblock_may_probe() helper function

This function can be used during the kernel boot sequence to forcefully override fw_devlink=on and unblock the probing of all devices that have a driver. It's mainly meant to be called from late_initcall() or late_initcall_sync() where a device needs to probe before the kernel can mount rootfs. S

[RFC PATCH v1 8/9] net: ipconfig: Force fw_devlink to unblock any devices that might probe

If there are network devices that could probe without some of their suppliers probing and those network devices are needed for IP auto config to work, then fw_devlink=on might break that usecase by blocking the network devices from probing by the time IP auto config starts. So, when IP auto config

[RFC PATCH v1 9/9] driver core: Delete driver_deferred_probe_check_state()

The function is no longer used. So delete it. Signed-off-by: Saravana Kannan --- drivers/base/dd.c | 30 -- include/linux/device/driver.h | 1 - 2 files changed, 31 deletions(-) diff --git a/drivers/base/dd.c b/drivers/base/dd.c index af8138d44e6c..789b0

Re: [PATCH v1] driver core: Extend deferred probe timeout on driver registration

On Sun, May 29, 2022 at 1:34 AM 'Niklas Cassel' via kernel-team wrote: > > On Wed, May 25, 2022 at 12:49:00PM -0700, Saravana Kannan wrote: > > On Wed, May 25, 2022 at 12:12 AM Sebastian Andrzej Siewior > > wrote: > > > > > > On 2022-05-24 10:46:49 [-0700], Saravana Kannan wrote: > > > > > Removi

[PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

Now that fw_devlink=on by default and fw_devlink supports "power-domains" property, the execution will never get to the point where driver_deferred_probe_check_state() is called before the supplier has probed successfully or before deferred probe timeout has expired. So, delete the call and replac

[PATCH v2 2/9] pinctrl: devicetree: Delete usage of driver_deferred_probe_check_state()

Now that fw_devlink=on by default and fw_devlink supports "pinctrl-[0-8]" property, the execution will never get to the point where driver_deferred_probe_check_state() is called before the supplier has probed successfully or before deferred probe timeout has expired. So, delete the call and replac

[PATCH v2 0/9] deferred_probe_timeout logic clean up

This series is based on linux-next + these 2 small patches applies on top: https://lore.kernel.org/lkml/20220526034609.480766-1-sarava...@google.com/ A lot of the deferred_probe_timeout logic is redundant with fw_devlink=on. Also, enabling deferred_probe_timeout by default breaks a few cases. Th

[PATCH v2 3/9] net: mdio: Delete usage of driver_deferred_probe_check_state()

Now that fw_devlink=on by default and fw_devlink supports interrupt properties, the execution will never get to the point where driver_deferred_probe_check_state() is called before the supplier has probed successfully or before deferred probe timeout has expired. So, delete the call and replace it

[PATCH v2 4/9] driver core: Add wait_for_init_devices_probe helper function

Some devices might need to be probed and bound successfully before the kernel boot sequence can finish and move on to init/userspace. For example, a network interface might need to be bound to be able to mount a NFS rootfs. With fw_devlink=on by default, some of these devices might be blocked from

[PATCH v2 5/9] net: ipconfig: Relax fw_devlink if we need to mount a network rootfs

If there are network devices that could probe without some of their suppliers probing and those network devices are needed to mount a network rootfs, then fw_devlink=on might break that usecase by blocking the network devices from probing by the time IP auto config starts. So, if no network device

[PATCH v2 6/9] Revert "driver core: Set default deferred_probe_timeout back to 0."

This reverts commit 11f7e7ef553b6b93ac1aa74a3c2011b9cc8aeb61. Let's take another shot at getting deferred_probe_timeout=10 to work. Signed-off-by: Saravana Kannan --- drivers/base/dd.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/base/dd.c b/drivers/base/dd.c index 4a55fbb7e

[PATCH v2 7/9] driver core: Set fw_devlink.strict=1 by default

Now that deferred_probe_timeout is non-zero by default, fw_devlink will never permanently block the probing of devices. It'll try its best to probe the devices in the right order and then finally let devices probe even if their suppliers don't have any drivers. Signed-off-by: Saravana Kannan ---

[PATCH v2 8/9] iommu/of: Delete usage of driver_deferred_probe_check_state()

Now that fw_devlink=on and fw_devlink.strict=1 by default and fw_devlink supports iommu DT properties, the execution will never get to the point where driver_deferred_probe_check_state() is called before the supplier has probed successfully or before deferred probe timeout has expired. So, delete

[PATCH v2 9/9] driver core: Delete driver_deferred_probe_check_state()

The function is no longer used. So delete it. Signed-off-by: Saravana Kannan --- drivers/base/dd.c | 30 -- include/linux/device/driver.h | 1 - 2 files changed, 31 deletions(-) diff --git a/drivers/base/dd.c b/drivers/base/dd.c index 335e71d3a618..e600d

Re: [RFC PATCH v1 4/9] Revert "driver core: Set default deferred_probe_timeout back to 0."

On Mon, May 30, 2022 at 2:13 AM Geert Uytterhoeven wrote: > > Hi Saravana, > > On Thu, May 26, 2022 at 10:16 AM Saravana Kannan wrote: > > This reverts commit 11f7e7ef553b6b93ac1aa74a3c2011b9cc8aeb61. > > scripts/chdeckpatch.pl says: > > WARNING: Unknown commit id > '11f7e7ef553b6b93ac1aa74a3

Re: [RFC PATCH v1 2/9] pinctrl: devicetree: Delete usage of driver_deferred_probe_check_state()

On Mon, May 30, 2022 at 2:22 AM Geert Uytterhoeven wrote: > > Hi Saravana, > > Thanks for your patch! > > On Thu, May 26, 2022 at 10:16 AM Saravana Kannan wrote: > > Now that fw_devlink=on by default and fw_devlink supports > > "pinctrl-[0-8]" property, the execution will never get to the point >

Re: [RFC PATCH v1 0/9] deferred_probe_timeout logic clean up

On Mon, May 30, 2022 at 1:49 AM Sebastian Andrzej Siewior wrote: > > On 2022-05-26 01:15:39 [-0700], Saravana Kannan wrote: > > Yoshihiro/Geert, > Hi Saravana, > > > If you can test this patch series and confirm that the NFS root case > > works, I'd really appreciate that. > > The two patches you

Re: [RFC PATCH v1 0/9] deferred_probe_timeout logic clean up

On Mon, May 30, 2022 at 2:38 AM Geert Uytterhoeven wrote: > > Hi Saravana, > > On Thu, May 26, 2022 at 10:15 AM Saravana Kannan wrote: > > This series is based on linux-next + these 2 small patches applies on top: > > https://lore.kernel.org/lkml/20220526034609.480766-1-sarava...@google.com/ > >

Re: [RFC PATCH v1 4/9] Revert "driver core: Set default deferred_probe_timeout back to 0."

On Sat, Jun 4, 2022 at 8:18 PM Saravana Kannan wrote: > > On Mon, May 30, 2022 at 2:13 AM Geert Uytterhoeven > wrote: > > > > Hi Saravana, > > > > On Thu, May 26, 2022 at 10:16 AM Saravana Kannan > > wrote: > > > This reverts commit 11f7e7ef553b6b93ac1aa74a3c2011b9cc8aeb61. > > > > scripts/chd

Re: [PATCH v2 0/9] deferred_probe_timeout logic clean up

-Hideaki -- their email keeps bouncing. On Tue, Jun 7, 2022 at 11:13 AM Geert Uytterhoeven wrote: > > Hi Saravana, > > On Wed, Jun 1, 2022 at 12:46 PM Saravana Kannan wrote: > > This series is based on linux-next + these 2 small patches applies on top: > > https://lore.kernel.org/lkml/2022052603

Re: [PATCH v2 0/9] deferred_probe_timeout logic clean up

On Tue, Jun 7, 2022 at 5:55 PM Saravana Kannan wrote: > > -Hideaki -- their email keeps bouncing. > > On Tue, Jun 7, 2022 at 11:13 AM Geert Uytterhoeven > wrote: > > > > Hi Saravana, > > > > On Wed, Jun 1, 2022 at 12:46 PM Saravana Kannan > > wrote: > > > This series is based on linux-next + t

Re: [PATCH v2 0/9] deferred_probe_timeout logic clean up

On Wed, Jun 8, 2022 at 3:26 AM Geert Uytterhoeven wrote: > > Hi Saravana, > > On Wed, Jun 8, 2022 at 6:17 AM Saravana Kannan wrote: > > On Tue, Jun 7, 2022 at 5:55 PM Saravana Kannan wrote: > > > On Tue, Jun 7, 2022 at 11:13 AM Geert Uytterhoeven > > > wrote: > > > > On Wed, Jun 1, 2022 at 12:

Re: [PATCH v2 0/9] deferred_probe_timeout logic clean up

On Wed, Jun 8, 2022 at 11:54 AM Geert Uytterhoeven wrote: > > Hi Saravana, > > On Wed, Jun 8, 2022 at 8:13 PM Saravana Kannan wrote: > > On Wed, Jun 8, 2022 at 3:26 AM Geert Uytterhoeven > > wrote: > > > On Wed, Jun 8, 2022 at 6:17 AM Saravana Kannan > > > wrote: > > > > On Tue, Jun 7, 2022 a

Re: [PATCH v2 0/9] deferred_probe_timeout logic clean up

On Wed, Jun 8, 2022 at 3:49 PM Jakub Kicinski wrote: > > On Wed, 8 Jun 2022 14:07:44 -0700 Saravana Kannan wrote: > > David/Jakub, > > > > Do the IP4 autoconfig changes look reasonable to you? > > I'm no expert in this area, I'd trust the opinion of the embedded folks > (adding Florian as well) mo

Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

On Thu, Jun 9, 2022 at 4:45 AM Ulf Hansson wrote: > > On Wed, 1 Jun 2022 at 09:07, Saravana Kannan wrote: > > > > Now that fw_devlink=on by default and fw_devlink supports > > "power-domains" property, the execution will never get to the point > > where driver_deferred_probe_check_state() is call

Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

On Tue, Jun 21, 2022 at 12:28 AM Tony Lindgren wrote: > > Hi, > > * Saravana Kannan [700101 02:00]: > > Now that fw_devlink=on by default and fw_devlink supports > > "power-domains" property, the execution will never get to the point > > where driver_deferred_probe_check_state() is called before

Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

On Tue, Jun 21, 2022 at 9:59 PM Tony Lindgren wrote: > > Hi, > > * Saravana Kannan [220621 19:29]: > > On Tue, Jun 21, 2022 at 12:28 AM Tony Lindgren wrote: > > > > > > Hi, > > > > > > * Saravana Kannan [700101 02:00]: > > > > Now that fw_devlink=on by default and fw_devlink supports > > > > "p

Re: [PATCH v2 7/9] driver core: Set fw_devlink.strict=1 by default

On Wed, Jun 22, 2022 at 1:44 AM Linus Walleij wrote: > > On Wed, Jun 22, 2022 at 9:48 AM Sascha Hauer wrote: > > > This patch has the effect that console UART devices which have "dmas" > > properties specified in the device tree get deferred for 10 to 20 > > seconds. This happens on i.MX and like

Re: [PATCH v2 7/9] driver core: Set fw_devlink.strict=1 by default

On Wed, Jun 22, 2022 at 12:40 PM Saravana Kannan wrote: > > On Wed, Jun 22, 2022 at 1:44 AM Linus Walleij > wrote: > > > > On Wed, Jun 22, 2022 at 9:48 AM Sascha Hauer wrote: > > > > > This patch has the effect that console UART devices which have "dmas" > > > properties specified in the device

[PATCH v1 1/2] driver core: fw_devlink: Allow firmware to mark devices as best effort

When firmware sets the FWNODE_FLAG_BEST_EFFORT flag for a fwnode, fw_devlink will do a best effort ordering for that device where it'll only enforce the probe/suspend/resume ordering of that device with suppliers that have drivers. The driver of that device can then decide if it wants to defer prob

[PATCH v1 0/2] Fix console probe delay due to fw_devlink

fw_devlink.strict=1 has been enabled by default. This was delaying the probe of console devices. This series fixes that. Sasha/Peng, Can you test this please? -Saravana Cc: Sascha Hauer Cc: Peng Fan Cc: Kevin Hilman Cc: Ulf Hansson Cc: Len Brown Cc: Pavel Machek Cc: Joerg Roedel Cc: Will

[PATCH v1 2/2] of: base: Avoid console probe delay when fw_devlink.strict=1

Commit 71066545b48e ("driver core: Set fw_devlink.strict=1 by default") enabled iommus and dmas dependency enforcement by default. On some systems, this caused the console device's probe to get delayed until the deferred_probe_timeout expires. We need consoles to work as soon as possible, so mark

Re: [PATCH v2 7/9] driver core: Set fw_devlink.strict=1 by default

On Wed, Jun 22, 2022 at 1:35 PM Saravana Kannan wrote: > > On Wed, Jun 22, 2022 at 12:40 PM Saravana Kannan wrote: > > > > On Wed, Jun 22, 2022 at 1:44 AM Linus Walleij > > wrote: > > > > > > On Wed, Jun 22, 2022 at 9:48 AM Sascha Hauer wrote: > > > > > > > This patch has the effect that conso

Re: [PATCH v1 0/2] Fix console probe delay due to fw_devlink

On Wed, Jun 22, 2022 at 3:32 PM Peng Fan wrote: > > > Subject: [PATCH v1 0/2] Fix console probe delay due to fw_devlink > > > > fw_devlink.strict=1 has been enabled by default. This was delaying the probe > > of console devices. This series fixes that. > > > > Sasha/Peng, > > > > Can you test this

Re: [PATCH v1 1/2] driver core: fw_devlink: Allow firmware to mark devices as best effort

On Wed, Jun 22, 2022 at 11:50 PM Sascha Hauer wrote: > > On Wed, Jun 22, 2022 at 02:59:10PM -0700, Saravana Kannan wrote: > > When firmware sets the FWNODE_FLAG_BEST_EFFORT flag for a fwnode, > > fw_devlink will do a best effort ordering for that device where it'll > > only enforce the probe/suspe

[PATCH v2 0/2] Fix console probe delay due to fw_devlink

fw_devlink.strict=1 has been enabled by default. This was delaying the probe of console devices. This series fixes that. v1->v2: - Added missing NULL check - Added Tested-by tags -Saravana cc: sascha hauer cc: peng fan cc: kevin hilman cc: ulf hansson cc: len brown cc: pavel machek cc: joe

[PATCH v2 1/2] driver core: fw_devlink: Allow firmware to mark devices as best effort

When firmware sets the FWNODE_FLAG_BEST_EFFORT flag for a fwnode, fw_devlink will do a best effort ordering for that device where it'll only enforce the probe/suspend/resume ordering of that device with suppliers that have drivers. The driver of that device can then decide if it wants to defer prob

[PATCH v2 2/2] of: base: Avoid console probe delay when fw_devlink.strict=1

Commit 71066545b48e ("driver core: Set fw_devlink.strict=1 by default") enabled iommus and dmas dependency enforcement by default. On some systems, this caused the console device's probe to get delayed until the deferred_probe_timeout expires. We need consoles to work as soon as possible, so mark

Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

On Thu, Jun 23, 2022 at 12:01 AM Tony Lindgren wrote: > > * Saravana Kannan [220622 19:05]: > > On Tue, Jun 21, 2022 at 9:59 PM Tony Lindgren wrote: > > > > > > Hi, > > > > > > * Saravana Kannan [220621 19:29]: > > > > On Tue, Jun 21, 2022 at 12:28 AM Tony Lindgren wrote: > > > > > > > > > > H

Re: [PATCH v2 2/2] of: base: Avoid console probe delay when fw_devlink.strict=1

On Thu, Jun 23, 2022 at 3:05 AM sascha hauer wrote: > > On Thu, Jun 23, 2022 at 01:03:43AM -0700, Saravana Kannan wrote: > > Commit 71066545b48e ("driver core: Set fw_devlink.strict=1 by default") > > enabled iommus and dmas dependency enforcement by default. On some > > systems, this caused the c

Re: [PATCH v2 2/2] of: base: Avoid console probe delay when fw_devlink.strict=1

On Thu, Jun 23, 2022 at 9:39 AM Andy Shevchenko wrote: > > On Thu, Jun 23, 2022 at 12:04:21PM +0200, sascha hauer wrote: > > On Thu, Jun 23, 2022 at 01:03:43AM -0700, Saravana Kannan wrote: > > ... > > > I wonder if it wouldn't be a better approach to just probe all devices > > and record the devi

Re: [PATCH v2 2/2] of: base: Avoid console probe delay when fw_devlink.strict=1

On Thu, Jun 23, 2022 at 10:36 AM Ahmad Fatoum wrote: > > Hello Saravana, > > On 23.06.22 19:26, Saravana Kannan wrote: > > On Thu, Jun 23, 2022 at 3:05 AM sascha hauer wrote: > >> > >> On Thu, Jun 23, 2022 at 01:03:43AM -0700, Saravana Kannan wrote: > >>> Commit 71066545b48e ("driver core: Set fw

Re: [PATCH v2 2/2] of: base: Avoid console probe delay when fw_devlink.strict=1

On Thu, Jun 23, 2022 at 1:37 PM sascha hauer wrote: > > On Thu, Jun 23, 2022 at 10:26:46AM -0700, Saravana Kannan wrote: > > On Thu, Jun 23, 2022 at 3:05 AM sascha hauer wrote: > > > > > > On Thu, Jun 23, 2022 at 01:03:43AM -0700, Saravana Kannan wrote: > > > > Commit 71066545b48e ("driver core:

Re: [PATCH v2 2/2] of: base: Avoid console probe delay when fw_devlink.strict=1

On Mon, Jun 27, 2022 at 10:50 AM Rob Herring wrote: > > On Thu, Jun 23, 2022 at 12:04:21PM +0200, sascha hauer wrote: > > On Thu, Jun 23, 2022 at 01:03:43AM -0700, Saravana Kannan wrote: > > > Commit 71066545b48e ("driver core: Set fw_devlink.strict=1 by default") > > > enabled iommus and dmas dep

[PATCH v1 0/2] Fix console probe delay when stdout-path isn't set

Since the series that fixes console probe delay based on stdout-path[1] got pulled into driver-core-next, I made these patches on top of them. Even if stdout-path isn't set in DT, this patch should take console probe times back to how they were before the deferred_probe_timeout clean up series[2].

[PATCH v1 1/2] driver core: Add probe_no_timeout flag for drivers

This flag only needs to be set for drivers of devices that meet all the following conditions: - Need to probe successfully before userspace init in started - Have optional suppliers - Can't wait for deferred_probe_timeout to expire fw_devlink=on uses this info, as needed, to ignore dependencies on

[PATCH v1 2/2] serial: Set probe_no_timeout for all DT based drivers

With commit 71066545b48e ("driver core: Set fw_devlink.strict=1 by default") the probing of TTY consoles could get delayed if they have optional suppliers that are listed in DT, but those suppliers don't probe by the time kernel boot finishes. The console devices will probe eventually after driver_

Re: [PATCH v1 2/2] serial: Set probe_no_timeout for all DT based drivers

On Tue, Jun 28, 2022 at 7:00 AM Tobias Klauser wrote: > > On 2022-06-28 at 04:01:03 +0200, Saravana Kannan wrote: > > diff --git a/drivers/tty/serial/8250/8250_acorn.c > > b/drivers/tty/serial/8250/8250_acorn.c > > index 758c4aa203ab..5a6f2f67de4f 100644 > > --- a/drivers/tty/serial/8250/8250_ac

Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

On Mon, Jun 27, 2022 at 2:10 AM Tony Lindgren wrote: > > * Saravana Kannan [220623 08:17]: > > On Thu, Jun 23, 2022 at 12:01 AM Tony Lindgren wrote: > > > > > > * Saravana Kannan [220622 19:05]: > > > > On Tue, Jun 21, 2022 at 9:59 PM Tony Lindgren wrote: > > > > > This issue is no directly re

Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

On Thu, Jun 30, 2022 at 4:26 PM Rob Herring wrote: > > On Thu, Jun 30, 2022 at 5:11 PM Saravana Kannan wrote: > > > > On Mon, Jun 27, 2022 at 2:10 AM Tony Lindgren wrote: > > > > > > * Saravana Kannan [220623 08:17]: > > > > On Thu, Jun 23, 2022 at 12:01 AM Tony Lindgren wrote: > > > > > > > >

Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

On Thu, Jun 23, 2022 at 5:08 AM Alexander Stein wrote: > > Hi, > > Am Dienstag, 21. Juni 2022, 09:28:43 CEST schrieb Tony Lindgren: > > Hi, > > > > * Saravana Kannan [700101 02:00]: > > > Now that fw_devlink=on by default and fw_devlink supports > > > "power-domains" property, the execution will

[PATCH v2 0/2] Fix console probe delay when stdout-path isn't set

These patches are on top of driver-core-next. Even if stdout-path isn't set in DT, this patch should take console probe times back to how they were before the deferred_probe_timeout clean up series[1]. v1->v2: - Fixed the accidental change that Tobias pointed out. - Added Tested-by tag [1] - ht

[PATCH v2 1/2] driver core: Add probe_no_timeout flag for drivers

This flag only needs to be set for drivers of devices that meet all the following conditions: - Need to probe successfully before userspace init in started - Have optional suppliers - Can't wait for deferred_probe_timeout to expire fw_devlink=on uses this info, as needed, to ignore dependencies on

[PATCH v2 2/2] serial: Set probe_no_timeout for all DT based drivers

With commit 71066545b48e ("driver core: Set fw_devlink.strict=1 by default") the probing of TTY consoles could get delayed if they have optional suppliers that are listed in DT, but those suppliers don't probe by the time kernel boot finishes. The console devices will probe eventually after driver_

Re: (EXT) Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

On Thu, Jun 30, 2022 at 11:02 PM Alexander Stein wrote: > > Hi Saravana, > > Am Freitag, 1. Juli 2022, 02:37:14 CEST schrieb Saravana Kannan: > > On Thu, Jun 23, 2022 at 5:08 AM Alexander Stein > > > > wrote: > > > Hi, > > > > > > Am Dienstag, 21. Juni 2022, 09:28:43 CEST schrieb Tony Lindgren: >

Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

On Thu, Jun 30, 2022 at 11:12 PM Tony Lindgren wrote: > > * Tony Lindgren [220701 08:33]: > > * Saravana Kannan [220630 23:25]: > > > On Thu, Jun 30, 2022 at 4:26 PM Rob Herring wrote: > > > > > > > > On Thu, Jun 30, 2022 at 5:11 PM Saravana Kannan > > > > wrote: > > > > > > > > > > On Mon, J

Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

On Fri, Jul 1, 2022 at 1:10 AM Saravana Kannan wrote: > > On Thu, Jun 30, 2022 at 11:12 PM Tony Lindgren wrote: > > > > * Tony Lindgren [220701 08:33]: > > > * Saravana Kannan [220630 23:25]: > > > > On Thu, Jun 30, 2022 at 4:26 PM Rob Herring wrote: > > > > > > > > > > On Thu, Jun 30, 2022 at

Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

On Fri, Jul 1, 2022 at 8:08 AM Sudeep Holla wrote: > > Hi, Saravana, > > On Fri, Jul 01, 2022 at 01:26:12AM -0700, Saravana Kannan wrote: > > [...] > > > Can you check if this hack helps? If so, then I can think about > > whether we can pick it up without breaking everything else. Copy-paste > > t

Re: [PATCH 4/6] iommu: Combine device strictness requests with the global default

On Mon, Jun 21, 2021 at 4:53 PM Douglas Anderson wrote: > > In the patch ("drivers: base: Add bits to struct device to control > iommu strictness") we add the ability for devices to tell us about > their IOMMU strictness requirements. Let's now take that into account > in the IOMMU layer. > > A fe

Re: [PATCH 4/6] iommu: Combine device strictness requests with the global default

On Tue, Jun 22, 2021 at 9:46 AM Doug Anderson wrote: > > Hi, > > On Mon, Jun 21, 2021 at 7:56 PM Saravana Kannan wrote: > > > > On Mon, Jun 21, 2021 at 4:53 PM Douglas Anderson > > wrote: > > > > > > In the patch ("drivers: base: Add bits to struct device to control > > > iommu strictness") we

Re: [PATCH 0/6] iommu: Enable devices to request non-strict DMA, starting with QCom SD/MMC

On Tue, Jun 22, 2021 at 1:02 PM Rob Herring wrote: > > On Tue, Jun 22, 2021 at 09:06:02AM -0700, Doug Anderson wrote: > > Hi, > > > > On Tue, Jun 22, 2021 at 4:35 AM Robin Murphy wrote: > > > > > > Hi Doug, > > > > > > On 2021-06-22 00:52, Douglas Anderson wrote: > > > > > > > > This patch attemp

Re: [PATCH] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module

On Mon, Jul 19, 2021 at 12:36 PM Bjorn Andersson wrote: > > On Mon 19 Jul 14:00 CDT 2021, John Stultz wrote: > > > On Fri, Jul 16, 2021 at 10:01 PM Bjorn Andersson > > wrote: > > > On Tue 06 Jul 23:53 CDT 2021, John Stultz wrote: > > > > Allow the qcom_scm driver to be loadable as a permenent mod

Re: [PATCH] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module

On Wed, Jul 21, 2021 at 10:24 AM John Stultz wrote: > > On Wed, Jul 21, 2021 at 4:54 AM Greg Kroah-Hartman > wrote: > > > > On Wed, Jul 07, 2021 at 04:53:20AM +, John Stultz wrote: > > > Allow the qcom_scm driver to be loadable as a permenent module. > > > > This feels like a regression, it s

Re: [PATCH] firmware: QCOM_SCM: Allow qcom_scm driver to be loadable as a permenent module

On Wed, Jul 21, 2021 at 1:23 PM Bjorn Andersson wrote: > > On Wed 21 Jul 13:00 CDT 2021, Saravana Kannan wrote: > > > On Wed, Jul 21, 2021 at 10:24 AM John Stultz wrote: > > > > > > On Wed, Jul 21, 2021 at 4:54 AM Greg Kroah-Hartman > > > wrote: > > > > > > > > On Wed, Jul 07, 2021 at 04:53:20AM

Re: (EXT) Re: (EXT) Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

On Mon, Jul 4, 2022 at 12:07 AM Alexander Stein wrote: > > Am Freitag, 1. Juli 2022, 09:02:22 CEST schrieb Saravana Kannan: > > On Thu, Jun 30, 2022 at 11:02 PM Alexander Stein > > > > wrote: > > > Hi Saravana, > > > > > > Am Freitag, 1. Juli 2022, 02:37:14 CEST schrieb Saravana Kannan: > > > > O

Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()

On Fri, Jul 1, 2022 at 12:13 PM Saravana Kannan wrote: > > On Fri, Jul 1, 2022 at 8:08 AM Sudeep Holla wrote: > > > > Hi, Saravana, > > > > On Fri, Jul 01, 2022 at 01:26:12AM -0700, Saravana Kannan wrote: > > > > [...] > > > > > Can you check if this hack helps? If so, then I can think about > >