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
> >
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:
> > > >
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
> >
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
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,
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:
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
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] -
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 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
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:
> > > > >
> >
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
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
> > ---
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
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
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
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
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:
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
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
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
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:
> > > > >
> > > > >
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
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
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:
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
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
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
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
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
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:
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
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
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
> > > >
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
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
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)
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
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
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 +
-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:
> >
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.
> >
> >
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/
> >
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
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
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
>
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
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
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
---
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
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
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
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
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
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.
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
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:
> > > > >
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
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
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.
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
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
---
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
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
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
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
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.
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?
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
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
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
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:
> > > >
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
> >
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
> > >
> > > [...]
> > >
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
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 bridge de
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,
> > >
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
94 matches
Mail list logo
