All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Saravana Kannan <saravanak@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	kernel-team@android.com, linux-kernel@vger.kernel.org,
	Jisheng Zhang <Jisheng.Zhang@synaptics.com>,
	Kevin Hilman <khilman@baylibre.com>,
	John Stultz <john.stultz@linaro.org>,
	Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
	Marc Zyngier <maz@kernel.org>
Subject: Re: [PATCH v1 5/5] driver core: Set fw_devlink=on by default
Date: Tue, 9 Feb 2021 21:54:30 -0800	[thread overview]
Message-ID: <20210210055430.GA73123@roeck-us.net> (raw)
In-Reply-To: <20201218031703.3053753-6-saravanak@google.com>

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
> dependencies don't block probing, set fw_devlink=on by default.
> 
> Setting fw_devlink=on by default brings a bunch of benefits (currently,
> only for systems with device tree firmware):
> * Significantly cuts down deferred probes.
> * Device probe is effectively attempted in graph order.
> * Makes it much easier to load drivers as modules without having to
>   worry about functional dependencies between modules (depmod is still
>   needed for symbol dependencies).
> 
> If this patch prevents some devices from probing, it's very likely due
> to the system having one or more device drivers that "probe"/set up a
> device (DT node with compatible property) without creating a struct
> device for it.  If we hit such cases, the device drivers need to be
> fixed so that they populate struct devices and probe them like normal
> device drivers so that the driver core is aware of the devices and their
> status. See [1] for an example of such a case.
> 
> [1] - https://lore.kernel.org/lkml/CAGETcx9PiX==mLxB9PO8Myyk6u2vhPVwTMsA5NkD-ywH5xhusw@mail.gmail.com/
> Signed-off-by: Saravana Kannan <saravanak@google.com>

This patch breaks nios2 boot tests in qemu. The system gets stuck when
trying to reboot. Reverting this patch fixes the problem. Bisect log
is attached.

It may also break a variety of other boot tests, but with 115 of 430
boot tests failing in -next it is difficult to identify all culprits.

Guenter

---
Bisect log:

# bad: [a4bfd8d46ac357c12529e4eebb6c89502b03ecc9] Add linux-next specific files for 20210209
# good: [92bf22614b21a2706f4993b278017e437f7785b3] Linux 5.11-rc7
git bisect start 'HEAD' 'v5.11-rc7'
# good: [a8eb921ba7e8e77d994a1c6c69c8ef08456ecf53] Merge remote-tracking branch 'crypto/master'
git bisect good a8eb921ba7e8e77d994a1c6c69c8ef08456ecf53
# good: [21d507c41bdf83f6afc0e02976e43c10badfc6cd] Merge remote-tracking branch 'spi/for-next'
git bisect good 21d507c41bdf83f6afc0e02976e43c10badfc6cd
# bad: [30cd4c688a3bcf324f011d7716044b1a4681efc1] Merge remote-tracking branch 'soundwire/next'
git bisect bad 30cd4c688a3bcf324f011d7716044b1a4681efc1
# good: [c43d2173d3eb4047bb62a7a393a298a1032cce18] Merge remote-tracking branch 'drivers-x86/for-next'
git bisect good c43d2173d3eb4047bb62a7a393a298a1032cce18
# bad: [4dd66c506de68a592f2dd4ef64cc9b0d7c0f3117] Merge remote-tracking branch 'usb-chipidea-next/for-usb-next'
git bisect bad 4dd66c506de68a592f2dd4ef64cc9b0d7c0f3117
# good: [29b01295a829fba7399ee84afff4e64660e49f04] usb: typec: Add typec_partner_set_pd_revision
git bisect good 29b01295a829fba7399ee84afff4e64660e49f04
# bad: [dac8ab120e531bf7c358b85750338e1b3d3ca0b9] Merge remote-tracking branch 'usb/usb-next'
git bisect bad dac8ab120e531bf7c358b85750338e1b3d3ca0b9
# good: [678481467d2e1460a49e626d8e9ba0c7e9742f53] usb: dwc3: core: Check maximum_speed SSP genXxY
git bisect good 678481467d2e1460a49e626d8e9ba0c7e9742f53
# good: [5d3d0a61479847a8729ffdda33867f6b3443c15f] Merge remote-tracking branch 'ipmi/for-next'
git bisect good 5d3d0a61479847a8729ffdda33867f6b3443c15f
# bad: [e13f5b7a130f7b6d4d34be27a87393890b5ee2ba] of: property: Add fw_devlink support for "gpio" and "gpios" binding
git bisect bad e13f5b7a130f7b6d4d34be27a87393890b5ee2ba
# good: [b0e2fa4f611bb9ab22928605d5b1c7fd44e73955] driver core: Handle cycles in device links created by fw_devlink
git bisect good b0e2fa4f611bb9ab22928605d5b1c7fd44e73955
# bad: [0fab972eef49ef8d30eb91d6bd98861122d083d1] drivers: core: Detach device from power domain on shutdown
git bisect bad 0fab972eef49ef8d30eb91d6bd98861122d083d1
# bad: [e590474768f1cc04852190b61dec692411b22e2a] driver core: Set fw_devlink=on by default
git bisect bad e590474768f1cc04852190b61dec692411b22e2a
# good: [c13b827927112ba6170bea31c638a8573c127461] driver core: fw_devlink_relax_cycle() can be static
git bisect good c13b827927112ba6170bea31c638a8573c127461
# first bad commit: [e590474768f1cc04852190b61dec692411b22e2a] driver core: Set fw_devlink=on by default

  parent reply	other threads:[~2021-02-10  5:58 UTC|newest]

Thread overview: 93+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-18  3:16 [PATCH v1 0/5] Enable fw_devlink=on by default Saravana Kannan
2020-12-18  3:16 ` [PATCH v1 1/5] driver core: Add debug logs for device link related probe deferrals Saravana Kannan
2020-12-18  3:17 ` [PATCH v1 2/5] driver core: Add device link support for INFERRED flag Saravana Kannan
2020-12-18  3:17 ` [PATCH v1 3/5] driver core: Have fw_devlink use DL_FLAG_INFERRED Saravana Kannan
2020-12-18  3:17 ` [PATCH v1 4/5] driver core: Handle cycles in device links created by fw_devlink Saravana Kannan
2020-12-18  6:39   ` kernel test robot
2020-12-18  6:39     ` kernel test robot
2020-12-18  6:39   ` [RFC PATCH] driver core: fw_devlink_relax_cycle() can be static kernel test robot
2020-12-18  6:39     ` kernel test robot
2020-12-18  6:48   ` [PATCH v1 4/5] driver core: Handle cycles in device links created by fw_devlink kernel test robot
2020-12-18  6:48     ` kernel test robot
2020-12-18  7:12   ` kernel test robot
2020-12-18  7:12     ` kernel test robot
2020-12-18  3:17 ` [PATCH v1 5/5] driver core: Set fw_devlink=on by default Saravana Kannan
     [not found]   ` <CGME20210111111245eucas1p15acde7ecc2ca7f7782beb8ed74c72022@eucas1p1.samsung.com>
2021-01-11 11:12     ` Marek Szyprowski
     [not found]       ` <CGME20210111141814eucas1p1f388df07b789693a999042b27f0d8c2a@eucas1p1.samsung.com>
2021-01-11 14:18         ` Marek Szyprowski
2021-01-11 21:47           ` Saravana Kannan
2021-01-12  7:11             ` Marek Szyprowski
2021-01-12 20:51               ` Saravana Kannan
2021-01-13  7:04                 ` Marek Szyprowski
2021-01-13 19:23                   ` Saravana Kannan
2021-01-14  7:36                     ` Marek Szyprowski
2021-01-14 18:08                       ` Saravana Kannan
2021-01-18 17:43                 ` Geert Uytterhoeven
2021-01-17 23:01   ` Michael Walle
2021-01-18 21:01     ` Saravana Kannan
2021-01-19 10:41       ` Michael Walle
2021-01-20  0:00         ` Saravana Kannan
2021-01-18 17:39   ` Geert Uytterhoeven
2021-01-18 17:59     ` Marc Zyngier
2021-01-18 19:16       ` Geert Uytterhoeven
2021-01-18 19:30         ` Marc Zyngier
2021-01-18 21:18         ` Saravana Kannan
2021-01-19  9:05           ` Geert Uytterhoeven
2021-01-19 18:08             ` Saravana Kannan
2021-01-19 21:50               ` Saravana Kannan
2021-01-20  9:40                 ` Geert Uytterhoeven
2021-01-20 14:26                   ` Geert Uytterhoeven
2021-01-20 17:22                     ` Saravana Kannan
2021-01-21 16:04                       ` Geert Uytterhoeven
2021-01-25 23:30                         ` Saravana Kannan
2021-01-26  8:25                           ` Geert Uytterhoeven
2021-01-20  9:11               ` Geert Uytterhoeven
2021-01-21  8:22   ` [TEST PATCH v1] driver: core: Make fw_devlink=on more forgiving Saravana Kannan
2021-01-21  8:27     ` Saravana Kannan
2021-01-21 10:37       ` Geert Uytterhoeven
2021-01-22  1:07         ` Saravana Kannan
2021-01-21 10:33     ` Marek Szyprowski
2021-01-25 17:05   ` [PATCH v1 5/5] driver core: Set fw_devlink=on by default Tudor.Ambarus
2021-01-25 18:16     ` Saravana Kannan
2021-01-28 10:59       ` Tudor.Ambarus
2021-01-28 17:04         ` Saravana Kannan
2021-02-10  5:54   ` Guenter Roeck [this message]
2021-02-10  8:20     ` Saravana Kannan
2021-02-10 15:10       ` Guenter Roeck
2021-02-10 20:52         ` Saravana Kannan
2021-02-10 21:21           ` Guenter Roeck
2021-02-17  2:39             ` Saravana Kannan
2021-02-17  3:05               ` Guenter Roeck
2021-02-17  3:13                 ` Saravana Kannan
2020-12-18 21:11 ` [PATCH v1 0/5] Enable " Saravana Kannan
2020-12-21  8:18 ` Jisheng Zhang
     [not found]   ` <CAHp75VfqL1QuvjCZ7p23e_2qhY3DUgVNaS--Uk1mEoEHsD8GBA@mail.gmail.com>
2021-01-14 16:49     ` Saravana Kannan
2020-12-21  9:48 ` Rafael J. Wysocki
2021-01-07 20:05 ` Greg Kroah-Hartman
2021-01-07 21:53   ` Saravana Kannan
2021-01-13 11:11   ` Marc Zyngier
2021-01-13 15:27     ` Jon Hunter
2021-01-13 21:29       ` Saravana Kannan
2021-01-14 11:34         ` Jon Hunter
2021-01-14 16:40           ` Saravana Kannan
2021-01-14 16:47             ` Jon Hunter
2021-01-14 16:52               ` Saravana Kannan
2021-01-14 18:55                 ` Jon Hunter
2021-01-14 21:50                   ` Saravana Kannan
2021-01-15 16:12                     ` Jon Hunter
2021-01-15 17:44                       ` Saravana Kannan
2021-01-13 20:56     ` Saravana Kannan
2021-01-13 11:30 ` Jon Hunter
2021-01-13 21:26   ` Saravana Kannan
2021-01-14 16:11     ` Jon Hunter
2021-01-14 16:47       ` Saravana Kannan
2021-01-14 16:56         ` Jon Hunter
2021-01-28 15:03           ` Jon Hunter
2021-01-28 17:27             ` Saravana Kannan
2021-02-11  0:02             ` Saravana Kannan
2021-02-11 15:03               ` Rafael J. Wysocki
2021-02-11 17:14                 ` Saravana Kannan
2021-02-11 17:48                   ` Rafael J. Wysocki
2021-02-12  3:04                     ` Saravana Kannan
2021-01-13 11:44 ` Nicolas Saenz Julienne
2021-01-13 11:48   ` Marc Zyngier
2021-01-13 21:27     ` Saravana Kannan

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=20210210055430.GA73123@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=Jisheng.Zhang@synaptics.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=john.stultz@linaro.org \
    --cc=kernel-team@android.com \
    --cc=khilman@baylibre.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=nsaenzjulienne@suse.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.