On Tue, Apr 6, 2021 at 8:45 PM 'Saravana Kannan' via kernel-team
wrote:
>
> Clocks can be turned on (by the hardware, bootloader, etc) upon a
> reset/boot of a hardware platform. These "boot clocks" could be clocking
> devices that are active before the kernel start
traversing the deferred_probe_pending_list.
Cc: sta...@vger.kernel.org
Fixes: 25b4e70dcce9 ("driver core: allow stopping deferred probe after init")
Signed-off-by: Saravana Kannan
Link: https://lore.kernel.org/r/20210402040342.2944858-2-sarava...@google.com
Signed-off-by: Greg Kroah-Hartman
-
On Fri, Apr 9, 2021 at 12:26 PM Rob Herring wrote:
>
> On Wed, Apr 7, 2021 at 3:45 PM Ilya Lipnitskiy
> wrote:
> >
> > On Tue, Apr 6, 2021 at 6:24 PM Saravana Kannan wrote:
> > >
> > > On Tue, Apr 6, 2021 at 6:10 PM Rob Herring wrote:
> > > &
This can be used by frameworks to set the sync_state() helper functions
for drivers that don't already have them set.
Signed-off-by: Saravana Kannan
---
include/linux/device.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index
the logic to turn off unused clocks has already run during
late_initcall_sync(). Adding sync_state() support also makes sure these
unused boot clocks are turned off once all the consumers have probed.
Signed-off-by: Saravana Kannan
---
drivers/clk/clk.c
Stephen,
We can decide later if both these patches land through clk tree or the
driver-core tree. The meat of the series is in Patch 2/2 and that commit
text gives all the details.
Saravana Kannan (2):
driver core: Add dev_set_drv_sync_state()
clk: Add support for sync_state()
drivers/clk
On Tue, Apr 6, 2021 at 6:10 PM Rob Herring wrote:
>
> On Tue, Apr 6, 2021 at 7:46 PM Saravana Kannan wrote:
> >
> > On Tue, Apr 6, 2021 at 5:34 PM Rob Herring wrote:
> > >
> > > On Tue, Apr 06, 2021 at 04:09:10PM -0700, Saravana Kannan wrote:
> &g
On Tue, Apr 6, 2021 at 5:34 PM Rob Herring wrote:
>
> On Tue, Apr 06, 2021 at 04:09:10PM -0700, Saravana Kannan wrote:
> > On Mon, Apr 5, 2021 at 3:26 PM Ilya Lipnitskiy
> > wrote:
> > >
> > > [,]nr-gpios property is used by some GPIO drivers[0] to indica
> Fixes errors such as:
> OF: /palmbus@30/gpio@600: could not find phandle
>
> Fixes: 7f00be96f125 ("of: property: Add device link support for
> interrupt-parent, dmas and -gpio(s)")
> Signed-off-by: Ilya Lipnitskiy
> Cc: Saravana Kannan
> Cc: # 5.5.x
On Tue, Apr 6, 2021 at 12:28 PM Ilya Lipnitskiy
wrote:
>
> On Tue, Apr 6, 2021 at 10:40 AM Rob Herring wrote:
> >
> > On Mon, Apr 05, 2021 at 01:18:56PM -0700, Saravana Kannan wrote:
> > > On Mon, Apr 5, 2021 at 1:10 PM Ilya Lipnitskiy
> > >
On Tue, Apr 6, 2021 at 2:11 AM Greg KH wrote:
>
> On Tue, Apr 06, 2021 at 06:19:45PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the driver-core tree got a conflict in:
> >
> > drivers/of/property.c
> >
> > between commit:
> >
> > 3915fed92365 ("of:
On Mon, Apr 5, 2021 at 3:43 PM Sebastian Reichel
wrote:
>
> Hi,
>
> On Tue, Mar 30, 2021 at 10:05:45AM -0700, Saravana Kannan wrote:
> > On Tue, Mar 30, 2021 at 2:09 AM Sebastian Reichel
> > wrote:
> > > On Mon, Mar 29, 2021 at 05:36:11PM -0700, Saravana Kan
On Mon, Apr 5, 2021 at 1:10 PM Ilya Lipnitskiy
wrote:
>
> Hi Saravana,
>
> On Mon, Apr 5, 2021 at 1:01 PM Saravana Kannan wrote:
> >
> > On Sun, Apr 4, 2021 at 8:14 PM Ilya Lipnitskiy
> > wrote:
> > >
> > > [,]nr-gpios property is used by s
+0xbc/0xf0
> plat_of_setup+0x1c/0x34
>
> Fixes: 7f00be96f125 ("of: property: Add device link support for
> interrupt-parent, dmas and -gpio(s)")
> Signed-off-by: Ilya Lipnitskiy
> Cc: Saravana Kannan
> Cc: # 5.5.x
> ---
> drivers/of/property.c | 11
fail attempts
to acquire resources from suppliers that truly don't have any driver vs
suppliers that just happen to not have probed yet.
Signed-off-by: Saravana Kannan
---
drivers/base/base.h | 1 +
drivers/base/core.c | 64 -
drivers/base/dd.c | 5
This series fixes existing bugs in deferred_probe_timeout and fixes some
interaction with fw_devlink=on.
Saravana Kannan (2):
driver core: Fix locking bug in deferred_probe_timeout_work_func()
driver core: Improve fw_devlink & deferred_probe_timeout interaction
drivers/base/base.h
...@vger.kernel.org
Fixes: 25b4e70dcce9 ("driver core: allow stopping deferred probe after init")
Signed-off-by: Saravana Kannan
---
drivers/base/dd.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 20b69b5e0e91..28ad8afd8
On Tue, Mar 30, 2021 at 12:36 PM Stephen Boyd wrote:
>
> Quoting Saravana Kannan (2021-03-30 11:50:55)
> > remote-endpoint property seems to always come in pairs where two devices
> > point to each other. So, we can't really tell from DT if there is a
> > functional probe
use the sync_state() to
figure it out.
[1] -
https://lore.kernel.org/lkml/CAGETcx9Snf23wrXqjDhJiTok9M3GcoVYDSyNYSMj9QnSRrA=c...@mail.gmail.com/#t
Fixes: ea718c699055 ("Revert "Revert "driver core: Set fw_devlink=on by
default""")
Reported-by: Stephen Boyd
Signed-of
On Tue, Mar 30, 2021 at 2:09 AM Sebastian Reichel
wrote:
>
> Hi,
>
> On Mon, Mar 29, 2021 at 05:36:11PM -0700, Saravana Kannan wrote:
> > On Mon, Mar 29, 2021 at 2:53 PM Sebastian Reichel
> > wrote:
> > > On Mon, Mar 29, 2021 at 01:03:20PM -0700, Saravana Kan
; > The above commit updated the deprecated of_clk_add_provider(),
> > but missed to update the preferred of_clk_add_hw_provider().
> > Update it now.
> >
> > Signed-off-by: Tudor Ambarus
> > Reviewed-by: Saravana Kannan
> > ---
> > drivers/clk/clk.c | 2 ++
&
On Mon, Mar 29, 2021 at 2:53 PM Sebastian Reichel
wrote:
>
> Hi,
>
> On Mon, Mar 29, 2021 at 01:03:20PM -0700, Saravana Kannan wrote:
> > On Fri, Mar 26, 2021 at 2:52 AM Sebastian Reichel
> > wrote:
> > > On Thu, Mar 25, 2021 at 06:55:52PM -0700, Saravana Kan
On Mon, Mar 29, 2021 at 2:25 PM Stephen Boyd wrote:
>
> Quoting Geert Uytterhoeven (2021-03-26 11:29:55)
> > On Fri, Mar 26, 2021 at 7:13 PM Stephen Boyd wrote:
> > > Quoting Nicolas Saenz Julienne (2021-03-25 11:25:24)
> > > > >
> > > > > This patch mainly revealed that
On Fri, Mar 26, 2021 at 2:52 AM Sebastian Reichel
wrote:
>
> Hi Saravana,
>
> On Thu, Mar 25, 2021 at 06:55:52PM -0700, Saravana Kannan wrote:
> > On Thu, Mar 25, 2021 at 6:27 PM Rob Herring wrote:
> > >
> > > +Saravana
> > >
> > > On Th
On Thu, Mar 25, 2021 at 6:27 PM Rob Herring wrote:
>
> +Saravana
>
> On Thu, Mar 18, 2021 at 10:03:18PM +0100, Sebastian Reichel wrote:
> > On Congatec's QMX6 system on module one of the i.MX6 fixed clocks
> > is provided by an I2C RTC. Specifying this properly results in a
> > circular
On Thu, Mar 25, 2021 at 2:19 PM Stephen Boyd wrote:
>
> Quoting Saravana Kannan (2021-03-02 13:11:32)
> > This reverts commit 3e4c982f1ce75faf5314477b8da296d2d00919df.
> >
> > Since all reported issues due to fw_devlink=on should be addressed by
> > this series,
On Wed, Mar 10, 2021 at 10:21 PM Calvin Johnson
wrote:
>
> Define fwnode_mdio_find_device() to get a pointer to the
> mdio_device from fwnode passed to the function.
>
> Refactor of_mdio_find_device() to use fwnode_mdio_find_device().
>
> Signed-off-by: Calvin Johnson
> ---
>
> Changes in v7:
>
On Tue, Mar 2, 2021 at 1:11 PM Saravana Kannan wrote:
>
> There's no point in adding a device to the deferred probe list if we
> know for sure that it doesn't have a matching driver. So, check if a
> device can match with a driver before adding it to the deferred probe
> list.
On Sun, Mar 7, 2021 at 11:28 PM Marek Szyprowski
wrote:
>
> Hi Saravana,
>
> On 05.03.2021 19:02, Saravana Kannan wrote:
> > On Fri, Mar 5, 2021 at 3:45 AM Marek Szyprowski
> > wrote:
> >> On 04.03.2021 20:51, Saravana Kannan wrote:
> >>> The uevents
On Fri, Mar 5, 2021 at 3:45 AM Marek Szyprowski
wrote:
>
> Hi Saravana,
>
> On 04.03.2021 20:51, Saravana Kannan wrote:
> > The uevents generated for an amba device need PID and CID information
> > that's available only when the amba device is powered on, clocked
On Wed, Mar 3, 2021 at 2:21 AM Michael Walle wrote:
>
> Am 2021-03-03 10:28, schrieb Saravana Kannan:
> > On Wed, Mar 3, 2021 at 12:59 AM Michael Walle wrote:
> >>
> >> Am 2021-03-02 23:47, schrieb Saravana Kannan:
> >> > On Tue, Mar 2, 202
. This allows us to delete all the amba specific
deferring code and also avoid the arbitrary probing delays.
Cc: Rob Herring
Cc: Ulf Hansson
Cc: John Stultz
Cc: Saravana Kannan
Cc: Linus Walleij
Cc: Sudeep Holla
Cc: Nicolas Saenz Julienne
Cc: Geert Uytterhoeven
Cc: Marek Szyprowski
Cc: Russell
On Thu, Mar 4, 2021 at 6:12 AM Russell King - ARM Linux admin
wrote:
>
> On Wed, Mar 03, 2021 at 08:08:44PM -0800, Saravana Kannan wrote:
> > Marek,
> >
> > I tested it and saw the device get added before the resources were
> > available and the uevent file looke
On Wed, Mar 3, 2021 at 8:00 PM Saravana Kannan wrote:
>
> The uevents generated for an amba device need PID and CID information
> that's available only when the amba device is powered on, clocked and
> out of reset. So, if those resources aren't available, the information
>
On Wed, Mar 3, 2021 at 8:00 PM Saravana Kannan wrote:
>
> The uevents generated for an amba device need PID and CID information
> that's available only when the amba device is powered on, clocked and
> out of reset. So, if those resources aren't available, the information
>
. This allows us to delete all the amba specific
deferring code and also avoid the arbitrary probing delays.
Cc: Rob Herring
Cc: Ulf Hansson
Cc: John Stultz
Cc: Saravana Kannan
Cc: Linus Walleij
Cc: Sudeep Holla
Cc: Nicolas Saenz Julienne
Cc: Geert Uytterhoeven
Cc: Russell King
Signed-off
On Wed, Mar 3, 2021 at 2:03 AM Geert Uytterhoeven wrote:
>
> Hi Saravana,
>
> On Wed, Mar 3, 2021 at 10:24 AM Saravana Kannan wrote:
> > On Wed, Mar 3, 2021 at 1:22 AM Geert Uytterhoeven
> > wrote:
> > > On Tue, Mar 2, 2021 at 10:11 PM Saravana Kannan
>
Hansson
Cc: John Stultz
Cc: Saravana Kannan
Cc: Sudeep Holla
Cc: Nicolas Saenz Julienne
Cc: Geert Uytterhoeven
Cc: Russell King
Cc: Rob Herring
Signed-off-by: Saravana Kannan
---
We talked about this almost a year ago[1] and it has been nagging me all
this time. So, finally got around
On Wed, Mar 3, 2021 at 1:22 AM Geert Uytterhoeven wrote:
>
> Hi Saravana,
>
> On Tue, Mar 2, 2021 at 10:11 PM Saravana Kannan wrote:
> > This series fixes the last few remaining issues reported when fw_devlink=on
> > by default.
>
> [...]
>
> Thank
On Wed, Mar 3, 2021 at 12:32 AM Saravana Kannan wrote:
>
> The addition/probe of amba devices has its own weird deferred probe
> mechanism that needs to be maintained separately. It doesn't
> automatically get any bugs fixes or improvements to the common deferred
> probe mechani
On Wed, Mar 3, 2021 at 12:59 AM Michael Walle wrote:
>
> Am 2021-03-02 23:47, schrieb Saravana Kannan:
> > On Tue, Mar 2, 2021 at 2:42 PM Saravana Kannan
> > wrote:
> >>
> >> On Tue, Mar 2, 2021 at 2:24 PM Michael Walle wrote:
> >> >
>
On Tue, Mar 2, 2021 at 2:42 PM Saravana Kannan wrote:
>
> On Tue, Mar 2, 2021 at 2:24 PM Michael Walle wrote:
> >
> > Am 2021-03-02 22:11, schrieb Saravana Kannan:
> > > I think Patch 1 should fix [4] without [5]. Can you test the series
> > > please?
> &
On Tue, Mar 2, 2021 at 2:24 PM Michael Walle wrote:
>
> Am 2021-03-02 22:11, schrieb Saravana Kannan:
> > I think Patch 1 should fix [4] without [5]. Can you test the series
> > please?
>
> Mh, I'm on latest linux-next (next-20210302) and I've applied patch 3/3
-ba5a-a8c7-23de-2969d98c5...@nvidia.com/
Signed-off-by: Saravana Kannan
---
drivers/base/base.h | 1 +
drivers/base/core.c | 35 +++
drivers/base/dd.c | 4 +++-
3 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/drivers/base/base.h b/drivers/base
There's no point in adding a device to the deferred probe list if we
know for sure that it doesn't have a matching driver. So, check if a
device can match with a driver before adding it to the deferred probe
list.
Signed-off-by: Saravana Kannan
---
drivers/base/dd.c | 6 ++
include
This reverts commit 3e4c982f1ce75faf5314477b8da296d2d00919df.
Since all reported issues due to fw_devlink=on should be addressed by
this series, revert the revert. fw_devlink=on Take II.
Signed-off-by: Saravana Kannan
---
drivers/base/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
] - https://lore.kernel.org/lkml/20210120105246.23218-1-mich...@walle.cc/
[6] -
https://lore.kernel.org/lkml/20210217235130.1744843-1-sarava...@google.com/
Cc: Michael Walle
Cc: Jon Hunter
Cc: Marek Szyprowski
Cc: Geert Uytterhoeven
Cc: Guenter Roeck
Thanks,
Saravana
Saravana Kannan (3
On Mon, Mar 1, 2021 at 1:12 AM Bartosz Golaszewski
wrote:
>
> On Mon, Mar 1, 2021 at 10:05 AM Johan Hovold wrote:
> >
> > Here's a fix for a regression in 5.12 due to the new stub-driver hack,
> > and a fix for potential list corruption due to missing locking which has
> > been there since the
On Sat, Feb 27, 2021 at 6:27 AM Greg KH wrote:
>
> On Wed, Feb 24, 2021 at 10:20:44AM -0800, Linus Torvalds wrote:
> > On Wed, Feb 24, 2021 at 6:27 AM Greg KH wrote:
> > >
> > > [..] I've reverted that change at
> > > the very end so we don't have to worry about regressions in 5.12.
> >
> >
driver-data pointer which is used to retrieve the struct gpio_device in
> its release callback.
>
> Fix this by using container_of() in the release callback as should have
> been done all along.
>
> Fixes: 4731210c09f5 ("gpiolib: Bind gpio_device to a driver to enable
> fw_
ce, dev);
> + unsigned long flags;
>
> + spin_lock_irqsave(_lock, flags);
> list_del(>list);
> + spin_unlock_irqrestore(_lock, flags);
> +
Reviewed-by: Saravana Kannan
-Saravana
> ida_free(_ida, gdev->id);
> kfree_const(gdev->label);
> kfree(gdev->descs);
> --
> 2.26.2
>
On Mon, Feb 22, 2021 at 6:33 PM Saravana Kannan wrote:
>
> On Thu, Feb 4, 2021 at 6:07 PM Saravana Kannan wrote:
> >
> > On Thu, Feb 4, 2021 at 5:54 PM Fabio Estevam wrote:
> > >
> > > Hi Saravana,
> > >
> > > On Thu, Feb 4, 2021 at 10:39 P
On Thu, Feb 25, 2021 at 1:25 AM Geert Uytterhoeven wrote:
>
> Hi Saravana,
>
> On Mon, Feb 15, 2021 at 10:03 PM Saravana Kannan wrote:
> > On Mon, Feb 15, 2021 at 11:10 AM Geert Uytterhoeven
> > wrote:
> > > On Mon, Feb 15, 2021 at 7:37 PM Saravana Kannan
&g
On Thu, Feb 18, 2021 at 9:24 AM Saravana Kannan wrote:
>
> On Thu, Feb 18, 2021 at 9:18 AM Rafael J. Wysocki wrote:
> >
> > On Thu, Feb 18, 2021 at 12:51 AM Saravana Kannan
> > wrote:
> > >
> > > There's no point in adding a device to the def
On Tue, Feb 23, 2021 at 2:10 AM Geert Uytterhoeven wrote:
>
> Hi Saravana,
>
> On Thu, Feb 18, 2021 at 12:51 AM Saravana Kannan wrote:
> > There's no point in adding a device to the deferred probe list if we
> > know for sure that it doesn't have a matching driver. So, c
On Thu, Feb 4, 2021 at 6:07 PM Saravana Kannan wrote:
>
> On Thu, Feb 4, 2021 at 5:54 PM Fabio Estevam wrote:
> >
> > Hi Saravana,
> >
> > On Thu, Feb 4, 2021 at 10:39 PM Saravana Kannan
> > wrote:
> > >
> > > Using IRQCHI
On Thu, Feb 18, 2021 at 9:24 AM Saravana Kannan wrote:
>
> On Thu, Feb 18, 2021 at 9:18 AM Rafael J. Wysocki wrote:
> >
> > On Thu, Feb 18, 2021 at 12:51 AM Saravana Kannan
> > wrote:
> > >
> > > There's no point in adding a device to the def
On Thu, Feb 18, 2021 at 9:18 AM Rafael J. Wysocki wrote:
>
> On Thu, Feb 18, 2021 at 12:51 AM Saravana Kannan wrote:
> >
> > There's no point in adding a device to the deferred probe list if we
> > know for sure that it doesn't have a matching driver. So, check i
On Tue, Feb 16, 2021 at 12:31 PM Geert Uytterhoeven
wrote:
>
> Hi Saravana,
>
> On Tue, Feb 16, 2021 at 7:49 PM Saravana Kannan wrote:
> > On Tue, Feb 16, 2021 at 12:05 AM Geert Uytterhoeven
> > wrote:
> > > On Mon, Feb 15, 2021 at 10:27 PM Saravana Kannan
&g
There's no point in adding a device to the deferred probe list if we
know for sure that it doesn't have a matching driver. So, check if a
device can match with a driver before adding it to the deferred probe
list.
Signed-off-by: Saravana Kannan
---
Geert,
Can you give this a shot for your I2C
On Tue, Feb 16, 2021 at 7:05 PM Guenter Roeck wrote:
>
> On Tue, Feb 16, 2021 at 06:39:55PM -0800, Saravana Kannan wrote:
> > On Wed, Feb 10, 2021 at 1:21 PM Guenter Roeck wrote:
> > >
> > > On 2/10/21 12:52 PM, Saravana Kannan wrote:
> > > > On
On Wed, Feb 10, 2021 at 1:21 PM Guenter Roeck wrote:
>
> On 2/10/21 12:52 PM, Saravana Kannan wrote:
> > On Wed, Feb 10, 2021 at 7:10 AM Guenter Roeck wrote:
> >>
> >> On 2/10/21 12:20 AM, Saravana Kannan wrote:
> >>> On Tue, Feb 9, 2021 at 9:54 PM Guent
On Tue, Feb 16, 2021 at 12:20 PM Enrico Weigelt, metux IT consult
wrote:
>
> On 15.02.21 23:42, Saravana Kannan wrote:
>
> Hi,
>
> > diff --git a/drivers/of/property.c b/drivers/of/property.c
> > index 79b68519fe30..5036a362f52e 100644
> > --- a/driver
On Tue, Feb 16, 2021 at 12:05 AM Geert Uytterhoeven
wrote:
>
> Hi Saravana,
>
> On Mon, Feb 15, 2021 at 10:27 PM Saravana Kannan wrote:
> > On Mon, Feb 15, 2021 at 4:38 AM Geert Uytterhoeven
> > wrote:
> > > On Fri, Feb 12, 2021 at 4:00 AM Saravana Kannan
&g
bound. If the rmobile-reset driver is
> not available, this will never happen, and thus lead to complete system
> boot failures.
>
> Fix this by explicitly marking the fwnode initialized.
>
> Suggested-by: Saravana Kannan
> Signed-off-by: Geert Uytterhoeven
> ---
> This
On Mon, Feb 15, 2021 at 12:59 PM Saravana Kannan wrote:
>
> On Mon, Feb 15, 2021 at 11:08 AM Geert Uytterhoeven
> wrote:
> >
> > Hi Saravana,
> >
> > On Mon, Feb 15, 2021 at 7:27 PM Saravana Kannan
> > wrote:
> > > On Mon, Feb 15, 2021 at 6:59 AM
Signed-off-by: Saravana Kannan
---
Greg/Rob,
I believe this needs to land on driver-core-next.
-Saravana
drivers/of/property.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/of/property.c b/drivers/of/property.c
index 79b68519fe30..5036a362f52e 100644
--- a/drivers/of/property.c
+++
On Mon, Feb 15, 2021 at 1:09 AM Marc Zyngier wrote:
>
> Hi Saravana,
>
> On Mon, 15 Feb 2021 08:29:53 +,
> Saravana Kannan wrote:
> >
> > On Sun, Feb 14, 2021 at 7:58 PM Guenter Roeck wrote:
> > >
> > > On 2/14/21 1:12 PM, Saravana Kannan wrote:
Hi Geert,
On Mon, Feb 15, 2021 at 7:16 AM Geert Uytterhoeven wrote:
>
> Hi Saravana,
>
> On Fri, Feb 12, 2021 at 4:00 AM Saravana Kannan wrote:
> > On Thu, Feb 11, 2021 at 5:00 AM Geert Uytterhoeven
> > wrote:
> > > 1. R-Car Gen2 (Koelsch),
On Mon, Feb 15, 2021 at 4:38 AM Geert Uytterhoeven wrote:
>
> Hi Saravana,
>
> On Fri, Feb 12, 2021 at 4:00 AM Saravana Kannan wrote:
> > On Thu, Feb 11, 2021 at 5:00 AM Geert Uytterhoeven
> > wrote:
> > > - I2C on R-Car Gen3 does not seem to use DMA
On Mon, Feb 15, 2021 at 11:10 AM Geert Uytterhoeven
wrote:
>
> Hi Saravana,
>
> On Mon, Feb 15, 2021 at 7:37 PM Saravana Kannan wrote:
> > On Mon, Feb 15, 2021 at 7:14 AM Geert Uytterhoeven
> > > @@ -148,7 +149,11 @@ static int board_staging_add_dev_domain(struct
On Mon, Feb 15, 2021 at 11:08 AM Geert Uytterhoeven
wrote:
>
> Hi Saravana,
>
> On Mon, Feb 15, 2021 at 7:27 PM Saravana Kannan wrote:
> > On Mon, Feb 15, 2021 at 6:59 AM Rafael J. Wysocki wrote:
> > > On Mon, Feb 15, 2021 at 12:16 PM Geert Uytterhoeven
> >
On Mon, Feb 15, 2021 at 7:14 AM Geert Uytterhoeven
wrote:
>
> On Armadillo-800-EVA with CONFIG_DEBUG_SPINLOCK=y:
>
> BUG: spinlock bad magic on CPU#0, swapper/1
> lock: lcdc0_device+0x10c/0x308, .magic: , .owner: /-1,
> .owner_cpu: 0
> CPU: 0 PID: 1 Comm: swapper Not tainted
On Mon, Feb 15, 2021 at 6:59 AM Rafael J. Wysocki wrote:
>
> On Mon, Feb 15, 2021 at 12:16 PM Geert Uytterhoeven
> wrote:
> >
> > With fw_devlink=permissive, devices are added to the deferred probe
> > pending list if their driver's .probe() method returns -EPROBE_DEFER.
> >
> > With
On Sun, Feb 14, 2021 at 7:58 PM Guenter Roeck wrote:
>
> On 2/14/21 1:12 PM, Saravana Kannan wrote:
> [ ... ]
> >
> > Can you please give me the following details:
> > * The DTS file for the board (not the SoC).
>
> The devicetree file extracted from the r
On Fri, Feb 12, 2021 at 4:39 PM Stephen Boyd wrote:
>
> Quoting Saravana Kannan (2021-02-05 14:26:44)
> > This allows fw_devlink to recognize clock provider drivers that don't
> > use the device-driver model to initialize the device. fw_devlink will
> > use this informatio
On Sat, Feb 13, 2021 at 10:54 AM Guenter Roeck wrote:
>
> Hi,
>
> On Thu, Jan 21, 2021 at 02:57:12PM -0800, Saravana Kannan wrote:
> > This allows fw_devlink to create device links between consumers of an
> > interrupt and the supplier of the interrupt.
> >
>
On Fri, Feb 12, 2021 at 12:15 AM Geert Uytterhoeven
wrote:
>
> Hi Saravana,
>
> On Fri, Feb 12, 2021 at 4:00 AM Saravana Kannan wrote:
> > On Thu, Feb 11, 2021 at 5:00 AM Geert Uytterhoeven
> > wrote:
> > > 1. R-Car Gen2 (Koelsch),
On Thu, Feb 11, 2021 at 5:57 AM Andrew Lunn wrote:
>
> > Yeah, I plan to fix this. So I have a few more questions. In the
> > example I gave, what should happen if the gpios listed in the phy's DT
> > node aren't ready yet?
>
> There are four different use cases for GPIO.
>
> 1) The GPIO is used
On Thu, Feb 11, 2021 at 9:48 AM Rafael J. Wysocki wrote:
>
> On Thu, Feb 11, 2021 at 6:15 PM Saravana Kannan wrote:
> >
> > On Thu, Feb 11, 2021 at 7:03 AM Rafael J. Wysocki wrote:
> > >
> > > On Thu, Feb 11, 2021 at 1:02 AM Saravana Kannan
> > >
On Thu, Feb 11, 2021 at 5:00 AM Geert Uytterhoeven wrote:
>
> Hi Saravana,
>
> On Fri, Feb 5, 2021 at 11:26 PM Saravana Kannan wrote:
> > There are a lot of devices/drivers where they never have a struct device
> > created for them or the driver initializes the hardware
On Thu, Feb 11, 2021 at 7:03 AM Rafael J. Wysocki wrote:
>
> On Thu, Feb 11, 2021 at 1:02 AM Saravana Kannan wrote:
> >
> > On Thu, Jan 28, 2021 at 7:03 AM Jon Hunter wrote:
> > >
> > >
> > > On 14/01/2021 16:56, Jon Hunter wrote:
> > >
On Wed, Feb 10, 2021 at 11:31 PM Heiner Kallweit wrote:
>
> On 11.02.2021 00:29, Saravana Kannan wrote:
> > On Wed, Feb 10, 2021 at 2:52 PM Andrew Lunn wrote:
> >>
> >> On Wed, Feb 10, 2021 at 02:13:48PM -0800, Saravana Kannan wrote:
> >>> Hi,
> >
On Thu, Jan 28, 2021 at 7:03 AM Jon Hunter wrote:
>
>
> On 14/01/2021 16:56, Jon Hunter wrote:
> >
> > On 14/01/2021 16:47, Saravana Kannan wrote:
> >
> > ...
> >
> >>> Yes this is the warning shown here [0] and this is coming from
> >&
On Wed, Feb 10, 2021 at 2:52 PM Andrew Lunn wrote:
>
> On Wed, Feb 10, 2021 at 02:13:48PM -0800, Saravana Kannan wrote:
> > Hi,
> >
> > This email was triggered by this other email[1].
> >
> > Why is phy_attach_direct() directly calling device_bind_driver()
&
Hi,
This email was triggered by this other email[1].
Why is phy_attach_direct() directly calling device_bind_driver()
instead of using bus_probe_device()? I'm asking because this is
causing device links status to not get updated correctly and causes
this[2] warning.
We can fix the device links
On Wed, Feb 10, 2021 at 7:10 AM Guenter Roeck wrote:
>
> On 2/10/21 12:20 AM, Saravana Kannan wrote:
> > On Tue, Feb 9, 2021 at 9:54 PM Guenter Roeck wrote:
> >>
> >> On Thu, Dec 17, 2020 at 07:17:03PM -0800, Saravana Kannan wrote:
> >>> Cyclic depende
On Wed, Feb 10, 2021 at 12:15 PM Rob Herring wrote:
>
> On Wed, Feb 10, 2021 at 1:17 PM Saravana Kannan wrote:
> >
> > On Wed, Feb 10, 2021 at 11:06 AM Saravana Kannan
> > wrote:
> > >
> > > On Wed, Feb 10, 2021 at 10:18 AM Greg KH wrote:
> >
ue.
Fixes: 1852ebd13542 ("of: irq: make a stub for of_irq_parse_one()")
Signed-off-by: Saravana Kannan
---
This needs to go into driver-core.
-Saravana
include/linux/of_irq.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/of_irq.h b/include/
On Wed, Feb 10, 2021 at 11:06 AM Saravana Kannan wrote:
>
> On Wed, Feb 10, 2021 at 10:18 AM Greg KH wrote:
> >
> > On Wed, Feb 10, 2021 at 09:47:20PM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > After merging the driver-core tree, toda
On Wed, Feb 10, 2021 at 2:02 AM wrote:
>
> On 2/10/21 10:54 AM, Saravana Kannan wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > On Wed, Feb 10, 2021 at 12:19 AM wrote:
> >>
> >
missed to update the preferred of_clk_add_hw_provider().
> Update it now.
Thanks Tudor! Good catch!
I checked to make sure the deregistration path undoes this one. So, it
looks good to me.
Reviewed-by: Saravana Kannan
-Saravana
>
> Signed-off-by: Tudor Ambarus
> ---
> drivers/clk/clk.c | 2 ++
>
On Wed, Feb 10, 2021 at 10:18 AM Greg KH wrote:
>
> On Wed, Feb 10, 2021 at 09:47:20PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the driver-core tree, today's linux-next build (sparc64
> > defconfig) failed like this:
> >
> > drivers/of/property.o: In function
On Wed, Feb 10, 2021 at 12:51 AM Geert Uytterhoeven
wrote:
>
> Hi Saravana,
>
> On Wed, Feb 10, 2021 at 1:57 AM Saravana Kannan wrote:
> > On Tue, Feb 9, 2021 at 4:54 PM Stephen Boyd wrote:
> > > Quoting tudor.amba...@microchip.com (2021-02-08 01:49:45)
> > &
On Wed, Feb 10, 2021 at 12:19 AM wrote:
>
> Hi, Saravana,
>
> On 2/6/21 12:26 AM, Saravana Kannan wrote:
> > There are a lot of devices/drivers where they never have a struct device
> > created for them or the driver initializes the hardware without ever
> >
On Tue, Feb 9, 2021 at 9:54 PM Guenter Roeck wrote:
>
> On Thu, Dec 17, 2020 at 07:17:03PM -0800, Saravana Kannan wrote:
> > Cyclic dependencies in some firmware was one of the last remaining
> > reasons fw_devlink=on couldn't be set by default. Now that cyclic
> >
On Tue, Feb 9, 2021 at 4:54 PM Stephen Boyd wrote:
>
> Quoting tudor.amba...@microchip.com (2021-02-08 01:49:45)
> > Hi, Michael, Stephen,
> >
> > Do you plan to take this patch for v5.12?
> > If fw_devlink will remain set to ON for v5.12, some of our boards will
> > no longer boot without this
On Tue, Feb 9, 2021 at 1:33 PM Rob Herring wrote:
>
> On Fri, Feb 05, 2021 at 02:26:40PM -0800, Saravana Kannan wrote:
> > Not all DT bindings are mandatory bindings. Add support for optional DT
> > bindings and mark iommus, iommu-map, dmas as optional DT bindings.
>
>
On Tue, Feb 9, 2021 at 7:21 AM wrote:
>
> Hi, Saravana,
>
> On 2/9/21 11:11 AM, Saravana Kannan wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> > content is safe
> >
> > On Mon, Feb 8, 2021 at 11:55 PM Stephen Boyd wrot
On Mon, Feb 8, 2021 at 11:55 PM Stephen Boyd wrote:
>
> Quoting Saravana Kannan (2021-01-28 09:01:41)
> > On Thu, Jan 28, 2021 at 2:45 AM Tudor Ambarus
> > wrote:
> > >
> > > The sama5d2 requires the clock provider initialized before timers.
> > > W
1 - 100 of 1232 matches
Mail list logo
