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
> > > wrote:
> > > >
> > > > On Thu, Jan 28, 2021 at
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
> > wrote:
> > >
> > > On Thu, Jan 28, 2021 at 7:03 AM Jon Hunter wrote:
> > > >
> > > >
> > > > On 14/01/2021 16:56, Jon
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 14/01/2021 16:47, Saravana Kannan 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 14/01/2021 16:47, Saravana Kannan wrote:
> > >
> > > ...
> > >
> > >>> Yes this is the warning shown here [0] and this is
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
> >>> the 'Generic PHY stmmac-0:00' device.
> >>
> >> Can you
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
> >>> the 'Generic PHY stmmac-0:00' device.
> >>
> >> Can you
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
>>> the 'Generic PHY stmmac-0:00' device.
>>
>> Can you print the supplier and consumer device when this warning is
>> happening
On Fri, Jan 15, 2021 at 8:13 AM Jon Hunter wrote:
>
>
> On 14/01/2021 21:50, Saravana Kannan wrote:
> > On Thu, Jan 14, 2021 at 10:55 AM Jon Hunter wrote:
> >>
> >>
> >> On 14/01/2021 16:52, Saravana Kannan wrote:
> >>
> >> ...
> >>
> >>> Thanks! I think you forgot to enable those logs though.
On 14/01/2021 21:50, Saravana Kannan wrote:
> On Thu, Jan 14, 2021 at 10:55 AM Jon Hunter wrote:
>>
>>
>> On 14/01/2021 16:52, Saravana Kannan wrote:
>>
>> ...
>>
>>> Thanks! I think you forgot to enable those logs though. Also, while
>>> you are at it, maybe enable the logs in
On Thu, Jan 14, 2021 at 10:55 AM Jon Hunter wrote:
>
>
> On 14/01/2021 16:52, Saravana Kannan wrote:
>
> ...
>
> > Thanks! I think you forgot to enable those logs though. Also, while
> > you are at it, maybe enable the logs in device_link_add() too please?
>
>
> Sorry try this one.
>
> Cheers
>
On 14/01/2021 16:47, Saravana Kannan wrote:
...
>> Yes this is the warning shown here [0] and this is coming from
>> the 'Generic PHY stmmac-0:00' device.
>
> Can you print the supplier and consumer device when this warning is
> happening and let me know? That'd help too. I'm guessing the phy
On Thu, Jan 14, 2021 at 8:48 AM Jon Hunter wrote:
>
>
> On 14/01/2021 16:40, Saravana Kannan wrote:
> > On Thu, Jan 14, 2021 at 3:35 AM Jon Hunter wrote:
> >>
> >>
> >> On 13/01/2021 21:29, Saravana Kannan wrote:
> >>
> >> ...
> >>
> I am seeing the same problem on Tegra30 Cardhu A04 where
On Wed, Jan 13, 2021 at 11:48 PM Andy Shevchenko
wrote:
>
>
>
> On Monday, December 21, 2020, Jisheng Zhang
> wrote:
>>
>> On Thu, 17 Dec 2020 19:16:58 -0800 Saravana Kannan wrote:
>>
>>
>> >
>> >
>> > As discussed in LPC 2020, cyclic dependencies in firmware that couldn't
>> > be broken using
On Thu, Jan 14, 2021 at 8:11 AM Jon Hunter wrote:
>
>
> On 13/01/2021 21:26, Saravana Kannan wrote:
> > On Wed, Jan 13, 2021 at 3:30 AM Jon Hunter wrote:
> >>
> >>
> >> On 18/12/2020 03:16, Saravana Kannan wrote:
> >>> As discussed in LPC 2020, cyclic dependencies in firmware that couldn't
> >>>
On 14/01/2021 16:40, Saravana Kannan wrote:
> On Thu, Jan 14, 2021 at 3:35 AM Jon Hunter wrote:
>>
>>
>> On 13/01/2021 21:29, Saravana Kannan wrote:
>>
>> ...
>>
I am seeing the same problem on Tegra30 Cardhu A04 where several regulators
are continuously deferred and prevents the board
On Thu, Jan 14, 2021 at 3:35 AM Jon Hunter wrote:
>
>
> On 13/01/2021 21:29, Saravana Kannan wrote:
>
> ...
>
> >> I am seeing the same problem on Tegra30 Cardhu A04 where several regulators
> >> are continuously deferred and prevents the board from booting ...
> >>
> >> [2.518334] platform
On 13/01/2021 21:26, Saravana Kannan wrote:
> On Wed, Jan 13, 2021 at 3:30 AM Jon Hunter wrote:
>>
>>
>> On 18/12/2020 03:16, Saravana Kannan wrote:
>>> As discussed in LPC 2020, cyclic dependencies in firmware that couldn't
>>> be broken using logic was one of the last remaining reasons
>>>
On 13/01/2021 21:29, Saravana Kannan wrote:
...
>> I am seeing the same problem on Tegra30 Cardhu A04 where several regulators
>> are continuously deferred and prevents the board from booting ...
>>
>> [2.518334] platform panel: probe deferral - supplier regulator@11 not
>> ready
>>
>> [
On Wed, Jan 13, 2021 at 3:48 AM Marc Zyngier wrote:
>
> On 2021-01-13 11:44, Nicolas Saenz Julienne wrote:
> > On Thu, 2020-12-17 at 19:16 -0800, Saravana Kannan wrote:
> >> As discussed in LPC 2020, cyclic dependencies in firmware that
> >> couldn't
> >> be broken using logic was one of the last
On Wed, Jan 13, 2021 at 3:30 AM Jon Hunter wrote:
>
>
> On 18/12/2020 03:16, Saravana Kannan wrote:
> > As discussed in LPC 2020, cyclic dependencies in firmware that couldn't
> > be broken using logic was one of the last remaining reasons
> > fw_devlink=on couldn't be set by default.
> >
> >
On Wed, Jan 13, 2021 at 7:27 AM Jon Hunter wrote:
>
>
> On 13/01/2021 11:11, Marc Zyngier wrote:
> > On 2021-01-07 20:05, Greg Kroah-Hartman wrote:
> >> On Thu, Dec 17, 2020 at 07:16:58PM -0800, Saravana Kannan wrote:
> >>> As discussed in LPC 2020, cyclic dependencies in firmware that couldn't
>
On Wed, Jan 13, 2021 at 3:11 AM Marc Zyngier wrote:
>
> On 2021-01-07 20:05, Greg Kroah-Hartman wrote:
> > On Thu, Dec 17, 2020 at 07:16:58PM -0800, Saravana Kannan wrote:
> >> As discussed in LPC 2020, cyclic dependencies in firmware that
> >> couldn't
> >> be broken using logic was one of the
On 13/01/2021 11:11, Marc Zyngier wrote:
> On 2021-01-07 20:05, Greg Kroah-Hartman wrote:
>> On Thu, Dec 17, 2020 at 07:16:58PM -0800, Saravana Kannan wrote:
>>> As discussed in LPC 2020, cyclic dependencies in firmware that couldn't
>>> be broken using logic was one of the last remaining
On 2021-01-13 11:44, Nicolas Saenz Julienne wrote:
On Thu, 2020-12-17 at 19:16 -0800, Saravana Kannan wrote:
As discussed in LPC 2020, cyclic dependencies in firmware that
couldn't
be broken using logic was one of the last remaining reasons
fw_devlink=on couldn't be set by default.
This
On Thu, 2020-12-17 at 19:16 -0800, Saravana Kannan wrote:
> As discussed in LPC 2020, cyclic dependencies in firmware that couldn't
> be broken using logic was one of the last remaining reasons
> fw_devlink=on couldn't be set by default.
>
> This series changes fw_devlink so that when a cyclic
On 18/12/2020 03:16, Saravana Kannan wrote:
> As discussed in LPC 2020, cyclic dependencies in firmware that couldn't
> be broken using logic was one of the last remaining reasons
> fw_devlink=on couldn't be set by default.
>
> This series changes fw_devlink so that when a cyclic dependency is
On 2021-01-07 20:05, Greg Kroah-Hartman wrote:
On Thu, Dec 17, 2020 at 07:16:58PM -0800, Saravana Kannan wrote:
As discussed in LPC 2020, cyclic dependencies in firmware that
couldn't
be broken using logic was one of the last remaining reasons
fw_devlink=on couldn't be set by default.
This
On Thu, Jan 7, 2021 at 12:04 PM Greg Kroah-Hartman
wrote:
>
> On Thu, Dec 17, 2020 at 07:16:58PM -0800, Saravana Kannan wrote:
> > As discussed in LPC 2020, cyclic dependencies in firmware that couldn't
> > be broken using logic was one of the last remaining reasons
> > fw_devlink=on couldn't be
On Thu, Dec 17, 2020 at 07:16:58PM -0800, Saravana Kannan wrote:
> As discussed in LPC 2020, cyclic dependencies in firmware that couldn't
> be broken using logic was one of the last remaining reasons
> fw_devlink=on couldn't be set by default.
>
> This series changes fw_devlink so that when a
On Fri, Dec 18, 2020 at 4:17 AM Saravana Kannan wrote:
>
> As discussed in LPC 2020, cyclic dependencies in firmware that couldn't
> be broken using logic was one of the last remaining reasons
> fw_devlink=on couldn't be set by default.
>
> This series changes fw_devlink so that when a cyclic
On Thu, 17 Dec 2020 19:16:58 -0800 Saravana Kannan wrote:
>
>
> As discussed in LPC 2020, cyclic dependencies in firmware that couldn't
> be broken using logic was one of the last remaining reasons
> fw_devlink=on couldn't be set by default.
>
> This series changes fw_devlink so that when a
On Thu, Dec 17, 2020 at 7:17 PM Saravana Kannan wrote:
>
> As discussed in LPC 2020, cyclic dependencies in firmware that couldn't
> be broken using logic was one of the last remaining reasons
> fw_devlink=on couldn't be set by default.
>
> This series changes fw_devlink so that when a cyclic
As discussed in LPC 2020, cyclic dependencies in firmware that couldn't
be broken using logic was one of the last remaining reasons
fw_devlink=on couldn't be set by default.
This series changes fw_devlink so that when a cyclic dependency is found
in firmware, the links between those devices
33 matches
Mail list logo
