[PATCH v2 00/11] fw_devlink improvements

[Maxim Kiselev]

пт, 3 февр. 2023 г. в 09:07, Saravana Kannan <saravanak at google.com>:
>
> On Thu, Feb 2, 2023 at 9:36 AM Maxim Kiselev <bigunclemax at gmail.com> wrote:
> >
> > Hi Saravana,
> >
> > > Can you try the patch at the end of this email under these
> > > configurations and tell me which ones fail vs pass? I don't need logs
> >
> > I did these tests and here is the results:
>
> Did you hand edit the In-Reply-To: in the header? Because in the
> thread you are reply to the wrong email, but the context in your email
> seems to be from the right email.
>
> For example, see how your reply isn't under the email you are replying
> to in this thread overview:
> https://lore.kernel.org/lkml/20230127001141.407071-1-saravanak@google.com/#r
>
> > 1. On top of this series - Not works
> > 2. Without this series    - Works
> > 3. On top of the series with the fwnode_dev_initialized() deleted - Not works
> > 4. Without this series, with the fwnode_dev_initialized() deleted  - Works
> >
> > So your nvmem/core.c patch helps only when it is applied without the series.
> > But despite the fact that this helps to avoid getting stuck at probing
> > my ethernet device, there is still regression.
> >
> > When the ethernet module is loaded it takes a lot of time to drop dependency
> > from the nvmem-cell with mac address.
> >
> > Please look at the kernel logs below.
>
> The kernel logs below really aren't that useful for me in their
> current state. See more below.
>
> ---8<---- <snip> --->8----
>
> > P.S. Your nvmem patch definitely helps to avoid a device probe stuck
> > but look like it is not best way to solve a problem which we discussed
> > in the MTD thread.
> >
> > P.P.S. Also I don't know why your nvmem-cell patch doesn't help when it was
> > applied on top of this series. Maybe I missed something.
>
> Yeah, I'm not too sure if the test was done correctly. You also didn't
> answer my question about the dts from my earlier email.
> https://lore.kernel.org/lkml/CAGETcx8FpmbaRm2CCwqt3BRBpgbogwP5gNB+iA5OEtuxWVTNLA@mail.gmail.com/#t
>
> So, can you please retest config 1 with all pr_debug and dev_dbg in
> drivers/core/base.c changed to the _info variants? And then share the
> kernel log from the beginning of boot? Maybe attach it to the email so
> it doesn't get word wrapped by your email client. And please point me
> to the .dts that corresponds to your board. Without that, I can't
> debug much.
>
> Thanks,
> Saravana

> Did you hand edit the In-Reply-To: in the header? Because in the
> thread you are reply to the wrong email, but the context in your email
> seems to be from the right email.

Sorry for that, it seems like I accidently deleted it.

> So, can you please retest config 1 with all pr_debug and dev_dbg in
> drivers/core/base.c changed to the _info variants? And then share the
> kernel log from the beginning of boot? Maybe attach it to the email so
> it doesn't get word wrapped by your email client. And please point me
> to the .dts that corresponds to your board. Without that, I can't
> debug much.

Ok, I retested config 1 with all _debug logs changed to the _info. I
added the kernel log and the dts file to the attachment of this email.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_kern.log
Type: text/x-log
Size: 22393 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20230203/dc69d8fd/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.dts
Type: audio/vnd.dts
Size: 7897 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20230203/dc69d8fd/attachment-0001.dts>