linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Saravana Kannan <saravanak@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Marc Zyngier <maz@kernel.org>,
	Tudor Ambarus <Tudor.Ambarus@microchip.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <bgolaszewski@baylibre.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Android Kernel Team <kernel-team@android.com>
Subject: Re: [PATCH v1 0/2] Make fw_devlink=on more forgiving
Date: Mon, 1 Feb 2021 09:05:34 +0100	[thread overview]
Message-ID: <ca582e9f-bc4d-bb94-f700-1cf9dc897b57@samsung.com> (raw)
In-Reply-To: <CAGETcx941J7Zhrf=ZjO6PW0fiax5VXcV3gbsLQfM_wU_U0EnYw@mail.gmail.com>

Hi Saravana,

On 30.01.2021 05:08, Saravana Kannan wrote:
> On Fri, Jan 29, 2021 at 8:03 PM Saravana Kannan <saravanak@google.com> wrote:
>> This patch series solves two general issues with fw_devlink=on
>>
>> Patch 1/2 addresses the issue of firmware nodes that look like they'll
>> have struct devices created for them, but will never actually have
>> struct devices added for them. For example, DT nodes with a compatible
>> property that don't have devices added for them.
>>
>> Patch 2/2 address (for static kernels) the issue of optional suppliers
>> that'll never have a driver registered for them. So, if the device could
>> have probed with fw_devlink=permissive with a static kernel, this patch
>> should allow those devices to probe with a fw_devlink=on. This doesn't
>> solve it for the case where modules are enabled because there's no way
>> to tell if a driver will never be registered or it's just about to be
>> registered. I have some other ideas for that, but it'll have to come
>> later thinking about it a bit.
>>
>> These two patches might remove the need for several other patches that
>> went in as fixes for commit e590474768f1 ("driver core: Set
>> fw_devlink=on by default"), but I think all those fixes are good
>> changes. So I think we should leave those in.
>>
>> Marek, Geert,
>>
>> Can you try this series on a static kernel with your OF_POPULATED
>> changes reverted? I just want to make sure these patches can identify
>> and fix those cases.
>>
>> Tudor,
>>
>> You should still make the clock driver fix (because it's a bug), but I
>> think this series will fix your issue too (even without the clock driver
>> fix). Can you please give this a shot?
> Marek, Geert, Tudor,
>
> Forgot to say that this will probably fix your issues only in a static
> kernel. So please try this with a static kernel. If you can also try
> and confirm that this does not fix the issue for a modular kernel,
> that'd be good too.

I've checked those patches on top of linux next-20210129 with 
c09a3e6c97f0 ("soc: samsung: pm_domains: Convert to regular platform 
driver") commit reverted. Sadly it doesn't help. All devices that belong 
to the Exynos power domains are never probed and stay endlessly on the 
deferred devices list. I've used static kernel build - the one from 
exynos_defconfig.

Best regards

-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


  reply	other threads:[~2021-02-01  8:06 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-30  4:03 [PATCH v1 0/2] Make fw_devlink=on more forgiving Saravana Kannan
2021-01-30  4:03 ` [PATCH v1 1/2] driver core: fw_devlink: Detect supplier devices that will never be added Saravana Kannan
2021-02-01 14:29   ` Rafael J. Wysocki
2021-01-30  4:03 ` [PATCH v1 2/2] driver core: fw_devlink: Handle missing drivers for optional suppliers Saravana Kannan
2021-02-01 10:31   ` Geert Uytterhoeven
2021-02-01 20:48     ` Saravana Kannan
2021-02-02  8:49       ` Geert Uytterhoeven
2021-02-02 19:33         ` Saravana Kannan
2021-03-10  2:08   ` [gpiolib] 4731210c09: BUG:kernel_NULL_pointer_dereference,address kernel test robot
2021-01-30  4:08 ` [PATCH v1 0/2] Make fw_devlink=on more forgiving Saravana Kannan
2021-02-01  8:05   ` Marek Szyprowski [this message]
2021-02-01  9:02     ` Saravana Kannan
2021-02-02  8:12       ` Marek Szyprowski
2021-02-02  8:33         ` Saravana Kannan
2021-02-01 10:39   ` Geert Uytterhoeven
2021-02-02  3:00     ` Saravana Kannan
2021-02-02  7:55       ` Geert Uytterhoeven
2021-02-02  8:20         ` Saravana Kannan
2021-01-31 21:37 ` Saravana Kannan
2021-02-01 14:42 ` Marc Zyngier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ca582e9f-bc4d-bb94-f700-1cf9dc897b57@samsung.com \
    --to=m.szyprowski@samsung.com \
    --cc=Tudor.Ambarus@microchip.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-team@android.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=rafael@kernel.org \
    --cc=saravanak@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).